------=_Part_200_1181537328.1460542430847
Content-Type: multipart/alternative;
 boundary="----=_Part_201_1868749313.1460542430848"

------=_Part_201_1868749313.1460542430848
Content-Type: text/plain; charset=UTF-8

On Wednesday, April 13, 2016 at 9:33:28 AM UTC+1, TONGARI J wrote:
>
> Hi,
>
> The draft can be viewed at:
> http://jamboree.github.io/designator-draft.html
>
> The prototype based on Clang can be found at:
> https://github.com/jamboree/clang/tree/feature/designator
>
>
> I'm not sure if it's proper to submit a new proposal before C++17 is
> settled, anyway, I'd like to make this work public now.
>
>
Not much to say. Seems a pretty good proposal. I like the syntax for
opting-in on named function arguments.

-- gpd



>
>
> Thanks
>

--
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/5c5ebfb8-bfc1-4526-8b8a-752aa3f64a77%40isocpp.org.

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

<div dir=3D"ltr">On Wednesday, April 13, 2016 at 9:33:28 AM UTC+1, TONGARI =
J 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"><div>=
Hi,</div><div><br></div><div>The draft can be viewed at:</div><a href=3D"ht=
tp://jamboree.github.io/designator-draft.html" target=3D"_blank" rel=3D"nof=
ollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3=
A%2F%2Fjamboree.github.io%2Fdesignator-draft.html\46sa\75D\46sntz\0751\46us=
g\75AFQjCNHpl7fvspzlrc1ynxvCJgWnuF4yzA&#39;;return true;" onclick=3D"this.h=
ref=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fjamboree.github.io%2F=
designator-draft.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHpl7fvspzlrc1ynxvC=
JgWnuF4yzA&#39;;return true;">http://jamboree.github.io/<wbr>designator-dra=
ft.html</a><br><div><br></div><div>The prototype based on Clang can be foun=
d at:</div><div><a href=3D"https://github.com/jamboree/clang/tree/feature/d=
esignator" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fjamboree%2Fcla=
ng%2Ftree%2Ffeature%2Fdesignator\46sa\75D\46sntz\0751\46usg\75AFQjCNGa_hHsO=
QOQjduH5UvFz5148ItL2g&#39;;return true;" onclick=3D"this.href=3D&#39;https:=
//www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fjamboree%2Fclang%2Ftree=
%2Ffeature%2Fdesignator\46sa\75D\46sntz\0751\46usg\75AFQjCNGa_hHsOQOQjduH5U=
vFz5148ItL2g&#39;;return true;">https://github.com/jamboree/<wbr>clang/tree=
/feature/designator</a><br></div><div><br></div><div><br></div><div>I&#39;m=
 not sure if it&#39;s proper to submit a new proposal before C++17 is settl=
ed, anyway, I&#39;d like to make this work public now.</div><div><br></div>=
</div></blockquote><div><br>Not much to say. Seems a pretty good proposal. =
I like the syntax for opting-in on named function arguments.<br><br>-- gpd<=
br><br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div></div><div><br></div><div><br></div><div>Thanks</div></div></blo=
ckquote></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/5c5ebfb8-bfc1-4526-8b8a-752aa3f64a77%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5c5ebfb8-bfc1-4526-8b8a-752aa3f64a77=
%40isocpp.org</a>.<br />

------=_Part_201_1868749313.1460542430848--
------=_Part_200_1181537328.1460542430847--

.

------=_Part_253_1841071418.1460543349363
Content-Type: multipart/alternative;
 boundary="----=_Part_254_1208314943.1460543349363"

------=_Part_254_1208314943.1460543349363
Content-Type: text/plain; charset=UTF-8

As a some practical example, qemu is a large project written in C and it
uses designated initializers all over the place (they are irreplaceable for
large aggregates).
If you try to compile qemu code as C++, then designated initializers is
probably the largest reason preventing it from compiling.
I'm not talking that qemu is ever going to be converted to C++, but
designated initializers (even in their simplest form `{ .field = value }`)
can be helpful for migrating other C libraries into C++.

--
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/07f79d12-b072-49c3-81f7-1a3b27809510%40isocpp.org.

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

<div dir=3D"ltr"><div>As a some practical example, qemu is a large project =
written in C and it uses designated initializers all over the place (they a=
re irreplaceable for large aggregates).</div><div>If you try to compile qem=
u code as C++, then designated initializers is probably the largest reason =
preventing it from compiling.</div><div>I&#39;m not talking that qemu is ev=
er going to be converted to C++, but designated initializers (even in their=
 simplest form `{ .field =3D value }`) can be helpful for migrating other C=
 libraries into C++.</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/07f79d12-b072-49c3-81f7-1a3b27809510%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/07f79d12-b072-49c3-81f7-1a3b27809510=
%40isocpp.org</a>.<br />

------=_Part_254_1208314943.1460543349363--
------=_Part_253_1841071418.1460543349363--

.

On 2016-04-13 11:33, TONGARI J wrote:
> Hi,
>
> The draft can be viewed at:
> http://jamboree.github.io/designator-draft.html
>
> The prototype based on Clang can be found at:
> https://github.com/jamboree/clang/tree/feature/designator
>
>
> I'm not sure if it's proper to submit a new proposal before C++17 is
> settled, anyway, I'd like to make this work public now.
> Please let me know if anyone wants to be a champion if it's submitted.

In a few places in the proposal document, you state that
copy-initialization is used with designated initializers. This is not so
with normal initializers or positional function arguments and depends on
whether the initialized member/argument is a reference. Is this
difference intentional? If yes, then what's the rationale for it (as it
doesn't look reasonable to me)?

--
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/72f36085-ebd3-f485-4c27-cf9d73883e04%40gmail.com.

.

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

2016-04-13 18:54 GMT+08:00 Andrey Semashev <andrey.semashev@gmail.com>:

> On 2016-04-13 11:33, TONGARI J wrote:
>
>> Hi,
>>
>> The draft can be viewed at:
>> http://jamboree.github.io/designator-draft.html
>>
>> The prototype based on Clang can be found at:
>> https://github.com/jamboree/clang/tree/feature/designator
>>
>>
>> I'm not sure if it's proper to submit a new proposal before C++17 is
>> settled, anyway, I'd like to make this work public now.
>> Please let me know if anyone wants to be a champion if it's submitted.
>>
>
> In a few places in the proposal document, you state that
> copy-initialization is used with designated initializers. This is not so
> with normal initializers or positional function arguments and depends on
> whether the initialized member/argument is a reference. Is this difference
> intentional? If yes, then > what's the rationale for it (as it doesn't look
> reasonable to me)?
>
>
>
In the "Design decisions" section?
It's not intentional, I'll try to improve the wording...

--
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/CANCwVhd02bieqqrz6i%2Be8E1HwKKQqOjjxRRsTm7xE66y9CvvdQ%40mail.gmail.com.

--001a114fa4c2658c6c05305cfd93
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">2016=
-04-13 18:54 GMT+08:00 Andrey Semashev <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semashev@gmail.com<=
/a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border=
-left-style:solid;padding-left:1ex"><span class=3D"">On 2016-04-13 11:33, T=
ONGARI J wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
Hi,<br>
<br>
The draft can be viewed at:<br>
<a href=3D"http://jamboree.github.io/designator-draft.html" rel=3D"noreferr=
er" target=3D"_blank">http://jamboree.github.io/designator-draft.html</a><b=
r>
<br>
The prototype based on Clang can be found at:<br>
<a href=3D"https://github.com/jamboree/clang/tree/feature/designator" rel=
=3D"noreferrer" target=3D"_blank">https://github.com/jamboree/clang/tree/fe=
ature/designator</a><br>
<br>
<br>
I&#39;m not sure if it&#39;s proper to submit a new proposal before C++17 i=
s<br>
settled, anyway, I&#39;d like to make this work public now.<br>
Please let me know if anyone wants to be a champion if it&#39;s submitted.<=
br>
</blockquote>
<br></span>
In a few places in the proposal document, you state that copy-initializatio=
n is used with designated initializers. This is not so with normal initiali=
zers or positional function arguments and depends on whether the initialize=
d member/argument is a reference. Is this difference intentional? If yes, t=
hen=C2=A0&gt; what&#39;s the rationale for it (as it doesn&#39;t look reaso=
nable to me)?<br><br><br></blockquote><div>=C2=A0</div><div>In the &quot;De=
sign decisions&quot; section?</div><div>It&#39;s not intentional, I&#39;ll =
try to improve the wording...</div></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/CANCwVhd02bieqqrz6i%2Be8E1HwKKQqOjjxR=
RsTm7xE66y9CvvdQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANCwVhd02bieqq=
rz6i%2Be8E1HwKKQqOjjxRRsTm7xE66y9CvvdQ%40mail.gmail.com</a>.<br />

--001a114fa4c2658c6c05305cfd93--

.

------=_Part_5594_1171278670.1460570342900
Content-Type: multipart/alternative;
 boundary="----=_Part_5595_825653191.1460570342900"

------=_Part_5595_825653191.1460570342900
Content-Type: text/plain; charset=UTF-8

2.3 can be solved by much smaller change in standard.
Do you consider allowing such syntax:

obj.f(default, b)


--
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/b9692187-ba5d-42eb-b07c-e98e07d0878e%40isocpp.org.

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

<div dir=3D"ltr">2.3 can be solved by much smaller change in standard.<br>D=
o you consider allowing such syntax:<br><pre class=3D"prettyprint"><code cl=
ass=3D"language-c++ hljs d">obj.f(<span class=3D"hljs-comment">default</spa=
n>, b)</code></pre><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/b9692187-ba5d-42eb-b07c-e98e07d0878e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b9692187-ba5d-42eb-b07c-e98e07d0878e=
%40isocpp.org</a>.<br />

------=_Part_5595_825653191.1460570342900--
------=_Part_5594_1171278670.1460570342900--

.

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

This looks more or less like how I'd always imagined designated
initializers would work in C++. Thanks for writing this! One question, you
say:

"3.2.1.1 Function redeclaration

If a function is declared with designatable parameters and/or default
arguments, it cannot be redeclared with designatable parameters and/or
default arguments, otherwise, the program is ill-formed."

This seems very strange to me. I would expect that:
a) every declaration of the same function must specify the same
designatable parameters, with the same names, and
b) perhaps overloading on designated parameter names should be permitted

One example of why (b) would be useful:

struct my_complex {
  my_complex(double .rho, double .theta);
  my_complex(double .real, double .imag);
};

Here, these constructors could *only* be called with designated parameter
names, because any non-designated call would be ambiguous.

On Wed, Apr 13, 2016 at 1:33 AM, TONGARI J <tongari95@gmail.com> wrote:

> Hi,
>
> The draft can be viewed at:
> http://jamboree.github.io/designator-draft.html
>
> The prototype based on Clang can be found at:
> https://github.com/jamboree/clang/tree/feature/designator
>
>
> I'm not sure if it's proper to submit a new proposal before C++17 is
> settled, anyway, I'd like to make this work public now.
> Please let me know if anyone wants to be a champion if it's submitted.
>
>
> Thanks
>
> --
> 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/e2d5660e-2cf7-4107-868d-7027bdce344f%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e2d5660e-2cf7-4107-868d-7027bdce344f%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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/CAOfiQqm6csXjnPy69xt6p0E365JYL92UPns5cHBebckP-7Sdaw%40mail.gmail.com.

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

<div dir=3D"ltr">This looks more or less like how I&#39;d always imagined d=
esignated initializers would work in C++. Thanks for writing this! One ques=
tion, you say:<div><br></div><div><div>&quot;3.2.1.1 Function redeclaration=
</div><div><br></div><div>If a function is declared with designatable param=
eters and/or default arguments, it cannot be redeclared with designatable p=
arameters and/or default arguments, otherwise, the program is ill-formed.&q=
uot;</div><div><br></div></div><div>This seems very strange to me. I would =
expect that:</div><div>a) every declaration of the same function must speci=
fy the same designatable parameters, with the same names, and</div><div>b) =
perhaps overloading on designated parameter names should be permitted</div>=
<div><br></div><div>One example of why (b) would be useful:</div><div><br><=
/div><div>struct my_complex {</div><div>=C2=A0 my_complex(double .rho, doub=
le .theta);</div><div>=C2=A0 my_complex(double .real, double .imag);</div><=
div>};</div><div><br></div><div>Here, these constructors could *only* be ca=
lled with designated parameter names, because any non-designated call would=
 be ambiguous.</div></div><div class=3D"gmail_extra"><br><div class=3D"gmai=
l_quote">On Wed, Apr 13, 2016 at 1:33 AM, TONGARI J <span dir=3D"ltr">&lt;<=
a href=3D"mailto:tongari95@gmail.com" target=3D"_blank">tongari95@gmail.com=
</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><=
div>Hi,</div><div><br></div><div>The draft can be viewed at:</div><a href=
=3D"http://jamboree.github.io/designator-draft.html" target=3D"_blank">http=
://jamboree.github.io/designator-draft.html</a><br><div><br></div><div>The =
prototype based on Clang can be found at:</div><div><a href=3D"https://gith=
ub.com/jamboree/clang/tree/feature/designator" target=3D"_blank">https://gi=
thub.com/jamboree/clang/tree/feature/designator</a><br></div><div><br></div=
><div><br></div><div>I&#39;m not sure if it&#39;s proper to submit a new pr=
oposal before C++17 is settled, anyway, I&#39;d like to make this work publ=
ic now.</div><div>Please let me know if anyone wants to be a champion if it=
&#39;s=C2=A0submitted.</div><div><br></div><div><br></div><div>Thanks</div>=
</div><span class=3D"HOEnZb"><font color=3D"#888888">

<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" target=3D"_=
blank">std-proposals+unsubscribe@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/e2d5660e-2cf7-4107-868d-7027bdce344f%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e2d5660e-2cf7-=
4107-868d-7027bdce344f%40isocpp.org</a>.<br>
</font></span></blockquote></div><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/CAOfiQqm6csXjnPy69xt6p0E365JYL92UPns5=
cHBebckP-7Sdaw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqm6csXjnPy6=
9xt6p0E365JYL92UPns5cHBebckP-7Sdaw%40mail.gmail.com</a>.<br />

--bcaec501620d5f7671053062d284--

.

On 13 April 2016 at 22:31, Richard Smith <richard@metafoo.co.uk> wrote:
> This looks more or less like how I'd always imagined designated initializers
> would work in C++. Thanks for writing this! One question, you say:
>
> "3.2.1.1 Function redeclaration
>
> If a function is declared with designatable parameters and/or default
> arguments, it cannot be redeclared with designatable parameters and/or
> default arguments, otherwise, the program is ill-formed."
>
> This seems very strange to me. I would expect that:
> a) every declaration of the same function must specify the same designatable
> parameters, with the same names, and
> b) perhaps overloading on designated parameter names should be permitted
>
> One example of why (b) would be useful:
>
> struct my_complex {
>   my_complex(double .rho, double .theta);
>   my_complex(double .real, double .imag);
> };
>
> Here, these constructors could *only* be called with designated parameter
> names, because any non-designated call would be ambiguous.


Just out of curiosity, how do you plan to mangle those names? The
reason why I ask is that
sure, yeah, such overloading could be handy, but it also introduces
additional complexity
to deal with.

--
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/CAFk2RUZbCGMJZRvWSoVdWCzDuoJUORex6972UdPPt29Yx6s_Jg%40mail.gmail.com.

.

--089e0158b3064831490530631067
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 13, 2016 at 12:33 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 13 April 2016 at 22:31, Richard Smith <richard@metafoo.co.uk> wrote:
> > This looks more or less like how I'd always imagined designated
> initializers
> > would work in C++. Thanks for writing this! One question, you say:
> >
> > "3.2.1.1 Function redeclaration
> >
> > If a function is declared with designatable parameters and/or default
> > arguments, it cannot be redeclared with designatable parameters and/or
> > default arguments, otherwise, the program is ill-formed."
> >
> > This seems very strange to me. I would expect that:
> > a) every declaration of the same function must specify the same
> designatable
> > parameters, with the same names, and
> > b) perhaps overloading on designated parameter names should be permitted
> >
> > One example of why (b) would be useful:
> >
> > struct my_complex {
> >   my_complex(double .rho, double .theta);
> >   my_complex(double .real, double .imag);
> > };
> >
> > Here, these constructors could *only* be called with designated parameter
> > names, because any non-designated call would be ambiguous.
>
> Just out of curiosity, how do you plan to mangle those names?


As a modifier immediately preceding or following the mangled type of the
parameter. (And for what it's worth, I think it'd also be useful for the
name to be part of the function type, with a standard conversion to remove
the parameter names, but I'm not necessarily convinced the added complexity
is worth it.)

The
> reason why I ask is that
> sure, yeah, such overloading could be handy, but it also introduces
> additional complexity
> to deal with.


I agree, but I don't think this mangling aspect is a big deal. The original
proposal introduces more significant mangling complexities regardless of
whether we allow overloading -- in a function template signature,
decltype(f(.a=T())) and decltype(f(T())) must mangle differently if T is a
dependent type, for instance.

If we go ahead with this proposal but don't allow overloading, I expect
people to fake it:

struct my_complex {
private:
  struct polar_tag {};
  struct cartesian_tag {};
public:
  my_complex(double .rho, double .theta, polar_tag = {});
  my_complex(double .real, double .imag, cartesian_tag = {});
};

--
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/CAOfiQqmOyWz6VsAvJ%2BxxS2RADnfYuWgZkE-uF26m1wTnP_QMSQ%40mail.gmail.com.

--089e0158b3064831490530631067
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 W=
ed, Apr 13, 2016 at 12:33 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilain=
en@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(=
204,204,204);border-left-style:solid;padding-left:1ex"><span class=3D"">On =
13 April 2016 at 22:31, Richard Smith &lt;<a href=3D"mailto:richard@metafoo=
..co.uk">richard@metafoo.co.uk</a>&gt; wrote:<br>
&gt; This looks more or less like how I&#39;d always imagined designated in=
itializers<br>
&gt; would work in C++. Thanks for writing this! One question, you say:<br>
&gt;<br>
&gt; &quot;3.2.1.1 Function redeclaration<br>
&gt;<br>
&gt; If a function is declared with designatable parameters and/or default<=
br>
&gt; arguments, it cannot be redeclared with designatable parameters and/or=
<br>
&gt; default arguments, otherwise, the program is ill-formed.&quot;<br>
&gt;<br>
&gt; This seems very strange to me. I would expect that:<br>
&gt; a) every declaration of the same function must specify the same design=
atable<br>
&gt; parameters, with the same names, and<br>
&gt; b) perhaps overloading on designated parameter names should be permitt=
ed<br>
&gt;<br>
&gt; One example of why (b) would be useful:<br>
&gt;<br>
&gt; struct my_complex {<br>
&gt;=C2=A0 =C2=A0my_complex(double .rho, double .theta);<br>
&gt;=C2=A0 =C2=A0my_complex(double .real, double .imag);<br>
&gt; };<br>
&gt;<br>
&gt; Here, these constructors could *only* be called with designated parame=
ter<br>
&gt; names, because any non-designated call would be ambiguous.<br><br>
</span>Just out of curiosity, how do you plan to mangle those names?</block=
quote><div><br></div><div>As a modifier immediately preceding or following =
the mangled type of the parameter. (And for what it&#39;s worth, I think it=
&#39;d also be useful for the name to be part of the function type, with a =
standard conversion to remove the parameter names, but I&#39;m not necessar=
ily convinced the added complexity is worth it.)</div><div><br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex">The<br>
reason why I ask is that<br>
sure, yeah, such overloading could be handy, but it also introduces<br>
additional complexity<br>
to deal with.</blockquote><div><br></div><div>I agree, but I don&#39;t thin=
k this mangling aspect is a big deal. The original proposal introduces more=
 significant mangling complexities regardless of whether we allow overloadi=
ng -- in a function template signature, decltype(f(.a=3DT())) and decltype(=
f(T())) must mangle differently if T is a dependent type, for instance.</di=
v><div><br></div><div>If we go ahead with this proposal but don&#39;t allow=
 overloading, I expect people to fake it:</div><div><br></div><div><span st=
yle=3D"font-size:12.8px">struct my_complex {</span></div><div><span style=
=3D"font-size:12.8px">private:</span></div><div><span style=3D"font-size:12=
..8px">=C2=A0 struct polar_tag {};</span></div><div><span style=3D"font-size=
:12.8px">=C2=A0 struct cartesian_tag {};</span></div><div><span style=3D"fo=
nt-size:12.8px">public:</span></div><div style=3D"font-size:12.8px">=C2=A0 =
my_complex(double .rho, double .theta, polar_tag =3D {});</div><div style=
=3D"font-size:12.8px">=C2=A0 my_complex(double .real, double .imag, cartesi=
an_tag =3D {});</div><div style=3D"font-size:12.8px">};</div></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/CAOfiQqmOyWz6VsAvJ%2BxxS2RADnfYuWgZkE=
-uF26m1wTnP_QMSQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqmOyWz6Vs=
AvJ%2BxxS2RADnfYuWgZkE-uF26m1wTnP_QMSQ%40mail.gmail.com</a>.<br />

--089e0158b3064831490530631067--

.

On 13 April 2016 at 22:48, Richard Smith <richard@metafoo.co.uk> wrote:
>> The
>> reason why I ask is that
>> sure, yeah, such overloading could be handy, but it also introduces
>> additional complexity
>> to deal with.
> I agree, but I don't think this mangling aspect is a big deal. The original
> proposal introduces more significant mangling complexities regardless of
> whether we allow overloading -- in a function template signature,
> decltype(f(.a=T())) and decltype(f(T())) must mangle differently if T is a
> dependent type, for instance.

Well, I don't think it's the biggest hurdle either. A much bigger
hurdle is having this proposal
survive five minutes after its presentation, because the previous ones
dropped dead in about that time.
Let me draw you a paraphrased caricature of what usually happens when
named arguments are proposed:

1) a "both sides must opt in" proposal comes in. The response is "this
doesn't help anyone in the near future, and makes
function declarations more complex, for questionable benefit. Either
use stronger and different types, or a parameter
type that has named setters, or <insert various work-around
suggestions here>..."

2) a "works automatically" proposal comes in. The response is "well,
that doesn't work with the standard library,
and authors of other libraries don't want to have the introduced
requirement to provide stable names without their opt-in,
so <insert the work-arounds again>..."

3) in either case, the complexity and its ratio to the apparent
benefit get strongly questioned.

Yeah, sure, this proposal doesn't look half bad. But I have no
illusions that it would somehow magically avoid all of the
opposing arguments that all previous proposals for named arguments have faced.

> If we go ahead with this proposal but don't allow overloading, I expect
> people to fake it:
>
> struct my_complex {
> private:
>   struct polar_tag {};
>   struct cartesian_tag {};
> public:
>   my_complex(double .rho, double .theta, polar_tag = {});
>   my_complex(double .real, double .imag, cartesian_tag = {});
> };

For some values of "people", maybe. But introducing such new kind of
overloading will probably meet resistance,
and be fuel for questioning the cost/benefit ratio.

--
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/CAFk2RUbocHoNgadLm1xMCkCyt_31A9sWYOowCeVNxv0Mbop1kw%40mail.gmail.com.

.

On 2016-04-13 16:10, Ville Voutilainen wrote:
> A much bigger hurdle is having this proposal survive five minutes
> after its presentation, because the previous ones dropped dead in
> about that time.
>
> 1) a "both sides must opt in" proposal comes in. The response is
> "this doesn't help anyone in the near future, and makes function
> declarations more complex, for questionable benefit.

Would it be the end of the world to make the following be synonymous?

  int square(int .x);
  int square([[named("x")]] int);
  int square([[named("x")]] int not_x);

I realize that attributes with meaning aren't loved, but the advantage
this has is addressing the 'not useful *now*' complaint, by making it
possible to write code (without using macros) that can be compiled with
a C++11 compiler that still provides named arguments when used with a
newer compiler. It also addresses the standard library to some extent,
as it permits adding named arguments to the API while still allowing the
implementation to use whatever it wants for names.

Note that this would however preclude encoding the argument names into
the ABI.

--
Matthew

--
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/nembdl%24frg%241%40ger.gmane.org.

.

--047d7bdc15ba0ce3170530640b94
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 13, 2016 at 1:33 AM, TONGARI J <tongari95@gmail.com> wrote:

> Hi,
>
> The draft can be viewed at:
> http://jamboree.github.io/designator-draft.html
>
> The prototype based on Clang can be found at:
> https://github.com/jamboree/clang/tree/feature/designator
>

Have you considered the interaction of this proposal with forwarding
functions and with types like std::function? I would find it problematic if
correct forwarding is not possible for functions with designated
parameters. I think you will encounter resistance if something like this is
not possible, and we have no known path forward to support it:

  void f(int .foo, int .bar);
  std::function<void(int .foo, int .bar)> fn = f;
  fn(.bar = 1, .foo = 2);

One possible way to make this work could be:
 (a) designated parameter names to become part of a function type, and
 (b) add a way to write a function template that accepts a pack of
designated parameters, capturing both the names and the values, and
allowing both to be used when forwarding
But (b) in particular seems like it would add a lot of complexity. I hope
there's a better alternative.


> I'm not sure if it's proper to submit a new proposal before C++17 is
> settled, anyway, I'd like to make this work public now.
> Please let me know if anyone wants to be a champion if it's submitted.
>
>
> Thanks
>
> --
> 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/e2d5660e-2cf7-4107-868d-7027bdce344f%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e2d5660e-2cf7-4107-868d-7027bdce344f%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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/CAOfiQq%3DZjfOq_rvNQPB-qWrNLhaLMs-1fG4-11q%2BpXTYqCPQ2w%40mail.gmail.com.

--047d7bdc15ba0ce3170530640b94
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 W=
ed, Apr 13, 2016 at 1:33 AM, TONGARI J <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:tongari95@gmail.com" target=3D"_blank">tongari95@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Hi,</div>=
<div><br></div><div>The draft can be viewed at:</div><a href=3D"http://jamb=
oree.github.io/designator-draft.html" target=3D"_blank">http://jamboree.git=
hub.io/designator-draft.html</a><br><div><br></div><div>The prototype based=
 on Clang can be found at:</div><div><a href=3D"https://github.com/jamboree=
/clang/tree/feature/designator" target=3D"_blank">https://github.com/jambor=
ee/clang/tree/feature/designator</a></div></div></blockquote><div><br></div=
><div>Have you considered the interaction of this proposal with forwarding =
functions and with types like std::function? I would find it problematic if=
 correct forwarding is not possible for functions with designated parameter=
s. I think you will encounter resistance if something like this is not poss=
ible, and we have no known path forward to support it:</div><div><br></div>=
<div>=C2=A0 void f(int .foo, int .bar);</div><div>=C2=A0 std::function&lt;v=
oid(int .foo, int .bar)&gt; fn =3D f;</div><div>=C2=A0 fn(.bar =3D 1, .foo =
=3D 2);</div><div><br></div><div>One possible way to make this work could b=
e:</div><div>=C2=A0(a) designated parameter names to become part of a funct=
ion type, and</div><div>=C2=A0(b) add a way to write a function template th=
at accepts a pack of designated parameters, capturing both the names and th=
e values, and allowing both to be used when forwarding</div><div>But (b) in=
 particular seems like it would add a lot of complexity. I hope there&#39;s=
 a better alternative.</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div>I&#39;m not sure if it&#39;s proper to submit a new =
proposal before C++17 is settled, anyway, I&#39;d like to make this work pu=
blic now.</div><div>Please let me know if anyone wants to be a champion if =
it&#39;s=C2=A0submitted.</div><div><br></div><div><br></div><div>Thanks</di=
v></div><span class=3D"HOEnZb"><font color=3D"#888888">

<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" target=3D"_=
blank">std-proposals+unsubscribe@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/e2d5660e-2cf7-4107-868d-7027bdce344f%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e2d5660e-2cf7-=
4107-868d-7027bdce344f%40isocpp.org</a>.<br>
</font></span></blockquote></div><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/CAOfiQq%3DZjfOq_rvNQPB-qWrNLhaLMs-1fG=
4-11q%2BpXTYqCPQ2w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3DZjf=
Oq_rvNQPB-qWrNLhaLMs-1fG4-11q%2BpXTYqCPQ2w%40mail.gmail.com</a>.<br />

--047d7bdc15ba0ce3170530640b94--

.

------=_Part_206_195057279.1460582034322
Content-Type: multipart/alternative;
 boundary="----=_Part_207_737443063.1460582034322"

------=_Part_207_737443063.1460582034322
Content-Type: text/plain; charset=UTF-8


>
> 2) a "works automatically" proposal comes in. The response is "well,
> that doesn't work with the standard library,
> and authors of other libraries don't want to have the introduced
> requirement to provide stable names without their opt-in,
> so <insert the work-arounds again>..."
>

Is that really the argument against "works automatically"? Library authors
could simply not document/advertise those names (i.e. use those at your own
risk).  Keeping argument names stable doesn't strike me as more burdensome
than keep everything else stable. How often do you change an argument name,
but nothing else?

Besides, Python has had this ability for years and been *wildly *successful
at sharing libraries.

--
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/c0aec269-80bb-4c27-b01d-81eb323e35af%40isocpp.org.

------=_Part_207_737443063.1460582034322
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;">2) a &quot;wo=
rks automatically&quot; proposal comes in. The response is &quot;well,
<br>that doesn&#39;t work with the standard library,
<br>and authors of other libraries don&#39;t want to have the introduced
<br>requirement to provide stable names without their opt-in,
<br>so &lt;insert the work-arounds again&gt;...&quot;
<br></blockquote><div><br></div><div>Is that really the argument against &q=
uot;works automatically&quot;? Library authors could simply not document/ad=
vertise those names (i.e. use those at your own risk). =C2=A0Keeping argume=
nt names stable doesn&#39;t strike me as more burdensome than keep everythi=
ng else stable. How often do you change an argument name, but nothing else?=
=C2=A0</div><div><br></div><div>Besides, Python has had this ability for ye=
ars and been=C2=A0<i>wildly=C2=A0</i>successful at sharing libraries.=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&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/c0aec269-80bb-4c27-b01d-81eb323e35af%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c0aec269-80bb-4c27-b01d-81eb323e35af=
%40isocpp.org</a>.<br />

------=_Part_207_737443063.1460582034322--
------=_Part_206_195057279.1460582034322--

.

On 13 April 2016 at 23:49, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> On 2016-04-13 16:10, Ville Voutilainen wrote:
>> A much bigger hurdle is having this proposal survive five minutes
>> after its presentation, because the previous ones dropped dead in
>> about that time.
>>
>> 1) a "both sides must opt in" proposal comes in. The response is
>> "this doesn't help anyone in the near future, and makes function
>> declarations more complex, for questionable benefit.
>
> Would it be the end of the world to make the following be synonymous?
>
>   int square(int .x);
>   int square([[named("x")]] int);
>   int square([[named("x")]] int not_x);

I'm not quite sure what you're suggesting there. Make them synonymous, as in
allow all of those various syntaxes?

> I realize that attributes with meaning aren't loved, but the advantage
> this has is addressing the 'not useful *now*' complaint, by making it

No, the "not useful now" complaint is that in order to use named arguments,
the call site obviously needs to say that it uses them, but in an
opt-in proposal
the declaration also has to say so. Therefore both a user and a (whatever, not
necessarily the standard) library author need to decide that they want
such a thing.
That is in contrast to the other kinds of proposals where the caller
can just name
(except when the arguments can't be named, like with standard library functions)
the arguments so that the names are picked up from some declaration. Whatever
syntax you come up with, the issues remain. You may disagree on whether that's
an issue, but the real complaint is that some audiences don't want
named arguments
because then there's potentially lots of churn (or at least requests
for such churn)
in many codebases to add support for them, for arguably questionable benefit.

--
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/CAFk2RUYaBy%3DejRYaJcJTSw7VVM_X%2Bmb%3D8MRxyP3MvZZ5Czad2g%40mail.gmail.com.

