--001a1141e2562eb31905244a4ef4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11 November 2015 at 15:02, Bryce Glover <randomdsdevel@gmail.com> wrote:

>      Given the attached examples of the frequency with which people seem
> to be creating workarounds for the fact that C++ does not currently suppo=
rt
> templatized virtual member functions, should the committee reconsider its
> collective decision to prohibit that construct?  I believe that the reaso=
n
> that the feature was rejected in the first place was because it would be
> overly troublesome to implement, especially from a linker designer=E2=80=
=99s point
> of view, but is that still the case now?
>

As we like to say on the committee, people want unicorns. :-)

If someone wants this feature, it is likely they will have to describe an
implementation strategy that works with compilers, linkers, shared
libraries, etc.

So, how would you go and implement this? :-)

--=20
 Nevin ":-)" Liber  <mailto:nevin@cplusplusguy.com <nevin@eviloverlord.com>=
>
+1-847-691-1404

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a1141e2562eb31905244a4ef4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 11 November 2015 at 15:02, Bryce Glover <span dir=3D"lt=
r">&lt;<a href=3D"mailto:randomdsdevel@gmail.com" target=3D"_blank">randomd=
sdevel@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap=
:break-word"><div>=C2=A0 =C2=A0 =C2=A0Given the attached examples of the fr=
equency with which people seem to be creating workarounds for the fact that=
 C++ does not currently support templatized virtual member functions, shoul=
d the committee reconsider its collective decision to prohibit that constru=
ct?=C2=A0 I believe that the reason that the feature was rejected in the fi=
rst place was because it would be overly troublesome to implement, especial=
ly from a linker designer=E2=80=99s point of view, but is that still the ca=
se now? =C2=A0</div></div></blockquote><div><br></div><div>As we like to sa=
y on the committee, people want unicorns. :-)</div><div><br></div><div>If s=
omeone wants this feature, it is likely they will have to describe an imple=
mentation strategy that works with compilers, linkers, shared libraries, et=
c.</div><div><br></div><div>So, how would you go and implement this? :-)<br=
 clear=3D"all"><div><br></div>-- <br><div class=3D"gmail_signature"><div di=
r=3D"ltr">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mai=
lto:nevin@eviloverlord.com" target=3D"_blank">nevin@cplusplusguy.com</a>&gt=
;=C2=A0 +1-847-691-1404<br></div></div>
</div></div></div>
</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1141e2562eb31905244a4ef4--

.

On 11 November 2015 at 23:02, Bryce Glover <randomdsdevel@gmail.com> wrote:
>      Given the attached examples of the frequency with which people seem =
to
> be creating workarounds for the fact that C++ does not currently support
> templatized virtual member functions, should the committee reconsider its
> collective decision to prohibit that construct?

No. Not based on that, no.

>I believe that the reason
> that the feature was rejected in the first place was because it would be
> overly troublesome to implement, especially from a linker designer=E2=80=
=99s point
> of view, but is that still the case now?

Yes.

Your move. :)

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

Bryce Glover <randomdsdevel@gmail.com> writes:

> Given the attached examples of the frequency with which people seem to
> be creating workarounds for the fact that C++ does not currently
> support templatized virtual member functions, should the committee
> reconsider its collective decision to prohibit that construct?  I
> believe that the reason that the feature was rejected in the first
> place was because it would be overly troublesome to implement,
> especially from a linker designer=E2=80=99s point of view, but is that st=
ill
> the case now?

Apart from the question how difficult it would be to implement such a
feature, I think we should also consider how "teachable" it would be.
Personally, I don't know what a `virtual template` should be.  I think
one of the strengths of C++ is that it is usually straight-forward to
gauge the cost of using or not using a specific feature.  Not paying for
what you don't use is great but it's only useful if you have a sense of
price.  I'm afraid that `virtual template`s -- if they could be made
work at all -- would add a lot confusion.  Something similar has already
happened with `std::function` (which is a *great* feature, by the way)
and it is being mis-used all over the place, incurring costs users have
difficulties to control.

I'm not saying that such a feature couldn't be useful but I'd only want
it if we could reasonably assume that people understand it and its cost.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_1071_1706015471.1447280800122
Content-Type: multipart/alternative;
 boundary="----=_Part_1072_407000980.1447280800122"

------=_Part_1072_407000980.1447280800122
Content-Type: text/plain; charset=UTF-8

Or we could just have language support for mixins
<https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/HjGujSdKXX0>,
with the template base class calling whatever interface the derived class
provides.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1072_407000980.1447280800122
Content-Type: text/html; charset=UTF-8

