------=_Part_478_1724797509.1475817519774
Content-Type: multipart/alternative;
 boundary="----=_Part_479_718600449.1475817519775"

------=_Part_479_718600449.1475817519775
Content-Type: text/plain; charset=UTF-8

P0119 outlined a way to get overload sets as a functor. This proposal seems
to be progressing forward towards C++20, but will apparently go back to the
[]funcname syntax, as stated in this trip report from Oulu
<https://botondballo.wordpress.com/2016/07/06/trip-report-c-standards-meeting-in-oulu-june-2016/>
..

That's all to the good. But it seems reasonable to expand on the power of
this lifting. Specifically, it should be expanded to constructors.

That is, `[]TypeName` should result in a functor that returns by value a
`TypeName` object, which shall be constructed in accord with guaranteed
elision. So basically this:

[]TypeName

//becomes

[](auto &&...args) {return TypeName(std::forward<decltype(args)>(args)...);}

Of course, `[]TypeName` should be able to work with class constructor
template deduction if `TypeName` is a class template. So you should be able
to do `[]shared_ptr`, then call it with an appropriate `T*` to get a
`shared_ptr<T>`.

--
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/15063d27-1048-411d-b5d6-d9d75e86a08b%40isocpp.org.

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

<div dir=3D"ltr">P0119 outlined a way to get overload sets as a functor. Th=
is proposal seems to be progressing forward towards C++20, but will apparen=
tly go back to the []funcname syntax, <a href=3D"https://botondballo.wordpr=
ess.com/2016/07/06/trip-report-c-standards-meeting-in-oulu-june-2016/">as s=
tated in this trip report from Oulu</a>.<br><br>That&#39;s all to the good.=
 But it seems reasonable to expand on the power of this lifting. Specifical=
ly, it should be expanded to constructors.<br><br>That is, `[]TypeName` sho=
uld result in a functor that returns by value a `TypeName` object, which sh=
all be constructed in accord with guaranteed elision. So basically this:<br=
><br><div style=3D"background-color: rgb(250, 250, 250); border-color: rgb(=
187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: brea=
k-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"su=
bprettyprint"><span style=3D"color: #660;" class=3D"styled-by-prettify">[]<=
/span><span style=3D"color: #606;" class=3D"styled-by-prettify">TypeName</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></spa=
n><span style=3D"color: #800;" class=3D"styled-by-prettify">//becomes</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">[](</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">&amp;&amp;...</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">args</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">TypeNam=
e</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">forward</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">decltype</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">args</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">)&gt;(</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify">args</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">)...);}</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span></div></code></div><br>Of course, `[]TypeName` should be ab=
le to work with class constructor template deduction if `TypeName` is a cla=
ss template. So you should be able to do `[]shared_ptr`, then call it with =
an appropriate `T*` to get a `shared_ptr&lt;T&gt;`.<br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/15063d27-1048-411d-b5d6-d9d75e86a08b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/15063d27-1048-411d-b5d6-d9d75e86a08b=
%40isocpp.org</a>.<br />

------=_Part_479_718600449.1475817519775--

------=_Part_478_1724797509.1475817519774--

.

------=_Part_3000_1275429750.1475856363883
Content-Type: multipart/alternative;
 boundary="----=_Part_3001_2117306292.1475856363883"

------=_Part_3001_2117306292.1475856363883
Content-Type: text/plain; charset=UTF-8

On Thursday, October 6, 2016 at 10:18:40 PM UTC-7, Nicol Bolas wrote:
>
> P0119 outlined a way to get overload sets as a functor. This proposal
> seems to be progressing forward towards C++20, but will apparently go back
> to the []funcname syntax, as stated in this trip report from Oulu
> <https://botondballo.wordpress.com/2016/07/06/trip-report-c-standards-meeting-in-oulu-june-2016/>
> .
>
> That's all to the good. But it seems reasonable to expand on the power of
> this lifting. Specifically, it should be expanded to constructors.
>
> That is, `[]TypeName` should result in a functor that returns by value a
> `TypeName` object, which shall be constructed in accord with guaranteed
> elision. So basically this:
>

Love it.

Worth it to make sure at the standardization level, but would the
combination of P0119 and cast operators (P0119 states that operates should
be liftable) result in this behavior implicitly?