.

On 2016-04-13 22:31, Richard Smith wrote:
> This looks more or less like how I'd always imagined designated
> initializers would work in C++. Thanks for writing this! One question,
> you say:
>
> "3.2.1.1 Function redeclaration
>
> If a function is declared with designatable parameters and/or default
> arguments, it cannot be redeclared with designatable parameters and/or
> default arguments, otherwise, the program is ill-formed."
>
> This seems very strange to me. I would expect that:
> a) every declaration of the same function must specify the same
> designatable parameters, with the same names, and
> b) perhaps overloading on designated parameter names should be permitted
>
> One example of why (b) would be useful:
>
> struct my_complex {
>   my_complex(double .rho, double .theta);
>   my_complex(double .real, double .imag);
> };
>
> Here, these constructors could *only* be called with designated
> parameter names, because any non-designated call would be ambiguous.

I don't think this is a good idea. If those were two functions, there
would be no way to resolve the ambiguity when taking an address of the
function.

--
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/abd1385f-dfeb-cee2-184d-d5f6936896fa%40gmail.com.

.

On 14 April 2016 at 00:13,  <barry.revzin@gmail.com> wrote:
>> 2) a "works automatically" proposal comes in. The response is "well,
>> that doesn't work with the standard library,
>> and authors of other libraries don't want to have the introduced
>> requirement to provide stable names without their opt-in,
>> so <insert the work-arounds again>..."
> Is that really the argument against "works automatically"?

Well, considering that it was an argument that was raised when discussing
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4172.htm,
sure, it's an argument against "works automatically". Whether you agree with
that argument is a separate matter.

> Library authors could simply not document/advertise those names (i.e. use those at your own
> risk).  Keeping argument names stable doesn't strike me as more burdensome
> than keep everything else stable. How often do you change an argument name,
> but nothing else?

Based on the arguments made when discussing the aforementioned paper,
depending on who you
ask, the answers are 1) that will not work 2) it is more burdensome
and 3) often enough to oppose
such a proposal.

> Besides, Python has had this ability for years and been wildly successful at
> sharing libraries.

Yeah, but the argument is that C++ library writers know that they
don't need to deal with it, and don't want
it imposed on them, and then we go back to "both sides opt in" which
will not work with the standard library,
because unlike python and lisp, the argument names are not standardized in C++.

--
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/CAFk2RUa4_rUAhUnJzw%3DHZ%2B_sWYJVs43LszOF80D22o2fMrPmhA%40mail.gmail.com.

.

On 2016-04-13 17:18, Ville Voutilainen wrote:
> On 13 April 2016 at 23:49, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>> On 2016-04-13 16:10, Ville Voutilainen wrote:
>>> A much bigger hurdle is having this proposal survive five minutes
>>> after its presentation, because the previous ones dropped dead in
>>> about that time.
>>>
>>> 1) a "both sides must opt in" proposal comes in. The response is
>>> "this doesn't help anyone in the near future, and makes function
>>> declarations more complex, for questionable benefit.
>>
>> Would it be the end of the world to make the following be synonymous?
>>
>>   int square(int .x);
>>   int square([[named("x")]] int);
>>   int square([[named("x")]] int not_x);
>
> I'm not quite sure what you're suggesting there. Make them synonymous, as in
> allow all of those various syntaxes?

Yes. As in, all three lines would a) be allowed and b) have the same
meaning.

>> I realize that attributes with meaning aren't loved, but the advantage
>> this has is addressing the 'not useful *now*' complaint, by making it
>
> No, the "not useful now" complaint is that in order to use named
> arguments, the call site obviously needs to say that it uses them,
> but in an opt-in proposal the declaration also has to say so.
> Therefore both a user and a (whatever, not necessarily the standard)
> library author need to decide that they want such a thing.

But this is a direct result of the parameter names not being implicitly
part of the API (i.e. your "authors of other libraries don't want to
have the introduced requirement to provide stable names without their
opt-in"). If both complaints are fatal to any possible proposal, then we
cannot make progress, because we *must* accept one or the other of those
limitations.

That may be the case. If so, however, it would be good to know (and
perhaps document?) so that we can shoot down any named argument
proposals immediately as being fundamentally intractable.

The idea behind the above was to provide a not-too-painful mechanism
that would let authors that aren't willing to commit to C++20 to write
libraries that can require only C++11 but still provide named argument
support without too much pain, so that libraries can be forward-looking
in order to mitigate that complaint.

> That is in contrast to the other kinds of proposals where the caller
> can just name (except when the arguments can't be named, like with
> standard library functions) the arguments so that the names are
> picked up from some declaration.

Again, the suggestion is intended to mitigate this (especially the
standard library case), by having an API argument name that is separate
from the "actual" name as used by the implementation. (I would argue
that if you aren't willing to commit to a stable API argument name, you
aren't committing to a stable API, period.)

> You may disagree on whether that's an issue

I don't. I recognize that there are legitimate concerns from both sides,
and am trying to come up with a way to at least mitigate (note: *not*
"eliminate"; I suspect that's impossible) them so that progress can be
made. I made the above suggestion in the hopes that it might be useful
in that sense, though I suspect it isn't, much :-(.

--
Matthew

--
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/nemea1%24uq8%241%40ger.gmane.org.

.

=E2=80=8E0. Naming is hard.=C2=A0

Something to consider: how would I later rename a param? Particularly once =
users have started =E2=80=8Eusing the old name and I don't want to break th=
em. =C2=A0

I could rename the whole function, but see #0 above. (and if it is the cons=
tructor, do I rename the whole class?)

So it might be nice to allow ways to overload, even if the overload just tu=
rns around and calls the original:

=E2=80=8Emy_complex(double .real, double .imag);
// whoops! Coding guidelines say no short forms
my_complex(doule .real, double .imaginary) ;



Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: Andrey Semashev
Sent: Wednesday, April 13, 2016 5:21 PM
To: std-proposals@isocpp.org
Reply To: std-proposals@isocpp.org
Subject: Re: [std-proposals] [RFC] Uniform designated initializers and argu=
ments for C++ (implementation available)

On 2016-04-13 22:31, Richard Smith wrote:
> This looks more or less like how I'd always imagined designated
> initializers would work in C++. Thanks for writing this! One question,
> you say:
>
> "3.2.1.1 Function redeclaration
>
> If a function is declared with designatable parameters and/or default
> arguments, it cannot be redeclared with designatable parameters and/or
> default arguments, otherwise, the program is ill-formed."
>
> This seems very strange to me. I would expect that:
> a) every declaration of the same function must specify the same
> designatable parameters, with the same names, and
> b) perhaps overloading on designated parameter names should be permitted
>
> One example of why (b) would be useful:
>
> struct my_complex {
> my_complex(double .rho, double .theta);
> my_complex(double .real, double .imag);
> };
>
> Here, these constructors could *only* be called with designated
> parameter names, because any non-designated call would be ambiguous.

I don't think this is a good idea. If those were two functions, there=20
would be no way to resolve the ambiguity when taking an address of the=20
function.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/abd1385f-dfeb-cee2-184d-d5f6936896fa%40gmail.com=
..

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20160413214246.4907089.83410.9691%40gmail.com.

.

On 14 April 2016 at 00:39, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>>> Would it be the end of the world to make the following be synonymous?
>>>
>>>   int square(int .x);
>>>   int square([[named("x")]] int);
>>>   int square([[named("x")]] int not_x);
>>
>> I'm not quite sure what you're suggesting there. Make them synonymous, as in
>> allow all of those various syntaxes?
>
> Yes. As in, all three lines would a) be allowed and b) have the same
> meaning.

Well, I will not make end-of-the-world predictions, but such an idea
is guaranteed to generate
strong opposition. Partly because it complicates the idea, partly
because it's using attributes
for semantics.

>> No, the "not useful now" complaint is that in order to use named
>> arguments, the call site obviously needs to say that it uses them,
>> but in an opt-in proposal the declaration also has to say so.
>> Therefore both a user and a (whatever, not necessarily the standard)
>> library author need to decide that they want such a thing.
>
> But this is a direct result of the parameter names not being implicitly
> part of the API (i.e. your "authors of other libraries don't want to
> have the introduced requirement to provide stable names without their
> opt-in"). If both complaints are fatal to any possible proposal, then we
> cannot make progress, because we *must* accept one or the other of those
> limitations.

Well, perhaps that's one of the reasons why named arguments have
failed every time.

> That may be the case. If so, however, it would be good to know (and
> perhaps document?) so that we can shoot down any named argument
> proposals immediately as being fundamentally intractable.

Well - 'automatic' ones are highly questionable because they don't
work with the standard library,
unless everything in it changes, which is not backwards compatible,
which means we can probably
skip to an 'opt-in'. I'm not sure whether I know all the
counterarguments and opposition of it.
I have indeed toyed with the idea of writing a rumination paper on why
named arguments have failed,
as far as I know and have observed it (which doesn't cover all the old
proposals), but perhaps I was
kinda hoping I wouldn't need to. :)

> The idea behind the above was to provide a not-too-painful mechanism
> that would let authors that aren't willing to commit to C++20 to write
> libraries that can require only C++11 but still provide named argument
> support without too much pain, so that libraries can be forward-looking
> in order to mitigate that complaint.

Ah, so the expectation is that a C++11 implementation would just
ignore the attributes it doesn't grok,
and a C++20 implementation would give them semantic meaning. That is a
silent change in meaning
of code, and those tend to have a short life expectancy.

>> That is in contrast to the other kinds of proposals where the caller
>> can just name (except when the arguments can't be named, like with
>> standard library functions) the arguments so that the names are
>> picked up from some declaration.
> Again, the suggestion is intended to mitigate this (especially the
> standard library case), by having an API argument name that is separate
> from the "actual" name as used by the implementation. (I would argue
> that if you aren't willing to commit to a stable API argument name, you
> aren't committing to a stable API, period.)

Well, today, and for multiple decades, an argument name has been an
implementation detail,
nothing more. Hence the argument that not providing a stable name
means not providing a
stable API cannot possibly be sound.

--
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/CAFk2RUYvzGPWJyrPjQRrg-RQYVbDN%3DExc036D5fP14xuiutS2A%40mail.gmail.com.

.

------=_Part_1045_1178686262.1460586823443
Content-Type: multipart/alternative;
 boundary="----=_Part_1046_581569183.1460586823443"

------=_Part_1046_581569183.1460586823443
Content-Type: text/plain; charset=UTF-8

Am Mittwoch, 13. April 2016 22:58:45 UTC+2 schrieb Richard Smith:
>
> On Wed, Apr 13, 2016 at 1:33 AM, TONGARI J <tong...@gmail.com
> <javascript:>> wrote:
>
>> Hi,
>>
>> The draft can be viewed at:
>> http://jamboree.github.io/designator-draft.html
>>
>> The prototype based on Clang can be found at:
>> https://github.com/jamboree/clang/tree/feature/designator
>>
>
> Have you considered the interaction of this proposal with forwarding
> functions and with types like std::function? I would find it problematic if
> correct forwarding is not possible for functions with designated
> parameters. I think you will encounter resistance if something like this is
> not possible, and we have no known path forward to support it:
>
>   void f(int .foo, int .bar);
>   std::function<void(int .foo, int .bar)> fn = f;
>   fn(.bar = 1, .foo = 2);
>
> One possible way to make this work could be:
>  (a) designated parameter names to become part of a function type, and
>

What are the downsides of disignated parameters being part of a function
type?


>  (b) add a way to write a function template that accepts a pack of
> designated parameters, capturing both the names and the values, and
> allowing both to be used when forwarding
>

Wouldn't this require some kind of reflection mechanism? (To save the
names).


> But (b) in particular seems like it would add a lot of complexity. I hope
> there's a better alternative.
>
>
>> I'm not sure if it's proper to submit a new proposal before C++17 is
>> settled, anyway, I'd like to make this work public now.
>> Please let me know if anyone wants to be a champion if it's submitted.
>>
>>
>> Thanks
>>
>> --
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e2d5660e-2cf7-4107-868d-7027bdce344f%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e2d5660e-2cf7-4107-868d-7027bdce344f%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
>

--
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/84335887-a9d3-4ef1-97eb-921220b1fb0e%40isocpp.org.

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

<div dir=3D"ltr">Am Mittwoch, 13. April 2016 22:58:45 UTC+2 schrieb Richard=
 Smith:<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"><div><=
div class=3D"gmail_quote">On Wed, Apr 13, 2016 at 1:33 AM, TONGARI J <span =
dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"2dTt3Kk0BAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;java=
script:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;ret=
urn true;">tong...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div>Hi,</div><div><br></div><div>The draft can =
be viewed at:</div><a href=3D"http://jamboree.github.io/designator-draft.ht=
ml" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http=
://www.google.com/url?q\75http%3A%2F%2Fjamboree.github.io%2Fdesignator-draf=
t.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHpl7fvspzlrc1ynxvCJgWnuF4yzA&#39;=
;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\75ht=
tp%3A%2F%2Fjamboree.github.io%2Fdesignator-draft.html\46sa\75D\46sntz\0751\=
46usg\75AFQjCNHpl7fvspzlrc1ynxvCJgWnuF4yzA&#39;;return true;">http://jambor=
ee.github.io/<wbr>designator-draft.html</a><br><div><br></div><div>The prot=
otype based on Clang can be found at:</div><div><a href=3D"https://github.c=
om/jamboree/clang/tree/feature/designator" target=3D"_blank" rel=3D"nofollo=
w" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\75https%3A%=
2F%2Fgithub.com%2Fjamboree%2Fclang%2Ftree%2Ffeature%2Fdesignator\46sa\75D\4=
6sntz\0751\46usg\75AFQjCNGa_hHsOQOQjduH5UvFz5148ItL2g&#39;;return true;" on=
click=3D"this.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fgith=
ub.com%2Fjamboree%2Fclang%2Ftree%2Ffeature%2Fdesignator\46sa\75D\46sntz\075=
1\46usg\75AFQjCNGa_hHsOQOQjduH5UvFz5148ItL2g&#39;;return true;">https://git=
hub.com/jamboree/<wbr>clang/tree/feature/designator</a></div></div></blockq=
uote><div><br></div><div>Have you considered the interaction of this propos=
al with forwarding functions and with types like std::function? I would fin=
d it problematic if correct forwarding is not possible for functions with d=
esignated parameters. I think you will encounter resistance if something li=
ke this is not possible, and we have no known path forward to support it:</=
div><div><br></div><div>=C2=A0 void f(int .foo, int .bar);</div><div>=C2=A0=
 std::function&lt;void(int .foo, int .bar)&gt; fn =3D f;</div><div>=C2=A0 f=
n(.bar =3D 1, .foo =3D 2);</div><div><br></div><div>One possible way to mak=
e this work could be:</div><div>=C2=A0(a) designated parameter names to bec=
ome part of a function type, and</div></div></div></div></blockquote><div><=
br></div><div>What are the downsides of disignated parameters being part of=
 a function type?</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>=C2=A0(b) a=
dd a way to write a function template that accepts a pack of designated par=
ameters, capturing both the names and the values, and allowing both to be u=
sed when forwarding</div></div></div></div></blockquote><div><br></div><div=
>Wouldn&#39;t this require some kind of reflection mechanism? (To save the =
names).</div><div>=C2=A0</div><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><div class=3D"gmail_quote"><div>But (b) in particular=
 seems like it would add a lot of complexity. I hope there&#39;s a better a=
lternative.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div>I&#39;m not sure if it&#39;s proper to submit a new proposal =
before C++17 is settled, anyway, I&#39;d like to make this work public now.=
</div><div>Please let me know if anyone wants to be a champion if it&#39;s=
=C2=A0submitted.</div><div><br></div><div><br></div><div>Thanks</div></div>=
<span><font color=3D"#888888">

<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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
2dTt3Kk0BAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"2dTt3Kk0BAAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@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/e2d5660e-2cf7-4107-868d-7027bdce344f%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/e2d5660e-2cf7-4107-868d-7027bdce344f%40i=
socpp.org?utm_medium\75email\46utm_source\75footer&#39;;return true;" oncli=
ck=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/e2d5660e-2cf7-4107-868d-7027bdce344f%40isocpp.org?utm_medium\75ema=
il\46utm_source\75footer&#39;;return true;">https://groups.google.com/a/<wb=
r>isocpp.org/d/msgid/std-<wbr>proposals/e2d5660e-2cf7-4107-<wbr>868d-7027bd=
ce344f%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br></div></div>
</blockquote></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/84335887-a9d3-4ef1-97eb-921220b1fb0e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/84335887-a9d3-4ef1-97eb-921220b1fb0e=
%40isocpp.org</a>.<br />

------=_Part_1046_581569183.1460586823443--
------=_Part_1045_1178686262.1460586823443--

.

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

On Wed, Apr 13, 2016 at 2:21 PM, Andrey Semashev <andrey.semashev@gmail.com>
wrote:

> On 2016-04-13 22:31, Richard Smith wrote:
>
>> This looks more or less like how I'd always imagined designated
>> initializers would work in C++. Thanks for writing this! One question,
>> you say:
>>
>> "3.2.1.1 Function redeclaration
>>
>> If a function is declared with designatable parameters and/or default
>> arguments, it cannot be redeclared with designatable parameters and/or
>> default arguments, otherwise, the program is ill-formed."
>>
>> This seems very strange to me. I would expect that:
>> a) every declaration of the same function must specify the same
>> designatable parameters, with the same names, and
>> b) perhaps overloading on designated parameter names should be permitted
>>
>> One example of why (b) would be useful:
>>
>> struct my_complex {
>>   my_complex(double .rho, double .theta);
>>   my_complex(double .real, double .imag);
>> };
>>
>> Here, these constructors could *only* be called with designated
>> parameter names, because any non-designated call would be ambiguous.
>>
>
> I don't think this is a good idea. If those were two functions, there
> would be no way to resolve the ambiguity when taking an address of the
> function.


Note that I'm also in favour of designatable parameter names being part of
the function type. With that change, this would work the same as any other
overload / address of function situation.

--
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/CAOfiQq%3Dcwvf2bamvSHMruSpio3inaOkfGDYD6Z43Y7MgZz7gDQ%40mail.gmail.com.

--001a113ea5f068bb010530671d10
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 W=
ed, Apr 13, 2016 at 2:21 PM, Andrey Semashev <span dir=3D"ltr">&lt;<a href=
=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semashev@gma=
il.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=
=3D"">On 2016-04-13 22:31, Richard Smith wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
This looks more or less like how I&#39;d always imagined designated<br>
initializers would work in C++. Thanks for writing this! One question,<br>
you say:<br>
<br>
&quot;3.2.1.1 Function redeclaration<br>
<br>
If a function is declared with designatable parameters and/or default<br>
arguments, it cannot be redeclared with designatable parameters and/or<br>
default arguments, otherwise, the program is ill-formed.&quot;<br>
<br>
This seems very strange to me. I would expect that:<br>
a) every declaration of the same function must specify the same<br>
designatable parameters, with the same names, and<br>
b) perhaps overloading on designated parameter names should be permitted<br=
>
<br>
One example of why (b) would be useful:<br>
<br>
struct my_complex {<br>
=C2=A0 my_complex(double .rho, double .theta);<br>
=C2=A0 my_complex(double .real, double .imag);<br>
};<br>
<br>
Here, these constructors could *only* be called with designated<br>
parameter names, because any non-designated call would be ambiguous.<br>
</blockquote>
<br></span>
I don&#39;t think this is a good idea. If those were two functions, there w=
ould be no way to resolve the ambiguity when taking an address of the funct=
ion.</blockquote><div><br></div><div>Note that I&#39;m also in favour of de=
signatable parameter names being part of the function type. With that chang=
e, this would work the same as any other overload / address of function sit=
uation.</div></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/CAOfiQq%3Dcwvf2bamvSHMruSpio3inaOkfGD=
YD6Z43Y7MgZz7gDQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3Dcwvf2=
bamvSHMruSpio3inaOkfGDYD6Z43Y7MgZz7gDQ%40mail.gmail.com</a>.<br />

--001a113ea5f068bb010530671d10--

.

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

On Wed, Apr 13, 2016 at 3:33 PM, <paulpeet17@gmail.com> wrote:

> Am Mittwoch, 13. April 2016 22:58:45 UTC+2 schrieb Richard Smith:
>>
>> On Wed, Apr 13, 2016 at 1:33 AM, TONGARI J <tong...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> The draft can be viewed at:
>>> http://jamboree.github.io/designator-draft.html
>>>
>>> The prototype based on Clang can be found at:
>>> https://github.com/jamboree/clang/tree/feature/designator
>>>
>>
>> Have you considered the interaction of this proposal with forwarding
>> functions and with types like std::function? I would find it problematic if
>> correct forwarding is not possible for functions with designated
>> parameters. I think you will encounter resistance if something like this is
>> not possible, and we have no known path forward to support it:
>>
>>   void f(int .foo, int .bar);
>>   std::function<void(int .foo, int .bar)> fn = f;
>>   fn(.bar = 1, .foo = 2);
>>
>> One possible way to make this work could be:
>>  (a) designated parameter names to become part of a function type, and
>>
>
> What are the downsides of disignated parameters being part of a function
> type?
>

I think increased complexity is the big one. Presumably we'd want this to
work:

void f(int .a, int .b);
void (*p)(int, int) = &f;

.... which implies there is a conversion that discards the names from the
type. Adding names should presumably also be permissible (perhaps with an
explicit cast), as should calling through a function pointer whose
parameter names differ from those of the function.

It also means that everyone who is decomposing a function type via a
template needs to change their code to cope with designators. The way that
works would depend on how we tackle part (b):


>  (b) add a way to write a function template that accepts a pack of
>> designated parameters, capturing both the names and the values, and
>> allowing both to be used when forwarding
>>
>
> Wouldn't this require some kind of reflection mechanism? (To save the
> names).
>

"Reflection" is not a well-defined term; we can't say what is or isn't a
reflection mechanism. But I don't see this as being much different from
template argument deduction deducing the types of parameters from the type
of arguments (is that reflection? opinions vary).

We could imagine something like this:

template<typename F, designator ...D, typename ...T> decltype(auto) f(F f,
T &&... .D) {
  return f(0, .D = std::forward<T>(D) ...);
}

That is: a new kind of template parameter representing a designator, and
designator names are looked up to see if they name such a parameter before
assuming they're an opaque identifier. (Plus a notional "empty designator"
that is deduced in cases where no designator is specified.) I don't think I
like this approach, and as noted, I hope there's a better answer.


> But (b) in particular seems like it would add a lot of complexity. I hope
>> there's a better alternative.
>>
>>
>>> I'm not sure if it's proper to submit a new proposal before C++17 is
>>> settled, anyway, I'd like to make this work public now.
>>> Please let me know if anyone wants to be a champion if it's submitted.
>>>
>>>
>>> Thanks
>>>
>>> --
>>> 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-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e2d5660e-2cf7-4107-868d-7027bdce344f%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e2d5660e-2cf7-4107-868d-7027bdce344f%40isocpp.org?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>> --
> 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/84335887-a9d3-4ef1-97eb-921220b1fb0e%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/84335887-a9d3-4ef1-97eb-921220b1fb0e%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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/CAOfiQqns6dE7nro%3D3btO9Wy0n%3Dx2ev8MELGs8XB2m9PRTMsEqA%40mail.gmail.com.

--f46d04289df7a28e0405306740a7
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 W=
ed, Apr 13, 2016 at 3:33 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:paulp=
eet17@gmail.com" target=3D"_blank">paulpeet17@gmail.com</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex"><div dir=3D"ltr">Am Mittwoch, 13. April 2016 22:58:4=
5 UTC+2 schrieb Richard Smith:<span class=3D""><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c=
olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D=
"ltr"><div><div class=3D"gmail_quote">On Wed, Apr 13, 2016 at 1:33 AM, TONG=
ARI J <span dir=3D"ltr">&lt;<a rel=3D"nofollow">tong...@gmail.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>Hi,</div><div><br></=
div><div>The draft can be viewed at:</div><a href=3D"http://jamboree.github=
..io/designator-draft.html" rel=3D"nofollow" target=3D"_blank">http://jambor=
ee.github.io/designator-draft.html</a><br><div><br></div><div>The prototype=
 based on Clang can be found at:</div><div><a href=3D"https://github.com/ja=
mboree/clang/tree/feature/designator" rel=3D"nofollow" target=3D"_blank">ht=
tps://github.com/jamboree/clang/tree/feature/designator</a></div></div></bl=
ockquote><div><br></div><div>Have you considered the interaction of this pr=
oposal with forwarding functions and with types like std::function? I would=
 find it problematic if correct forwarding is not possible for functions wi=
th designated parameters. I think you will encounter resistance if somethin=
g like this is not possible, and we have no known path forward to support i=
t:</div><div><br></div><div>=C2=A0 void f(int .foo, int .bar);</div><div>=
=C2=A0 std::function&lt;void(int .foo, int .bar)&gt; fn =3D f;</div><div>=
=C2=A0 fn(.bar =3D 1, .foo =3D 2);</div><div><br></div><div>One possible wa=
y to make this work could be:</div><div>=C2=A0(a) designated parameter name=
s to become part of a function type, and</div></div></div></div></blockquot=
e><div><br></div></span><div>What are the downsides of disignated parameter=
s being part of a function type?</div></div></blockquote><div><br></div><di=
v>I think increased complexity is the big one. Presumably we&#39;d want thi=
s to work:</div><div><br></div><div>void f(int .a, int .b);</div><div>void =
(*p)(int, int) =3D &amp;f;</div><div><br></div><div>... which implies there=
 is a conversion that discards the names from the type. Adding names should=
 presumably also be permissible (perhaps with an explicit cast), as should =
calling through a function pointer whose parameter names differ from those =
of the function.</div><div><br></div><div>It also means that everyone who i=
s decomposing a function type via a template needs to change their code to =
cope with designators. The way that works would depend on how we tackle par=
t (b):</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2=
04);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><span class=
=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><di=
v>=C2=A0(b) add a way to write a function template that accepts a pack of d=
esignated parameters, capturing both the names and the values, and allowing=
 both to be used when forwarding</div></div></div></div></blockquote><div><=
br></div></span><div>Wouldn&#39;t this require some kind of reflection mech=
anism? (To save the names).</div></div></blockquote><div><br></div><div>&qu=
ot;Reflection&quot; is not a well-defined term; we can&#39;t say what is or=
 isn&#39;t a reflection mechanism. But I don&#39;t see this as being much d=
ifferent from template argument deduction deducing the types of parameters =
from the type of arguments (is that reflection? opinions vary).</div><div><=
br></div><div>We could imagine something like this:</div><div><br></div><di=
v>template&lt;typename F, designator ...D, typename ...T&gt; decltype(auto)=
 f(F f, T &amp;&amp;... .D) {</div><div>=C2=A0 return f(0, .D =3D std::forw=
ard&lt;T&gt;(D) ...);</div><div>}</div><div><br></div><div>That is: a new k=
ind of template parameter representing a designator, and designator names a=
re looked up to see if they name such a parameter before assuming they&#39;=
re an opaque identifier. (Plus a notional &quot;empty designator&quot; that=
 is deduced in cases where no designator is specified.) I don&#39;t think I=
 like this approach, and as noted, I hope there&#39;s a better answer.</div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-=
left-style:solid;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div d=
ir=3D"ltr"><div><div class=3D"gmail_quote"><span class=3D""><div>But (b) in=
 particular seems like it would add a lot of complexity. I hope there&#39;s=
 a better alternative.</div><div>=C2=A0</div></span><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span =
class=3D""><div dir=3D"ltr"><div>I&#39;m not sure if it&#39;s proper to sub=
mit a new proposal before C++17 is settled, anyway, I&#39;d like to make th=
is work public now.</div><div>Please let me know if anyone wants to be a ch=
ampion if it&#39;s=C2=A0submitted.</div><div><br></div><div><br></div><div>=
Thanks</div></div></span><span><font color=3D"#888888"><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span class=3D""><br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e2d5660e-2cf7-4107-868d-7027bdce344f%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposa=
ls/e2d5660e-2cf7-4107-868d-7027bdce344f%40isocpp.org</a>.<br>
</span></font></span></blockquote></div><br></div></div>
</blockquote></div><span class=3D"">

<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" target=3D"_=
blank">std-proposals+unsubscribe@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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/84335887-a9d3-4ef1-97eb-921220b1fb0e%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/84335887-a9d3-=
4ef1-97eb-921220b1fb0e%40isocpp.org</a>.<br>
</blockquote></div><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/CAOfiQqns6dE7nro%3D3btO9Wy0n%3Dx2ev8M=
ELGs8XB2m9PRTMsEqA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqns6dE7=
nro%3D3btO9Wy0n%3Dx2ev8MELGs8XB2m9PRTMsEqA%40mail.gmail.com</a>.<br />

--f46d04289df7a28e0405306740a7--

.

------=_Part_5541_1930704981.1460597766966
Content-Type: multipart/alternative;
 boundary="----=_Part_5542_1982396102.1460597766966"

------=_Part_5542_1982396102.1460597766966
Content-Type: text/plain; charset=UTF-8



On Wednesday, April 13, 2016 at 8:33:28 PM UTC+12, TONGARI J wrote:
>
> Hi,
>
> The draft can be viewed at:
> http://jamboree.github.io/designator-draft.html
>
> The prototype based on Clang can be found at:
> https://github.com/jamboree/clang/tree/feature/designator
>
>
> I'm not sure if it's proper to submit a new proposal before C++17 is
> settled, anyway, I'd like to make this work public now.
> Please let me know if anyone wants to be a champion if it's submitted.
>
>
> Thanks
>

This looks like a very well written and presented proposal. I think it
could be better evaluated though if there were more discussion about it in
the context of existing API designs that have been created with languages
that already have the features the proposed. In particular regarding named
function parameters.

My own experience of using libraries with extensive numbers of
parameters are the Microsoft COM object libraries that lay behind
applications like Microsoft Word and Excel etc.
See here:
https://msdn.microsoft.com/en-us/library/kw65a0we.aspx
https://msdn.microsoft.com/en-us/library/office/ff194068.aspx

This proposal would seem to make using such libraries a lot easier?

As important to me though is whether people consider such API designs good?
And do we want to encourage more of them by making them easier?

So to my mind we have to evaluate this proposal against real existing
APIs while also determining if those real API's need to be as complex as
they are so we. This should help us verify if this proposal helps with
using such API's and reveal whether an alternative API design or language
feature would be better to get the kinds of api's we do want.

I don't feel I can appreciate the value of this proposal without such
discussion

If more recent API's could be discussed it might even more relevant. I am
thinking some of the web driving api's (think setting html attributes from
code etc). like those in the ASP.NET's MVC API, which are C#
API's. Maybe that could be addressed? Perhaps a lot of
lessons/encouragement could be learned from that?

So I think ultimately we have to compare this proposal against these types
of API's and evaluate the alternatives to appreciate this proposal, don't
we?

Thanks for the proposal so far.

--
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/2623effe-c614-4956-964d-2b5028f5d57e%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Wednesday, April 13, 2016 at 8:33:28 PM UTC+12,=
 TONGARI J wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>Hi,</di=