<div dir="ltr">Or we could just have <a href="https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/HjGujSdKXX0">language support for mixins</a>, with the template base class calling whatever interface the derived class provides.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_1072_407000980.1447280800122--
------=_Part_1071_1706015471.1447280800122--

.

------=_Part_6050_467017349.1447329132422
Content-Type: multipart/alternative;
 boundary="----=_Part_6051_1085959622.1447329132423"

------=_Part_6051_1085959622.1447329132423
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le mercredi 11 novembre 2015 22:14:03 UTC+1, Nevin Liber a =C3=A9crit :
>
> On 11 November 2015 at 15:02, Bryce Glover <random...@gmail.com=20
> <javascript:>> wrote:
>
>>      Given the attached examples of the frequency with which people seem=
=20
>> to be creating workarounds for the fact that C++ does not currently supp=
ort=20
>> templatized virtual member functions, should the committee reconsider it=
s=20
>> collective decision to prohibit that construct?  I believe that the reas=
on=20
>> that the feature was rejected in the first place was because it would be=
=20
>> overly troublesome to implement, especially from a linker designer=E2=80=
=99s point=20
>> of view, but is that still the case now? =20
>>
>
> As we like to say on the committee, people want unicorns. :-)
>

I don't think they want unicorns here.  But I do think that the internal=20
model of template they are using when asking for that is not the one of=20
C++.  It would be possible and not too troublesome to specify and implement=
=20
a notion of type parameter for virtual functions (think about type=20
erasure), but the result would be too far from C++ templates to be called=
=20
virtual template member functions. =20

If someone wants this feature, it is likely they will have to describe an=
=20
> implementation strategy that works with compilers, linkers, shared=20
> libraries, etc.
>
=20
A second kind of type parameterization.  We could name it generic to make=
=20
the difference from templates and not increase the confusion. (I'm *not* pr=
oposing=20
that, I don't think the use cases warrant the complexity).

Something which has all the feature of templates?  Before asking for a way=
=20
to implement it, I'd like to see the specification saying how things like=
=20
explicit specialization interfere with virtualness. Eh... no, I don't want=
=20
to see it. ;-)

Yours,

--=20
Jean-Marc

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_6051_1085959622.1447329132423
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le mercredi 11 novembre 2015 22:14:03 UTC+1, Nevin Liber a =C3=A9crit=C2=A0=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On 11 Novemb=
er 2015 at 15:02, Bryce Glover <span dir=3D"ltr">&lt;<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"yMIrAxdHFwAJ" rel=3D"nofollow"=
 onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"=
this.href=3D&#39;javascript:&#39;;return true;">random...@gmail.com</a>&gt;=
</span> wrote:<br><div><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div style=3D"word-wrap:break-word"><div>=C2=A0 =C2=A0 =C2=A0Given th=
e attached examples of the frequency with which people seem to be creating =
workarounds for the fact that C++ does not currently support templatized vi=
rtual member functions, should the committee reconsider its collective deci=
sion to prohibit that construct?=C2=A0 I believe that the reason that the f=
eature was rejected in the first place was because it would be overly troub=
lesome to implement, especially from a linker designer=E2=80=99s point of v=
iew, but is that still the case now? =C2=A0</div></div></blockquote><div><b=
r></div><div>As we like to say on the committee, people want unicorns. :-)<=
/div></div></div></div></blockquote><div><br></div><div>I don&#39;t think t=
hey want unicorns here. =C2=A0But I do think that the internal model of tem=
plate they are using when asking for that is not the one of C++. =C2=A0It w=
ould be possible and not too troublesome to specify and implement a notion =
of type parameter for virtual functions (think about type erasure), but the=
 result would be too far from C++ templates to be called virtual template m=
ember functions. =C2=A0</div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>If some=
one wants this feature, it is likely they will have to describe an implemen=
tation strategy that works with compilers, linkers, shared libraries, etc.<=
/div></div></div></div></blockquote><div>=C2=A0</div><div>A second kind of =
type parameterization. =C2=A0We could name it generic to make the differenc=
e from templates and not increase the confusion. (I&#39;m <b>not</b>=C2=A0p=
roposing that, I don&#39;t think the use cases warrant the complexity).</di=
v><div><br></div><div>Something which has all the feature of templates? =C2=
=A0Before asking for a way to implement it, I&#39;d like to see the specifi=
cation saying how things like explicit specialization interfere with virtua=
lness. Eh... no, I don&#39;t want to see it. ;-)<br></div><div><br></div><d=
iv>Yours,</div><div><br></div><div>--=C2=A0</div><div>Jean-Marc</div><div><=
br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_6051_1085959622.1447329132423--
------=_Part_6050_467017349.1447329132422--

.