--
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/d4c232a8-098c-4331-a148-380e60227627%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, October 6, 2016 at 10:18:40 PM UTC-7, Nicol B=
olas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">P0=
119 outlined a way to get overload sets as a functor. This proposal seems t=
o be progressing forward towards C++20, but will apparently go back to the =
[]funcname syntax, <a href=3D"https://botondballo.wordpress.com/2016/07/06/=
trip-report-c-standards-meeting-in-oulu-june-2016/" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\=
x3dhttps%3A%2F%2Fbotondballo.wordpress.com%2F2016%2F07%2F06%2Ftrip-report-c=
-standards-meeting-in-oulu-june-2016%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dA=
FQjCNGZNd3tY9x3aqywaL5EIRVeu4eZlA&#39;;return true;" onclick=3D"this.href=
=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fbotondballo.wordpress=
..com%2F2016%2F07%2F06%2Ftrip-report-c-standards-meeting-in-oulu-june-2016%2=
F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGZNd3tY9x3aqywaL5EIRVeu4eZlA&#39;=
;return true;">as stated in this trip report from Oulu</a>.<br><br>That&#39=
;s all to the good. But it seems reasonable to expand on the power of this =
lifting. Specifically, it should be expanded to constructors.<br><br>That i=
s, `[]TypeName` should result in a functor that returns by value a `TypeNam=
e` object, which shall be constructed in accord with guaranteed elision. So=
 basically this:<br></div></blockquote><div><br></div><div>Love it.</div><d=
iv><br></div><div>Worth it to make sure at the standardization level, but w=
ould the combination of P0119 and cast operators (P0119 states that operate=
s should be liftable) result in this behavior implicitly?</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d4c232a8-098c-4331-a148-380e60227627%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d4c232a8-098c-4331-a148-380e60227627=
%40isocpp.org</a>.<br />

------=_Part_3001_2117306292.1475856363883--

------=_Part_3000_1275429750.1475856363883--

.

------=_Part_2447_1394516567.1475872112698
Content-Type: multipart/alternative;
 boundary="----=_Part_2448_83813516.1475872112698"

------=_Part_2448_83813516.1475872112698
Content-Type: text/plain; charset=UTF-8

On Friday, October 7, 2016 at 12:06:04 PM UTC-4, Sean Middleditch wrote:
>
> On Thursday, October 6, 2016 at 10:18:40 PM UTC-7, Nicol Bolas wrote:
>>
>> P0119 outlined a way to get overload sets as a functor. This proposal
>> seems to be progressing forward towards C++20, but will apparently go back
>> to the []funcname syntax, as stated in this trip report from Oulu
>> <https://botondballo.wordpress.com/2016/07/06/trip-report-c-standards-meeting-in-oulu-june-2016/>
>> .
>>
>> That's all to the good. But it seems reasonable to expand on the power of
>> this lifting. Specifically, it should be expanded to constructors.
>>
>> That is, `[]TypeName` should result in a functor that returns by value a
>> `TypeName` object, which shall be constructed in accord with guaranteed
>> elision. So basically this:
>>
>
> Love it.
>
> Worth it to make sure at the standardization level, but would the
> combination of P0119 and cast operators (P0119 states that operates should
> be liftable) result in this behavior implicitly?
>

Well, the wording from the most recent P0119 revision doesn't show how cast
operators could be lifted. It also explicitly excludes `operator new` and
`operator delete`. So it's not clear how the current proposal would allow
lifting casting operators.

Also, wouldn't cast operators only be able to convert a single value to a
different value? So they wouldn't be able to call any constructor, just
single-argument ones. But in any case, I don't think casting permits
template deduction for classes, which is kinda important.

--
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/9425809b-1377-4791-ba4e-211b6890e7a7%40isocpp.org.

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

<div dir=3D"ltr">On Friday, October 7, 2016 at 12:06:04 PM UTC-4, Sean Midd=
leditch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>On Thursday, October 6, 2016 at 10:18:40 PM UTC-7, Nicol Bolas wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">P0119 outlined a way to=
 get overload sets as a functor. This proposal seems to be progressing forw=
ard towards C++20, but will apparently go back to the []funcname syntax, <a=
 href=3D"https://botondballo.wordpress.com/2016/07/06/trip-report-c-standar=
ds-meeting-in-oulu-june-2016/" rel=3D"nofollow" target=3D"_blank" onmousedo=
wn=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fbotond=
ballo.wordpress.com%2F2016%2F07%2F06%2Ftrip-report-c-standards-meeting-in-o=
ulu-june-2016%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGZNd3tY9x3aqywaL5E=
IRVeu4eZlA&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.googl=
e.com/url?q\x3dhttps%3A%2F%2Fbotondballo.wordpress.com%2F2016%2F07%2F06%2Ft=
rip-report-c-standards-meeting-in-oulu-june-2016%2F\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNGZNd3tY9x3aqywaL5EIRVeu4eZlA&#39;;return true;">as stated =
in this trip report from Oulu</a>.<br><br>That&#39;s all to the good. But i=
t seems reasonable to expand on the power of this lifting. Specifically, it=
 should be expanded to constructors.<br><br>That is, `[]TypeName` should re=