v><div><br></div><div>The draft can be viewed at:</div><a onmousedown=3D"th=
is.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fjamboree.github.i=
o%2Fdesignator-draft.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHpl7fvspzlrc1y=
nxvCJgWnuF4yzA&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.go=
ogle.com/url?q\75http%3A%2F%2Fjamboree.github.io%2Fdesignator-draft.html\46=
sa\75D\46sntz\0751\46usg\75AFQjCNHpl7fvspzlrc1ynxvCJgWnuF4yzA&#39;;return t=
rue;" href=3D"http://jamboree.github.io/designator-draft.html" target=3D"_b=
lank" rel=3D"nofollow">http://jamboree.github.io/<wbr>designator-draft.html=
</a><br><div><br></div><div>The prototype based on Clang can be found at:</=
div><div><a onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\75=
https%3A%2F%2Fgithub.com%2Fjamboree%2Fclang%2Ftree%2Ffeature%2Fdesignator\4=
6sa\75D\46sntz\0751\46usg\75AFQjCNGa_hHsOQOQjduH5UvFz5148ItL2g&#39;;return =
true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\75https%3A%=
2F%2Fgithub.com%2Fjamboree%2Fclang%2Ftree%2Ffeature%2Fdesignator\46sa\75D\4=
6sntz\0751\46usg\75AFQjCNGa_hHsOQOQjduH5UvFz5148ItL2g&#39;;return true;" hr=
ef=3D"https://github.com/jamboree/clang/tree/feature/designator" target=3D"=
_blank" rel=3D"nofollow">https://github.com/jamboree/<wbr>clang/tree/featur=
e/designator</a><br></div><div><br></div><div><br></div><div>I&#39;m not su=
re if it&#39;s proper to submit a new proposal before C++17 is settled, any=
way, I&#39;d like to make this work public now.</div><div>Please let me kno=
w if anyone wants to be a champion if it&#39;s=C2=A0submitted.</div><div><b=
r></div><div><br></div><div>Thanks</div></div></blockquote><div><br></div><=
div>This looks like a very well written and presented proposal.=C2=A0I thin=
k it could be better evaluated=C2=A0though=C2=A0if=C2=A0there were more dis=
cussion=C2=A0about it in the context of existing API=C2=A0designs that=C2=
=A0have been created=C2=A0with languages that already have the features the=
 proposed. In particular=C2=A0regarding=C2=A0named function parameters.</di=
v><div><br></div><div>My own experience of using libraries with extensive n=
umbers of parameters=C2=A0are=C2=A0the Microsoft COM object libraries that =
lay behind applications like Microsoft Word and Excel etc.</div><div>See he=
re:</div><div><div><a href=3D"https://msdn.microsoft.com/en-us/library/kw65=
a0we.aspx">https://msdn.microsoft.com/en-us/library/kw65a0we.aspx</a></div>=
<div><a href=3D"https://msdn.microsoft.com/en-us/library/office/ff194068.as=
px">https://msdn.microsoft.com/en-us/library/office/ff194068.aspx</a></div>=
</div><div><br></div><div>This proposal would seem to=C2=A0make using such =
libraries a lot easier?</div><div><br></div><div>As=C2=A0important to me th=
ough is whether=C2=A0people consider such API designs good? And=C2=A0do we =
want to encourage more of them by making them easier?</div><div><br></div><=
div>So to my mind we=C2=A0have to evaluate=C2=A0this proposal=C2=A0against=
=C2=A0real existing APIs=C2=A0while also determining if those real=C2=A0API=
&#39;s=C2=A0need to be=C2=A0as complex as they are so=C2=A0we.=C2=A0This sh=
ould help us=C2=A0verify=C2=A0if this proposal helps with using=C2=A0such A=
PI&#39;s=C2=A0and=C2=A0reveal=C2=A0whether an alternative API design or lan=
guage feature=C2=A0would be=C2=A0better to get the kinds of api&#39;s we do=
 want.</div><div><br></div><div>I=C2=A0don&#39;t=C2=A0feel=C2=A0I can=C2=A0=
appreciate the value of this proposal without such discussion</div><div><br=
></div><div>If=C2=A0more recent=C2=A0API&#39;s could be=C2=A0discussed it m=
ight even more relevant. I am thinking some of the=C2=A0web driving api&#39=
;s (think setting html attributes from code etc). like those=C2=A0in the=C2=
=A0ASP.NET&#39;s=C2=A0MVC API, which are=C2=A0C# API&#39;s.=C2=A0Maybe=C2=
=A0that could be addressed?=C2=A0Perhaps a=C2=A0lot of lessons/encouragemen=
t could be learned from that?</div><div><br></div><div>So I=C2=A0think ulti=
mately we have to compare this proposal against=C2=A0these types of=C2=A0AP=
I&#39;s and evaluate the alternatives to appreciate this proposal, don&#39;=
t we?</div><div><br></div><div>Thanks for the proposal so far.</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/2623effe-c614-4956-964d-2b5028f5d57e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2623effe-c614-4956-964d-2b5028f5d57e=
%40isocpp.org</a>.<br />

------=_Part_5542_1982396102.1460597766966--
------=_Part_5541_1930704981.1460597766966--

.

------=_Part_4166_144733049.1460598980503
Content-Type: multipart/alternative;
 boundary="----=_Part_4167_1743618581.1460598980503"

------=_Part_4167_1743618581.1460598980503
Content-Type: text/plain; charset=UTF-8

On Thursday, April 14, 2016 at 1:59:03 AM UTC+8, qwa...@gmail.com wrote:
>
> 2.3 can be solved by much smaller change in standard.
> Do you consider allowing such syntax:
>
> obj.f(default, b)
>
>
Actually I did. This could be useful in its own, but it's outside the scope
of this proposal.

--
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/1c310d01-9084-4b8b-b77c-df752c0affa8%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, April 14, 2016 at 1:59:03 AM UTC+8, qwa...@gm=
ail.com 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"=
>2.3 can be solved by much smaller change in standard.<br>Do you consider a=
llowing such syntax:<br><pre><code>obj.f(<span>default</span>, b)</code></p=
re></div></blockquote><div><br></div><div>Actually I did. This could be use=
ful in its own, but it&#39;s outside the scope of this proposal.<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/1c310d01-9084-4b8b-b77c-df752c0affa8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1c310d01-9084-4b8b-b77c-df752c0affa8=
%40isocpp.org</a>.<br />

------=_Part_4167_1743618581.1460598980503--
------=_Part_4166_144733049.1460598980503--

.

------=_Part_7489_1533469430.1460603395051
Content-Type: multipart/alternative;
 boundary="----=_Part_7490_1624963422.1460603395052"

------=_Part_7490_1624963422.1460603395052
Content-Type: text/plain; charset=UTF-8

Hi Richard,

On Thursday, April 14, 2016 at 3:31:20 AM UTC+8, Richard Smith wrote:
>
> This looks more or less like how I'd always imagined designated
> initializers would work in C++. Thanks for writing this! One question, you
> say:
>
> "3.2.1.1 Function redeclaration
>
> If a function is declared with designatable parameters and/or default
> arguments, it cannot be redeclared with designatable parameters and/or
> default arguments, otherwise, the program is ill-formed."
>
> This seems very strange to me. I would expect that:
> a) every declaration of the same function must specify the same
> designatable parameters, with the same names, and
> b) perhaps overloading on designated parameter names should be permitted
>
> One example of why (b) would be useful:
>
> struct my_complex {
>   my_complex(double .rho, double .theta);
>   my_complex(double .real, double .imag);
> };
>
> Here, these constructors could *only* be called with designated parameter
> names, because any non-designated call would be ambiguous.
>

There are some principles I set when designing the feature:
* Don't interfere with the type system
* Don't require ABI changes
* Don't complicate the function declaration

I did consider allowing multiple function declarations with different
designators in early stage, but the idea soon got dropped.
The idea was different from what you would expect though:
void f(int .a, int .b);
void f(int .x, int .y);

The 2 declarations will be the *same* function, not 2 overloads. This may
be useful in some case but also confusing and may complicate the
implementation so I dropped it.

As for allowing multiple identical declarations, my argument against it is
for consistency, consider default arguments:
void f(int a = 1);
void f(int a = 1);

It's not allowed even though the 2 are lexically identical, and I think the
same should apply to designatable parameters as well.

What you suggested in the my_complex example is to make them overloads,
which is a design decision I don't want to take in this proposal.


> Have you considered the interaction of this proposal with forwarding
> functions and with types like std::function? I would find it problematic if
> correct forwarding is not possible for functions with designated
> parameters. I think you will encounter resistance if something like this is
> not possible, and we have no known path forward to support it:
>
>   void f(int .foo, int .bar);
>   std::function<void(int .foo, int .bar)> fn = f;
>   fn(.bar = 1, .foo = 2);
>
> One possible way to make this work could be:
>  (a) designated parameter names to become part of a function type, and
>  (b) add a way to write a function template that accepts a pack of
> designated parameters, capturing both the names and the values, and
> allowing both to be used when forwarding
> But (b) in particular seems like it would add a lot of complexity. I hope
> there's a better alternative.
>

Actually, forwarding function is explicitly listed in my non-goals, that's
why I deliberately disable the indirect use in the end of section 3.2.3.

If I were going to support forwarding functions, that means I have to make
designatable parameters part of the type as you suggested in (a), and that
breaks my design principles.
My choice for designated arguments is much like parameter pack, that is,
don't make them first class objects.

I should emphasize how reluctant I am in interfering with the type system -
it's a no-go for me if adding designatable parameters to existing API would
break the ABI.

--
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/394c670e-6339-4933-abba-8f6d950dff47%40isocpp.org.

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

<div dir=3D"ltr">Hi Richard,<br><br>On Thursday, April 14, 2016 at 3:31:20 =
AM UTC+8, Richard Smith 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">This looks more or less like how I&#39;d always imagined d=
esignated initializers would work in C++. Thanks for writing this! One ques=
tion, you say:<div><br></div><div><div>&quot;3.2.1.1 Function redeclaration=
</div><div><br></div><div>If a function is declared with designatable param=
eters and/or default arguments, it cannot be redeclared with designatable p=
arameters and/or default arguments, otherwise, the program is ill-formed.&q=
uot;</div><div><br></div></div><div>This seems very strange to me. I would =
expect that:</div><div>a) every declaration of the same function must speci=
fy the same designatable parameters, with the same names, and</div><div>b) =
perhaps overloading on designated parameter names should be permitted</div>=
<div><br></div><div>One example of why (b) would be useful:</div><div><br><=
/div><div>struct my_complex {</div><div>=C2=A0 my_complex(double .rho, doub=
le .theta);</div><div>=C2=A0 my_complex(double .real, double .imag);</div><=
div>};</div><div><br></div><div>Here, these constructors could *only* be ca=
lled with designated parameter names, because any non-designated call would=
 be ambiguous.</div></div></blockquote><div><br></div><div>There are some p=
rinciples I set when designing the feature:</div><div>* Don&#39;t interfere=
 with the type system</div><div>* Don&#39;t require ABI changes</div><div>*=
 Don&#39;t complicate the function declaration</div><div><br></div><div>I d=
id consider allowing multiple function declarations with different designat=
ors in early stage, but the idea soon got dropped.</div><div>The idea was d=
ifferent from what you would expect though:</div><div class=3D"prettyprint"=
 style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; back=
ground-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> f<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">a</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">b</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: #008;"=
 class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </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 styl=
e=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">int</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: #000;" class=3D"styled-by-pret=
tify">y</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);<=
/span></div></code></div><div><br></div><div>The 2 declarations will be the=
 <i>same</i>=C2=A0function, not 2 overloads. This may be useful in some cas=
e but also confusing and may complicate the implementation so I dropped it.=
</div><div><br></div><div>As for allowing multiple identical declarations, =
my argument against it is for consistency, consider default arguments:</div=
><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); =
word-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 a </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #066;" class=3D"styled-by-prettify">1</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: #008;" =
class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 a </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">);</span></div></code></div><br>=
<div>It&#39;s not allowed even though the 2 are lexically identical, and I =
think the same should apply to designatable parameters as well.</div><div><=
br></div><div>What you suggested in the <font face=3D"courier new, monospac=
e">my_complex </font>example is to make them overloads, which is a design d=
ecision I don&#39;t want to take in this proposal.</div><div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; bo=
rder-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-st=
yle: solid; padding-left: 1ex;"><div dir=3D"ltr"><div class=3D"gmail_quote"=
><div></div><div>Have you considered the interaction of this proposal with =
forwarding functions and with types like std::function? I would find it pro=
blematic if correct forwarding is not possible for functions with designate=
d parameters. I think you will encounter resistance if something like this =
is not possible, and we have no known path forward to support it:</div><div=
><br></div><div>=C2=A0 void f(int .foo, int .bar);</div><div>=C2=A0 std::fu=
nction&lt;void(int .foo, int .bar)&gt; fn =3D f;</div><div>=C2=A0 fn(.bar =
=3D 1, .foo =3D 2);</div><div><br></div><div>One possible way to make this =
work could be:</div><div>=C2=A0(a) designated parameter names to become par=
t of a function type, and</div><div>=C2=A0(b) add a way to write a function=
 template that accepts a pack of designated parameters, capturing both the =
names and the values, and allowing both to be used when forwarding</div><di=
v>But (b) in particular seems like it would add a lot of complexity. I hope=
 there&#39;s a better alternative.</div></div></div></blockquote><div><br><=
/div><div>Actually, forwarding function is explicitly listed in my non-goal=
s, that&#39;s why I deliberately disable the indirect use in the end of sec=
tion 3.2.3.</div></div><div><br></div><div>If I were going to support forwa=
rding functions, that means I have to make designatable parameters part of =
the type as you suggested in (a), and that breaks my design principles.</di=
v><div>My choice for designated arguments is much like parameter pack, that=
 is, don&#39;t make them first class objects.</div><div><br></div><div>I sh=
ould emphasize how reluctant I am in interfering with the type system - it&=
#39;s a no-go for me if adding designatable parameters to existing API woul=
d break the ABI.</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/394c670e-6339-4933-abba-8f6d950dff47%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/394c670e-6339-4933-abba-8f6d950dff47=
%40isocpp.org</a>.<br />

------=_Part_7490_1624963422.1460603395052--
------=_Part_7489_1533469430.1460603395051--

.

------=_Part_689_413909276.1460604001501
Content-Type: multipart/alternative;
 boundary="----=_Part_690_111249681.1460604001501"

------=_Part_690_111249681.1460604001501
Content-Type: text/plain; charset=UTF-8

On Thursday, April 14, 2016 at 5:23:42 AM UTC+8, Ville Voutilainen wrote:
>
> On 14 April 2016 at 00:13,  <barry....@gmail.com <javascript:>> wrote:
> >> 2) a "works automatically" proposal comes in. The response is "well,
> >> that doesn't work with the standard library,
> >> and authors of other libraries don't want to have the introduced
> >> requirement to provide stable names without their opt-in,
> >> so <insert the work-arounds again>..."
> > Is that really the argument against "works automatically"?
>
> Well, considering that it was an argument that was raised when discussing
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4172.htm,
> sure, it's an argument against "works automatically". Whether you agree
> with
> that argument is a separate matter.
>
> > Library authors could simply not document/advertise those names (i.e.
> use those at your own
> > risk).  Keeping argument names stable doesn't strike me as more
> burdensome
> > than keep everything else stable. How often do you change an argument
> name,
> > but nothing else?
>
> Based on the arguments made when discussing the aforementioned paper,
> depending on who you
> ask, the answers are 1) that will not work 2) it is more burdensome
> and 3) often enough to oppose
> such a proposal.
>
> > Besides, Python has had this ability for years and been wildly
> successful at
> > sharing libraries.
>
> Yeah, but the argument is that C++ library writers know that they
> don't need to deal with it, and don't want
> it imposed on them, and then we go back to "both sides opt in" which
> will not work with the standard library,
> because unlike python and lisp, the argument names are not standardized in
> C++.
>

Do you mean the argument names cannot be standardized in the future? why?
I don't see any problem with the opt-in model I proposed, as I suggested in
section 4.1.

--
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/b787b0e5-9562-4b92-9a77-75c1bd1ca1ba%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, April 14, 2016 at 5:23:42 AM UTC+8, Ville Vou=
tilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 14 April 201=
6 at 00:13, =C2=A0&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"rG0tVAY2BAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#3=
9;;return true;">barry....@gmail.com</a>&gt; wrote:
<br>&gt;&gt; 2) a &quot;works automatically&quot; proposal comes in. The re=
sponse is &quot;well,
<br>&gt;&gt; that doesn&#39;t work with the standard library,
<br>&gt;&gt; and authors of other libraries don&#39;t want to have the intr=
oduced
<br>&gt;&gt; requirement to provide stable names without their opt-in,
<br>&gt;&gt; so &lt;insert the work-arounds again&gt;...&quot;
<br>&gt; Is that really the argument against &quot;works automatically&quot=
;?
<br>
<br>Well, considering that it was an argument that was raised when discussi=
ng
<br><a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4172.ht=
m" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http:=
//www.google.com/url?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fd=
ocs%2Fpapers%2F2014%2Fn4172.htm\46sa\75D\46sntz\0751\46usg\75AFQjCNHTbhmT5i=
q76k3DZVD7KaXhpI80Zw&#39;;return true;" onclick=3D"this.href=3D&#39;http://=
www.google.com/url?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdoc=
s%2Fpapers%2F2014%2Fn4172.htm\46sa\75D\46sntz\0751\46usg\75AFQjCNHTbhmT5iq7=
6k3DZVD7KaXhpI80Zw&#39;;return true;">http://open-std.org/JTC1/SC22/<wbr>WG=
21/docs/papers/2014/n4172.<wbr>htm</a>,
<br>sure, it&#39;s an argument against &quot;works automatically&quot;. Whe=
ther you agree with
<br>that argument is a separate matter.
<br>
<br>&gt; Library authors could simply not document/advertise those names (i=
..e. use those at your own
<br>&gt; risk). =C2=A0Keeping argument names stable doesn&#39;t strike me a=
s more burdensome
<br>&gt; than keep everything else stable. How often do you change an argum=
ent name,
<br>&gt; but nothing else?
<br>
<br>Based on the arguments made when discussing the aforementioned paper,
<br>depending on who you
<br>ask, the answers are 1) that will not work 2) it is more burdensome
<br>and 3) often enough to oppose
<br>such a proposal.
<br>
<br>&gt; Besides, Python has had this ability for years and been wildly suc=
cessful at
<br>&gt; sharing libraries.
<br>
<br>Yeah, but the argument is that C++ library writers know that they
<br>don&#39;t need to deal with it, and don&#39;t want
<br>it imposed on them, and then we go back to &quot;both sides opt in&quot=
; which
<br>will not work with the standard library,
<br>because unlike python and lisp, the argument names are not standardized=
 in C++.
<br></blockquote><div><br></div><div>Do you mean the argument names cannot =
be standardized in the future? why?</div><div>I don&#39;t see any problem w=
ith the opt-in model I proposed, as I suggested in section 4.1.</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/b787b0e5-9562-4b92-9a77-75c1bd1ca1ba%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b787b0e5-9562-4b92-9a77-75c1bd1ca1ba=
%40isocpp.org</a>.<br />

------=_Part_690_111249681.1460604001501--
------=_Part_689_413909276.1460604001501--

.

------=_Part_4332_1163592662.1460604415678
Content-Type: multipart/alternative;
 boundary="----=_Part_4333_766171330.1460604415678"

------=_Part_4333_766171330.1460604415678
Content-Type: text/plain; charset=UTF-8

On Thursday, April 14, 2016 at 4:50:08 AM UTC+8, Matthew Woehlke wrote:
>
> On 2016-04-13 16:10, Ville Voutilainen wrote:
> > A much bigger hurdle is having this proposal survive five minutes
> > after its presentation, because the previous ones dropped dead in
> > about that time.
> >
> > 1) a "both sides must opt in" proposal comes in. The response is
> > "this doesn't help anyone in the near future, and makes function
> > declarations more complex, for questionable benefit.
>
> Would it be the end of the world to make the following be synonymous?
>
>   int square(int .x);
>   int square([[named("x")]] int);
>   int square([[named("x")]] int not_x);
>
> I realize that attributes with meaning aren't loved, but the advantage
> this has is addressing the 'not useful *now*' complaint, by making it
> possible to write code (without using macros) that can be compiled with
> a C++11 compiler that still provides named arguments when used with a
> newer compiler. It also addresses the standard library to some extent,
> as it permits adding named arguments to the API while still allowing the
> implementation to use whatever it wants for names.


Why not macros? Is the following really that bad?

#if has_designatable_parameters
#define NAMED_PARAM(p) .p
#else
#define NAMED_PARAM(p) p
#endif

void f(int NAMED_PARAM(a)); // use it now

--
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/09493752-1475-4bc1-9b29-ec447c309339%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, April 14, 2016 at 4:50:08 AM UTC+8, Matthew W=
oehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2016-04-13 16:=
10, Ville Voutilainen wrote:
<br>&gt; A much bigger hurdle is having this proposal survive five minutes
<br>&gt; after its presentation, because the previous ones dropped dead in
<br>&gt; about that time.
<br>&gt;=20
<br>&gt; 1) a &quot;both sides must opt in&quot; proposal comes in. The res=
ponse is
<br>&gt; &quot;this doesn&#39;t help anyone in the near future, and makes f=
unction
<br>&gt; declarations more complex, for questionable benefit.
<br>
<br>Would it be the end of the world to make the following be synonymous?
<br>
<br>=C2=A0 int square(int .x);
<br>=C2=A0 int square([[named(&quot;x&quot;)]] int);
<br>=C2=A0 int square([[named(&quot;x&quot;)]] int not_x);
<br>
<br>I realize that attributes with meaning aren&#39;t loved, but the advant=
age
<br>this has is addressing the &#39;not useful *now*&#39; complaint, by mak=
ing it
<br>possible to write code (without using macros) that can be compiled with
<br>a C++11 compiler that still provides named arguments when used with a
<br>newer compiler. It also addresses the standard library to some extent,
<br>as it permits adding named arguments to the API while still allowing th=
e
<br>implementation to use whatever it wants for names.</blockquote><div><br=
></div><div>Why not macros? Is the following really that bad?</div><div><br=
></div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, =
187); word-wrap: break-word; background-color: rgb(250, 250, 250);"><code c=
lass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #8=
00;" class=3D"styled-by-prettify">#if has_designatable_parameters</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #800;" class=3D"styled-by-prettify">#define</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> NAMED_PARAM</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">p</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: #000;" class=3D"styled-by-pret=
tify">p<br></span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>#else</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">#define</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> NAMED_PARAM<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">p</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> p<br></span><span style=3D"color: #8=
00;" class=3D"styled-by-prettify">#endif</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 NAMED_PARAM</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">a</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: #800;" class=3D"styled-by-prettify">// use it now</span></div></code=
></div><div><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/09493752-1475-4bc1-9b29-ec447c309339%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/09493752-1475-4bc1-9b29-ec447c309339=
%40isocpp.org</a>.<br />

------=_Part_4333_766171330.1460604415678--
------=_Part_4332_1163592662.1460604415678--

.

On 04/14/2016 02:48 AM, Richard Smith wrote:
> I think increased complexity is the big one. Presumably we'd want this to=
 work:
>=20
> void f(int .a, int .b);
> void (*p)(int, int) =3D &f;
>=20
> ... which implies there is a conversion that discards the names from the =
type. Adding names should presumably also be permissible (perhaps with an e=
xplicit cast), as should calling through a function pointer whose parameter=
 names differ from those of the function.

Note that I've already done some work for function pointer conversions (4.1=
2)
when I introduced "noexcept" to the type system.  That doesn't mean it's
easy, but the locations that need changes are at least text-searchable.
=20
> That is: a new kind of template parameter representing a designator,
> and designator names are looked up to see if they name such a
> parameter before assuming they're an opaque identifier. (Plus a
> notional "empty designator" that is deduced in cases where no
> designator is specified.) I don't think I like this approach, and as
> noted, I hope there's a better answer.

Agreed, in particular with the last sentence.

Jens

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/570F9502.5080607%40gmx.net.

.

On 2016-04-13 17:55, Ville Voutilainen wrote:
> Well - 'automatic' ones are highly questionable because they don't
> work with the standard library, unless everything in it changes,
> which is not backwards compatible,

....Why? Parameter names today have no effect on the generated code. If
we take the route that they don't affect the ABI, then why can't they be
changed in order to conform to a new codification of what they should be?

(OTOH, of course, that's a massive change to codify all the parameter
names everywhere... it could be done piecemeal, though, with the
standard providing no guarantees except where the names are specified.)

> On 14 April 2016 at 00:39, Matthew Woehlke wrote:
>> On 13 April 2016 at 23:49, Matthew Woehlke wrote:
>>> Would it be the end of the world to make the following be synonymous?
>>>
>>>   int square(int .x);
>>>   int square([[named("x")]] int);
>>>   int square([[named("x")]] int not_x);
>>
>> The idea behind the above was to provide a not-too-painful mechanism
>> that would let authors that aren't willing to commit to C++20 to write
>> libraries that can require only C++11 but still provide named argument
>> support without too much pain, so that libraries can be forward-looking
>> in order to mitigate that complaint.
>
> Ah, so the expectation is that a C++11 implementation would just
> ignore the attributes it doesn't grok, and a C++20 implementation
> would give them semantic meaning. That is a silent change in meaning
> of code, and those tend to have a short life expectancy.

....no? There are no named parameter semantics in C++11/14/17. The only
change would be that a new feature is available in (e.g.) C++20. I don't
see how this would be any different from C11 designated initializers vs.
C89/C99. The only change is a pure *addition*; you can do something you
couldn't do before.

Mind, I'm assuming that parameter names do *not* affect the ABI, and
that if it affects the function pointer type, a function pointer type
with named parameters decays into the same signature less the parameter
names. If either of those is not the case, then yes, my idea would not
be reasonable :-).

>> (I would argue that if you aren't willing to commit to a stable API
>> argument name, you aren't committing to a stable API, period.)
>
> Well, today, and for multiple decades, an argument name has been an
> implementation detail, nothing more. Hence the argument that not
> providing a stable name means not providing a stable API cannot
> possibly be sound.

I didn't say "won't", I said "not willing". There is a subtle
difference. Yes, the name has no compiler-defined semantic at present.
What it *does* have is a user-defined semantic. The argument, in other
words, is to ask why you would need to *change* the parameter name, once
a reasonable one has been selected (and therefore made part of the API),
if the user semantic of the parameter has not changed. The obvious
reasons (change of semantic meaning of the parameter, massive change of
coding style) imply that your API *is actually different*, and
therefore, an API break is not only warranted, it may be a *feature*.

Especially with my idea that would allow separating API name from
implementation name, such a change becomes *by definition* an API
change. (Note also that I'm assuming an opt-in approach at least at the
political level; i.e. in case of an automatic approach, a library might
explicitly disclaim API compatibility across versions w.r.t. parameter
names.)

I'd be interested in examples why you would *need* to change a parameter
name (as exported in the API) when the semantic meaning of the parameter
is *not* changed.

--
Matthew

--
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/neo8ta%242go%241%40ger.gmane.org.

.

On 2016-04-13 23:26, TONGARI J wrote:
> Why not macros? Is the following really that bad?
>
> #if has_designatable_parameters
> #define NAMED_PARAM(p) .p
> #else
> #define NAMED_PARAM(p) p
> #endif

Yes. You have to either undefine this macro after use, or prefix it with
something unique. Remember, you're talking about a library that may be
one of many libraries used by an application, all of which want to use
such a macro, and all of which have their own subtly different version
thereof. (The only reasonable way around this might be to have the macro
specified by the standard, with the proviso that users may define it -
with a specified definition - if it is not defined.)

Also, don't discount being able to give the parameter different names in
the API vs. the implementation. Or people that just plain hate macros.

--
Matthew

--
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/neo92k%242go%242%40ger.gmane.org.

.

On 2016-04-13 17:42, Tony V E wrote:
> =E2=80=8E0. Naming is hard.=20

Yup :-).

> Something to consider: how would I later rename a param? Particularly onc=
e users have started =E2=80=8Eusing the old name and I don't want to break =
them. =20
>=20
> I could rename the whole function, but see #0 above. (and if it is the co=
nstructor, do I rename the whole class?)
>=20
> So it might be nice to allow ways to overload, even if the overload just =
turns around and calls the original:
>=20
> =E2=80=8Emy_complex(double .real, double .imag);
> // whoops! Coding guidelines say no short forms
> my_complex(doule .real, double .imaginary) ;

If this is the *only* case of renaming you want to support (i.e. same
functions with "options" for names), you could easily extend my
attribute idea to do that. Even better:

  my_complex(
    double
    [[named("real")]]
    p_u,
    double
    [[deprecated]] [[named("imag")]]
    [[named("imaginary")]]
    p_v);

(Syntax definitely needs some love, but you get the idea... and I was
even able to make the old name deprecated, so code using it will emit a
warning! Yes, I can do that with your version also, but the warning will
be slightly more specific with mine, as the compiler can tell you
specifically that a parameter name is what is deprecated and can suggest
the replacement name. For a case like this where the code semantics
haven't changed, it would even be fairly easy to write a tool to
automatically "update" user code.)

--=20
Matthew

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/neo9lc%24g2r%241%40ger.gmane.org.

.

On 14 April 2016 at 17:19, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> On 2016-04-13 17:55, Ville Voutilainen wrote:
>> Well - 'automatic' ones are highly questionable because they don't
>> work with the standard library, unless everything in it changes,
>> which is not backwards compatible,
>
> ...Why? Parameter names today have no effect on the generated code. If
> we take the route that they don't affect the ABI, then why can't they be
> changed in order to conform to a new codification of what they should be?

Because my standard library implementation needs to work with elder
front-ends, so
in order to add conditional support for named arguments, you need a
strong argument that named
arguments are useful and necessary. Every proposal author that has
proposed named
arguments has thus far failed to do that.

>>>> Would it be the end of the world to make the following be synonymous?
>>>>
>>>>   int square(int .x);
>>>>   int square([[named("x")]] int);
>>>>   int square([[named("x")]] int not_x);
>>>
>>> The idea behind the above was to provide a not-too-painful mechanism
>>> that would let authors that aren't willing to commit to C++20 to write
>>> libraries that can require only C++11 but still provide named argument
>>> support without too much pain, so that libraries can be forward-looking
>>> in order to mitigate that complaint.
>>
>> Ah, so the expectation is that a C++11 implementation would just
>> ignore the attributes it doesn't grok, and a C++20 implementation
>> would give them semantic meaning. That is a silent change in meaning
>> of code, and those tend to have a short life expectancy.
>
> ...no? There are no named parameter semantics in C++11/14/17. The only
> change would be that a new feature is available in (e.g.) C++20. I don't
> see how this would be any different from C11 designated initializers vs.
> C89/C99. The only change is a pure *addition*; you can do something you
> couldn't do before.

Yes, except that the meaning of the function declaration changes depending on
which front-end you use. I'm probably going to use a macro for such a
thing, at which
point the usefulness of supporting such an attribute there becomes
nil, because I can
just macro the dot-name of the argument while I'm at it.

>> Well, today, and for multiple decades, an argument name has been an
>> implementation detail, nothing more. Hence the argument that not
>> providing a stable name means not providing a stable API cannot
>> possibly be sound.
>
> I didn't say "won't", I said "not willing". There is a subtle
> difference. Yes, the name has no compiler-defined semantic at present.
> What it *does* have is a user-defined semantic. The argument, in other

I fail to see what that user-defined "semantic" could possibly be.

> words, is to ask why you would need to *change* the parameter name, once
> a reasonable one has been selected (and therefore made part of the API),
> if the user semantic of the parameter has not changed. The obvious
> reasons (change of semantic meaning of the parameter, massive change of
> coding style) imply that your API *is actually different*, and
> therefore, an API break is not only warranted, it may be a *feature*.

I fail to see how a change of coding style implies that the API is
different. Sure,
such an API break *may* be a feature, it may not.

> Especially with my idea that would allow separating API name from
> implementation name, such a change becomes *by definition* an API
> change. (Note also that I'm assuming an opt-in approach at least at the
> political level; i.e. in case of an automatic approach, a library might
> explicitly disclaim API compatibility across versions w.r.t. parameter
> names.)
>
> I'd be interested in examples why you would *need* to change a parameter
> name (as exported in the API) when the semantic meaning of the parameter
> is *not* changed.

