Topic: Template Argument Deduction for call to a base
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Wed, 14 Nov 2018 13:20:33 -0800 (PST)
Raw View
------=_Part_250_750585525.1542230433438
Content-Type: multipart/alternative;
boundary="----=_Part_251_347560823.1542230433438"
------=_Part_251_347560823.1542230433438
Content-Type: text/plain; charset="UTF-8"
On Wednesday, November 14, 2018 at 2:32:42 PM UTC-6, mihailn...@gmail.com
wrote:
>
> This case is not considered in p1021
> <http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1021r1.html>.
> Any reason what this might be? An omission, a technical issue?
> Because sooner or later people will wonder why it works in one context and
> not in other.
>
Those are pretty different things, despite having the same syntax. In the
mem-initializer list, we already know what the thing we're constructing is
- it would very strange if at that point we stopped and redid overload
resolution to re-figure out what it is we're already in the process of
constructing. What if it happens to give you a different answer?
You can already directly use A<T> there, access the injected-class-name via
B::A.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/36736629-55ad-4f98-94c7-87c36bbd2ad7%40isocpp.org.
------=_Part_251_347560823.1542230433438
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, November 14, 2018 at 2:32:42 PM UTC-=
6, mihailn...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><div>This case is not considered in=C2=A0<a href=3D"http:/=
/www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1021r1.html" target=3D"_=
blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.c=
om/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpap=
ers%2F2018%2Fp1021r1.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFopxX6pIM=
-NbX154UGTcwSerAhUA';return true;" onclick=3D"this.href=3D'http://w=
ww.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2=
Fdocs%2Fpapers%2F2018%2Fp1021r1.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQj=
CNFopxX6pIM-NbX154UGTcwSerAhUA';return true;">p1021</a>. Any reason wha=
t this might be? An omission, a technical issue?<br></div><div>Because soon=
er or later people will wonder why it works in one context and not in other=
..</div></div></blockquote><div>=C2=A0</div><div>Those are pretty different =
things, despite having the same syntax. In the mem-initializer list, we alr=
eady know what the thing we're constructing is - it would very strange =
if at that point we stopped and redid overload resolution to re-figure out =
what it is we're already in the process of constructing. What if it hap=
pens to give you a different answer?=C2=A0</div><div><br></div><div>You can=
already directly use A<T> there, access the injected-class-name via =
B::A.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/36736629-55ad-4f98-94c7-87c36bbd2ad7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/36736629-55ad-4f98-94c7-87c36bbd2ad7=
%40isocpp.org</a>.<br />
------=_Part_251_347560823.1542230433438--
------=_Part_250_750585525.1542230433438--
.
Author: mihailnajdenov@gmail.com
Date: Thu, 15 Nov 2018 09:46:33 -0800 (PST)
Raw View
------=_Part_850_1844855474.1542303993534
Content-Type: multipart/alternative;
boundary="----=_Part_851_672898386.1542303993534"
------=_Part_851_672898386.1542303993534
Content-Type: text/plain; charset="UTF-8"
On Wednesday, November 14, 2018 at 11:20:33 PM UTC+2, Barry Revzin wrote:
>
>
>
> On Wednesday, November 14, 2018 at 2:32:42 PM UTC-6, mihailn...@gmail.com
> wrote:
>>
>> This case is not considered in p1021
>> <http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1021r1.html>.
>> Any reason what this might be? An omission, a technical issue?
>> Because sooner or later people will wonder why it works in one context
>> and not in other.
>>
>
> Those are pretty different things, despite having the same syntax. In the
> mem-initializer list, we already know what the thing we're constructing is
> - it would very strange if at that point we stopped and redid overload
> resolution to re-figure out what it is we're already in the process of
> constructing. What if it happens to give you a different answer?
>
> You can already directly use A<T> there, access the injected-class-name
> via B::A.
>
Yeah, they are different but both are a construction call and this
situation will rise stackoverflow questions for sure.
Is there a problem to resolve to B::A, if it wold fail otherwise? This will
make calls consistent with the expectations, though behind the scenes the
technicalities might be different.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e33edec4-d037-4b80-b0f7-c7e73f9321ec%40isocpp.org.
------=_Part_851_672898386.1542303993534
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, November 14, 2018 at 11:20:33 PM UTC=
+2, Barry Revzin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><br><br>On Wednesday, November 14, 2018 at 2:32:42 PM UTC-6, <a>m=
ihailn...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><div>This case is not considered in=C2=A0<a href=3D"http://www.=
open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1021r1.html" rel=3D"nofollow"=
target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/ur=
l?q\x3dhttp%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2=
F2018%2Fp1021r1.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFopxX6pIM-NbX1=
54UGTcwSerAhUA';return true;" onclick=3D"this.href=3D'http://www.go=
ogle.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs=
%2Fpapers%2F2018%2Fp1021r1.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFop=
xX6pIM-NbX154UGTcwSerAhUA';return true;">p1021</a>. Any reason what thi=
s might be? An omission, a technical issue?<br></div><div>Because sooner or=
later people will wonder why it works in one context and not in other.</di=
v></div></blockquote><div>=C2=A0</div><div>Those are pretty different thing=
s, despite having the same syntax. In the mem-initializer list, we already =
know what the thing we're constructing is - it would very strange if at=
that point we stopped and redid overload resolution to re-figure out what =
it is we're already in the process of constructing. What if it happens =
to give you a different answer?=C2=A0</div><div><br></div><div>You can alre=
ady directly use A<T> there, access the injected-class-name via B::A.=
</div></div></blockquote><div><br></div><div>Yeah, they are different but b=
oth are a construction call and this situation will rise stackoverflow ques=
tions for sure.=C2=A0</div><div><br></div><div>Is there a problem to resolv=
e to B::A, if it wold fail otherwise? This will make calls consistent with =
the expectations, though behind the scenes the technicalities might be diff=
erent.</div><div>=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e33edec4-d037-4b80-b0f7-c7e73f9321ec%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e33edec4-d037-4b80-b0f7-c7e73f9321ec=
%40isocpp.org</a>.<br />
------=_Part_851_672898386.1542303993534--
------=_Part_850_1844855474.1542303993534--
.