sult in a functor that returns by value a `TypeName` object, which shall be=
 constructed in accord with guaranteed elision. So basically this:<br></div=
></blockquote><div><br></div><div>Love it.</div><div><br></div><div>Worth i=
t to make sure at the standardization level, but would the combination of P=
0119 and cast operators (P0119 states that operates should be liftable) res=
ult in this behavior implicitly?</div></div></blockquote><div><br>Well, the=
 wording from the most recent P0119 revision doesn&#39;t show how cast oper=
ators could be lifted. It also explicitly excludes `operator new` and `oper=
ator delete`. So it&#39;s not clear how the current proposal would allow li=
fting casting operators.<br><br>Also, wouldn&#39;t cast operators only be a=
ble to convert a single value to a different value? So they wouldn&#39;t be=
 able to call any constructor, just single-argument ones. But in any case, =
I don&#39;t think casting permits template deduction for classes, which is =
kinda important.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9425809b-1377-4791-ba4e-211b6890e7a7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9425809b-1377-4791-ba4e-211b6890e7a7=
%40isocpp.org</a>.<br />

------=_Part_2448_83813516.1475872112698--

------=_Part_2447_1394516567.1475872112698--

.

--001a11441afc56771d053e4ce6a9
Content-Type: text/plain; charset=UTF-8

On Fri, Oct 7, 2016 at 1:28 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> Well, the wording from the most recent P0119 revision doesn't show how
> cast operators could be lifted. It also explicitly excludes `operator new`
> and `operator delete`. So it's not clear how the current proposal would
> allow lifting casting operators.
>

Hmm, yeah, on closer reading it is a bit lacking in that regard. As written
now I think you'd have to spell it something like `[]operator my_type`
rather than the preferable `[]my_type`.


>
> Also, wouldn't cast operators only be able to convert a single value to a
> different value?
>

Explicit function-like casts support arbitrary arity. Class template
deduction is written in those terms. At least all according to cppreference
anyway. :)

http://en.cppreference.com/w/cpp/language/explicit_cast

http://en.cppreference.com/w/cpp/language/class_template_deduction

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/GuEbjptqq84/unsubscribe.
> To unsubscribe from this group and all its topics, 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/9425809b-1377-4791-
> ba4e-211b6890e7a7%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9425809b-1377-4791-ba4e-211b6890e7a7%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>



--
Sean Middleditch
http://seanmiddleditch.com