I'm not sure whether I can find such examples. But other people report
they can easily
find examples where a declaration has a long elaborated name for a
parameter, and
the definition has a very terse name. The terse names may easily be changed over
time, and might e.g. become less terse. Even with your proposed
name-mapping, that
means changing multiple declarations, so named arguments do make such
name changes
much harder. So the question becomes "why bother"?

--
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/CAFk2RUYjitT7t%2BFq7VnKmDmud8xUwoNs0SLaiBAY94_NyrynKw%40mail.gmail.com.

.

On 2016-04-14 10:41, Ville Voutilainen wrote:
> On 14 April 2016 at 17:19, Matthew Woehlke wrote:
>> On 2016-04-13 17:55, Ville Voutilainen wrote:
>>> Well - 'automatic' ones are highly questionable because they don't
>>> work with the standard library, unless everything in it changes,
>>> which is not backwards compatible,
>>
>> ...Why? Parameter names today have no effect on the generated code. If
>> we take the route that they don't affect the ABI, then why can't they be
>> changed in order to conform to a new codification of what they should be=
?
>=20
> Because my standard library implementation needs to work with elder
> front-ends,

....but we were talking about *automatic* named parameters. We already
established that the parameter names don't matter currently, so why is
changing them to match an updated standard an issue?

In any case, I'm not seeing an issue here that can't be fixed with
macros, or (at least for "elderly" being minimum C++11) my attribute idea.

>>>>> Would it be the end of the world to make the following be synonymous?
>>>>>
>>>>>   int square(int .x);
>>>>>   int square([[named("x")]] int);
>>>>>   int square([[named("x")]] int not_x);
>>>>
>>>> The idea behind the above was to provide a not-too-painful mechanism
>>>> that would let authors that aren't willing to commit to C++20 to write
>>>> libraries that can require only C++11 but still provide named argument
>>>> support without too much pain, so that libraries can be forward-lookin=
g
>>>> in order to mitigate that complaint.
>>>
>>> Ah, so the expectation is that a C++11 implementation would just
>>> ignore the attributes it doesn't grok, and a C++20 implementation
>>> would give them semantic meaning. That is a silent change in meaning
>>> of code, and those tend to have a short life expectancy.
>>
>> ...no? There are no named parameter semantics in C++11/14/17. The only
>> change would be that a new feature is available in (e.g.) C++20. I don't
>> see how this would be any different from C11 designated initializers vs.
>> C89/C99. The only change is a pure *addition*; you can do something you
>> couldn't do before.
>=20
> Yes, except that the meaning of the function declaration changes

....in what way? You keep asserting this, but I am not understanding what
change you think is occurring. I can only assume therefore that we
aren't talking about the same implementation.

Given:

  int add(int [[named("a")] a, int [[named("b")]] b);

In both cases you have a function with the signature `int (int, int)`
(either because names aren't part of the type, or at least that decays
to that). In both cases, you can call the function like `add(2, 3);`.
All that has changed is that in one case you can *also* call it like
`add(.b =3D 3, .a =3D 2);`.

Again, this wasn't an issue for C11. Why would it be an issue for C++?

> I'm probably going to use a macro for such a thing, at which point
> the usefulness of supporting such an attribute there becomes nil,
> because I can just macro the dot-name of the argument while I'm at
> it.

Maybe. The advantage of the attribute is that it does not require a
macro (for people that hate those, and for people that care about
namespacing it properly), and allows the API name and implementation
name to be different.

Is that worth it? Maybe not :-).

>>> Well, today, and for multiple decades, an argument name has been an
>>> implementation detail, nothing more. Hence the argument that not
>>> providing a stable name means not providing a stable API cannot
>>> possibly be sound.
>>
>> I didn't say "won't", I said "not willing". There is a subtle
>> difference. Yes, the name has no compiler-defined semantic at present.
>> What it *does* have is a user-defined semantic. The argument, in other
>=20
> I fail to see what that user-defined "semantic" could possibly be.

The function/meaning of the parameter. For example, in `sin(double
..radians)`, the "user semantic" of `radians` is 'an angle in radians'.
If I want to rename that to `degrees`, it is a *feature* that this is an
API break, because the API did in fact change in a non-compatible
manner. This is different from "compiler semantic" because the compiler
(at least currently) has no way to diagnose if I pass degrees to a
function that expects radians, or vice versa.

Given a function where the parameter name is part of the API, I expect
that name to relate to the user-semantic of the parameter. A change in
the name=C2=B9 therefore implies a change in the user-semantic of the
parameter, which is an API break. Hopefully that makes sense now?

(=C2=B9 Tony V.E. already covered the one case I can think of where one mig=
ht
reasonably want to rename a parameter where no semantic change occurs.
See also my reply there.)

>> I'd be interested in examples why you would *need* to change a parameter
>> name (as exported in the API) when the semantic meaning of the parameter
>> is *not* changed.
>=20
> I'm not sure whether I can find such examples. But other people=20
> report they can easily find examples where a declaration has a long=20
> elaborated name for a parameter, and the definition has a very terse=20
> name. The terse names may easily be changed over time, and might e.g.
> become less terse.

Sounds like an advantage of my attribute idea.

> Even with your proposed name-mapping, that means changing multiple
> declarations,

Not if we don't allow overloading on names?=C2=B2

  // header
  int foo(int [[named("bar")]] maybe_bar);

  // implementation
  int foo(int not_bar) // note: API name not repeated
  { ... }

(=C2=B2 FWIW, I'll note that Python doesn't - at least not without jumping
through hoops - allow overloading *at all*, so this doesn't seem like an
unreasonable limitation. Especially if we ever get strong type aliases,
which would allow type overloading for most of the cases where you'd
otherwise want name overloading.)

--=20
Matthew

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/neocfe%242o8%241%40ger.gmane.org.

.

On 14 April 2016 at 18:20, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> On 2016-04-14 10:41, Ville Voutilainen wrote:
>> On 14 April 2016 at 17:19, Matthew Woehlke wrote:
>>> On 2016-04-13 17:55, Ville Voutilainen wrote:
>>>> Well - 'automatic' ones are highly questionable because they don't
>>>> work with the standard library, unless everything in it changes,
>>>> which is not backwards compatible,
>>>
>>> ...Why? Parameter names today have no effect on the generated code. If
>>> we take the route that they don't affect the ABI, then why can't they be
>>> changed in order to conform to a new codification of what they should be?
>>
>> Because my standard library implementation needs to work with elder
>> front-ends,
>
> ...but we were talking about *automatic* named parameters. We already
> established that the parameter names don't matter currently, so why is
> changing them to match an updated standard an issue?

Because I expect that in that newer standard they won't be uglified,
whereas they
need to be when an older standard is used, so now I have to write conditional
code. I don't have time to do such nonsensical work unless the
motivation for it is strong.

> In any case, I'm not seeing an issue here that can't be fixed with
> macros, or (at least for "elderly" being minimum C++11) my attribute idea.

Yay, so we fix a problem with macros, and now we have two problems. :)

>>>>>> Would it be the end of the world to make the following be synonymous?
>>>>>>
>>>>>>   int square(int .x);
>>>>>>   int square([[named("x")]] int);
>>>>>>   int square([[named("x")]] int not_x);
>>>>>
>>>>> The idea behind the above was to provide a not-too-painful mechanism
>>>>> that would let authors that aren't willing to commit to C++20 to write
>>>>> libraries that can require only C++11 but still provide named argument
>>>>> support without too much pain, so that libraries can be forward-looking
>>>>> in order to mitigate that complaint.
>>>>
>>>> Ah, so the expectation is that a C++11 implementation would just
>>>> ignore the attributes it doesn't grok, and a C++20 implementation
>>>> would give them semantic meaning. That is a silent change in meaning
>>>> of code, and those tend to have a short life expectancy.
>>>
>>> ...no? There are no named parameter semantics in C++11/14/17. The only
>>> change would be that a new feature is available in (e.g.) C++20. I don't
>>> see how this would be any different from C11 designated initializers vs.
>>> C89/C99. The only change is a pure *addition*; you can do something you
>>> couldn't do before.
>>
>> Yes, except that the meaning of the function declaration changes
>
> ...in what way? You keep asserting this, but I am not understanding what
> change you think is occurring. I can only assume therefore that we
> aren't talking about the same implementation.
>
> Given:
>
>   int add(int [[named("a")] a, int [[named("b")]] b);
>
> In both cases you have a function with the signature `int (int, int)`
> (either because names aren't part of the type, or at least that decays
> to that). In both cases, you can call the function like `add(2, 3);`.
> All that has changed is that in one case you can *also* call it like
> `add(.b = 3, .a = 2);`.

Well, duh, I can now also call the function like that because the meaning
of the function declaration changed. Had it not changed, I wouldn't be able
to call it that way. The meaning now changes automatically, regardless
of whether
I change anything anywhere. I might not want that, which is why I would probably
macro-conditionalize the declaration anyway, and therefore the
attribute doesn't help
me at all.

>>>> Well, today, and for multiple decades, an argument name has been an
>>>> implementation detail, nothing more. Hence the argument that not
>>>> providing a stable name means not providing a stable API cannot
>>>> possibly be sound.
>>>
>>> I didn't say "won't", I said "not willing". There is a subtle
>>> difference. Yes, the name has no compiler-defined semantic at present.
>>> What it *does* have is a user-defined semantic. The argument, in other
>>
>> I fail to see what that user-defined "semantic" could possibly be.
> The function/meaning of the parameter. For example, in `sin(double
> .radians)`, the "user semantic" of `radians` is 'an angle in radians'.
> If I want to rename that to `degrees`, it is a *feature* that this is an
> API break, because the API did in fact change in a non-compatible
> manner. This is different from "compiler semantic" because the compiler
> (at least currently) has no way to diagnose if I pass degrees to a
> function that expects radians, or vice versa.

In other words, you think you can make names have a "user semantic" if
named arguments are supported. That doesn't mean that all names have such
"user semantics", because currently none of them do, hence my confusion about
what these "user semantics" are. Today, they are a figment of imagination. With
named arguments, they might be a thing, although they might not be. I wouldn't
call that the strongest rationale for named arguments.

--
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/CAFk2RUYniDB%3DtnGxERowN9qattWardzCYXhxn95sdCHfAOe4_A%40mail.gmail.com.

.

------=_Part_7839_1214289465.1460648998777
Content-Type: multipart/alternative;
 boundary="----=_Part_7840_1386096026.1460648998788"

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

On Thursday, April 14, 2016 at 11:20:35 PM UTC+8, Matthew Woehlke wrote:
>
> Not if we don't allow overloading on names?=C2=B2=20
>
>   // header=20
>   int foo(int [[named("bar")]] maybe_bar);=20
>
>   // implementation=20
>   int foo(int not_bar) // note: API name not repeated=20
>   { ... }=20
>

Out of curious, why bother to specify maybe_bar in the header? Is the name=
=20
used anywhere?

FWIW, in my proposal, this is allowed:

int foo(int .bar);
int foo(int not_bar);

But this is not:

int foo(int .bar);
int foo(int .not_bar);

section 5.6=20
<http://jamboree.github.io/designator-draft.html#56-why-not-allow-parameter=
-name-based-overloading> gave=20
some rationale. What Tony V.E described is path 1, and what Richard=20
Smith described is path 2.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/6ea2b03c-445d-4dc2-a9f7-e359a480dcaf%40isocpp.or=
g.

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

<div dir=3D"ltr">On Thursday, April 14, 2016 at 11:20:35 PM UTC+8, Matthew =
Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Not if we don&#3=
9;t allow overloading on names?=C2=B2
<br>
<br>=C2=A0 // header
<br>=C2=A0 int foo(int [[named(&quot;bar&quot;)]] maybe_bar);
<br>
<br>=C2=A0 // implementation
<br>=C2=A0 int foo(int not_bar) // note: API name not repeated
<br>=C2=A0 { ... }
<br></blockquote><div><br></div><div><span style=3D"font-family: arial, san=
s-serif; font-size: small;">Out of curious, why bother to specify=C2=A0</sp=
an><span style=3D"font-size: small;"><font face=3D"courier new, monospace">=
maybe_bar</font></span>=C2=A0in the header? Is the name used anywhere?</div=
><div><br></div><div>FWIW, in my proposal, this is allowed:</div><div><br><=
/div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 18=
7); word-wrap: break-word; background-color: rgb(250, 250, 250);"><code cla=
ss=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008=
;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">bar</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"co=
lor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> not_bar</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">);</span></div></code></div><div><br>But this is not:</div><div><=
br></div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187=
, 187); word-wrap: break-word; background-color: rgb(250, 250, 250);"><code=
 class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: =
#008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">.=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">bar</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">n=
ot_bar</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</=
span></div></code></div><br><div><a href=3D"http://jamboree.github.io/desig=
nator-draft.html#56-why-not-allow-parameter-name-based-overloading">section=
 5.6</a>=C2=A0gave some rationale. What Tony V.E described is path 1,=C2=A0=
and what Richard Smith=C2=A0described is path=C2=A02.</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/6ea2b03c-445d-4dc2-a9f7-e359a480dcaf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6ea2b03c-445d-4dc2-a9f7-e359a480dcaf=
%40isocpp.org</a>.<br />

------=_Part_7840_1386096026.1460648998788--
------=_Part_7839_1214289465.1460648998777--

.

On 2016-04-14 11:30, Ville Voutilainen wrote:
> On 14 April 2016 at 18:20, Matthew Woehlke wrote:
>> ...but we were talking about *automatic* named parameters. We already
>> established that the parameter names don't matter currently, so why is
>> changing them to match an updated standard an issue?
>
> Because I expect that in that newer standard they won't be uglified,
> whereas they need to be when an older standard is used,

I don't get it. If parameter names don't matter in "old" C++, why must
the 'ugly' names be used? What am I missing?

>> On 2016-04-14 10:41, Ville Voutilainen wrote:
>>> [...] the meaning of the function declaration changes
>>
>> ...in what way? You keep asserting this, but I am not understanding what
>> change you think is occurring. I can only assume therefore that we
>> aren't talking about the same implementation.
>>
>> Given:
>>
>>   int add(int [[named("a")] a, int [[named("b")]] b);
>>
>> In both cases you have a function with the signature `int (int, int)`
>> (either because names aren't part of the type, or at least that decays
>> to that). In both cases, you can call the function like `add(2, 3);`.
>> All that has changed is that in one case you can *also* call it like
>> `add(.b = 3, .a = 2);`.
>
> Well, duh, I can now also call the function like that because the meaning
> of the function declaration changed. Had it not changed, I wouldn't be able
> to call it that way.

Huh?

Let me try rephrasing this. Let's say we have a C struct:

  struct foo { int bar };

In C89, the "meaning" of this struct is that I can construct it like
`{1}`. In C11, the "meaning" is that I can (additionally) construct it
like `{.bar=1}`. This was evidently not a problem for C11. What "change
of meaning" occurs in C++ that is different from this example and
therefore problematic?

>> The function/meaning of the parameter. For example, in `sin(double
>> .radians)`, the "user semantic" of `radians` is 'an angle in radians'.
>> If I want to rename that to `degrees`, it is a *feature* that this is an
>> API break, because the API did in fact change in a non-compatible
>> manner. This is different from "compiler semantic" because the compiler
>> (at least currently) has no way to diagnose if I pass degrees to a
>> function that expects radians, or vice versa.
>
> In other words, you think you can make names have a "user semantic" if
> named arguments are supported.

They would (when employed) become part of the public API in the same
manner as the function name, with similar issues arising if you want to
change the names. (In fact, I hadn't realized this before... the same
problems that would arise with renaming named parameters *already exist*
w.r.t. the name of the function itself. And yet, somehow we're managing.)

> That doesn't mean that all names have such
> "user semantics", because currently none of them do, hence my confusion about
> what these "user semantics" are. Today, they are a figment of imagination. With
> named arguments, they might be a thing, although they might not be. I wouldn't
> call that the strongest rationale for named arguments.

Ah... I think you perhaps misunderstand the intended scope. This
particular argument is not meant as an argument *for* named parameters,
only as an argument why the concern about "committing my API to a name"
is possibly overemphasized.

--
Matthew

--
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/neoelk%249ko%241%40ger.gmane.org.

.

On 14 April 2016 at 18:57, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> On 2016-04-14 11:30, Ville Voutilainen wrote:
>> On 14 April 2016 at 18:20, Matthew Woehlke wrote:
>>> ...but we were talking about *automatic* named parameters. We already
>>> established that the parameter names don't matter currently, so why is
>>> changing them to match an updated standard an issue?
>>
>> Because I expect that in that newer standard they won't be uglified,
>> whereas they need to be when an older standard is used,
>
> I don't get it. If parameter names don't matter in "old" C++, why must
> the 'ugly' names be used? What am I missing?

Macros must not leak in?

>
>>> On 2016-04-14 10:41, Ville Voutilainen wrote:
>>>> [...] the meaning of the function declaration changes
>>>
>>> ...in what way? You keep asserting this, but I am not understanding what
>>> change you think is occurring. I can only assume therefore that we
>>> aren't talking about the same implementation.
>>>
>>> Given:
>>>
>>>   int add(int [[named("a")] a, int [[named("b")]] b);
>>>
>>> In both cases you have a function with the signature `int (int, int)`
>>> (either because names aren't part of the type, or at least that decays
>>> to that). In both cases, you can call the function like `add(2, 3);`.
>>> All that has changed is that in one case you can *also* call it like
>>> `add(.b = 3, .a = 2);`.
>>
>> Well, duh, I can now also call the function like that because the meaning
>> of the function declaration changed. Had it not changed, I wouldn't be able
>> to call it that way.
>
> Huh?
>
> Let me try rephrasing this. Let's say we have a C struct:
>
>   struct foo { int bar };
>
> In C89, the "meaning" of this struct is that I can construct it like
> `{1}`. In C11, the "meaning" is that I can (additionally) construct it
> like `{.bar=1}`. This was evidently not a problem for C11. What "change
> of meaning" occurs in C++ that is different from this example and
> therefore problematic?

With an opt-in, there is no problem, since I can choose with a macro
whether I opt in or not.
I can do that without the attributes you propose. So, again, those
attributes don't seem to be useful.
I don't want to use such attributes because then the opt-in happens
half-automatically, although
I admit that's not a huge problem because nobody is forcing me to use
those attributes.

--
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/CAFk2RUbO7BRVJtqaKkorPUQwkFAyyEy6OcE-svfyQVpwU7BODQ%40mail.gmail.com.

.

On 2016-04-14 11:49, TONGARI J wrote:
> On Thursday, April 14, 2016 at 11:20:35 PM UTC+8, Matthew Woehlke wrote:
>>   // header
>>   int foo(int [[named("bar")]] maybe_bar);
>>
>>   // implementation
>>   int foo(int not_bar) // note: API name not repeated
>>   { ... }
>
> Out of curious, why bother to specify maybe_bar in the header?

Purely for illustrative purposes. I wanted to show that the
implementation name in a declaration can be different from the
implementation name in the definition. I could also have omitted it
entirely.

> FWIW, in my proposal, this is allowed:
>
> int foo(int .bar);
> int foo(int not_bar);

Cool :-). FWIW, I think that's a good approach.

--
Matthew

--
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/neoesl%24dd9%241%40ger.gmane.org.

.

On 2016-04-14 12:03, Ville Voutilainen wrote:
> On 14 April 2016 at 18:57, Matthew Woehlke wrote:
>> On 2016-04-14 11:30, Ville Voutilainen wrote:
>>> On 14 April 2016 at 18:20, Matthew Woehlke wrote:
>>>> ...but we were talking about *automatic* named parameters. We already
>>>> established that the parameter names don't matter currently, so why is
>>>> changing them to match an updated standard an issue?
>>>
>>> Because I expect that in that newer standard they won't be uglified,
>>> whereas they need to be when an older standard is used,
>>
>> I don't get it. If parameter names don't matter in "old" C++, why must
>> the 'ugly' names be used? What am I missing?
>
> Macros must not leak in?

Do you mean that, for example std::map::find cannot use `key` as the
parameter name in case the user has done `#define key` somewhere?

If yes, a) wouldn't that be a problem for a "modern" standard library
with codified parameter names also, and b) isn't this solved by my
attribute idea? (In particular, because the parameter name given in an
attribute is quoted, it should not be subject to PP 'tampering'. This is
not the case with `.name` as in the original proposal.)

--
Matthew

--
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/neohhj%24r38%241%40ger.gmane.org.

.

On 14 April 2016 at 19:46, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>>> I don't get it. If parameter names don't matter in "old" C++, why must
>>> the 'ugly' names be used? What am I missing?
>>
>> Macros must not leak in?
>
> Do you mean that, for example std::map::find cannot use `key` as the
> parameter name in case the user has done `#define key` somewhere?

Yes.

> If yes, a) wouldn't that be a problem for a "modern" standard library
> with codified parameter names also, and b) isn't this solved by my

Excellent question. :) Yes, I think a modern library should solve that
problem too.

> attribute idea? (In particular, because the parameter name given in an
> attribute is quoted, it should not be subject to PP 'tampering'. This is

Yay.. I mean, eurgh. :)

> not the case with `.name` as in the original proposal.)

How so? I don't think you can #define .name whatever.

--
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/CAFk2RUb-5N1JAesthOWeRzCou8kOaXTL0dmT0d9pmP77v-8pDw%40mail.gmail.com.

.

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

On Wed, Apr 13, 2016 at 8:09 PM, TONGARI J <tongari95@gmail.com> wrote:

> Hi Richard,
>
> On Thursday, April 14, 2016 at 3:31:20 AM UTC+8, Richard Smith wrote:
>>
>> This looks more or less like how I'd always imagined designated
>> initializers would work in C++. Thanks for writing this! One question, you
>> say:
>>
>> "3.2.1.1 Function redeclaration
>>
>> If a function is declared with designatable parameters and/or default
>> arguments, it cannot be redeclared with designatable parameters and/or
>> default arguments, otherwise, the program is ill-formed."
>>
>> This seems very strange to me. I would expect that:
>> a) every declaration of the same function must specify the same
>> designatable parameters, with the same names, and
>> b) perhaps overloading on designated parameter names should be permitted
>>
>> One example of why (b) would be useful:
>>
>> struct my_complex {
>>   my_complex(double .rho, double .theta);
>>   my_complex(double .real, double .imag);
>> };
>>
>> Here, these constructors could *only* be called with designated parameter
>> names, because any non-designated call would be ambiguous.
>>
>
> There are some principles I set when designing the feature:
> * Don't interfere with the type system
>

Please allow me to suggest an alternative principle: integrate into the
existing language.

Far too often, people proposing features make the mistake of making their
feature be its own special island that has rules different from the rest of
the language. This is a trap to be avoided. Language continuity is
important: C++20 should look and feel like a development of C++17, in order
to make it easier for programmers and programs to adapt, but we don't get
there by minimizing the amount of change to the language or specification,
we get there by making the changes complete so they feel like an extension
of what came before.

A feature that does not integrate into the type system, but whose design
would naturally lead to type system changes, is flawed. In my opinion, you
should first design the feature, and then analyze the type system
implications, not the other way around. (And if that leads to no type
system changes, that's fine, of course.)

* Don't require ABI changes
>

I think you should distinguish between "don't change the ABI of existing
libraries" and "don't change the ABI when designated parameters are added
to an interface". The first seems like an important principle. The second,
less so -- as long as the library maintainer still gets to control their
ABI as they see fit.


> * Don't complicate the function declaration
>
> I did consider allowing multiple function declarations with different
> designators in early stage, but the idea soon got dropped.
> The idea was different from what you would expect though:
> void f(int .a, int .b);
> void f(int .x, int .y);
>
> The 2 declarations will be the *same* function, not 2 overloads. This may
> be useful in some case but also confusing and may complicate the
> implementation so I dropped it.
>
> As for allowing multiple identical declarations, my argument against it is
> for consistency, consider default arguments:
> void f(int a = 1);
> void f(int a = 1);
>
> It's not allowed even though the 2 are lexically identical, and I think
> the same should apply to designatable parameters as well.
>
> What you suggested in the my_complex example is to make them overloads,
> which is a design decision I don't want to take in this proposal.
>
>
>> Have you considered the interaction of this proposal with forwarding
>> functions and with types like std::function? I would find it problematic if
>> correct forwarding is not possible for functions with designated
>> parameters. I think you will encounter resistance if something like this is
>> not possible, and we have no known path forward to support it:
>>
>>   void f(int .foo, int .bar);
>>   std::function<void(int .foo, int .bar)> fn = f;
>>   fn(.bar = 1, .foo = 2);
>>
>> One possible way to make this work could be:
>>  (a) designated parameter names to become part of a function type, and
>>  (b) add a way to write a function template that accepts a pack of
>> designated parameters, capturing both the names and the values, and
>> allowing both to be used when forwarding
>> But (b) in particular seems like it would add a lot of complexity. I hope
>> there's a better alternative.
>>
>
> Actually, forwarding function is explicitly listed in my non-goals, that's
> why I deliberately disable the indirect use in the end of section 3.2.3.
>

The fact that this is a non-goal is going to make your proposal very
unappealing to some portion of the committee.


> If I were going to support forwarding functions, that means I have to make
> designatable parameters part of the type as you suggested in (a), and that
> breaks my design principles.
> My choice for designated arguments is much like parameter pack, that is,
> don't make them first class objects.
>
> I should emphasize how reluctant I am in interfering with the type system
> - it's a no-go for me if adding designatable parameters to existing API
> would break the ABI.
>

Adding parameters with default arguments to existing API would break the
ABI too, as would many other API changes. With a suitable overload
resolution rule, I'd expect to be able to change an API that does this:

  struct A {
    void f(int a, int b);
  };

.... to do this:

  struct A {
    void f(int a, int b);
    void f(int .a, int .b) { f(a, b); }
  };

.... as a non-breaking change (except if someone is taking the address of
the function), for people who need perfect ABI compatibility.

--
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/CAOfiQqkL-hpY2KMY8JGGk6KZ3ApDqtZvKCaJeFe0Z5fnFdd13g%40mail.gmail.com.

--001a113ea5f07cdfbe053075a000
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 W=
ed, Apr 13, 2016 at 8:09 PM, TONGARI J <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:tongari95@gmail.com" target=3D"_blank">tongari95@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi Richard,<sp=
an class=3D""><br><br>On Thursday, April 14, 2016 at 3:31:20 AM UTC+8, Rich=
ard Smith 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">Th=
is looks more or less like how I&#39;d always imagined designated initializ=
ers would work in C++. Thanks for writing this! One question, you say:<div>=
<br></div><div><div>&quot;3.2.1.1 Function redeclaration</div><div><br></di=
v><div>If a function is declared with designatable parameters and/or defaul=
t arguments, it cannot be redeclared with designatable parameters and/or de=
fault arguments, otherwise, the program is ill-formed.&quot;</div><div><br>=
</div></div><div>This seems very strange to me. I would expect that:</div><=
div>a) every declaration of the same function must specify the same designa=
table parameters, with the same names, and</div><div>b) perhaps overloading=
 on designated parameter names should be permitted</div><div><br></div><div=
>One example of why (b) would be useful:</div><div><br></div><div>struct my=
_complex {</div><div>=C2=A0 my_complex(double .rho, double .theta);</div><d=
iv>=C2=A0 my_complex(double .real, double .imag);</div><div>};</div><div><b=
r></div><div>Here, these constructors could *only* be called with designate=
d parameter names, because any non-designated call would be ambiguous.</div=
></div></blockquote><div><br></div></span><div>There are some principles I =
set when designing the feature:</div><div>* Don&#39;t interfere with the ty=
pe system</div></div></blockquote><div><br></div><div>Please allow me to su=
ggest an alternative principle: integrate into the existing language.</div>=
<div><br></div><div>Far too often, people proposing features make the mista=
ke of making their feature be its own special island that has rules differe=
nt from the rest of the language. This is a trap to be avoided. Language co=
ntinuity is important: C++20 should look and feel like a development of C++=
17, in order to make it easier for programmers and programs to adapt, but w=
e don&#39;t get there by minimizing the amount of change to the language or=
 specification, we get there by making the changes complete so they feel li=
ke an extension of what came before.</div><div><br></div><div>A feature tha=
t does not integrate into the type system, but whose design would naturally=
 lead to type system changes, is flawed. In my opinion, you should first de=
sign the feature, and then analyze the type system implications, not the ot=
her way around. (And if that leads to no type system changes, that&#39;s fi=
ne, of course.)</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div>* Don&#39;t require ABI changes</div></div></blockquote><div>=
<br></div><div>I think you should distinguish between &quot;don&#39;t chang=
e the ABI of existing libraries&quot; and &quot;don&#39;t change the ABI wh=
en designated parameters are added to an interface&quot;. The first seems l=
ike an important principle. The second, less so -- as long as the library m=
aintainer still gets to control their ABI as they see fit.</div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>* Don&#39;t comp=
licate the function declaration</div><div><br></div><div>I did consider all=
owing multiple function declarations with different designators in early st=
age, but the idea soon got dropped.</div><div>The idea was different from w=
hat you would expect though:</div><div style=3D"border:1px solid rgb(187,18=
7,187);word-wrap:break-word;background-color:rgb(250,250,250)"><code><div><=
span class=3D""><span style=3D"color:#008">void</span><span style=3D"color:=
#000"> f</span><span style=3D"color:#660">(</span><span style=3D"color:#008=
">int</span><span style=3D"color:#000"> </span><span style=3D"color:#660">.=
</span><span style=3D"color:#000">a</span><span style=3D"color:#660">,</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#008">int</span><=
span style=3D"color:#000"> </span><span style=3D"color:#660">.</span><span =
style=3D"color:#000">b</span><span style=3D"color:#660">);</span><span styl=
e=3D"color:#000"><br></span></span><span style=3D"color:#008">void</span><s=
pan style=3D"color:#000"> f</span><span style=3D"color:#660">(</span><span =
style=3D"color:#008">int</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#660">.</span><span style=3D"color:#000">x</span><span style=3D=
"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#008">int</span><span style=3D"color:#000"> </span><span style=3D"color:#=
660">.</span><span style=3D"color:#000">y</span><span style=3D"color:#660">=
);</span></div></code></div><div><br></div><div>The 2 declarations will be =
the <i>same</i>=C2=A0function, not 2 overloads. This may be useful in some =
case but also confusing and may complicate the implementation so I dropped =
it.</div><div><br></div><div>As for allowing multiple identical declaration=
s, my argument against it is for consistency, consider default arguments:</=
div><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;ba=
ckground-color:rgb(250,250,250)"><code><div><span style=3D"color:#008">void=
</span><span style=3D"color:#000"> f</span><span style=3D"color:#660">(</sp=
an><span style=3D"color:#008">int</span><span style=3D"color:#000"> a </spa=
n><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><=
span style=3D"color:#066">1</span><span style=3D"color:#660">);</span><span=
 style=3D"color:#000"><br></span><span style=3D"color:#008">void</span><spa=
n style=3D"color:#000"> f</span><span style=3D"color:#660">(</span><span st=
yle=3D"color:#008">int</span><span style=3D"color:#000"> a </span><span sty=
le=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span style=
=3D"color:#066">1</span><span style=3D"color:#660">);</span></div></code></=
div><br><div>It&#39;s not allowed even though the 2 are lexically identical=
, and I think the same should apply to designatable parameters as well.</di=
v><div><br></div><div>What you suggested in the <font face=3D"courier new, =
monospace">my_complex </font>example is to make them overloads, which is a =
design decision I don&#39;t want to take in this proposal.</div><div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><s=
pan class=3D""><div></div><div>Have you considered the interaction of this =
proposal with forwarding functions and with types like std::function? I wou=
ld find it problematic if correct forwarding is not possible for functions =
with designated parameters. I think you will encounter resistance if someth=
ing like this is not possible, and we have no known path forward to support=
 it:</div><div><br></div><div>=C2=A0 void f(int .foo, int .bar);</div><div>=
=C2=A0 std::function&lt;void(int .foo, int .bar)&gt; fn =3D f;</div><div>=
=C2=A0 fn(.bar =3D 1, .foo =3D 2);</div><div><br></div><div>One possible wa=
y to make this work could be:</div><div>=C2=A0(a) designated parameter name=
s to become part of a function type, and</div></span><span class=3D""><div>=
=C2=A0(b) add a way to write a function template that accepts a pack of des=
ignated parameters, capturing both the names and the values, and allowing b=
oth to be used when forwarding</div></span><span class=3D""><div>But (b) in=
 particular seems like it would add a lot of complexity. I hope there&#39;s=
 a better alternative.</div></span></div></div></blockquote><div><br></div>=
<div>Actually, forwarding function is explicitly listed in my non-goals, th=
at&#39;s why I deliberately disable the indirect use in the end of section =
3.2.3.</div></div></div></blockquote><div><br></div><div>The fact that this=
 is a non-goal is going to make your proposal very unappealing to some port=
ion of the committee.</div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr"><div>If I were going to support forwarding functions, that=
 means I have to make designatable parameters part of the type as you sugge=
sted in (a), and that breaks my design principles.</div><div>My choice for =
designated arguments is much like parameter pack, that is, don&#39;t make t=
hem first class objects.</div><div><br></div><div>I should emphasize how re=
luctant I am in interfering with the type system - it&#39;s a no-go for me =
if adding designatable parameters to existing API would break the ABI.</div=
></div></blockquote><div><br></div><div>Adding parameters with default argu=
ments to existing API would break the ABI too, as would many other API chan=
ges. With a suitable overload resolution rule, I&#39;d expect to be able to=
 change an API that does this:</div><div><br></div><div>=C2=A0 struct A {</=
div><div>=C2=A0 =C2=A0 void f(int a, int b);</div><div>=C2=A0 };</div><div>=
<br></div><div>... to do this:</div><div><br></div><div>=C2=A0 struct A {</=
div><div>=C2=A0 =C2=A0 void f(int a, int b);</div><div>=C2=A0 =C2=A0 void f=
(int .a, int .b) { f(a, b); }</div><div>=C2=A0 };</div><div><br></div><div>=
.... as a non-breaking change (except if someone is taking the address of th=
e function), for people who need perfect ABI compatibility.</div></div></di=
v></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/CAOfiQqkL-hpY2KMY8JGGk6KZ3ApDqtZvKCaJ=
eFe0Z5fnFdd13g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqkL-hpY2KMY=
8JGGk6KZ3ApDqtZvKCaJeFe0Z5fnFdd13g%40mail.gmail.com</a>.<br />

--001a113ea5f07cdfbe053075a000--

.

On 2016-04-14 13:54, Ville Voutilainen wrote:
> On 14 April 2016 at 19:46, Matthew Woehlke wrote:
>> (In particular, because the parameter name given in an attribute is
>> quoted, it should not be subject to PP 'tampering'. This is not the
>> case with `.name` as in the original proposal.)
>=20
> How so? I don't think you can #define .name whatever.

No, but if you `#define name oops`, `.name` will be replaced with
`.oops`. (There is a certain nasty case that recently bit me where
_GNU_SOURCE "adds" a pseudo-member to a system struct using exactly this
kludge; ugh. Also, I just checked=C2=B9 :-).)

(=C2=B9 `echo -e '#define foo bar\nnone(.foo =3D 5);' | gcc -E -`)

--=20
Matthew

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/neoo26%249s3%241%40ger.gmane.org.

.

On 2016-04-14 13:57, Richard Smith wrote:
> Adding parameters with default arguments to existing API would break the
> ABI too, as would many other API changes. With a suitable overload
> resolution rule, I'd expect to be able to change an API that does this:
>=20
>   struct A {
>     void f(int a, int b);
>   };
>=20
> ... to do this:
>=20
>   struct A {
>     void f(int a, int b);
>     void f(int .a, int .b) { f(a, b); }
>   };
>=20
> ... as a non-breaking change (except if someone is taking the address of
> the function), for people who need perfect ABI compatibility.

I'd expect that this:

  struct A {
    void f(int .a, int .b);
  };

....is a (mostly?=C2=B9) non-breaking change. Yes, function pointer and all;
*if* named parameters are part of the function type, then IMO the
respective pointer types should implicitly decay to pointers with fewer
named arguments. IOW:

  int f(int .a, int .b);
  int (*p1)(int .a, int .b) =3D &f; // okay
  int (*p2)(int, int .b) =3D &f; // also okay
  int (*p3)(int, int) =3D &f; // also okay

  int g(int .a, int .b);
  int g(int .x, int .y);
  int (*p4)(int .a, int .b) =3D &g; // okay
  int (*p5)(int, int .b) =3D &g; // still okay
  int (*p6)(int, int) =3D &g; // error: ambiguous
  int (*p7)(int, int) =3D p4; // okay

(=C2=B9 There might be cases where the change in type of the function point=
er
breaks something, but not just due to trying to feed it to something
that expects the no-named-parameters pointer type.)

However, I'll mention again that IMO there are non-trivial issues
including parameter names in the type system, and that the language most
commonly cited for supporting named parameters (Python) *doesn't allow
overloading* (at all). Also, that most cases that come to mind where
you'd want it seem better solved with strong type aliases. This causes
me to strongly question the value of including parameter names in the
type system.

--=20
Matthew

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/neop0a%24n8b%241%40ger.gmane.org.

.

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

=E2=80=8BFeels like designated initialization of =E2=80=8BPOD types is less=
 controversial,
more conservative, yet more elegant than expected.
For naming function arguments one might wrap it in a function object:

struct caller;
void caller::operator()()
{
    f(x,y);
};
caller{.x=3D1,.y=3D2}();

or even shorter:

struct caller;
caller::~caller()
{
    f(x,y);
};
caller{.x=3D1,.y=3D2};

Of Course it doesn't cover every corner case of function calls such as
constructor with named args(eg. std::vector::vector or
std::complex::complex).

For constructors I would rather put all args in a POD type:

std::complex<double>   c1{ polar{ .magnitude=3D1.0, .angle=3Ddegree(30) } }=
;
std::complex<double>   c1{ cartesian{ .real=3D1.0, .image=3D1.0 } };

I agree that this is not as sweat as functions with named variables.

Another more fundamental problem with types is that uninitialized members
will try to use implicit default constructors. This might partially be
overcome by forcing the programmer to explicitly initialize members:

struct bar{
      //new syntax:
      explicit int x;// explicitly initialized
      int y;            // don't care about y
};

bar b1{1,2};  //ok
bar b2{.x=3D2};//ok
bar b3;         //compile error: x not initialized

or even stricter:

//new syntax:
explicit struct foo //every member is explicitly initialized, except if
defaulted
{
     int x;
     int y=3D1;  // y has default value
};

foo f1{.x=3D0};         //ok
foo f2{.y=3D2,.x=3D0}; //ok
foo f3;                  //compile error: x not initialized

regards,
FM.


2016-04-14 23:24 GMT+04:30 Matthew Woehlke <mwoehlke.floss@gmail.com>:

> On 2016-04-14 13:57, Richard Smith wrote:
> > Adding parameters with default arguments to existing API would break th=
e
> > ABI too, as would many other API changes. With a suitable overload
> > resolution rule, I'd expect to be able to change an API that does this:
> >
> >   struct A {
> >     void f(int a, int b);
> >   };
> >
> > ... to do this:
> >
> >   struct A {
> >     void f(int a, int b);
> >     void f(int .a, int .b) { f(a, b); }
> >   };
> >
> > ... as a non-breaking change (except if someone is taking the address o=
f
> > the function), for people who need perfect ABI compatibility.
>
> I'd expect that this:
>
>   struct A {
>     void f(int .a, int .b);
>   };
>
> ...is a (mostly?=C2=B9) non-breaking change. Yes, function pointer and al=
l;
> *if* named parameters are part of the function type, then IMO the
> respective pointer types should implicitly decay to pointers with fewer
> named arguments. IOW:
>
>   int f(int .a, int .b);
>   int (*p1)(int .a, int .b) =3D &f; // okay
>   int (*p2)(int, int .b) =3D &f; // also okay
>   int (*p3)(int, int) =3D &f; // also okay
>
>   int g(int .a, int .b);
>   int g(int .x, int .y);
>   int (*p4)(int .a, int .b) =3D &g; // okay
>   int (*p5)(int, int .b) =3D &g; // still okay
>   int (*p6)(int, int) =3D &g; // error: ambiguous
>   int (*p7)(int, int) =3D p4; // okay
>
> (=C2=B9 There might be cases where the change in type of the function poi=
nter
> breaks something, but not just due to trying to feed it to something
> that expects the no-named-parameters pointer type.)
>
> However, I'll mention again that IMO there are non-trivial issues
> including parameter names in the type system, and that the language most
> commonly cited for supporting named parameters (Python) *doesn't allow
> overloading* (at all). Also, that most cases that come to mind where
> you'd want it seem better solved with strong type aliases. This causes
> me to strongly question the value of including parameter names in the
> type system.
>
> --
> Matthew
>
> --
> 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/neop0a%24n8b=
%241%40ger.gmane.org
> .
>



--=20
how am I supposed to end the twisted road of  your hair in such a dark
night??
unless the candle of your face does shed some light upon my way!!!

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CALDL7dGM%2BKX5BK0%3DQioxu04_zzvbgiGWU2V5b%3DaRy=
BnBpXVWXg%40mail.gmail.com.

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

<div dir=3D"rtl"><div class=3D"gmail_default" style=3D"font-family:&#39;ari=
al narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">=E2=80=8BFeels like =
designated initialization of =E2=80=8BPOD types is less controversial, more=
 conservative, yet more elegant than expected.</div><div class=3D"gmail_def=
ault" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:larg=
e" dir=3D"ltr">For naming function arguments one might wrap it in a functio=
n object:</div><div class=3D"gmail_default" style=3D"font-family:&#39;arial=
 narrow&#39;,sans-serif;font-size:large" dir=3D"ltr"><br></div><div class=
=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;f=
ont-size:large" dir=3D"ltr">struct caller;</div><div class=3D"gmail_default=
" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" d=
ir=3D"ltr">void caller::operator()()</div><div class=3D"gmail_default" styl=
e=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"=
ltr">{</div><div class=3D"gmail_default" style=3D"font-family:&#39;arial na=
rrow&#39;,sans-serif;font-size:large" dir=3D"ltr">=C2=A0 =C2=A0 f(x,y);</di=
v><div class=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,=
sans-serif;font-size:large" dir=3D"ltr">};</div><div class=3D"gmail_default=
" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" d=
ir=3D"ltr">caller{.x=3D1,.y=3D2}();</div><div class=3D"gmail_default" style=
=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"l=
tr"><br></div><div class=3D"gmail_default" style=3D"font-family:&#39;arial =
narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">or even shorter:</div><=
div class=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,san=
s-serif;font-size:large" dir=3D"ltr"><br></div><div class=3D"gmail_default"=
 dir=3D"ltr" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-si=
ze:large">struct caller;</div><div class=3D"gmail_default" style=3D"font-fa=
mily:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">caller:=
:~caller()</div><div class=3D"gmail_default" style=3D"font-family:&#39;aria=
l narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">{</div><div class=3D"=
gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-=
size:large" dir=3D"ltr">=C2=A0 =C2=A0 f(x,y);</div><div class=3D"gmail_defa=
ult" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large=
" dir=3D"ltr">};<br></div><div class=3D"gmail_default" style=3D"font-family=
:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr"><div class=
=3D"gmail_default" dir=3D"ltr">caller{.x=3D1,.y=3D2};</div><div class=3D"gm=
ail_default" dir=3D"ltr"><br></div><div class=3D"gmail_default">Of Course i=
t doesn&#39;t cover every corner case of function calls such as constructor=
 with named args(eg. std::vector::vector or std::complex::complex).=C2=A0</=
div><div class=3D"gmail_default"><br></div><div class=3D"gmail_default">For=
 constructors I would rather put all args in a POD type:</div><div class=3D=
"gmail_default"><br></div><div class=3D"gmail_default">std::complex&lt;doub=
le&gt; =C2=A0 c1{ polar{ .magnitude=3D1.0, .angle=3Ddegree(30) } };</div><d=
iv class=3D"gmail_default">std::complex&lt;double&gt; =C2=A0 c1{ cartesian{=
 .real=3D1.0, .image=3D1.0 } };</div><div class=3D"gmail_default">=C2=A0<br=
></div><div class=3D"gmail_default">I agree that this is not as sweat as fu=
nctions with named variables.</div><div class=3D"gmail_default"><br></div><=
div class=3D"gmail_default">Another more fundamental problem with types is =
that uninitialized members will try to use implicit default constructors. T=
his might partially be overcome by forcing the programmer to explicitly ini=
tialize members:</div><div class=3D"gmail_default"><br></div><div class=3D"=
gmail_default">struct bar{</div><div class=3D"gmail_default">=C2=A0 =C2=A0 =
=C2=A0 //new syntax:</div><div class=3D"gmail_default">=C2=A0 =C2=A0 =C2=A0=
 explicit int x;// explicitly initialized</div><div class=3D"gmail_default"=
>=C2=A0 =C2=A0 =C2=A0 int y; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// do=
n&#39;t care about y</div><div class=3D"gmail_default">};</div><div class=
=3D"gmail_default"><br></div><div class=3D"gmail_default">bar b1{1,2}; =C2=
=A0//ok</div><div class=3D"gmail_default">bar b2{.x=3D2};//ok</div><div cla=
ss=3D"gmail_default">bar b3; =C2=A0 =C2=A0 =C2=A0 =C2=A0 //compile error: x=
 not initialized</div><div class=3D"gmail_default"><br></div><div class=3D"=
gmail_default">or even stricter:</div><div class=3D"gmail_default"><br></di=
v><div class=3D"gmail_default">//new syntax:</div><div class=3D"gmail_defau=
lt">explicit struct foo //every member is explicitly initialized, except if=
 defaulted</div><div class=3D"gmail_default">{</div><div class=3D"gmail_def=
ault">=C2=A0 =C2=A0 =C2=A0int x;</div><div class=3D"gmail_default">=C2=A0 =
=C2=A0 =C2=A0int y=3D1; =C2=A0// y has default value</div><div class=3D"gma=
il_default">};</div><div class=3D"gmail_default"><br></div><div class=3D"gm=
ail_default">foo f1{.x=3D0}; =C2=A0 =C2=A0 =C2=A0 =C2=A0 //ok</div><div cla=
ss=3D"gmail_default">foo f2{.y=3D2,.x=3D0}; //ok</div><div>foo f3; =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0//compile error: x n=
ot initialized</div><div><br></div><div>regards,</div><div>FM.</div></div><=
div class=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,san=
s-serif;font-size:large" dir=3D"ltr">=C2=A0</div></div><div class=3D"gmail_=
extra"><br><div class=3D"gmail_quote"><div dir=3D"ltr">2016-04-14 23:24 GMT=
+04:30 Matthew Woehlke <span dir=3D"ltr">&lt;<a href=3D"mailto:mwoehlke.flo=
ss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail.com</a>&gt;</span>:</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><span class=3D"">On 2016-04-14 13:57, Ric=
hard Smith wrote:<br>
&gt; Adding parameters with default arguments to existing API would break t=
he<br>
&gt; ABI too, as would many other API changes. With a suitable overload<br>
&gt; resolution rule, I&#39;d expect to be able to change an API that does =
this:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0struct A {<br>
&gt;=C2=A0 =C2=A0 =C2=A0void f(int a, int b);<br>
&gt;=C2=A0 =C2=A0};<br>
&gt;<br>
&gt; ... to do this:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0struct A {<br>
&gt;=C2=A0 =C2=A0 =C2=A0void f(int a, int b);<br>
&gt;=C2=A0 =C2=A0 =C2=A0void f(int .a, int .b) { f(a, b); }<br>
&gt;=C2=A0 =C2=A0};<br>
&gt;<br>
&gt; ... as a non-breaking change (except if someone is taking the address =
of<br>
&gt; the function), for people who need perfect ABI compatibility.<br>
<br>
</span>I&#39;d expect that this:<br>
<br>
=C2=A0 struct A {<br>
=C2=A0 =C2=A0 void f(int .a, int .b);<br>
=C2=A0 };<br>
<br>
....is a (mostly?=C2=B9) non-breaking change. Yes, function pointer and all;=
<br>
*if* named parameters are part of the function type, then IMO the<br>
respective pointer types should implicitly decay to pointers with fewer<br>
named arguments. IOW:<br>
<br>
=C2=A0 int f(int .a, int .b);<br>
=C2=A0 int (*p1)(int .a, int .b) =3D &amp;f; // okay<br>
=C2=A0 int (*p2)(int, int .b) =3D &amp;f; // also okay<br>
=C2=A0 int (*p3)(int, int) =3D &amp;f; // also okay<br>
<br>
=C2=A0 int g(int .a, int .b);<br>
=C2=A0 int g(int .x, int .y);<br>
=C2=A0 int (*p4)(int .a, int .b) =3D &amp;g; // okay<br>
=C2=A0 int (*p5)(int, int .b) =3D &amp;g; // still okay<br>
=C2=A0 int (*p6)(int, int) =3D &amp;g; // error: ambiguous<br>
=C2=A0 int (*p7)(int, int) =3D p4; // okay<br>
<br>
(=C2=B9 There might be cases where the change in type of the function point=
er<br>
breaks something, but not just due to trying to feed it to something<br>
that expects the no-named-parameters pointer type.)<br>
<br>
However, I&#39;ll mention again that IMO there are non-trivial issues<br>
including parameter names in the type system, and that the language most<br=
>
commonly cited for supporting named parameters (Python) *doesn&#39;t allow<=
br>
overloading* (at all). Also, that most cases that come to mind where<br>
you&#39;d want it seem better solved with strong type aliases. This causes<=
br>
me to strongly question the value of including parameter names in the<br>
type system.<br>
<br>
--<br>
Matthew<br>
<span class=3D""><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%2Bunsubscribe@isocpp.org">std-propo=
sals+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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/neop0a%24n8b%241%40ger.gmane.o=
rg" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/neop0a%24n8b%241%40ger.gmane.org</a>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature"><div dir=3D"rtl"><div><div dir=3D"ltr">how am I suppos=
ed to end the twisted road of=C2=A0 your hair in such a dark night??<br>unl=
ess the candle of your face does shed some light upon my way!!!<br></div></=
div></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/CALDL7dGM%2BKX5BK0%3DQioxu04_zzvbgiGW=
U2V5b%3DaRyBnBpXVWXg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALDL7dGM%2=
BKX5BK0%3DQioxu04_zzvbgiGWU2V5b%3DaRyBnBpXVWXg%40mail.gmail.com</a>.<br />

--001a11431e1ccf15390530773e5f--

.

--Apple-Mail=_26A352A8-C287-4740-AE95-96345C775D06
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

> Ville Voutilainen <ville.voutilainen@gmail.com <mailto:ville.voutilainen@=
gmail.com>>: Apr 14 12:55AM +0300
>=20
> =E2=80=A6I have indeed toyed with the idea of writing a rumination paper =
on why named arguments have failed, as far as I know and have observed it (=
which doesn=E2=80=99t cover all the old proposals), but perhaps I was kinda=
 hoping I wouldn=E2=80=99t need to. :)
>=20
> =E2=8B=AE

     As a lurker who=E2=80=99s been following some of the more recent discu=
ssions on adding named arguments to C++, I would actually appreciate seeing=
 a more expansive paper that does go back and, as you put it, =E2=80=98cove=
r all the old arguments=E2=80=99 in addition to your more concise summary o=
f more contemporary events in this area.  Given your reluctance to do that =
right now, though, I wouldn=E2=80=99t mind seeing the more extensive analys=
is as either part of a later revision of your paper or a separate one altog=
ether. =20

=E2=80=94=E2=80=89Bryce Glover
=E3=80=80=E2=80=89RandomDSdevel@gmail.com

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/FE05C500-82B4-4507-9008-71179053ECE3%40gmail.com=
..

--Apple-Mail=_26A352A8-C287-4740-AE95-96345C775D06
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div class=3D""><b=
lockquote type=3D"cite" class=3D""><span style=3D"color: rgb(177, 176, 176)=
; font-family: arial; font-size: 15px; background-color: rgb(255, 255, 255)=
;" class=3D"">Ville Voutilainen &lt;</span><a href=3D"mailto:ville.voutilai=
nen@gmail.com" style=3D"font-family: arial; font-size: 15px;" class=3D"">vi=
lle.voutilainen@gmail.com</a><span style=3D"color: rgb(177, 176, 176); font=
-family: arial; font-size: 15px; background-color: rgb(255, 255, 255);" cla=
ss=3D"">&gt;: Apr 14 12:55AM +0300</span></blockquote><blockquote type=3D"c=
ite" class=3D""><br class=3D""></blockquote><blockquote type=3D"cite" class=
=3D"">=E2=80=A6I have indeed toyed with the idea of writing a rumination pa=
per on why&nbsp;named arguments have failed,&nbsp;as far as I know and have=
 observed it (which doesn=E2=80=99t cover all the old&nbsp;proposals), but =
perhaps I was&nbsp;kinda hoping I wouldn=E2=80=99t need to. :)</blockquote>=
<blockquote type=3D"cite" class=3D""><br class=3D""></blockquote><blockquot=
e type=3D"cite" class=3D"">=E2=8B=AE</blockquote></div><br class=3D""><div =
class=3D"">&nbsp; &nbsp; &nbsp;As a lurker who=E2=80=99s been following som=
e of the more recent discussions on adding named arguments to C++, I would =
actually appreciate seeing a more expansive paper that <i class=3D"">does</=
i>&nbsp;go back and, as you put it, =E2=80=98cover all the old arguments=E2=
=80=99 in addition to your more concise summary of more contemporary events=
 in this area. &nbsp;Given your reluctance to do that right now, though, I =
wouldn=E2=80=99t mind seeing the more extensive analysis as either part of =
a later revision of your paper or a separate one altogether. &nbsp;</div><d=
iv class=3D""><br class=3D"webkit-block-placeholder"></div><div class=3D"">
<div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; t=
ext-align: start; text-indent: 0px; text-transform: none; white-space: norm=
al; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-w=
rap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-=
space;" class=3D""><div style=3D"color: rgb(0, 0, 0); letter-spacing: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-=
break: after-white-space;" class=3D""><div class=3D"">=E2=80=94=E2=80=89Bry=
ce Glover</div><div class=3D"">=E3=80=80=E2=80=89<a href=3D"mailto:RandomDS=
devel@gmail.com" class=3D"">RandomDSdevel@gmail.com</a></div></div></div></=
div></body></html>

<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/FE05C500-82B4-4507-9008-71179053ECE3%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/FE05C500-82B4-4507-9008-71179053ECE3%=
40gmail.com</a>.<br />

--Apple-Mail=_26A352A8-C287-4740-AE95-96345C775D06--

.

> =E2=80=8EHuh?
>
> Let me try rephrasing this. Let's say we have a C struct:
>
> struct foo { int bar };
>
> In C89, the "meaning" of this struct is that I can construct it like `{1}=
`. In C11, the "meaning" is that I can (additionally) construct it=E2=80=8E=
 like `{.bar=3D1}`. This was evidently not a problem for C11. What "change =
of meaning" occurs in C++ that is different from this example and therefore=
 problematic?
>


In a struct, the member names are already part of the API.



Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: Matthew Woehlke
Sent: Thursday, April 14, 2016 11:57 AM
To: std-proposals@isocpp.org
Reply To: std-proposals@isocpp.org
Subject: [std-proposals] Re: [RFC] Uniform designated initializers and argu=
ments for C++ (implementation available)

On 2016-04-14 11:30, Ville Voutilainen wrote:
> On 14 April 2016 at 18:20, Matthew Woehlke wrote:
>> ...but we were talking about *automatic* named parameters. We already
>> established that the parameter names don't matter currently, so why is
>> changing them to match an updated standard an issue?
>=20
> Because I expect that in that newer standard they won't be uglified,
> whereas they need to be when an older standard is used,

I don't get it. If parameter names don't matter in "old" C++, why must
the 'ugly' names be used? What am I missing?

>> On 2016-04-14 10:41, Ville Voutilainen wrote:
>>> [...] the meaning of the function declaration changes
>>
>> ...in what way? You keep asserting this, but I am not understanding what
>> change you think is occurring. I can only assume therefore that we
>> aren't talking about the same implementation.
>>
>> Given:
>>
>> int add(int [[named("a")] a, int [[named("b")]] b);
>>
>> In both cases you have a function with the signature `int (int, int)`
>> (either because names aren't part of the type, or at least that decays
>> to that). In both cases, you can call the function like `add(2, 3);`.
>> All that has changed is that in one case you can *also* call it like
>> `add(.b =3D 3, .a =3D 2);`.
>=20
> Well, duh, I can now also call the function like that because the meaning
> of the function declaration changed. Had it not changed, I wouldn't be ab=
le
> to call it that way.

Huh?

Let me try rephrasing this. Let's say we have a C struct:

struct foo { int bar };

In C89, the "meaning" of this struct is that I can construct it like
`{1}`. In C11, the "meaning" is that I can (additionally) construct it
like `{.bar=3D1}`. This was evidently not a problem for C11. What "change
of meaning" occurs in C++ that is different from this example and
therefore problematic?

>> The function/meaning of the parameter. For example, in `sin(double
>> .radians)`, the "user semantic" of `radians` is 'an angle in radians'.
>> If I want to rename that to `degrees`, it is a *feature* that this is an
>> API break, because the API did in fact change in a non-compatible
>> manner. This is different from "compiler semantic" because the compiler
>> (at least currently) has no way to diagnose if I pass degrees to a
>> function that expects radians, or vice versa.
>=20
> In other words, you think you can make names have a "user semantic" if
> named arguments are supported.

They would (when employed) become part of the public API in the same
manner as the function name, with similar issues arising if you want to
change the names. (In fact, I hadn't realized this before... the same
problems that would arise with renaming named parameters *already exist*
w.r.t. the name of the function itself. And yet, somehow we're managing.)

> That doesn't mean that all names have such
> "user semantics", because currently none of them do, hence my confusion a=
bout
> what these "user semantics" are. Today, they are a figment of imagination=
.. With
> named arguments, they might be a thing, although they might not be. I wou=
ldn't
> call that the strongest rationale for named arguments.

Ah... I think you perhaps misunderstand the intended scope. This
particular argument is not meant as an argument *for* named parameters,
only as an argument why the concern about "committing my API to a name"
is possibly overemphasized.

--=20
Matthew

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/neoelk%249ko%241%40ger.gmane.org.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20160414211921.4902992.88470.9761%40gmail.com.

.

--Apple-Mail=_060FFB6C-6CDE-4A2B-A69C-BA4FB33CDDC4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

> gmisocpp@gmail.com <mailto:gmisocpp@gmail.com>: Apr 13 06:36PM -0700
>=20
> =E2=8B=AE
>=20
> This looks like a very well written and presented proposal. I think it co=
uld be better evaluated though if there were more discussion about it in th=
e context of existing API designs that have been created with languages tha=
t already have the features the proposed. In particular regarding named fun=
ction parameters.
>=20
> My own experience of using libraries with extensive numbers of parameters=
 are the Microsoft COM object libraries that lay behind applications like M=
icrosoft Word and Excel etc.
> See here:
> https://msdn.microsoft.com/en-us/library/kw65a0we.aspx <https://msdn.micr=
osoft.com/en-us/library/kw65a0we.aspx>
> https://msdn.microsoft.com/en-us/library/office/ff194068.aspx <https://ms=
dn.microsoft.com/en-us/library/office/ff194068.aspx>
>=20
> This proposal would seem to make using such libraries a lot easier?
>=20
> As important to me though is whether people consider such API designs goo=
d? And do we want to encourage more of them by making them easier?
>=20
> So to my mind we have to evaluate this proposal against real existing API=
s while also determining if those real API's need to be as complex as they =
are so we. This should help us verify if this proposal helps with using suc=
h API's and reveal whether an alternative API design or language feature wo=
uld be better to get the kinds of api's we do want.
>=20
> I don't feel I can appreciate the value of this proposal without such dis=
cussion
>=20
> If more recent API's could be discussed it might even more relevant. I am=
 thinking some of the web driving api's (think setting html attributes from=
 code etc). like those in the ASP.NET <http://asp.net/>'s MVC API, which ar=
e C# API's. Maybe that could be addressed? Perhaps a lot of lessons/encoura=
gement could be learned from that?
>=20
> So I think ultimately we have to compare this proposal against these type=
s of API=E2=80=99s and evaluate the alternatives to appreciate this proposa=
l, don't we?
>=20
> Thanks for the proposal so far.


     Off the top of my head, another set of examples that might bear examin=
ation could exist in Apple=E2=80=99s Cocoa library for Objective-C, which, =
IIRC, heavily utilizes that language=E2=80=99s support for named arguments.=
 =20

=E2=80=94=E2=80=89Bryce Glover
=E3=80=80=E2=80=89RandomDSdevel@gmail.com

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/57F50182-39F9-4CD9-8781-48BF1294EF28%40gmail.com=
..

--Apple-Mail=_060FFB6C-6CDE-4A2B-A69C-BA4FB33CDDC4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div class=3D""><b=
lockquote type=3D"cite" class=3D""><a href=3D"mailto:gmisocpp@gmail.com" st=
yle=3D"font-family: arial; font-size: 15px;" class=3D"">gmisocpp@gmail.com<=
/a><span style=3D"color: rgb(177, 176, 176); font-family: arial; font-size:=
 15px; background-color: rgb(255, 255, 255);" class=3D"">: Apr 13 06:36PM -=
0700</span></blockquote><blockquote type=3D"cite" class=3D""><br class=3D""=
></blockquote><blockquote type=3D"cite" class=3D"">=E2=8B=AE</blockquote><b=
lockquote type=3D"cite" class=3D""><br class=3D""></blockquote><blockquote =
type=3D"cite" class=3D""><span style=3D"color: rgb(46, 46, 46); font-family=
: arial; background-color: rgb(255, 255, 255);" class=3D"">This looks like =
a very well written and presented proposal. I think it&nbsp;</span><span st=
yle=3D"color: rgb(46, 46, 46); font-family: arial; background-color: rgb(25=
5, 255, 255);" class=3D"">could be better evaluated though if there were mo=
re discussion about it in</span><span style=3D"color: rgb(46, 46, 46); font=
-family: arial; background-color: rgb(255, 255, 255);" class=3D"">&nbsp;</s=
pan><span style=3D"color: rgb(46, 46, 46); font-family: arial; background-c=
olor: rgb(255, 255, 255);" class=3D"">the context of existing API designs t=
hat have been created with languages</span><span style=3D"color: rgb(46, 46=
, 46); font-family: arial; background-color: rgb(255, 255, 255);" class=3D"=
">&nbsp;</span><span style=3D"color: rgb(46, 46, 46); font-family: arial; b=
ackground-color: rgb(255, 255, 255);" class=3D"">that already have the feat=
ures the proposed. In particular regarding named</span><span style=3D"color=
: rgb(46, 46, 46); font-family: arial; background-color: rgb(255, 255, 255)=
;" class=3D"">&nbsp;</span><span style=3D"color: rgb(46, 46, 46); font-fami=
ly: arial; background-color: rgb(255, 255, 255);" class=3D"">function param=
eters.</span></blockquote><blockquote type=3D"cite" class=3D""><br style=3D=
"color: rgb(46, 46, 46); font-family: arial; background-color: rgb(255, 255=
, 255);" class=3D""></blockquote><blockquote type=3D"cite" class=3D""><span=
 style=3D"color: rgb(46, 46, 46); font-family: arial; font-size: medium; ba=