--
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/CALQmNFgqjanjWNQh%2B7rKb8-54Pg4b_nJrfOAJ4j7GcKRpxRXAw%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Oct 7, 2016 at 1:28 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D=
"ltr"><div>Well, the wording from the most recent P0119 revision doesn&#39;=
t show how cast operators could be lifted. It also explicitly excludes `ope=
rator new` and `operator delete`. So it&#39;s not clear how the current pro=
posal would allow lifting casting operators.<br></div></div></blockquote><d=
iv><br></div><div>Hmm, yeah, on closer reading it is a bit lacking in that =
regard. As written now I think you&#39;d have to spell it something like `[=
]operator my_type` rather than the preferable `[]my_type`.</div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><d=
iv><br>Also, wouldn&#39;t cast operators only be able to convert a single v=
alue to a different value?</div></div></blockquote><div><br></div><div>Expl=
icit function-like casts support arbitrary arity. Class template deduction =
is written in those terms. At least all according to cppreference anyway. :=
)</div><div><br></div><div><a href=3D"http://en.cppreference.com/w/cpp/lang=
uage/explicit_cast">http://en.cppreference.com/w/cpp/language/explicit_cast=
</a><br></div><div><br></div><div><a href=3D"http://en.cppreference.com/w/c=
pp/language/class_template_deduction">http://en.cppreference.com/w/cpp/lang=
uage/class_template_deduction</a><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex"><span class=3D"gmail-HOEnZb"><font color=3D"#888888">

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/GuEbjptqq84/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/G=
uEbjptqq84/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/9425809b-1377-4791-ba4e-211b6890e7a7%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/9425=
809b-1377-4791-<wbr>ba4e-211b6890e7a7%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r><div class=3D"gmail_signature">Sean Middleditch<br><a href=3D"http://sean=
middleditch.com" target=3D"_blank">http://seanmiddleditch.com</a></div>
</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALQmNFgqjanjWNQh%2B7rKb8-54Pg4b_nJrf=
OAJ4j7GcKRpxRXAw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALQmNFgqjanjWN=
Qh%2B7rKb8-54Pg4b_nJrfOAJ4j7GcKRpxRXAw%40mail.gmail.com</a>.<br />

--001a11441afc56771d053e4ce6a9--

.

------=_Part_375_1163732050.1475879767823
Content-Type: multipart/alternative;
 boundary="----=_Part_376_46141834.1475879767823"

------=_Part_376_46141834.1475879767823
Content-Type: text/plain; charset=UTF-8


>
>
> That is, `[]TypeName` should result in a functor that returns by value a
> `TypeName` object, which shall be constructed in accord with guaranteed
> elision. So basically this:
>
>
The []id notation exists because in the case of non-overloaded names (or at
least, names we think are non-overloaded when we use them outside the
context of a function call), passing id to a function template already has
a meaning and we want to change it.

But for type names, we don't have that restriction. Passing a type name is
already meaningless. So why not go one step further and think of type names
themselves as object factories, when used in such a context? That is:

struct X {
    X();
    X(int );
};

auto a = std::invoke(X);    // equivalent to X a{};
auto b = std::invoke(X, 4); // equivalent to X b{4};

Don't really need the [] introducer to disambiguate.

--
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/c360935c-c145-4d0a-beb6-20a82118316b%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><br>That is, `[]TypeName` should result in a functor that returns by va=
lue a `TypeName` object, which shall be constructed in accord with guarante=
ed elision. So basically this:<br><br></div></blockquote><div><br></div><di=
v>The <font face=3D"courier new, monospace">[]id</font> notation exists bec=
ause in the case of non-overloaded names (or at least, names we think are n=
on-overloaded when we use them outside the context of a function call), pas=
sing <font face=3D"courier new, monospace">id </font>to a function template=
 already has a meaning and we want to change it.=C2=A0</div><div><br></div>=
<div>But for type names, we don&#39;t have that restriction. Passing a type=
 name is already meaningless. So why not go one step further and think of t=
ype names themselves as object factories, when used in such a context? That=
 is:</div><div><br></div><div><div class=3D"prettyprint" style=3D"backgroun=
d-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style=
: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettypr=
int"><div class=3D"subprettyprint"><font color=3D"#660066"><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> X </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 X</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 X</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> a </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">invoke</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">X</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
=C2=A0 =C2=A0</span><span style=3D"color: #800;" class=3D"styled-by-prettif=
y">// equivalent to X a{};</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> b </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">invoke</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">X</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by=
-prettify">4</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #800;" class=3D"styled-by-prettify">// equivalent t=
o X b{4};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span></font></div></code></div><div><br></div>Don&#39;t really need th=
e [] introducer to disambiguate.=C2=A0<br><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c360935c-c145-4d0a-beb6-20a82118316b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c360935c-c145-4d0a-beb6-20a82118316b=
%40isocpp.org</a>.<br />

------=_Part_376_46141834.1475879767823--

------=_Part_375_1163732050.1475879767823--

.

--001a1135409259a8a2053e4e7106
Content-Type: text/plain; charset=UTF-8

On Fri, Oct 7, 2016 at 3:36 PM, Barry Revzin <barry.revzin@gmail.com> wrote:
>
> Don't really need the [] introducer to disambiguate.
>

While I can appreciate eliding unnecessary cruft, I personally feel that
consistency matters here _far_ more than avoiding two characters. I'd much
rather have a predictable syntax for lifting anything than needing separate
syntaxes for lifting constructors or overload sets and a different syntax
for lifting functions and operators.

This is important for template uses and code generation tools, if nothing
else.
--
Sean Middleditch
http://seanmiddleditch.com

--
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/CALQmNFiigKWoRJxiPzuH0D2Dja_Ji6U1_FQDt%2B_K7c1%2B%3DCHikA%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Oct 7, 2016 at 3:36 PM, Barry Revzin <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:barry.revzin@gmail.com" target=3D"_blank">barry.revzin@gmail.com</a>&=
gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Don&#=
39;t really need the [] introducer to disambiguate.=C2=A0<br></div></div></=
blockquote><div><br></div><div>While I can appreciate eliding unnecessary c=
ruft, I personally feel that consistency matters here _far_ more than avoid=
ing two characters. I&#39;d much rather have a predictable syntax for lifti=
ng anything than needing separate syntaxes for lifting constructors or over=
load sets and a different syntax for lifting functions and operators.</div>=
<div><br></div><div>This is important for template uses and code generation=
 tools, if nothing else.</div></div>-- <br><div class=3D"gmail_signature" d=
ata-smartmail=3D"gmail_signature">Sean Middleditch<br><a href=3D"http://sea=
nmiddleditch.com" target=3D"_blank">http://seanmiddleditch.com</a></div>
</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALQmNFiigKWoRJxiPzuH0D2Dja_Ji6U1_FQD=
t%2B_K7c1%2B%3DCHikA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALQmNFiigK=
WoRJxiPzuH0D2Dja_Ji6U1_FQDt%2B_K7c1%2B%3DCHikA%40mail.gmail.com</a>.<br />

--001a1135409259a8a2053e4e7106--

.