ckground-color: rgb(255, 255, 255);" class=3D"">My own experience of using =
libraries with extensive numbers of&nbsp;</span><span style=3D"color: rgb(4=
6, 46, 46); font-family: arial; background-color: rgb(255, 255, 255);" clas=
s=3D"">parameters are the Microsoft COM object libraries that lay behind</s=
pan><span style=3D"color: rgb(46, 46, 46); font-family: arial; background-c=
olor: rgb(255, 255, 255);" class=3D"">&nbsp;</span><span style=3D"color: rg=
b(46, 46, 46); font-family: arial; background-color: rgb(255, 255, 255);" c=
lass=3D"">applications like Microsoft Word and Excel etc.</span></blockquot=
e><blockquote type=3D"cite" class=3D""><span style=3D"color: rgb(46, 46, 46=
); font-family: arial; background-color: rgb(255, 255, 255);" class=3D"">Se=
e here:</span></blockquote><blockquote type=3D"cite" class=3D""><a href=3D"=
https://msdn.microsoft.com/en-us/library/kw65a0we.aspx" style=3D"font-famil=
y: arial; background-color: rgb(255, 255, 255);" class=3D"">https://msdn.mi=
crosoft.com/en-us/library/kw65a0we.aspx</a><br style=3D"color: rgb(46, 46, =
46); font-family: arial; background-color: rgb(255, 255, 255);" class=3D"">=
</blockquote><blockquote type=3D"cite" class=3D""><a href=3D"https://msdn.m=
icrosoft.com/en-us/library/office/ff194068.aspx" style=3D"font-family: aria=
l; background-color: rgb(255, 255, 255);" class=3D"">https://msdn.microsoft=
..com/en-us/library/office/ff194068.aspx</a><br style=3D"color: rgb(46, 46, =
46); font-family: arial; background-color: rgb(255, 255, 255);" class=3D"">=
</blockquote><blockquote type=3D"cite" class=3D""><br style=3D"color: rgb(4=
6, 46, 46); font-family: arial; background-color: rgb(255, 255, 255);" clas=
s=3D""></blockquote><blockquote type=3D"cite" class=3D""><span style=3D"col=
or: rgb(46, 46, 46); font-family: arial; font-size: medium; background-colo=
r: rgb(255, 255, 255);" class=3D"">This proposal would seem to make using s=
uch libraries a lot easier?</span><br style=3D"color: rgb(46, 46, 46); font=
-family: arial; background-color: rgb(255, 255, 255);" class=3D""></blockqu=
ote><blockquote type=3D"cite" class=3D""><br style=3D"color: rgb(46, 46, 46=
); font-family: arial; background-color: rgb(255, 255, 255);" class=3D""></=
blockquote><blockquote type=3D"cite" class=3D""><span style=3D"color: rgb(4=
6, 46, 46); font-family: arial; font-size: medium; background-color: rgb(25=
5, 255, 255);" class=3D"">As important to me though is whether people consi=
der such API designs good?&nbsp;</span><span style=3D"color: rgb(46, 46, 46=
); font-family: arial; background-color: rgb(255, 255, 255);" class=3D"">An=
d do we want to encourage more of them by making them easier?</span></block=
quote><blockquote type=3D"cite" class=3D""><br style=3D"color: rgb(46, 46, =
46); font-family: arial; background-color: rgb(255, 255, 255);" class=3D"">=
</blockquote><blockquote type=3D"cite" class=3D""><span style=3D"color: rgb=
(46, 46, 46); font-family: arial; font-size: medium; background-color: rgb(=
255, 255, 255);" class=3D"">So to my mind we have to evaluate this proposal=
 against real existing&nbsp;</span><span style=3D"color: rgb(46, 46, 46); f=
ont-family: arial; background-color: rgb(255, 255, 255);" class=3D"">APIs w=
hile also determining if those real API's need to be as complex as</span><s=
pan style=3D"color: rgb(46, 46, 46); font-family: arial; background-color: =
rgb(255, 255, 255);" class=3D"">&nbsp;</span><span style=3D"color: rgb(46, =
46, 46); font-family: arial; background-color: rgb(255, 255, 255);" class=
=3D"">they are so we. This should help us verify if this proposal helps wit=
h</span><span style=3D"color: rgb(46, 46, 46); font-family: arial; backgrou=
nd-color: rgb(255, 255, 255);" class=3D"">&nbsp;</span><span style=3D"color=
: rgb(46, 46, 46); font-family: arial; background-color: rgb(255, 255, 255)=
;" class=3D"">using such API's and reveal whether an alternative API design=
 or language</span><span style=3D"color: rgb(46, 46, 46); font-family: aria=
l; background-color: rgb(255, 255, 255);" class=3D"">&nbsp;</span><span sty=
le=3D"color: rgb(46, 46, 46); font-family: arial; background-color: rgb(255=
, 255, 255);" class=3D"">feature would be better to get the kinds of api's =
we do want.</span></blockquote><blockquote type=3D"cite" class=3D""><br sty=
le=3D"color: rgb(46, 46, 46); font-family: arial; background-color: rgb(255=
, 255, 255);" class=3D""></blockquote><blockquote type=3D"cite" class=3D"">=
<span style=3D"color: rgb(46, 46, 46); font-family: arial; font-size: mediu=
m; background-color: rgb(255, 255, 255);" class=3D"">I don't feel I can app=
reciate the value of this proposal without such&nbsp;</span><span style=3D"=
color: rgb(46, 46, 46); font-family: arial; background-color: rgb(255, 255,=
 255);" class=3D"">discussion</span></blockquote><blockquote type=3D"cite" =
class=3D""><br style=3D"color: rgb(46, 46, 46); font-family: arial; backgro=
und-color: rgb(255, 255, 255);" class=3D""></blockquote><blockquote type=3D=
"cite" class=3D""><span style=3D"color: rgb(46, 46, 46); font-family: arial=
; font-size: medium; background-color: rgb(255, 255, 255);" class=3D"">If m=
ore recent API's could be discussed it might even more relevant. I am&nbsp;=
</span><span style=3D"color: rgb(46, 46, 46); font-family: arial; backgroun=
d-color: rgb(255, 255, 255);" class=3D"">thinking some of the web driving a=
pi's (think setting html attributes from</span><span style=3D"color: rgb(46=
, 46, 46); font-family: arial; background-color: rgb(255, 255, 255);" class=
=3D"">&nbsp;</span><span style=3D"color: rgb(46, 46, 46); font-family: aria=
l; background-color: rgb(255, 255, 255);" class=3D"">code etc). like those =
in the&nbsp;</span><a href=3D"http://asp.net" style=3D"font-family: arial; =
background-color: rgb(255, 255, 255);" class=3D"">ASP.NET</a><span style=3D=
"color: rgb(46, 46, 46); font-family: arial; background-color: rgb(255, 255=
, 255);" class=3D"">'s MVC API, which are C#&nbsp;</span><span style=3D"col=
or: rgb(46, 46, 46); font-family: arial; background-color: rgb(255, 255, 25=
5);" class=3D"">API's. Maybe that could be addressed? Perhaps a lot of</spa=
n><span style=3D"color: rgb(46, 46, 46); font-family: arial; background-col=
or: rgb(255, 255, 255);" class=3D"">&nbsp;</span><span style=3D"color: rgb(=
46, 46, 46); font-family: arial; background-color: rgb(255, 255, 255);" cla=
ss=3D"">lessons/encouragement could be learned from that?</span></blockquot=
e><blockquote type=3D"cite" class=3D""><br style=3D"color: rgb(46, 46, 46);=
 font-family: arial; background-color: rgb(255, 255, 255);" class=3D""></bl=
ockquote><blockquote type=3D"cite" class=3D""><span style=3D"color: rgb(46,=
 46, 46); font-family: arial; font-size: medium; background-color: rgb(255,=
 255, 255);" class=3D"">So I think ultimately we have to compare this propo=
sal against these types&nbsp;</span><span style=3D"background-color: rgb(25=
5, 255, 255);" class=3D""><font color=3D"#2e2e2e" face=3D"arial" class=3D""=
>of API=E2=80=99s and evaluate the alternatives to appreciate this proposal=
, don't</font></span><span style=3D"color: rgb(46, 46, 46); font-family: ar=
ial; background-color: rgb(255, 255, 255);" class=3D"">&nbsp;</span><span s=
tyle=3D"color: rgb(46, 46, 46); font-family: arial; background-color: rgb(2=
55, 255, 255);" class=3D"">we?</span></blockquote><blockquote type=3D"cite"=
 class=3D""><br style=3D"color: rgb(46, 46, 46); font-family: arial; backgr=
ound-color: rgb(255, 255, 255);" class=3D""></blockquote><blockquote type=
=3D"cite" class=3D""><span style=3D"color: rgb(46, 46, 46); font-family: ar=
ial; font-size: medium; background-color: rgb(255, 255, 255);" class=3D"">T=
hanks for the proposal so far.</span></blockquote></div><div class=3D""><br=
 class=3D""></div><div class=3D"">&nbsp; &nbsp; &nbsp;Off the top of my hea=
d, another set of examples that might bear examination could exist in Apple=
=E2=80=99s Cocoa library for Objective-C, which, IIRC, <i class=3D"">heavil=
y</i>&nbsp;utilizes that language=E2=80=99s support for named arguments. &n=
bsp;</div><br class=3D""><div class=3D"">
<div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; t=
ext-align: start; text-indent: 0px; text-transform: none; white-space: norm=
al; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-w=
rap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-=
space;" class=3D""><div style=3D"color: rgb(0, 0, 0); letter-spacing: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-=
break: after-white-space;" class=3D""><div class=3D"">=E2=80=94=E2=80=89Bry=
ce Glover</div><div class=3D"">=E3=80=80=E2=80=89<a href=3D"mailto:RandomDS=
devel@gmail.com" class=3D"">RandomDSdevel@gmail.com</a></div></div></div></=
div></body></html>

<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/57F50182-39F9-4CD9-8781-48BF1294EF28%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/57F50182-39F9-4CD9-8781-48BF1294EF28%=
40gmail.com</a>.<br />

--Apple-Mail=_060FFB6C-6CDE-4A2B-A69C-BA4FB33CDDC4--

.

On quinta-feira, 14 de abril de 2016 17:19:21 PDT Tony V E wrote:
> > =E2=80=8EHuh?
> >=20
> > Let me try rephrasing this. Let's say we have a C struct:
> >=20
> > struct foo { int bar };
> >=20
> > In C89, the "meaning" of this struct is that I can construct it like
> > `{1}`. In C11, the "meaning" is that I can (additionally) construct it=
=E2=80=8E
> > like `{.bar=3D1}`. This was evidently not a problem for C11. What "chan=
ge
> > of meaning" occurs in C++ that is different from this example and
> > therefore problematic?
> In a struct, the member names are already part of the API.

Kinda...

struct ip6_hdr
  {
    union
      {
 struct ip6_hdrctl
   {
     uint32_t ip6_un1_flow;   /* 4 bits version, 8 bits TC,
     20 bits flow-ID */
     uint16_t ip6_un1_plen;   /* payload length */
     uint8_t  ip6_un1_nxt;    /* next header */
     uint8_t  ip6_un1_hlim;   /* hop limit */
   } ip6_un1;
 uint8_t ip6_un2_vfc;       /* 4 bits version, top 4 bits tclass */
      } ip6_ctlun;
    struct in6_addr ip6_src;      /* source address */
    struct in6_addr ip6_dst;      /* destination address */
  };

#define ip6_vfc   ip6_ctlun.ip6_un2_vfc
#define ip6_flow  ip6_ctlun.ip6_un1.ip6_un1_flow
#define ip6_plen  ip6_ctlun.ip6_un1.ip6_un1_plen
#define ip6_nxt   ip6_ctlun.ip6_un1.ip6_un1_nxt
#define ip6_hlim  ip6_ctlun.ip6_un1.ip6_un1_hlim
#define ip6_hops  ip6_ctlun.ip6_un1.ip6_un1_hlim

The API for this struct says
 hdr.ip6_flow

but there's no member called "ip6_flow" in struct ip6_hdr.

See https://tools.ietf.org/html/rfc3542#section-2.1.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/3549854.PvpFWvaERv%40tjmaciei-mobl4.

.

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

Thiago, this is an evil (but welcome!) example.

I read the proposal and I like it in general; in that area, it's among the
good ones.

Contrary to some, I've been quite often in a situation where changing
argument names in functions was important, and in situations where the
documentary names in a .h/.hpp file were different from the names used in
the function's implementation. I would be inclined to support a proposal
that showed how named arguments fit in with this reality of software
development.

I don't see named arguments as a =C2=ABneed=C2=BB, but they do look like a =
=C2=ABwant=C2=BB. We
do need a clear path to existing (and future, in this case, as argument
names can change anytime) code management. The attribute pathway is a no-go
(semantics) but does have a nice upside, which is separating the =C2=ABinte=
rface
name=C2=BB from the =C2=ABimplementation name=C2=BB; this quality is not so=
mething to
throw away, IMHO.

Many have mentioned the C11 path, but C has no constructors, and C is a one
name, one function language. I'm not convinced it's a good basis for our
discussion.

Cheers! (and thanks to the author for bringing an old idea with a clear and
interesting presentation to make discussion meaningful)

2016-04-14 19:00 GMT-04:00 Thiago Macieira <thiago@macieira.org>:

> On quinta-feira, 14 de abril de 2016 17:19:21 PDT Tony V E wrote:
> > > =E2=80=8EHuh?
> > >
> > > Let me try rephrasing this. Let's say we have a C struct:
> > >
> > > struct foo { int bar };
> > >
> > > In C89, the "meaning" of this struct is that I can construct it like
> > > `{1}`. In C11, the "meaning" is that I can (additionally) construct i=
t=E2=80=8E
> > > like `{.bar=3D1}`. This was evidently not a problem for C11. What "ch=
ange
> > > of meaning" occurs in C++ that is different from this example and
> > > therefore problematic?
> > In a struct, the member names are already part of the API.
>
> Kinda...
>
> struct ip6_hdr
>   {
>     union
>       {
>         struct ip6_hdrctl
>           {
>             uint32_t ip6_un1_flow;   /* 4 bits version, 8 bits TC,
>                                         20 bits flow-ID */
>             uint16_t ip6_un1_plen;   /* payload length */
>             uint8_t  ip6_un1_nxt;    /* next header */
>             uint8_t  ip6_un1_hlim;   /* hop limit */
>           } ip6_un1;
>         uint8_t ip6_un2_vfc;       /* 4 bits version, top 4 bits tclass *=
/
>       } ip6_ctlun;
>     struct in6_addr ip6_src;      /* source address */
>     struct in6_addr ip6_dst;      /* destination address */
>   };
>
> #define ip6_vfc   ip6_ctlun.ip6_un2_vfc
> #define ip6_flow  ip6_ctlun.ip6_un1.ip6_un1_flow
> #define ip6_plen  ip6_ctlun.ip6_un1.ip6_un1_plen
> #define ip6_nxt   ip6_ctlun.ip6_un1.ip6_un1_nxt
> #define ip6_hlim  ip6_ctlun.ip6_un1.ip6_un1_hlim
> #define ip6_hops  ip6_ctlun.ip6_un1.ip6_un1_hlim
>
> The API for this struct says
>         hdr.ip6_flow
>
> but there's no member called "ip6_flow" in struct ip6_hdr.
>
> See https://tools.ietf.org/html/rfc3542#section-2.1.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
> --
> 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/3549854.PvpF=
WvaERv%40tjmaciei-mobl4
> .
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAKiZDp1e7YBHBa327X4L35MbzPfPynr1HdHasH-S2D%3DvL=
dvfTA%40mail.gmail.com.

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

<div dir=3D"ltr"><div><div><div>Thiago, this is an evil (but welcome!) exam=
ple.<br><br></div>I read the proposal and I like it in general; in that are=
a, it&#39;s among the good ones.<br><br></div>Contrary to some, I&#39;ve be=
en quite often in a situation where changing argument names in functions wa=
s important, and in situations where the documentary names in a .h/.hpp fil=
e were different from the names used in the function&#39;s implementation. =
I would be inclined to support a proposal that showed how named arguments f=
it in with this reality of software development.<br><br></div><div>I don&#3=
9;t see named arguments as a =C2=ABneed=C2=BB, but they do look like a =C2=
=ABwant=C2=BB. We do need a clear path to existing (and future, in this cas=
e, as argument names can change anytime) code management. The attribute pat=
hway is a no-go (semantics) but does have a nice upside, which is separatin=
g the =C2=ABinterface name=C2=BB from the =C2=ABimplementation name=C2=BB; =
this quality is not something to throw away, IMHO.<br><br>Many have mention=
ed the C11 path, but C has no constructors, and C is a one name, one functi=
on language. I&#39;m not convinced it&#39;s a good basis for our discussion=
..<br></div><div><br></div>Cheers! (and thanks to the author for bringing an=
 old idea with a clear and interesting presentation to make discussion mean=
ingful)<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
2016-04-14 19:00 GMT-04:00 Thiago Macieira <span dir=3D"ltr">&lt;<a href=3D=
"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&gt;<=
/span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On quinta-feira,=
 14 de abril de 2016 17:19:21 PDT Tony V E wrote:<br>
&gt; &gt; =E2=80=8EHuh?<br>
&gt; &gt;<br>
&gt; &gt; Let me try rephrasing this. Let&#39;s say we have a C struct:<br>
&gt; &gt;<br>
&gt; &gt; struct foo { int bar };<br>
&gt; &gt;<br>
&gt; &gt; In C89, the &quot;meaning&quot; of this struct is that I can cons=
truct it like<br>
&gt; &gt; `{1}`. In C11, the &quot;meaning&quot; is that I can (additionall=
y) construct it=E2=80=8E<br>
&gt; &gt; like `{.bar=3D1}`. This was evidently not a problem for C11. What=
 &quot;change<br>
&gt; &gt; of meaning&quot; occurs in C++ that is different from this exampl=
e and<br>
&gt; &gt; therefore problematic?<br>
&gt; In a struct, the member names are already part of the API.<br>
<br>
</span>Kinda...<br>
<br>
struct ip6_hdr<br>
=C2=A0 {<br>
=C2=A0 =C2=A0 union<br>
=C2=A0 =C2=A0 =C2=A0 {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct ip6_hdrctl<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint32_t ip6_un1_flow;=C2=A0 =C2=
=A0/* 4 bits version, 8 bits TC,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 20 bits =
flow-ID */<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint16_t ip6_un1_plen;=C2=A0 =C2=
=A0/* payload length */<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint8_t=C2=A0 ip6_un1_nxt;=C2=A0 =
=C2=A0 /* next header */<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint8_t=C2=A0 ip6_un1_hlim;=C2=A0=
 =C2=A0/* hop limit */<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } ip6_un1;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint8_t ip6_un2_vfc;=C2=A0 =C2=A0 =C2=A0 =C2=A0=
/* 4 bits version, top 4 bits tclass */<br>
=C2=A0 =C2=A0 =C2=A0 } ip6_ctlun;<br>
=C2=A0 =C2=A0 struct in6_addr ip6_src;=C2=A0 =C2=A0 =C2=A0 /* source addres=
s */<br>
=C2=A0 =C2=A0 struct in6_addr ip6_dst;=C2=A0 =C2=A0 =C2=A0 /* destination a=
ddress */<br>
=C2=A0 };<br>
<br>
#define ip6_vfc=C2=A0 =C2=A0ip6_ctlun.ip6_un2_vfc<br>
#define ip6_flow=C2=A0 ip6_ctlun.ip6_un1.ip6_un1_flow<br>
#define ip6_plen=C2=A0 ip6_ctlun.ip6_un1.ip6_un1_plen<br>
#define ip6_nxt=C2=A0 =C2=A0ip6_ctlun.ip6_un1.ip6_un1_nxt<br>
#define ip6_hlim=C2=A0 ip6_ctlun.ip6_un1.ip6_un1_hlim<br>
#define ip6_hops=C2=A0 ip6_ctlun.ip6_un1.ip6_un1_hlim<br>
<br>
The API for this struct says<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 hdr.ip6_flow<br>
<br>
but there&#39;s no member called &quot;ip6_flow&quot; in struct ip6_hdr.<br=
>
<br>
See <a href=3D"https://tools.ietf.org/html/rfc3542#section-2.1" rel=3D"nore=
ferrer" target=3D"_blank">https://tools.ietf.org/html/rfc3542#section-2.1</=
a>.<br>
<br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<span class=3D""><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%2Bunsubscribe@isocpp.org">std-propo=
sals+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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/3549854.PvpFWvaERv%40tjmaciei-=
mobl4" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/iso=
cpp.org/d/msgid/std-proposals/3549854.PvpFWvaERv%40tjmaciei-mobl4</a>.<br>
</blockquote></div><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/CAKiZDp1e7YBHBa327X4L35MbzPfPynr1HdHa=
sH-S2D%3DvLdvfTA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp1e7YBHBa=
327X4L35MbzPfPynr1HdHasH-S2D%3DvLdvfTA%40mail.gmail.com</a>.<br />

--94eb2c124588c6f4d505307ae344--

.

------=_Part_3989_1209609039.1460684621831
Content-Type: multipart/alternative;
 boundary="----=_Part_3990_1298669289.1460684621831"

------=_Part_3990_1298669289.1460684621831
Content-Type: text/plain; charset=UTF-8

On Friday, April 15, 2016 at 8:14:10 AM UTC+8, Patrice Roy wrote:
>
> Thiago, this is an evil (but welcome!) example.
>
> I read the proposal and I like it in general; in that area, it's among the
> good ones.
>

I guess Thiago's example is an argument for designator list?


> Contrary to some, I've been quite often in a situation where changing
> argument names in functions was important, and in situations where the
> documentary names in a .h/.hpp file were different from the names used in
> the function's implementation. I would be inclined to support a proposal
> that showed how named arguments fit in with this reality of software
> development.
>

That's allowed in my proposal, see my reply to Matthew
<https://groups.google.com/a/isocpp.org/d/msg/std-proposals/gtGWEUtATU4/G-WSyGRyBAAJ>
..
It's just a normal function redeclaration after all.

--
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/461aca67-541c-4635-b37b-e97af281cb13%40isocpp.org.

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

<div dir=3D"ltr">On Friday, April 15, 2016 at 8:14:10 AM UTC+8, Patrice Roy=
 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"><div><=
div><div>Thiago, this is an evil (but welcome!) example.<br><br></div>I rea=
d the proposal and I like it in general; in that area, it&#39;s among the g=
ood ones.<br></div></div></div></blockquote><div><br></div><div style=3D"fo=
nt-family: arial, sans-serif; font-size: small;">I guess Thiago&#39;s examp=
le is an argument for designator list?</div><div><span style=3D"font-family=
: arial, sans-serif; font-size: small;">=C2=A0</span>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Contrary to some, =
I&#39;ve been quite often in a situation where changing argument names in f=
unctions was important, and in situations where the documentary names in a =
..h/.hpp file were different from the names used in the function&#39;s imple=
mentation. I would be inclined to support a proposal that showed how named =
arguments fit in with this reality of software development.<br></div></div>=
</blockquote><div><br></div><div>That&#39;s allowed in my proposal, see my =
<a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/gtGWE=
UtATU4/G-WSyGRyBAAJ">reply to  Matthew</a>.</div><div>It&#39;s just a norma=
l function redeclaration after all.</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/461aca67-541c-4635-b37b-e97af281cb13%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/461aca67-541c-4635-b37b-e97af281cb13=
%40isocpp.org</a>.<br />

------=_Part_3990_1298669289.1460684621831--
------=_Part_3989_1209609039.1460684621831--

.

------=_Part_1992_1524836420.1460686640898
Content-Type: multipart/alternative;
 boundary="----=_Part_1993_2097689633.1460686640898"

------=_Part_1993_2097689633.1460686640898
Content-Type: text/plain; charset=UTF-8

On Friday, April 15, 2016 at 1:57:27 AM UTC+8, Richard Smith wrote:
>
> On Wed, Apr 13, 2016 at 8:09 PM, TONGARI J <tong...@gmail.com
> <javascript:>> wrote:
>>
>> There are some principles I set when designing the feature:
>> * Don't interfere with the type system
>>
>
> Please allow me to suggest an alternative principle: integrate into the
> existing language.
>

Well, it does integrate into the existing language.
I know what I want for this feature, and smooth adoption w/o binary
incompatibility is what I desire, hence the principle.


> Far too often, people proposing features make the mistake of making their
> feature be its own special island that has rules different from the rest of
> the language. This is a trap to be avoided. Language continuity is
> important: C++20 should look and feel like a development of C++17, in order
> to make it easier for programmers and programs to adapt, but we don't get
> there by minimizing the amount of change to the language or specification,
> we get there by making the changes complete so they feel like an extension
> of what came before.
>
> A feature that does not integrate into the type system, but whose design
> would naturally lead to type system changes, is flawed. In my opinion, you
> should first design the feature, and then analyze the type system
> implications, not the other way around. (And if that leads to no type
> system changes, that's fine, of course.)
>
> * Don't require ABI changes
>>
>
> I think you should distinguish between "don't change the ABI of existing
> libraries" and "don't change the ABI when designated parameters are added
> to an interface". The first seems like an important principle. The second,
> less so -- as long as the library maintainer still gets to control their
> ABI as they see fit.
>

I have a feeling that there would be a resistance to adopt designatable
parameters because of ABI incompatibility.


> Actually, forwarding function is explicitly listed in my non-goals, that's
>> why I deliberately disable the indirect use in the end of section 3.2.3.
>>
>
> The fact that this is a non-goal is going to make your proposal very
> unappealing to some portion of the committee.
>
>
>> If I were going to support forwarding functions, that means I have to
>> make designatable parameters part of the type as you suggested in (a), and
>> that breaks my design principles.
>> My choice for designated arguments is much like parameter pack, that is,
>> don't make them first class objects.
>>
>> I should emphasize how reluctant I am in interfering with the type system
>> - it's a no-go for me if adding designatable parameters to existing API
>> would break the ABI.
>>
>
> Adding parameters with default arguments to existing API would break the
> ABI too
>

I don't see any difference in the generated LLVM IR with or without default
arguments, any example how it affects the ABI?

 as would many other API changes. With a suitable overload resolution rule,
> I'd expect to be able to change an API that does this:
>
>   struct A {
>     void f(int a, int b);
>   };
>
> ... to do this:
>
>   struct A {
>     void f(int a, int b);
>     void f(int .a, int .b) { f(a, b); }
>   };
>
> ... as a non-breaking change (except if someone is taking the address of
> the function), for people who need perfect ABI compatibility.
>

So call A{}.f(0, 1)is ruled by some conversion sequence?

What about:
void f(int .a, int .b);
void f(int .b, int .a);

Is the overload valid? Is f(.a = 0, .b = 1) ambiguous?

And how would you forward the designators for, say, std::function?

--
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/5a3ebaf4-5297-43d5-9de4-69566c841592%40isocpp.org.

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

<div dir=3D"ltr">On Friday, April 15, 2016 at 1:57:27 AM UTC+8, Richard Smi=
th 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"><div=
><div class=3D"gmail_quote">On Wed, Apr 13, 2016 at 8:09 PM, TONGARI J <spa=
n dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"aVVxrll5BAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;r=
eturn true;">tong...@gmail.com</a>&gt;</span> wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div>There are some principles I set when designin=
g the feature:</div><div>* Don&#39;t interfere with the type system</div></=
div></blockquote><div><br></div><div>Please allow me to suggest an alternat=
ive principle: integrate into the existing language.</div></div></div></div=
></blockquote><div><br></div><div>Well, it does integrate into the existing=
 language.</div><div>I know what I want for this feature, and smooth adopti=
on w/o binary incompatibility is what I desire, hence the principle.</div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div><div class=3D"gmail_quote"><div></div><div>Far too often, people pr=
oposing features make the mistake of making their feature be its own specia=
l island that has rules different from the rest of the language. This is a =
trap to be avoided. Language continuity is important: C++20 should look and=
 feel like a development of C++17, in order to make it easier for programme=
rs and programs to adapt, but we don&#39;t get there by minimizing the amou=
nt of change to the language or specification, we get there by making the c=
hanges complete so they feel like an extension of what came before.</div><d=
iv><br></div><div>A feature that does not integrate into the type system, b=
ut whose design would naturally lead to type system changes, is flawed. In =
my opinion, you should first design the feature, and then analyze the type =
system implications, not the other way around. (And if that leads to no typ=
e system changes, that&#39;s fine, of course.)</div><div><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div>* Don&#39;t require ABI change=
s</div></div></blockquote><div><br></div><div>I think you should distinguis=
h between &quot;don&#39;t change the ABI of existing libraries&quot; and &q=
uot;don&#39;t change the ABI when designated parameters are added to an int=
erface&quot;. The first seems like an important principle. The second, less=
 so -- as long as the library maintainer still gets to control their ABI as=
 they see fit.</div></div></div></div></blockquote><div><br></div><div>I ha=
ve a feeling that there would be a resistance to adopt designatable paramet=
ers because of ABI incompatibility.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>Actually, forwa=
rding function is explicitly listed in my non-goals, that&#39;s why I delib=
erately disable the indirect use in the end of section 3.2.3.</div></div></=
div></blockquote><div><br></div><div>The fact that this is a non-goal is go=
ing to make your proposal very unappealing to some portion of the committee=
..</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v>If I were going to support forwarding functions, that means I have to mak=
e designatable parameters part of the type as you suggested in (a), and tha=
t breaks my design principles.</div><div>My choice for designated arguments=
 is much like parameter pack, that is, don&#39;t make them first class obje=
cts.</div><div><br></div><div>I should emphasize how reluctant I am in inte=
rfering with the type system - it&#39;s a no-go for me if adding designatab=
le parameters to existing API would break the ABI.</div></div></blockquote>=
<div><br></div><div>Adding parameters with default arguments to existing AP=
I would break the ABI too</div></div></div></div></blockquote><div><br></di=
v><div>I don&#39;t see any difference in the generated LLVM IR with or with=
out default arguments, any example how it affects the ABI?</div><div><br></=
div><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"><div><div=
 class=3D"gmail_quote"><div>=C2=A0as would many other API changes. With a s=
uitable overload resolution rule, I&#39;d expect to be able to change an AP=
I that does this:</div><div><br></div><div>=C2=A0 struct A {</div><div>=C2=
=A0 =C2=A0 void f(int a, int b);</div><div>=C2=A0 };</div><div><br></div><d=
iv>... to do this:</div><div><br></div><div>=C2=A0 struct A {</div><div>=C2=
=A0 =C2=A0 void f(int a, int b);</div><div>=C2=A0 =C2=A0 void f(int .a, int=
 .b) { f(a, b); }</div><div>=C2=A0 };</div><div><br></div><div>... as a non=
-breaking change (except if someone is taking the address of the function),=
 for people who need perfect ABI compatibility.</div></div></div></div></bl=
ockquote><div>=C2=A0</div><div>So call <font face=3D"courier new, monospace=
">A{}.f(0, 1)</font>is ruled by some conversion sequence?<br></div><div><br=
></div><div>What about:</div><div class=3D"prettyprint" style=3D"border: 1p=
x solid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(25=
0, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> f</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">b</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">b</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: #008;" class=3D"styled-by=
-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">a</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">);</span></div></code><=
/div><br><div>Is the overload valid? Is=C2=A0<span style=3D"font-family: &#=
39;courier new&#39;, monospace;">f(.a =3D 0, .b =3D 1)=C2=A0</span>ambiguou=
s?</div><div><br></div><div>And how would you forward the designators for, =
say, <font face=3D"courier new, monospace">std::function</font>?</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/5a3ebaf4-5297-43d5-9de4-69566c841592%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5a3ebaf4-5297-43d5-9de4-69566c841592=
%40isocpp.org</a>.<br />

------=_Part_1993_2097689633.1460686640898--
------=_Part_1992_1524836420.1460686640898--

.

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

On Thu, Apr 14, 2016 at 7:17 PM, TONGARI J <tongari95@gmail.com> wrote:

> On Friday, April 15, 2016 at 1:57:27 AM UTC+8, Richard Smith wrote:
>>
>> On Wed, Apr 13, 2016 at 8:09 PM, TONGARI J <tong...@gmail.com> wrote:
>>>
>>> There are some principles I set when designing the feature:
>>> * Don't interfere with the type system
>>>
>>
>> Please allow me to suggest an alternative principle: integrate into the
>> existing language.
>>
>
> Well, it does integrate into the existing language.
> I know what I want for this feature, and smooth adoption w/o binary
> incompatibility is what I desire, hence the principle.
>
>
>> Far too often, people proposing features make the mistake of making their
>> feature be its own special island that has rules different from the rest of
>> the language. This is a trap to be avoided. Language continuity is
>> important: C++20 should look and feel like a development of C++17, in order
>> to make it easier for programmers and programs to adapt, but we don't get
>> there by minimizing the amount of change to the language or specification,
>> we get there by making the changes complete so they feel like an extension
>> of what came before.
>>
>> A feature that does not integrate into the type system, but whose design
>> would naturally lead to type system changes, is flawed. In my opinion, you
>> should first design the feature, and then analyze the type system
>> implications, not the other way around. (And if that leads to no type
>> system changes, that's fine, of course.)
>>
>> * Don't require ABI changes
>>>
>>
>> I think you should distinguish between "don't change the ABI of existing
>> libraries" and "don't change the ABI when designated parameters are added
>> to an interface". The first seems like an important principle. The second,
>> less so -- as long as the library maintainer still gets to control their
>> ABI as they see fit.
>>
>
> I have a feeling that there would be a resistance to adopt designatable
> parameters because of ABI incompatibility.
>
>
>> Actually, forwarding function is explicitly listed in my non-goals,
>>> that's why I deliberately disable the indirect use in the end of section
>>> 3.2.3.
>>>
>>
>> The fact that this is a non-goal is going to make your proposal very
>> unappealing to some portion of the committee.
>>
>>
>>> If I were going to support forwarding functions, that means I have to
>>> make designatable parameters part of the type as you suggested in (a), and
>>> that breaks my design principles.
>>> My choice for designated arguments is much like parameter pack, that is,
>>> don't make them first class objects.
>>>
>>> I should emphasize how reluctant I am in interfering with the type
>>> system - it's a no-go for me if adding designatable parameters to existing
>>> API would break the ABI.
>>>
>>
>> Adding parameters with default arguments to existing API would break the
>> ABI too
>>
>
> I don't see any difference in the generated LLVM IR with or without
> default arguments, any example how it affects the ABI?
>

"void f(int a);" and "void f(int a, int b = 0);" generate different code.
The point is that we only need to provide tools to avoid ABI breaks, we
don't need to make sure that using the feature doesn't break ABI. That's up
to the library vendor to deal with.


>  as would many other API changes. With a suitable overload resolution
>> rule, I'd expect to be able to change an API that does this:
>>
>>   struct A {
>>     void f(int a, int b);
>>   };
>>
>> ... to do this:
>>
>>   struct A {
>>     void f(int a, int b);
>>     void f(int .a, int .b) { f(a, b); }
>>   };
>>
>> ... as a non-breaking change (except if someone is taking the address of
>> the function), for people who need perfect ABI compatibility.
>>
>
> So call A{}.f(0, 1)is ruled by some conversion sequence?
>

Sure.


> What about:
> void f(int .a, int .b);
> void f(int .b, int .a);
>
> Is the overload valid? Is f(.a = 0, .b = 1) ambiguous?
>

Yes, ambiguous.


> And how would you forward the designators for, say, std::function?
>

I asked you the same question upthread :) I also sketched out one possible
approach.

--
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/CAOfiQqkREWaKKZ-3skHEDrp3kZW%3D5X2c-0n-OLOdStPAYMEPYw%40mail.gmail.com.

--001a113ea5f0792bc805307cf539
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 T=
hu, Apr 14, 2016 at 7:17 PM, TONGARI J <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:tongari95@gmail.com" target=3D"_blank">tongari95@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Friday, Apr=
il 15, 2016 at 1:57:27 AM UTC+8, Richard Smith wrote:<span class=3D""><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"><div><div class=3D"gmai=
l_quote">On Wed, Apr 13, 2016 at 8:09 PM, TONGARI J <span dir=3D"ltr">&lt;<=
a rel=3D"nofollow">tong...@gmail.com</a>&gt;</span> wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div>There are some principles I set when de=
signing the feature:</div><div>* Don&#39;t interfere with the type system</=
div></div></blockquote><div><br></div><div>Please allow me to suggest an al=
ternative principle: integrate into the existing language.</div></div></div=
></div></blockquote><div><br></div></span><div>Well, it does integrate into=
 the existing language.</div><div>I know what I want for this feature, and =
smooth adoption w/o binary incompatibility is what I desire, hence the prin=
ciple.</div><span class=3D""><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div=
>Far too often, people proposing features make the mistake of making their =
feature be its own special island that has rules different from the rest of=
 the language. This is a trap to be avoided. Language continuity is importa=
nt: C++20 should look and feel like a development of C++17, in order to mak=
e it easier for programmers and programs to adapt, but we don&#39;t get the=
re by minimizing the amount of change to the language or specification, we =
get there by making the changes complete so they feel like an extension of =
what came before.</div><div><br></div><div>A feature that does not integrat=
e into the type system, but whose design would naturally lead to type syste=
m changes, is flawed. In my opinion, you should first design the feature, a=
nd then analyze the type system implications, not the other way around. (An=
d if that leads to no type system changes, that&#39;s fine, of course.)</di=
v><div><br></div><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 require ABI changes</div></div></blockquote><div><br></div><div>I th=
ink you should distinguish between &quot;don&#39;t change the ABI of existi=
ng libraries&quot; and &quot;don&#39;t change the ABI when designated param=
eters are added to an interface&quot;. The first seems like an important pr=
inciple. The second, less so -- as long as the library maintainer still get=
s to control their ABI as they see fit.</div></div></div></div></blockquote=
><div><br></div></span><div>I have a feeling that there would be a resistan=
ce to adopt designatable parameters because of ABI incompatibility.</div><s=
pan class=3D""><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div><div>Actually, forwarding function is explicitly li=
sted in my non-goals, that&#39;s why I deliberately disable the indirect us=
e in the end of section 3.2.3.</div></div></div></blockquote><div><br></div=
><div>The fact that this is a non-goal is going to make your proposal very =
unappealing to some portion of the committee.</div><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div>If I were going to support fo=
rwarding functions, that means I have to make designatable parameters part =
of the type as you suggested in (a), and that breaks my design principles.<=
/div><div>My choice for designated arguments is much like parameter pack, t=
hat is, don&#39;t make them first class objects.</div><div><br></div><div>I=
 should emphasize how reluctant I am in interfering with the type system - =
it&#39;s a no-go for me if adding designatable parameters to existing API w=
ould break the ABI.</div></div></blockquote><div><br></div><div>Adding para=
meters with default arguments to existing API would break the ABI too</div>=
</div></div></div></blockquote><div><br></div></span><div>I don&#39;t see a=
ny difference in the generated LLVM IR with or without default arguments, a=
ny example how it affects the ABI?</div></div></blockquote><div><br></div><=
div>&quot;void f(int a);&quot; and &quot;void f(int a, int b =3D 0);&quot; =
generate different code. The point is that we only need to provide tools to=
 avoid ABI breaks, we don&#39;t need to make sure that using the feature do=
esn&#39;t break ABI. That&#39;s up to the library vendor to deal with.</div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span cla=
ss=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div =
class=3D"gmail_quote"><div>=C2=A0as would many other API changes. With a su=
itable overload resolution rule, I&#39;d expect to be able to change an API=
 that does this:</div><div><br></div><div>=C2=A0 struct A {</div><div>=C2=
=A0 =C2=A0 void f(int a, int b);</div><div>=C2=A0 };</div><div><br></div><d=
iv>... to do this:</div><div><br></div><div>=C2=A0 struct A {</div><div>=C2=
=A0 =C2=A0 void f(int a, int b);</div><div>=C2=A0 =C2=A0 void f(int .a, int=
 .b) { f(a, b); }</div><div>=C2=A0 };</div><div><br></div><div>... as a non=
-breaking change (except if someone is taking the address of the function),=
 for people who need perfect ABI compatibility.</div></div></div></div></bl=
ockquote><div>=C2=A0</div></span><div>So call <font face=3D"courier new, mo=
nospace">A{}.f(0, 1)</font>is ruled by some conversion sequence?</div></div=
></blockquote><div><br></div><div>Sure.</div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div>What about:</div><div style=3D"bord=
er:1px solid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250=
,250,250)"><code><div><span class=3D""><span style=3D"color:#008">void</spa=
n><span style=3D"color:#000"> f</span><span style=3D"color:#660">(</span><s=
pan style=3D"color:#008">int</span><span style=3D"color:#000"> </span><span=
 style=3D"color:#660">.</span><span style=3D"color:#000">a</span><span styl=
e=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"=
color:#008">int</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#660">.</span><span style=3D"color:#000">b</span><span style=3D"color:#6=
60">);</span><span style=3D"color:#000"><br></span></span><span style=3D"co=
lor:#008">void</span><span style=3D"color:#000"> f</span><span style=3D"col=
or:#660">(</span><span style=3D"color:#008">int</span><span style=3D"color:=
#000"> </span><span style=3D"color:#660">.</span><span style=3D"color:#000"=
>b</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#008">int</span><span style=3D"color:#000"> </span=
><span style=3D"color:#660">.</span><span style=3D"color:#000">a</span><spa=
n style=3D"color:#660">);</span></div></code></div><br><div>Is the overload=
 valid? Is=C2=A0<span style=3D"font-family:&#39;courier new&#39;,monospace"=
>f(.a =3D 0, .b =3D 1)=C2=A0</span>ambiguous?</div></div></blockquote><div>=
<br></div><div>Yes, ambiguous.</div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div>And how would you forward the designators fo=
r, say, <font face=3D"courier new, monospace">std::function</font>?</div></=
div></blockquote><div><br></div><div>I asked you the same question upthread=
 :) I also sketched out one possible approach.</div></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/CAOfiQqkREWaKKZ-3skHEDrp3kZW%3D5X2c-0=
n-OLOdStPAYMEPYw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqkREWaKKZ=
-3skHEDrp3kZW%3D5X2c-0n-OLOdStPAYMEPYw%40mail.gmail.com</a>.<br />

--001a113ea5f0792bc805307cf539--

.

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

Hi Tongari,

I've actually been working on a designated initialization proposal.  My
current thinking on the matter was to propose an uncontroversial first step
of motivating and adopting in C++ a strict subset of the existing C feature
(just the parts that clearly make sense for C++), and then showing how this
fits into a large family of possible future roadmaps, such as the one you
outline in your proposal.

My reaction to reading your proposal is that you are being too ambitious.
It would be multiple years of work to get standardized such a large feature
of "uniform designators" across function calls, aggregate initialization
and other types of initialization - and that is assuming consensus can be
achieved at all, which given the history of named parameter proposals, is a
long shot.

That's why I think breaking off and nailing down a smaller first step would
be more practical.  The C feature has extensive existing practice that can
be appealed to, so I think a subset-only proposal has a much better chance
of getting through.  Once that gets in and is nailed down, a proposal to
extend an existing feature will be much better received than trying to do
everything at once.

Regards,
Andrew.



On Wed, Apr 13, 2016 at 10:33 AM, TONGARI J <tongari95@gmail.com> wrote:

> Hi,
>
> The draft can be viewed at:
> http://jamboree.github.io/designator-draft.html
>
> The prototype based on Clang can be found at:
> https://github.com/jamboree/clang/tree/feature/designator
>
>
> I'm not sure if it's proper to submit a new proposal before C++17 is
> settled, anyway, I'd like to make this work public now.
> Please let me know if anyone wants to be a champion if it's submitted.
>
>
> Thanks
>
> --
> 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/e2d5660e-2cf7-4107-868d-7027bdce344f%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e2d5660e-2cf7-4107-868d-7027bdce344f%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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/CAB%2B4KH%2BwQxcNWsadfxqtM1nMopQ28vnJ0wmG%2B_WUzth8fiSN2g%40mail.gmail.com.

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

<div dir=3D"ltr">Hi Tongari,<div><br></div><div>I&#39;ve actually been work=
ing on a designated initialization proposal.=C2=A0 My current thinking on t=
he matter was to propose an uncontroversial first step of motivating and ad=
opting in C++ a strict subset of the existing C feature (just the parts tha=
t clearly make sense for C++), and then showing how this fits into a large =
family of possible future roadmaps, such as the one you outline in your pro=
posal.</div><div><br></div><div>My reaction to reading your proposal is tha=
t you are being too ambitious.=C2=A0 It would be multiple years of work to =
get standardized such a large feature of &quot;uniform designators&quot; ac=
ross function calls, aggregate initialization and other types of initializa=
tion - and that is assuming consensus can be achieved at all, which given t=
he history of named parameter proposals, is a long shot.<br></div><div><br>=
</div><div>That&#39;s why I think breaking off and nailing down a smaller f=
irst step would be more practical.=C2=A0 The C feature has extensive existi=
ng practice that can be appealed to, so I think a subset-only proposal has =
a much better chance of getting through.=C2=A0 Once that gets in and is nai=
led down, a proposal to extend an existing feature will be much better rece=
ived than trying to do everything at once.</div><div><br></div><div>Regards=
,</div><div>Andrew.</div><div><br></div><div><br></div></div><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote">On Wed, Apr 13, 2016 at 10:33 A=
M, TONGARI J <span dir=3D"ltr">&lt;<a href=3D"mailto:tongari95@gmail.com" t=
arget=3D"_blank">tongari95@gmail.com</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div>Hi,</div><div><br></div><div>The dr=
aft can be viewed at:</div><a href=3D"http://jamboree.github.io/designator-=
draft.html" target=3D"_blank">http://jamboree.github.io/designator-draft.ht=
ml</a><br><div><br></div><div>The prototype based on Clang can be found at:=
</div><div><a href=3D"https://github.com/jamboree/clang/tree/feature/design=
ator" target=3D"_blank">https://github.com/jamboree/clang/tree/feature/desi=
gnator</a><br></div><div><br></div><div><br></div><div>I&#39;m not sure if =
it&#39;s proper to submit a new proposal before C++17 is settled, anyway, I=
&#39;d like to make this work public now.</div><div>Please let me know if a=
nyone wants to be a champion if it&#39;s=C2=A0submitted.</div><div><br></di=
v><div><br></div><div>Thanks</div></div><span class=3D"HOEnZb"><font color=
=3D"#888888">

<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" target=3D"_=
blank">std-proposals+unsubscribe@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/e2d5660e-2cf7-4107-868d-7027bdce344f%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e2d5660e-2cf7-=
4107-868d-7027bdce344f%40isocpp.org</a>.<br>
</font></span></blockquote></div><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/CAB%2B4KH%2BwQxcNWsadfxqtM1nMopQ28vnJ=
0wmG%2B_WUzth8fiSN2g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KH%2=
BwQxcNWsadfxqtM1nMopQ28vnJ0wmG%2B_WUzth8fiSN2g%40mail.gmail.com</a>.<br />

--001a11416d4010bf1d05307db99e--

.

------=_Part_5586_143372592.1460692613527
Content-Type: multipart/alternative;
 boundary="----=_Part_5587_966535916.1460692613527"

------=_Part_5587_966535916.1460692613527
Content-Type: text/plain; charset=UTF-8

Hi Andrew,

On Friday, April 15, 2016 at 11:36:59 AM UTC+8, Andrew Tomazos wrote:
>
> Hi Tongari,
>
> I've actually been working on a designated initialization proposal.  My
> current thinking on the matter was to propose an uncontroversial first step
> of motivating and adopting in C++ a strict subset of the existing C feature
> (just the parts that clearly make sense for C++), and then showing how this
> fits into a large family of possible future roadmaps, such as the one you
> outline in your proposal.
>
> My reaction to reading your proposal is that you are being too ambitious.
> It would be multiple years of work to get standardized such a large feature
> of "uniform designators" across function calls, aggregate initialization
> and other types of initialization - and that is assuming consensus can be
> achieved at all, which given the history of named parameter proposals, is a
> long shot.
>

Obviously, Richard is much more ambitious than me ;)
What I proposed is really the minimal, simplest model in practice.


> That's why I think breaking off and nailing down a smaller first step
> would be more practical.  The C feature has extensive existing practice
> that can be appealed to, so I think a subset-only proposal has a much
> better chance of getting through.  Once that gets in and is nailed down, a
> proposal to extend an existing feature will be much better received than
> trying to do everything at once.
>

I'm not sure if you're an advocator of the alternative described in section
5.7 <http://57-alternative-of-designated-arguments>, which I already showed
would be a dead end for C++, or you just want to cutoff the proposal to an
even smaller subset.
Anyway, Richard seems to have the exact opposite opinion that we should
give a more comprehensive proposal, quoting from his mail:


> we don't get there by minimizing the amount of change to the language or
> specification, we get there by making the changes complete so they feel
> like an extension of what came before.

--
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/8177d926-1afe-4ca9-a2b3-a120532d9bbe%40isocpp.org.

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

<div dir=3D"ltr">Hi=C2=A0Andrew,<br><br>On Friday, April 15, 2016 at 11:36:=
59 AM UTC+8, Andrew Tomazos 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">Hi Tongari,<div><br></div><div>I&#39;ve actually bee=
n working on a designated initialization proposal.=C2=A0 My current thinkin=
g on the matter was to propose an uncontroversial first step of motivating =
and adopting in C++ a strict subset of the existing C feature (just the par=
ts that clearly make sense for C++), and then showing how this fits into a =
large family of possible future roadmaps, such as the one you outline in yo=
ur proposal.</div><div><br></div><div>My reaction to reading your proposal =
is that you are being too ambitious.=C2=A0 It would be multiple years of wo=
rk to get standardized such a large feature of &quot;uniform designators&qu=
ot; across function calls, aggregate initialization and other types of init=
ialization - and that is assuming consensus can be achieved at all, which g=
iven the history of named parameter proposals, is a long shot.<br></div></d=
iv></blockquote><div><br></div><div>Obviously, Richard is much more ambitio=
us than me ;)</div><div>What I proposed is really the minimal, simplest mod=
el in practice.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><div></div><div>That&#39;s why I think breaking of=
f and nailing down a smaller first step would be more practical.=C2=A0 The =
C feature has extensive existing practice that can be appealed to, so I thi=
nk a subset-only proposal has a much better chance of getting through.=C2=
=A0 Once that gets in and is nailed down, a proposal to extend an existing =
feature will be much better received than trying to do everything at once.<=
/div></div></blockquote><div><br></div><div>I&#39;m not sure if you&#39;re =
an advocator of the alternative described in <a href=3D"http://57-alternati=
ve-of-designated-arguments">section 5.7</a>, which I already showed would b=
e a dead end for C++, or you just want to cutoff the proposal to an even sm=
aller subset.</div><div>Anyway, Richard seems to have the exact opposite op=
inion that we should give a more comprehensive proposal, quoting from his m=
ail:</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 2=
04, 204); border-left-style: solid; padding-left: 1ex;">we don&#39;t get th=
ere by minimizing the amount of change to the language or specification, we=
 get there by making the changes complete so they feel like an extension of=
 what came before.</blockquote></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/8177d926-1afe-4ca9-a2b3-a120532d9bbe%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8177d926-1afe-4ca9-a2b3-a120532d9bbe=
%40isocpp.org</a>.<br />

------=_Part_5587_966535916.1460692613527--
------=_Part_5586_143372592.1460692613527--

.

On quinta-feira, 14 de abril de 2016 18:43:41 PDT TONGARI J wrote:
> I guess Thiago's example is an argument for designator list?

It's an argument against "member names are part of the API". However, this
*does* work in C99:

struct ip6_hdr hdr = {
 .ip6_flow = 0,
 .ip6_plen = 4,
 .ip6_nxt = 46,
 .ip6_hops = 64
};

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/3634317.zkgPMoJp7T%40tjmaciei-mobl4.

.

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

On Fri, Apr 15, 2016 at 5:56 AM, TONGARI J <tongari95@gmail.com> wrote:

> Hi Andrew,
>
> On Friday, April 15, 2016 at 11:36:59 AM UTC+8, Andrew Tomazos wrote:
>>
>> Hi Tongari,
>>
>> I've actually been working on a designated initialization proposal.  My
>> current thinking on the matter was to propose an uncontroversial first step
>> of motivating and adopting in C++ a strict subset of the existing C feature
>> (just the parts that clearly make sense for C++), and then showing how this
>> fits into a large family of possible future roadmaps, such as the one you
>> outline in your proposal.
>>
>> My reaction to reading your proposal is that you are being too
>> ambitious.  It would be multiple years of work to get standardized such a
>> large feature of "uniform designators" across function calls, aggregate
>> initialization and other types of initialization - and that is assuming
>> consensus can be achieved at all, which given the history of named
>> parameter proposals, is a long shot.
>>
>
> Obviously, Richard is much more ambitious than me ;)
> What I proposed is really the minimal, simplest model in practice.
>
>
>> That's why I think breaking off and nailing down a smaller first step
>> would be more practical.  The C feature has extensive existing practice
>> that can be appealed to, so I think a subset-only proposal has a much
>> better chance of getting through.  Once that gets in and is nailed down, a
>> proposal to extend an existing feature will be much better received than
>> trying to do everything at once.
>>
>
> I'm not sure if you're an advocator of the alternative described in section
> 5.7 <http://57-alternative-of-designated-arguments>, which I already
> showed would be a dead end for C++, or you just want to cutoff the proposal
> to an even smaller subset.
>

An even smaller subset.  Consider it as the intersection of your proposal
and the existing C feature.  This would necessarily be forward compatible
with your proposal, as the intersection is a subset of your proposal.  The
people that support your proposal must also support such a step.
Additionally, there may be people that don't support your proposal in
entirety, but support such a step.  Therefore that step has a better chance
of achieving consensus than your proposal.

Anyway, Richard seems to have the exact opposite opinion that we should
> give a more comprehensive proposal, quoting from his mail:
>
>
>> we don't get there by minimizing the amount of change to the language or
>> specification, we get there by making the changes complete so they feel
>> like an extension of what came before.
>
>
I think Richard and I are talking about different things.  He is talking
about the design.  I am talking about the execution.

I'm just suggesting we should break up the proposal into a series of steps,
not suggesting we change the destination.

--
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/CAB%2B4KHLBHmdp4XpyHKxrjfZM8HUXAG9jWp9dpk33rTYsmPrWoQ%40mail.gmail.com.

--001a113d058c0cdbe105307eb054
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, Apr 15, 2016 at 5:56 AM, TONGARI J <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:tongari95@gmail.com" target=3D"_blank">tongari95@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi=C2=A0Andrew=
,<span class=3D""><br><br>On Friday, April 15, 2016 at 11:36:59 AM UTC+8, A=
ndrew Tomazos wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
">Hi Tongari,<div><br></div><div>I&#39;ve actually been working on a design=
ated initialization proposal.=C2=A0 My current thinking on the matter was t=
o propose an uncontroversial first step of motivating and adopting in C++ a=
 strict subset of the existing C feature (just the parts that clearly make =
sense for C++), and then showing how this fits into a large family of possi=
ble future roadmaps, such as the one you outline in your proposal.</div><di=
v><br></div><div>My reaction to reading your proposal is that you are being=
 too ambitious.=C2=A0 It would be multiple years of work to get standardize=
d such a large feature of &quot;uniform designators&quot; across function c=
alls, aggregate initialization and other types of initialization - and that=
 is assuming consensus can be achieved at all, which given the history of n=
amed parameter proposals, is a long shot.<br></div></div></blockquote><div>=
<br></div></span><div>Obviously, Richard is much more ambitious than me ;)<=
/div><div>What I proposed is really the minimal, simplest model in practice=
..</div><span class=3D""><div>=C2=A0</div><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"><div></div><div>That&#39;s why I think breaking off =
and nailing down a smaller first step would be more practical.=C2=A0 The C =
feature has extensive existing practice that can be appealed to, so I think=
 a subset-only proposal has a much better chance of getting through.=C2=A0 =
Once that gets in and is nailed down, a proposal to extend an existing feat=
ure will be much better received than trying to do everything at once.</div=
></div></blockquote><div><br></div></span><div>I&#39;m not sure if you&#39;=
re an advocator of the alternative described in <a href=3D"http://57-altern=
ative-of-designated-arguments" target=3D"_blank">section 5.7</a>, which I a=
lready showed would be a dead end for C++, or you just want to cutoff the p=
roposal to an even smaller subset.</div></div></blockquote><div><br></div><=
div>An even smaller subset.=C2=A0 Consider it as the intersection of your p=
roposal and the existing C feature.=C2=A0 This would necessarily be forward=
 compatible with your proposal, as the intersection is a subset of your pro=
posal.=C2=A0 The people that support your proposal must also support such a=
 step.=C2=A0 Additionally, there may be people that don&#39;t support your =
proposal in entirety, but support such a step.=C2=A0 Therefore that step ha=
s a better chance of achieving consensus than your proposal.</div><div><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Anyway, Richard =
seems to have the exact opposite opinion that we should give a more compreh=
ensive proposal, quoting from his mail:</div><span class=3D""><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol=
id;padding-left:1ex">we don&#39;t get there by minimizing the amount of cha=
nge to the language or specification, we get there by making the changes co=
mplete so they feel like an extension of what came before.</blockquote></sp=
an></div></blockquote><div><br></div><div>I think Richard and I are talking=
 about different things.=C2=A0 He is talking about the design.=C2=A0 I am t=
alking about the execution.<br></div><div><br></div><div>I&#39;m just sugge=
sting we should break up the proposal into a series of steps, not suggestin=
g we change the destination.</div><div><br></div></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/CAB%2B4KHLBHmdp4XpyHKxrjfZM8HUXAG9jWp=
9dpk33rTYsmPrWoQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHLBHmdp=
4XpyHKxrjfZM8HUXAG9jWp9dpk33rTYsmPrWoQ%40mail.gmail.com</a>.<br />

--001a113d058c0cdbe105307eb054--

.

------=_Part_355_42339053.1460700081178
Content-Type: multipart/alternative;
 boundary="----=_Part_356_2109284660.1460700081179"

------=_Part_356_2109284660.1460700081179
Content-Type: text/plain; charset=UTF-8

On Friday, April 15, 2016 at 10:42:17 AM UTC+8, Richard Smith wrote:
>
> On Thu, Apr 14, 2016 at 7:17 PM, TONGARI J <tong...@gmail.com
> <javascript:>> wrote:
>>
>> And how would you forward the designators for, say, std::function?
>>
>
> I asked you the same question upthread :) I also sketched out one possible
> approach.
>

OK, quoting from your post:

We could imagine something like this:
> template<typename F, designator ...D, typename ...T> decltype(auto) f(F f,
> T &&... .D) {
>   return f(0, .D = std::forward<T>(D) ...);
> }
> That is: a new kind of template parameter representing a designator, and
> designator names are looked up to see if they name such a parameter before
> assuming they're an opaque identifier. (Plus a notional "empty designator"
> that is deduced in cases where no designator is specified.) I don't think I
> like this approach, and as noted, I hope there's a better answer.


I imagine a more proper syntax would be:

template<designator ...D, typename F, typename ...T> decltype(auto) call(F f
, T && D ...t) {
  return f(0, D = std::forward<T>(t) ...);
}

* "designator" would be a contextual keyword only allowed in template
param-list.
* The designators can be used in both param-list in
the function declaration (isolated from the actual param-name) and the
expr-list in function-call-expr.

However, I'm not sure if you could  deduce the designators from args or not?
call(f, .b = 1, .a = 2); // ok?

If you allow the call above, what if call is defined as below:
template<typename F, typename ...T> decltype(auto) call(F f, T && ...t) {
 return f(0, std::forward<T>(t) ...);
}
Should it give the same result?

I suspect you cannot do that. A simpler way is to force designators to be
explicitly specified:
call<.a, .b>(f, .b = 1, .a = 2);

I'm not sure I like it though, seems problematic if we're going to support
designated template arguments in the future, e.g. V<.T = int>.

You really think it worth the complexity?

--
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/98475b72-820c-4eaf-a530-a9ebd02d09f4%40isocpp.org.

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

<div dir=3D"ltr">On Friday, April 15, 2016 at 10:42:17 AM UTC+8, Richard Sm=
ith 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"><di=
v class=3D"gmail_quote">On Thu, Apr 14, 2016 at 7:17 PM, TONGARI J <span di=
r=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"R_cllP2VBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;">tong...@gmail.com</a>&gt;</span> wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div>And how would you forward the designators for, sa=
y, <font face=3D"courier new, monospace">std::function</font>?</div></div><=
/blockquote><div><br></div><div>I asked you the same question upthread :) I=
 also sketched out one possible approach.</div></div></div></blockquote><di=
v><br></div><div>OK, quoting from your post:</div><div><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-wid=
th: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; p=
adding-left: 1ex;">We could imagine something like this:<br>template&lt;typ=
ename F, designator ...D, typename ...T&gt; decltype(auto) f(F f, T &amp;&a=
mp;... .D) {<br>=C2=A0 return f(0, .D =3D std::forward&lt;T&gt;(D) ...);<br=
>}<br>That is: a new kind of template parameter representing a designator, =
and designator names are looked up to see if they name such a parameter bef=
ore assuming they&#39;re an opaque identifier. (Plus a notional &quot;empty=
 designator&quot; that is deduced in cases where no designator is specified=
..) I don&#39;t think I like this approach, and as noted, I hope there&#39;s=
 a better answer.=C2=A0</blockquote><div><br></div><div>I imagine a more pr=
oper syntax would be:</div><div><br></div><div class=3D"prettyprint" style=
=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; background=
-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subp=
rettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">templ=
ate</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</s=
pan><span class=3D"styled-by-prettify" style=3D"font-family: Arial, Helveti=
ca, sans-serif; color: rgb(0, 0, 0);">designator=C2=A0</span><span class=3D=
"styled-by-prettify" style=3D"font-family: Arial, Helvetica, sans-serif; co=
lor: rgb(102, 102, 0);">...</span><span class=3D"styled-by-prettify" style=
=3D"font-family: Arial, Helvetica, sans-serif; color: rgb(0, 0, 0);">D</spa=
n><span class=3D"styled-by-prettify" style=3D"font-family: Arial, Helvetica=
, sans-serif; color: rgb(102, 102, 0);">,</span><span class=3D"styled-by-pr=
ettify" style=3D"font-family: Arial, Helvetica, sans-serif; color: rgb(0, 0=
, 0);">=C2=A0</span><span class=3D"styled-by-prettify" style=3D"font-family=
: Arial, Helvetica, sans-serif; color: rgb(0, 0, 136);">typename</span><spa=
n class=3D"styled-by-prettify" style=3D"font-family: Arial, Helvetica, sans=
-serif; color: rgb(0, 0, 0);"> F</span><span class=3D"styled-by-prettify" s=
tyle=3D"font-family: Arial, Helvetica, sans-serif; color: rgb(102, 102, 0);=
">,</span><span class=3D"styled-by-prettify" style=3D"font-family: Arial, H=
elvetica, sans-serif; color: rgb(0, 0, 0);"> </span><span class=3D"styled-b=
y-prettify" style=3D"font-family: Arial, Helvetica, sans-serif; color: rgb(=
0, 0, 136);">typename</span><span class=3D"styled-by-prettify" style=3D"fon=
t-family: Arial, Helvetica, sans-serif; color: rgb(0, 0, 0);"> </span><span=
 class=3D"styled-by-prettify" style=3D"font-family: Arial, Helvetica, sans-=
serif; color: rgb(102, 102, 0);">...</span><span class=3D"styled-by-prettif=
y" style=3D"font-family: Arial, Helvetica, sans-serif; color: rgb(0, 0, 0);=
">T</span><span class=3D"styled-by-prettify" style=3D"font-family: Arial, H=
elvetica, sans-serif; color: rgb(102, 102, 0);">&gt;</span><span class=3D"s=
tyled-by-prettify" style=3D"font-family: Arial, Helvetica, sans-serif; colo=
r: rgb(0, 0, 0);"> </span><span class=3D"styled-by-prettify" style=3D"font-=
family: Arial, Helvetica, sans-serif; color: rgb(0, 0, 136);">decltype</spa=
n><span class=3D"styled-by-prettify" style=3D"font-family: Arial, Helvetica=
, sans-serif; color: rgb(102, 102, 0);">(</span><span class=3D"styled-by-pr=
ettify" style=3D"font-family: Arial, Helvetica, sans-serif; color: rgb(0, 0=
, 136);">auto</span><span class=3D"styled-by-prettify" style=3D"font-family=
: Arial, Helvetica, sans-serif; color: rgb(102, 102, 0);">)</span><span cla=
ss=3D"styled-by-prettify" style=3D"font-family: Arial, Helvetica, sans-seri=
f; color: rgb(0, 0, 0);"> call</span><span class=3D"styled-by-prettify" sty=
le=3D"font-family: Arial, Helvetica, sans-serif; color: rgb(102, 102, 0);">=
(</span><span class=3D"styled-by-prettify" style=3D"font-family: Arial, Hel=
vetica, sans-serif; color: rgb(0, 0, 0);">F f</span><span class=3D"styled-b=
y-prettify" style=3D"font-family: Arial, Helvetica, sans-serif; color: rgb(=
102, 102, 0);">,</span><span class=3D"styled-by-prettify" style=3D"font-fam=
ily: Arial, Helvetica, sans-serif; color: rgb(0, 0, 0);"> T </span><span cl=
ass=3D"styled-by-prettify" style=3D"font-family: Arial, Helvetica, sans-ser=
if; color: rgb(102, 102, 0);">&amp;&amp;</span><span class=3D"styled-by-pre=
ttify" style=3D"font-family: Arial, Helvetica, sans-serif; color: rgb(0, 0,=
 0);"> D </span><span class=3D"styled-by-prettify" style=3D"font-family: Ar=
ial, Helvetica, sans-serif; color: rgb(102, 102, 0);">...</span><span class=
=3D"styled-by-prettify" style=3D"font-family: Arial, Helvetica, sans-serif;=
 color: rgb(0, 0, 0);">t</span><span class=3D"styled-by-prettify" style=3D"=
font-family: Arial, Helvetica, sans-serif; color: rgb(102, 102, 0);">)</spa=
n><span class=3D"styled-by-prettify" style=3D"font-family: Arial, Helvetica=
, sans-serif; color: rgb(0, 0, 0);"> </span><span class=3D"styled-by-pretti=
fy" style=3D"font-family: Arial, Helvetica, sans-serif; color: rgb(102, 102=
, 0);">{</span></div><div class=3D"subprettyprint"><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">=C2=A0 </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #066;" class=3D"styled-by-=
prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> D </spa=
n><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 style=3D"colo=
r: #000;" class=3D"styled-by-prettify">forward</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&gt;(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">t</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">)</span><span style=3D"color: #000;" class=3D"styled-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></div></code><=
/div><div><br></div><div>* &quot;designator&quot; would be a contextual key=
word only allowed in template param-list.<br>* The=C2=A0designators can be =
used in both param-list in the=C2=A0function=C2=A0declaration (isolated fro=
m the actual param-name) and the expr-list in function-call-expr.<br></div>=
<div><br></div><div>However, I&#39;m not sure if you could =C2=A0deduce the=
 designators from args or not?</div><div class=3D"prettyprint" style=3D"bor=
der: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-color:=
 rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettypr=
int"><span style=3D"color: #000;" class=3D"styled-by-prettify">call</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">f</span><span style=3D"colo=
r: #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=
"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">b </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #066;" class=3D"styled-by-prettify">1</span><spa=
n 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"styled-by-prettify">.</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">a </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prett=
ify">2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #800;" class=3D"styled-by-prettify">// ok?</span></div></=
code></div><br>If you allow the call above, what if <font face=3D"courier n=
ew, monospace">call</font> is defined as below:<br><div class=3D"prettyprin=
t" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; ba=
ckground-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">template</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">typen=
ame</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> F</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">...</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
decltype</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> call</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">F f</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> T </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">&amp;&amp;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">...</span><span style=3D"color: #000;" class=3D"styled-by-prettify">t</s=
pan><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"styled-by-prettify">{</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br>=C2=A0</span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> st=
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">forward</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">&gt;(</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">t</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">...);</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</=
span></div></code></div>Should it give the same result?<br><div><br></div><=
div>I suspect you cannot do that. A simpler way is to force designators to =
be explicitly specified:</div><div class=3D"prettyprint" style=3D"border: 1=
px solid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(2=
50, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><=
span style=3D"color: #000;" class=3D"styled-by-prettify">call</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&lt;.</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">a</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"=
styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">b</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&gt;(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">f</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">b </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">1</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">a </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;=
" class=3D"styled-by-prettify">2</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span></div></code></div><div><br></div>I&#39;m =
not sure I like it though, seems problematic if we&#39;re going to support =
designated template arguments in the future, e.g. <font face=3D"courier new=
, monospace">V&lt;.T =3D int&gt;</font>.<div><br></div><div>You really thin=
k it worth the complexity?</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/98475b72-820c-4eaf-a530-a9ebd02d09f4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/98475b72-820c-4eaf-a530-a9ebd02d09f4=
%40isocpp.org</a>.<br />

------=_Part_356_2109284660.1460700081179--
------=_Part_355_42339053.1460700081178--

.

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

2016-04-15 12:46 GMT+08:00 Andrew Tomazos <andrewtomazos@gmail.com>:

> On Fri, Apr 15, 2016 at 5:56 AM, TONGARI J <tongari95@gmail.com> wrote:
>
>> Hi Andrew,
>>
>> On Friday, April 15, 2016 at 11:36:59 AM UTC+8, Andrew Tomazos wrote:
>>>
>>> Hi Tongari,
>>>
>>> I've actually been working on a designated initialization proposal.  My
>>> current thinking on the matter was to propose an uncontroversial first step
>>> of motivating and adopting in C++ a strict subset of the existing C feature
>>> (just the parts that clearly make sense for C++), and then showing how this
>>> fits into a large family of possible future roadmaps, such as the one you
>>> outline in your proposal.
>>>
>>> My reaction to reading your proposal is that you are being too
>>> ambitious.  It would be multiple years of work to get standardized such a
>>> large feature of "uniform designators" across function calls, aggregate
>>> initialization and other types of initialization - and that is assuming
>>> consensus can be achieved at all, which given the history of named
>>> parameter proposals, is a long shot.
>>>
>>
>> Obviously, Richard is much more ambitious than me ;)
>> What I proposed is really the minimal, simplest model in practice.
>>
>>
>>> That's why I think breaking off and nailing down a smaller first step
>>> would be more practical.  The C feature has extensive existing practice
>>> that can be appealed to, so I think a subset-only proposal has a much
>>> better chance of getting through.  Once that gets in and is nailed down, a
>>> proposal to extend an existing feature will be much better received than
>>> trying to do everything at once.
>>>
>>
>> I'm not sure if you're an advocator of the alternative described in section
>> 5.7 <http://57-alternative-of-designated-arguments>, which I already
>> showed would be a dead end for C++, or you just want to cutoff the proposal
>> to an even smaller subset.
>>
>
> An even smaller subset.  Consider it as the intersection of your proposal
> and the existing C feature.  This would necessarily be forward compatible
> with your proposal, as the intersection is a subset of your proposal.  The
> people that support your proposal must also support such a step.
> Additionally, there may be people that don't support your proposal in
> entirety, but support such a step.  Therefore that step has a better chance
> of achieving consensus than your proposal.
>

Well, it'd be fine if you could push designated initializers into C++17,
and I can aim for C++20. But if designated initializers could only aim for
C++20, another 3 years seem to be a long time for designated
arguments...during the long period, people could have established the
boring tricks to emulate designated arguments and it's not hard to imagine
that they're ask for the syntax-sugar alternative I illustrated instead of
a formal approach.

Maybe I'm just too pessimistic...

--
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/CANCwVhfa32N%3DcQVur_QY1wmFbPMNxVYErKPsLAYQWZ9yEC%3DQGg%40mail.gmail.com.

--001a113e798815acc30530804eb8
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">2016=
-04-15 12:46 GMT+08:00 Andrew Tomazos <span dir=3D"ltr">&lt;<a href=3D"mail=
to:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@gmail.com</a>&g=
t;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><span class=3D"">On Fri, Apr 15, 2016 at 5:56 AM=
, TONGARI J <span dir=3D"ltr">&lt;<a href=3D"mailto:tongari95@gmail.com" ta=
rget=3D"_blank">tongari95@gmail.com</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1e=
x"><div dir=3D"ltr">Hi=C2=A0Andrew,<span><br><br>On Friday, April 15, 2016 =
at 11:36:59 AM UTC+8, Andrew Tomazos wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color=
:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr=
">Hi Tongari,<div><br></div><div>I&#39;ve actually been working on a design=
ated initialization proposal.=C2=A0 My current thinking on the matter was t=
o propose an uncontroversial first step of motivating and adopting in C++ a=
 strict subset of the existing C feature (just the parts that clearly make =
sense for C++), and then showing how this fits into a large family of possi=
ble future roadmaps, such as the one you outline in your proposal.</div><di=
v><br></div><div>My reaction to reading your proposal is that you are being=
 too ambitious.=C2=A0 It would be multiple years of work to get standardize=
d such a large feature of &quot;uniform designators&quot; across function c=
alls, aggregate initialization and other types of initialization - and that=
 is assuming consensus can be achieved at all, which given the history of n=
amed parameter proposals, is a long shot.<br></div></div></blockquote><div>=
<br></div></span><div>Obviously, Richard is much more ambitious than me ;)<=
/div><div>What I proposed is really the minimal, simplest model in practice=
..</div><span><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div></div>=
<div>That&#39;s why I think breaking off and nailing down a smaller first s=
tep would be more practical.=C2=A0 The C feature has extensive existing pra=
ctice that can be appealed to, so I think a subset-only proposal has a much=
 better chance of getting through.=C2=A0 Once that gets in and is nailed do=
wn, a proposal to extend an existing feature will be much better received t=
han trying to do everything at once.</div></div></blockquote><div><br></div=
></span><div>I&#39;m not sure if you&#39;re an advocator of the alternative=
 described in <a href=3D"http://57-alternative-of-designated-arguments" tar=
get=3D"_blank">section 5.7</a>, which I already showed would be a dead end =
for C++, or you just want to cutoff the proposal to an even smaller subset.=
</div></div></blockquote><div><br></div></span><div>An even smaller subset.=
=C2=A0 Consider it as the intersection of your proposal and the existing C =
feature.=C2=A0 This would necessarily be forward compatible with your propo=
sal, as the intersection is a subset of your proposal.=C2=A0 The people tha=
t support your proposal must also support such a step.=C2=A0 Additionally, =
there may be people that don&#39;t support your proposal in entirety, but s=
upport such a step.=C2=A0 Therefore that step has a better chance of achiev=
ing consensus than your proposal.</div></div></div></div></blockquote><div>=
<br></div><div>Well, it&#39;d be fine if you could push designated initiali=
zers into C++17, and I can aim for C++20. But if designated initializers co=
uld only aim for C++20, another 3 years seem to be a long time for designat=
ed arguments...during the long period, people could have established the bo=
ring tricks to emulate designated arguments and it&#39;s not hard to imagin=
e that they&#39;re ask for the syntax-sugar alternative I illustrated inste=
ad of a formal approach.</div><div><br></div><div>Maybe I&#39;m just too=C2=
=A0pessimistic...</div></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/CANCwVhfa32N%3DcQVur_QY1wmFbPMNxVYErK=
PsLAYQWZ9yEC%3DQGg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANCwVhfa32N%=
3DcQVur_QY1wmFbPMNxVYErKPsLAYQWZ9yEC%3DQGg%40mail.gmail.com</a>.<br />

--001a113e798815acc30530804eb8--

.

On 2016-04-14 17:19, Tony V E wrote:
>> Let me try rephrasing this. Let's say we have a C struct:
>>
>> struct foo { int bar };
>>
>> In C89, the "meaning" of this struct is that I can construct it=20
>> like `{1}`. In C11, the "meaning" is that I can (additionally)
>> construct it=E2=80=8E like `{.bar=3D1}`. This was evidently not a proble=
m for
>> C11. What "change of meaning" occurs in C++ that is different from
>> this example and therefore problematic?
>=20
> In a struct, the member names are already part of the API.

That's not relevant. Remember, this was talking about an opt-in approach
using attributes. This would mean that in C++11, the parameter names are
*also* already part of the API; they're just not an *accessible* part
(the attribute is there, but ignored because it isn't recognized by
C++11). This is almost exactly the same as in C89, the member names are
"already part" of the initializer list; you just can't use them.

Example:

  int foo(int [[named("x")]]);

Note that the parameter name "x" is *already part of the API* (although
not a recognized part by C++11). In C++11, I can call `foo(5)`, just
like in C89 I can construct my struct like `{5}`. In C++??=C2=B9 I can *als=
o*
call `foo(.x =3D 5)`... again, just like in C11 I can also construct my
struct like `{.bar =3D 5}`.

I have yet to meet a non-hand-waving argument argument why the C89->C11
change is okay but the C++11->C++?? change is not.

(=C2=B9 C++?? -> a hypothetical version of C++ that includes this feature.)

--=20
Matthew

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/nequb8%24933%241%40ger.gmane.org.

.

On sexta-feira, 15 de abril de 2016 10:37:14 PDT Matthew Woehlke wrote:
> That's not relevant. Remember, this was talking about an opt-in approach
> using attributes.

I recommend you stop talking about attributes, as this lowers the chance of
the feature being accepted. Not only would the feature itself be fighting to
prove its worth (it's been rejected more than once), using attributes means
fighting against established rules over attributes.

Remember that this feature is asking for differences in overload resolution
and has consequences for the ABI. That's way outside what attributes are meant
to do.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/91376508.yeYmejBR2X%40tjmaciei-mobl4.

.

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

On Fri, Apr 15, 2016 at 8:41 AM, TONGARI J <tongari95@gmail.com> wrote:

> 2016-04-15 12:46 GMT+08:00 Andrew Tomazos <andrewtomazos@gmail.com>:
>
>> On Fri, Apr 15, 2016 at 5:56 AM, TONGARI J <tongari95@gmail.com> wrote:
>>
>>> Hi Andrew,
>>>
>>> On Friday, April 15, 2016 at 11:36:59 AM UTC+8, Andrew Tomazos wrote:
>>>>
>>>> Hi Tongari,
>>>>
>>>> I've actually been working on a designated initialization proposal.  My
>>>> current thinking on the matter was to propose an uncontroversial first step
>>>> of motivating and adopting in C++ a strict subset of the existing C feature
>>>> (just the parts that clearly make sense for C++), and then showing how this
>>>> fits into a large family of possible future roadmaps, such as the one you
>>>> outline in your proposal.
>>>>
>>>> My reaction to reading your proposal is that you are being too
>>>> ambitious.  It would be multiple years of work to get standardized such a
>>>> large feature of "uniform designators" across function calls, aggregate
>>>> initialization and other types of initialization - and that is assuming
>>>> consensus can be achieved at all, which given the history of named
>>>> parameter proposals, is a long shot.
>>>>
>>>
>>> Obviously, Richard is much more ambitious than me ;)
>>> What I proposed is really the minimal, simplest model in practice.
>>>
>>>
>>>> That's why I think breaking off and nailing down a smaller first step
>>>> would be more practical.  The C feature has extensive existing practice
>>>> that can be appealed to, so I think a subset-only proposal has a much
>>>> better chance of getting through.  Once that gets in and is nailed down, a
>>>> proposal to extend an existing feature will be much better received than
>>>> trying to do everything at once.
>>>>
>>>
>>> I'm not sure if you're an advocator of the alternative described in section
>>> 5.7 <http://57-alternative-of-designated-arguments>, which I already
>>> showed would be a dead end for C++, or you just want to cutoff the proposal
>>> to an even smaller subset.
>>>
>>
>> An even smaller subset.  Consider it as the intersection of your proposal
>> and the existing C feature.  This would necessarily be forward compatible
>> with your proposal, as the intersection is a subset of your proposal.  The
>> people that support your proposal must also support such a step.
>> Additionally, there may be people that don't support your proposal in
>> entirety, but support such a step.  Therefore that step has a better chance
>> of achieving consensus than your proposal.
>>
>
> Well, it'd be fine if you could push designated initializers into C++17,
> and I can aim for C++20. But if designated initializers could only aim for
> C++20, another 3 years seem to be a long time for designated
> arguments...during the long period, people could have established the
> boring tricks to emulate designated arguments and it's not hard to imagine
> that they're ask for the syntax-sugar alternative I illustrated instead of
> a formal approach.
>
> Maybe I'm just too pessimistic...
>

I think it's already too late to put new work into C++17.

As proposals are approved they are applied to the working draft.  Multiple
proposals that build upon one another can be applied to the working draft
between a single release cycle of the IS.

Having said that, I think C++20 is too ambitious a target for your entire
proposal.  I consider it about twice as large as defaulted comparisons.

Default comparisons were at the stage of your proposal in late 2013 by Oleg
Smolsky (informal paper, prototype impl):


https://groups.google.com/a/isocpp.org/d/topic/std-proposals/La6AbyApdTc/discussion

and it's not clear yet whether they will just squeak into C++17.

I don't think there is much risk of people getting a "syntax-sugar
alternative" instead of a "formal approach".   All alternative approaches
will be discussed and considered ad nauseam for many years before selecting
and standardizing one or none.

As long as whatever the first step proposal is, is shown to be forward
compatible with all the feasible approaches we might want to select later,
I think it can achieve consensus, and C++20 is a realistic target.

--
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/CAB%2B4KHLffno6Wc%2BRCRMYrdWXkrt9BMa7aPKn84z%2BQ8KSEx99rw%40mail.gmail.com.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Apr 15, 2016 at 8:41 AM, TONGARI J <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:tongari95@gmail.com" target=3D"_blank">tongari95@gmail.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_=
extra"><div class=3D"gmail_quote"><span>2016-04-15 12:46 GMT+08:00 Andrew T=
omazos <span dir=3D"ltr">&lt;<a href=3D"mailto:andrewtomazos@gmail.com" tar=
get=3D"_blank">andrewtomazos@gmail.com</a>&gt;</span>:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><spa=
n>On Fri, Apr 15, 2016 at 5:56 AM, TONGARI J <span dir=3D"ltr">&lt;<a href=
=3D"mailto:tongari95@gmail.com" target=3D"_blank">tongari95@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex"><div dir=3D"ltr">Hi=C2=A0Andrew,<span>=
<br><br>On Friday, April 15, 2016 at 11:36:59 AM UTC+8, Andrew Tomazos wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex"><div dir=3D"ltr">Hi Tongari,<div><br></div><div>I&#39;ve=
 actually been working on a designated initialization proposal.=C2=A0 My cu=
rrent thinking on the matter was to propose an uncontroversial first step o=
f motivating and adopting in C++ a strict subset of the existing C feature =
(just the parts that clearly make sense for C++), and then showing how this=
 fits into a large family of possible future roadmaps, such as the one you =
outline in your proposal.</div><div><br></div><div>My reaction to reading y=
our proposal is that you are being too ambitious.=C2=A0 It would be multipl=
e years of work to get standardized such a large feature of &quot;uniform d=
esignators&quot; across function calls, aggregate initialization and other =
types of initialization - and that is assuming consensus can be achieved at=
 all, which given the history of named parameter proposals, is a long shot.=
<br></div></div></blockquote><div><br></div></span><div>Obviously, Richard =
is much more ambitious than me ;)</div><div>What I proposed is really the m=
inimal, simplest model in practice.</div><span><div>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:=
1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left=
:1ex"><div dir=3D"ltr"><div></div><div>That&#39;s why I think breaking off =
and nailing down a smaller first step would be more practical.=C2=A0 The C =
feature has extensive existing practice that can be appealed to, so I think=
 a subset-only proposal has a much better chance of getting through.=C2=A0 =
Once that gets in and is nailed down, a proposal to extend an existing feat=
ure will be much better received than trying to do everything at once.</div=
></div></blockquote><div><br></div></span><div>I&#39;m not sure if you&#39;=
re an advocator of the alternative described in <a href=3D"http://57-altern=
ative-of-designated-arguments" target=3D"_blank">section 5.7</a>, which I a=
lready showed would be a dead end for C++, or you just want to cutoff the p=
roposal to an even smaller subset.</div></div></blockquote><div><br></div><=
/span><div>An even smaller subset.=C2=A0 Consider it as the intersection of=
 your proposal and the existing C feature.=C2=A0 This would necessarily be =
forward compatible with your proposal, as the intersection is a subset of y=
our proposal.=C2=A0 The people that support your proposal must also support=
 such a step.=C2=A0 Additionally, there may be people that don&#39;t suppor=
t your proposal in entirety, but support such a step.=C2=A0 Therefore that =
step has a better chance of achieving consensus than your proposal.</div></=
div></div></div></blockquote><div><br></div></span><div>Well, it&#39;d be f=
ine if you could push designated initializers into C++17, and I can aim for=
 C++20. But if designated initializers could only aim for C++20, another 3 =
years seem to be a long time for designated arguments...during the long per=
iod, people could have established the boring tricks to emulate designated =
arguments and it&#39;s not hard to imagine that they&#39;re ask for the syn=
tax-sugar alternative I illustrated instead of a formal approach.</div><div=
><br></div><div>Maybe I&#39;m just too=C2=A0pessimistic...</div></div></div=
></div></blockquote><div><br></div><div>I think it&#39;s already too late t=
o put new work into C++17.</div><div><br></div><div>As proposals are approv=
ed they are applied to the working draft.=C2=A0 Multiple proposals that bui=
ld upon one another can be applied to the working draft between a single re=
lease cycle of the IS.</div><div><br></div><div>Having said that, I think C=
++20 is too ambitious a target for your entire proposal.=C2=A0 I consider i=
t about twice as large as defaulted comparisons.</div><div><br></div><div>D=
efault comparisons were at the stage of your proposal in late 2013 by Oleg =
Smolsky (informal paper, prototype impl):</div><div><br></div><div>=C2=A0 =
=C2=A0<a href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-proposa=
ls/La6AbyApdTc/discussion">https://groups.google.com/a/isocpp.org/d/topic/s=
td-proposals/La6AbyApdTc/discussion</a><br></div><div><br></div><div>and it=
&#39;s not clear yet whether they will just squeak into C++17.</div><div><b=
r></div><div>I don&#39;t think there is much risk of people getting a &quot=
;syntax-sugar alternative&quot; instead of a &quot;formal approach&quot;. =
=C2=A0 All alternative approaches will be discussed and considered ad nause=
am for many years before selecting and standardizing one or none.</div><div=
><br></div><div>As long as whatever the first step proposal is, is shown to=
 be forward compatible with all the feasible approaches we might want to se=
lect later, I think it can achieve consensus, and C++20 is a realistic targ=
et.</div><div><br></div></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/CAB%2B4KHLffno6Wc%2BRCRMYrdWXkrt9BMa7=
aPKn84z%2BQ8KSEx99rw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHLf=
fno6Wc%2BRCRMYrdWXkrt9BMa7aPKn84z%2BQ8KSEx99rw%40mail.gmail.com</a>.<br />

--001a113e32b213ee2205308900fc--

.

On 2016-04-15 12:50, Thiago Macieira wrote:
> I recommend you stop talking about attributes, as this lowers the chance of
> the feature being accepted. Not only would the feature itself be fighting to
> prove its worth (it's been rejected more than once), using attributes means
> fighting against established rules over attributes.
>
> Remember that this feature is asking for differences in overload resolution
> and has consequences for the ABI. That's way outside what attributes are meant
> to do.

It *doesn't* have consequences for the ABI; Tongari has been rather
explicit on this point. I suspect it isn't "asking for differences in
overload resolution" either; not, at least, in the sense I suspect you
are thinking.

Note:

  int foo(int .a);
  int foo(int); // same as previous
  int foo(int .b); // error

I'm starting to think that the problem is that folks are interpreting
conversations based on the features and drawbacks of their own pet
implementation, rather than the variation actually being discussed in a
particular conversation thread.

--
Matthew

--
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/ner8dt%243n4%241%40ger.gmane.org.

.

--94eb2c0ba5da82fb680530896c6f
Content-Type: text/plain; charset=UTF-8

2016-04-16 1:04 GMT+08:00 Andrew Tomazos <andrewtomazos@gmail.com>:
>
> I think it's already too late to put new work into C++17.
>
> As proposals are approved they are applied to the working draft.  Multiple
> proposals that build upon one another can be applied to the working draft
> between a single release cycle of the IS.
>
> Having said that, I think C++20 is too ambitious a target for your entire
> proposal.  I consider it about twice as large as defaulted comparisons.
>
> Default comparisons were at the stage of your proposal in late 2013 by
> Oleg Smolsky (informal paper, prototype impl):
>
>
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/La6AbyApdTc/discussion
>
> and it's not clear yet whether they will just squeak into C++17.
>
> I don't think there is much risk of people getting a "syntax-sugar
> alternative" instead of a "formal approach".   All alternative approaches
> will be discussed and considered ad nauseam for many years before selecting
> and standardizing one or none.
>
> As long as whatever the first step proposal is, is shown to be forward
> compatible with all the feasible approaches we might want to select later,
> I think it can achieve consensus, and C++20 is a realistic target.
>

Fine, then please c.c. me if you have a draft to review or anything happens
to your proposal so I can continue the work.
You could also mention some future direction as the idea I illustrated in
my proposal, if that helps.

Good luck!

--
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/CANCwVheXPBkzd0MuD9Q9-OXSA4%3D5Ws_nuTXPjhQcPzXOjdXcRg%40mail.gmail.com.

--94eb2c0ba5da82fb680530896c6f
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">2016=
-04-16 1:04 GMT+08:00 Andrew Tomazos <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@gmail.com</a>&gt=
;</span>:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmai=
l_extra"><div class=3D"gmail_quote"><div>I think it&#39;s already too late =
to put new work into C++17.</div><div><br></div><div>As proposals are appro=
ved they are applied to the working draft.=C2=A0 Multiple proposals that bu=
ild upon one another can be applied to the working draft between a single r=
elease cycle of the IS.</div><div><br></div><div>Having said that, I think =
C++20 is too ambitious a target for your entire proposal.=C2=A0 I consider =
it about twice as large as defaulted comparisons.</div><div><br></div><div>=
Default comparisons were at the stage of your proposal in late 2013 by Oleg=
 Smolsky (informal paper, prototype impl):</div><div><br></div><div>=C2=A0 =
=C2=A0<a href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-proposa=
ls/La6AbyApdTc/discussion" target=3D"_blank">https://groups.google.com/a/is=
ocpp.org/d/topic/std-proposals/La6AbyApdTc/discussion</a><br></div><div><br=
></div><div>and it&#39;s not clear yet whether they will just squeak into C=
++17.</div><div><br></div><div>I don&#39;t think there is much risk of peop=
le getting a &quot;syntax-sugar alternative&quot; instead of a &quot;formal=
 approach&quot;. =C2=A0 All alternative approaches will be discussed and co=
nsidered ad nauseam for many years before selecting and standardizing one o=
r none.</div><div><br></div><div>As long as whatever the first step proposa=
l is, is shown to be forward compatible with all the feasible approaches we=
 might want to select later, I think it can achieve consensus, and C++20 is=
 a realistic target.</div></div></div></div></blockquote><div><br></div><di=
v>Fine, then please c.c. me if you have a draft to review or anything happe=
ns to your proposal so I can continue the work.</div><div>You could also me=
ntion some future direction as the idea I illustrated in my proposal, if th=
at helps.</div><div><br></div><div>Good luck!</div></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/CANCwVheXPBkzd0MuD9Q9-OXSA4%3D5Ws_nuT=
XPjhQcPzXOjdXcRg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANCwVheXPBkzd0=
MuD9Q9-OXSA4%3D5Ws_nuTXPjhQcPzXOjdXcRg%40mail.gmail.com</a>.<br />

--94eb2c0ba5da82fb680530896c6f--

.

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

2016-04-16 1:29 GMT+08:00 Matthew Woehlke <mwoehlke.floss@gmail.com>:

> On 2016-04-15 12:50, Thiago Macieira wrote:
> > I recommend you stop talking about attributes, as this lowers the chance
> of
> > the feature being accepted. Not only would the feature itself be
> fighting to
> > prove its worth (it's been rejected more than once), using attributes
> means
> > fighting against established rules over attributes.
> >
> > Remember that this feature is asking for differences in overload
> resolution
> > and has consequences for the ABI. That's way outside what attributes are
> meant
> > to do.
>
> It *doesn't* have consequences for the ABI; Tongari has been rather
> explicit on this point. I suspect it isn't "asking for differences in
> overload resolution" either; not, at least, in the sense I suspect you
> are thinking.


To be clear, it doesn't affect function overloading but does add a new step
in overload resolution process (i.e. argument-mapping).

--
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/CANCwVhch4z_AWn_szkp%2B-ztWXkuBxtQdPu%2B79bryG3CGjcaPMw%40mail.gmail.com.

--001a114e60fee1dc61053089781d
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">2016=
-04-16 1:29 GMT+08:00 Matthew Woehlke <span dir=3D"ltr">&lt;<a href=3D"mail=
to:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail.com</a>=
&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex"><span class=3D"">On 2016-04-15 12:50, Thia=
go Macieira wrote:<br>
&gt; I recommend you stop talking about attributes, as this lowers the chan=
ce of<br>
&gt; the feature being accepted. Not only would the feature itself be fight=
ing to<br>
&gt; prove its worth (it&#39;s been rejected more than once), using attribu=
tes means<br>
&gt; fighting against established rules over attributes.<br>
&gt;<br>
&gt; Remember that this feature is asking for differences in overload resol=
ution<br>
&gt; and has consequences for the ABI. That&#39;s way outside what attribut=
es are meant<br>
&gt; to do.<br>
<br>
</span>It *doesn&#39;t* have consequences for the ABI; Tongari has been rat=
her<br>
explicit on this point. I suspect it isn&#39;t &quot;asking for differences=
 in<br>
overload resolution&quot; either; not, at least, in the sense I suspect you=
<br>
are thinking.</blockquote><div><br></div><div>To be clear, it doesn&#39;t a=
ffect function overloading but does add a new step in overload resolution p=
rocess (i.e. argument-mapping).</div></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/CANCwVhch4z_AWn_szkp%2B-ztWXkuBxtQdPu=
%2B79bryG3CGjcaPMw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANCwVhch4z_A=
Wn_szkp%2B-ztWXkuBxtQdPu%2B79bryG3CGjcaPMw%40mail.gmail.com</a>.<br />

--001a114e60fee1dc61053089781d--

.

On sexta-feira, 15 de abril de 2016 13:29:32 PDT Matthew Woehlke wrote:
> It *doesn't* have consequences for the ABI; Tongari has been rather
> explicit on this point. I suspect it isn't "asking for differences in
> overload resolution" either; not, at least, in the sense I suspect you
> are thinking.
>
> Note:
>
>   int foo(int .a);
>   int foo(int); // same as previous
>   int foo(int .b); // error
>
> I'm starting to think that the problem is that folks are interpreting
> conversations based on the features and drawbacks of their own pet
> implementation, rather than the variation actually being discussed in a
> particular conversation thread.

Fair enough. I haven't paid enough attention to this thread, but I've seen
several times code like this going around:

 complex<double> make_complex(double .real, double .imag);
 complex<double> make_complex(double .magnitude, double .argument);

Still, attributes are the wrong solution for this.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/2518975.6yXMB68uC6%40tjmaciei-mobl4.

.