Topic: Named parameters
Author: <ziemowit.laski@gmail.com>
Date: Mon, 29 Oct 2018 10:50:19 -0700
Raw View
This is a multipart message in MIME format.
------=_NextPart_000_00C9_01D46F75.2FF41890
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hello C++-ers,
=20
I=E2=80=99d like to propose named parameter functionality for C++.
=20
I see that there have been previous attempts to add named parameter functio=
nality to C++ but led to syntactic ambiguities.
=20
However, I think/hope I=E2=80=99ve come up with something that might work, =
namely PARAMETER LABELS:
=20
int max(left: int, right: int); // declaration
int max(left: int left, right: int right); // OK
int max(p1: int, p2: int); // ERROR -labels must match
int max(int p1, p2: int p2); // ERROR -missing left label
=20
int max(left: int l, right: int r) {
return l > r? l: r;
}
=20
int foo(int p1, intp2) {
=E2=80=A6 max(left: p1, right: p2); // OK
=E2=80=A6 max(right: p1, left: p2); // OK
=E2=80=A6 max(p1, right: p2); // ERROR -missing label
=E2=80=A6 max(p1, p2); // ERROR -no labels=20
}
=20
I couldn=E2=80=99t find anything like this on the internets.
=20
Another question to consider is whether we should allow right-most labels t=
o be missing:
=20
int min(args: int arg1, int arg2, int arg3);
=20
=E2=80=A6min(args: 1, 2, 3); // OK
=E2=80=A6min(1, args: 2, 3); // ERROR =E2=80=93 non-labeled arguments m=
ust not preced labeled ones
=20
In other words, a label may be omitted for those parameters for which a def=
ault value may also be specified. I=E2=80=99m not sure about the soundness=
of this, but thought I=E2=80=99d put it out there.
=20
--Zem
=20
=20
=20
=20
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/00c801d46faf%24dc525450%2494f6fcf0%24%40gmail.co=
m.
------=_NextPart_000_00C9_01D46F75.2FF41890
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Dutf-8"><meta name=3DGenerator content=3D"Microsoft=
Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;}
..MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>Hello C++-ers,<o=
:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal=
>I=E2=80=99d like to propose named parameter functionality for C++.<o:p></o=
:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>I see=
that there have been previous attempts to add named parameter functionalit=
y to C++ but led to syntactic ambiguities.<o:p></o:p></p><p class=3DMsoNorm=
al><o:p> </o:p></p><p class=3DMsoNormal>However, I think/hope I=E2=80=
=99ve come up with something that might work, namely PARAMETER LABELS:<o:p>=
</o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>in=
t max(left: int, right: int);=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 // declaration<o:p></o:p></p><p class=3DMsoNormal>int max(left: int lef=
t, right: int right);=C2=A0=C2=A0=C2=A0=C2=A0 // OK<o:p></o:p></p><p class=
=3DMsoNormal>int max(p1: int, p2: int);=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 // ERROR -labels must matc=
h<o:p></o:p></p><p class=3DMsoNormal>int max(int p1, p2: int p2);=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // ERROR -missing left =
label<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMs=
oNormal>int max(left: int l, right: int r) {<o:p></o:p></p><p class=3DMsoNo=
rmal>=C2=A0 return l > r? l: r;<o:p></o:p></p><p class=3DMsoNormal>}<o:p=
></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>i=
nt foo(int p1, intp2) {<o:p></o:p></p><p class=3DMsoNormal>=C2=A0=C2=A0 =E2=
=80=A6 max(left: p1, right: p2);=C2=A0=C2=A0=C2=A0 // OK<o:p></o:p></p><p c=
lass=3DMsoNormal>=C2=A0=C2=A0 =E2=80=A6 max(right: p1, left: p2);=C2=A0=C2=
=A0=C2=A0=C2=A0 // OK<o:p></o:p></p><p class=3DMsoNormal>=C2=A0=C2=A0 =E2=
=80=A6 max(p1, right: p2);=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// ERROR -missing label<o:p></o:p></p><p clas=
s=3DMsoNormal>=C2=A0=C2=A0 =E2=80=A6 max(p1, p2);=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=C2=A0=C2=A0=C2=A0=C2=A0 // ERROR -no labels <o:p></o:=
p></p><p class=3DMsoNormal>}<o:p></o:p></p><p class=3DMsoNormal><o:p> =
</o:p></p><p class=3DMsoNormal>I couldn=E2=80=99t find anything like this o=
n the internets.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p=
class=3DMsoNormal>Another question to consider is whether we should allow =
right-most labels to be missing:<o:p></o:p></p><p class=3DMsoNormal><o:p>&n=
bsp;</o:p></p><p class=3DMsoNormal>int min(args: int arg1, int arg2, int ar=
g3);<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMso=
Normal>=C2=A0=C2=A0 =E2=80=A6min(args: 1, 2, 3);=C2=A0 // OK<o:p></o:p></p>=
<p class=3DMsoNormal>=C2=A0=C2=A0 =E2=80=A6min(1, args: 2, 3);=C2=A0 // ERR=
OR =E2=80=93 non-labeled arguments must not preced labeled ones<o:p></o:p><=
/p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>In other =
words, a label may be omitted for those parameters for which a default valu=
e may also be specified.=C2=A0 I=E2=80=99m not sure about the soundness of =
this, but thought I=E2=80=99d put it out there.<o:p></o:p></p><p class=3DMs=
oNormal><o:p> </o:p></p><p class=3DMsoNormal>--Zem<o:p></o:p></p><p cl=
ass=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal><o:p> </o:p>=
</p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal><o:p>&nb=
sp;</o:p></p></div></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/00c801d46faf%24dc525450%2494f6fcf0%24=
%40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/00c801d46faf%24dc525450%2494f6fcf0%2=
4%40gmail.com</a>.<br />
------=_NextPart_000_00C9_01D46F75.2FF41890--
.
Author: mihailnajdenov@gmail.com
Date: Mon, 29 Oct 2018 11:14:04 -0700 (PDT)
Raw View
------=_Part_1859_1628841420.1540836844625
Content-Type: multipart/alternative;
boundary="----=_Part_1860_1110682608.1540836844625"
------=_Part_1860_1110682608.1540836844625
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/wz0a7NrwnGQ/iBpN=
8pYMFQAJ
On Monday, October 29, 2018 at 7:50:26 PM UTC+2, ziemowi...@gmail.com wrote=
:
>
> Hello C++-ers,
>
> =20
>
> I=E2=80=99d like to propose named parameter functionality for C++.
>
> =20
>
> I see that there have been previous attempts to add named parameter=20
> functionality to C++ but led to syntactic ambiguities.
>
> =20
>
> However, I think/hope I=E2=80=99ve come up with something that might work=
, namely=20
> PARAMETER LABELS:
>
> =20
>
> int max(left: int, right: int); // declaration
>
> int max(left: int left, right: int right); // OK
>
> int max(p1: int, p2: int); // ERROR -labels must match
>
> int max(int p1, p2: int p2); // ERROR -missing left label
>
> =20
>
> int max(left: int l, right: int r) {
>
> return l > r? l: r;
>
> }
>
> =20
>
> int foo(int p1, intp2) {
>
> =E2=80=A6 max(left: p1, right: p2); // OK
>
> =E2=80=A6 max(right: p1, left: p2); // OK
>
> =E2=80=A6 max(p1, right: p2); // ERROR -missing label
>
> =E2=80=A6 max(p1, p2); // ERROR -no labels=20
>
> }
>
> =20
>
> I couldn=E2=80=99t find anything like this on the internets.
>
> =20
>
> Another question to consider is whether we should allow right-most labels=
=20
> to be missing:
>
> =20
>
> int min(args: int arg1, int arg2, int arg3);
>
> =20
>
> =E2=80=A6min(args: 1, 2, 3); // OK
>
> =E2=80=A6min(1, args: 2, 3); // ERROR =E2=80=93 non-labeled arguments=
must not preced=20
> labeled ones
>
> =20
>
> In other words, a label may be omitted for those parameters for which a=
=20
> default value may also be specified. I=E2=80=99m not sure about the soun=
dness of=20
> this, but thought I=E2=80=99d put it out there.
>
> =20
>
> --Zem
>
> =20
>
> =20
>
> =20
>
> =20
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9e426920-6db3-4d73-923b-aaf02c708a94%40isocpp.or=
g.
------=_Part_1860_1110682608.1540836844625
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">https://groups.google.com/a/isocpp.org/d/msg/std-proposals=
/wz0a7NrwnGQ/iBpN8pYMFQAJ<div><br></div><div><br><br>On Monday, October 29,=
2018 at 7:50:26 PM UTC+2, ziemowi...@gmail.com wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">=
<div><p class=3D"MsoNormal">Hello C++-ers,</p><p class=3D"MsoNormal">=C2=A0=
</p><p class=3D"MsoNormal">I=E2=80=99d like to propose named parameter func=
tionality for C++.</p><p class=3D"MsoNormal">=C2=A0</p><p class=3D"MsoNorma=
l">I see that there have been previous attempts to add named parameter func=
tionality to C++ but led to syntactic ambiguities.</p><p class=3D"MsoNormal=
">=C2=A0</p><p class=3D"MsoNormal">However, I think/hope I=E2=80=99ve come =
up with something that might work, namely PARAMETER LABELS:</p><p class=3D"=
MsoNormal">=C2=A0</p><p class=3D"MsoNormal">int max(left: int, right: int);=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // declaration</p><p class=
=3D"MsoNormal">int max(left: int left, right: int right);=C2=A0=C2=A0=C2=A0=
=C2=A0 // OK</p><p class=3D"MsoNormal">int max(p1: int, p2: int);=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=
// ERROR -labels must match</p><p class=3D"MsoNormal">int max(int p1, p2: =
int p2);=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // ERR=
OR -missing left label</p><p class=3D"MsoNormal">=C2=A0</p><p class=3D"MsoN=
ormal">int max(left: int l, right: int r) {</p><p class=3D"MsoNormal">=C2=
=A0 return l > r? l: r;</p><p class=3D"MsoNormal">}</p><p class=3D"MsoNo=
rmal">=C2=A0</p><p class=3D"MsoNormal">int foo(int p1, intp2) {</p><p class=
=3D"MsoNormal">=C2=A0=C2=A0 =E2=80=A6 max(left: p1, right: p2);=C2=A0=C2=A0=
=C2=A0 // OK</p><p class=3D"MsoNormal">=C2=A0=C2=A0 =E2=80=A6 max(right: p1=
, left: p2);=C2=A0=C2=A0=C2=A0=C2=A0 // OK</p><p class=3D"MsoNormal">=C2=A0=
=C2=A0 =E2=80=A6 max(p1, right: p2);=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// ERROR -missing label</p><p cla=
ss=3D"MsoNormal">=C2=A0=C2=A0 =E2=80=A6 max(p1, p2);=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=C2=A0=C2=A0=C2=A0=C2=A0 // ERROR -no labels </p><p=
class=3D"MsoNormal">}</p><p class=3D"MsoNormal">=C2=A0</p><p class=3D"MsoN=
ormal">I couldn=E2=80=99t find anything like this on the internets.</p><p c=
lass=3D"MsoNormal">=C2=A0</p><p class=3D"MsoNormal">Another question to con=
sider is whether we should allow right-most labels to be missing:</p><p cla=
ss=3D"MsoNormal">=C2=A0</p><p class=3D"MsoNormal">int min(args: int arg1, i=
nt arg2, int arg3);</p><p class=3D"MsoNormal">=C2=A0</p><p class=3D"MsoNorm=
al">=C2=A0=C2=A0 =E2=80=A6min(args: 1, 2, 3);=C2=A0 // OK</p><p class=3D"Ms=
oNormal">=C2=A0=C2=A0 =E2=80=A6min(1, args: 2, 3);=C2=A0 // ERROR =E2=80=93=
non-labeled arguments must not preced labeled ones</p><p class=3D"MsoNorma=
l">=C2=A0</p><p class=3D"MsoNormal">In other words, a label may be omitted =
for those parameters for which a default value may also be specified.=C2=A0=
I=E2=80=99m not sure about the soundness of this, but thought I=E2=80=99d =
put it out there.</p><p class=3D"MsoNormal">=C2=A0</p><p class=3D"MsoNormal=
">--Zem</p><p class=3D"MsoNormal">=C2=A0</p><p class=3D"MsoNormal">=C2=A0</=
p><p class=3D"MsoNormal">=C2=A0</p><p class=3D"MsoNormal">=C2=A0</p></div><=
/div></blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9e426920-6db3-4d73-923b-aaf02c708a94%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9e426920-6db3-4d73-923b-aaf02c708a94=
%40isocpp.org</a>.<br />
------=_Part_1860_1110682608.1540836844625--
------=_Part_1859_1628841420.1540836844625--
.
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Mon, 29 Oct 2018 11:20:32 -0700 (PDT)
Raw View
------=_Part_557_1450547232.1540837232124
Content-Type: multipart/alternative;
boundary="----=_Part_558_1525344856.1540837232124"
------=_Part_558_1525344856.1540837232124
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Monday, October 29, 2018 at 12:50:26 PM UTC-5, ziemowi...@gmail.com=20
wrote:
>
> Hello C++-ers,
>
> =20
>
> I=E2=80=99d like to propose named parameter functionality for C++.
>
> =20
>
> I see that there have been previous attempts to add named parameter=20
> functionality to C++ but led to syntactic ambiguities.
>
> =20
>
> However, I think/hope I=E2=80=99ve come up with something that might work=
, namely=20
> PARAMETER LABELS:
>
> =20
>
> int max(left: int, right: int); // declaration
>
> int max(left: int left, right: int right); // OK
>
> int max(p1: int, p2: int); // ERROR -labels must match
>
> int max(int p1, p2: int p2); // ERROR -missing left label
>
> =20
>
> int max(left: int l, right: int r) {
>
> return l > r? l: r;
>
> }
>
> =20
>
> int foo(int p1, intp2) {
>
> =E2=80=A6 max(left: p1, right: p2); // OK
>
> =E2=80=A6 max(right: p1, left: p2); // OK
>
> =E2=80=A6 max(p1, right: p2); // ERROR -missing label
>
> =E2=80=A6 max(p1, p2); // ERROR -no labels=20
>
> }
>
> =20
>
> I couldn=E2=80=99t find anything like this on the internets.
>
> =20
>
> Another question to consider is whether we should allow right-most labels=
=20
> to be missing:
>
> =20
>
> int min(args: int arg1, int arg2, int arg3);
>
> =20
>
> =E2=80=A6min(args: 1, 2, 3); // OK
>
> =E2=80=A6min(1, args: 2, 3); // ERROR =E2=80=93 non-labeled arguments=
must not preced=20
> labeled ones
>
> =20
>
> In other words, a label may be omitted for those parameters for which a=
=20
> default value may also be specified. I=E2=80=99m not sure about the soun=
dness of=20
> this, but thought I=E2=80=99d put it out there.
>
> =20
>
> --Zem
>
> =20
>
> =20
>
> =20
>
See: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0671r2.html
--=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/4e2e9987-99df-4d35-972c-51e9e0402c6d%40isocpp.or=
g.
------=_Part_558_1525344856.1540837232124
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, October 29, 2018 at 12:50:26 PM UTC-5, =
ziemowi...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNormal"=
>Hello C++-ers,</p><p class=3D"MsoNormal">=C2=A0</p><p class=3D"MsoNormal">=
I=E2=80=99d like to propose named parameter functionality for C++.</p><p cl=
ass=3D"MsoNormal">=C2=A0</p><p class=3D"MsoNormal">I see that there have be=
en previous attempts to add named parameter functionality to C++ but led to=
syntactic ambiguities.</p><p class=3D"MsoNormal">=C2=A0</p><p class=3D"Mso=
Normal">However, I think/hope I=E2=80=99ve come up with something that migh=
t work, namely PARAMETER LABELS:</p><p class=3D"MsoNormal">=C2=A0</p><p cla=
ss=3D"MsoNormal">int max(left: int, right: int);=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 // declaration</p><p class=3D"MsoNormal">int max(left=
: int left, right: int right);=C2=A0=C2=A0=C2=A0=C2=A0 // OK</p><p class=3D=
"MsoNormal">int max(p1: int, p2: int);=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 // ERROR -labels must matc=
h</p><p class=3D"MsoNormal">int max(int p1, p2: int p2);=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // ERROR -missing left label</p>=
<p class=3D"MsoNormal">=C2=A0</p><p class=3D"MsoNormal">int max(left: int l=
, right: int r) {</p><p class=3D"MsoNormal">=C2=A0 return l > r? l: r;</=
p><p class=3D"MsoNormal">}</p><p class=3D"MsoNormal">=C2=A0</p><p class=3D"=
MsoNormal">int foo(int p1, intp2) {</p><p class=3D"MsoNormal">=C2=A0=C2=A0 =
=E2=80=A6 max(left: p1, right: p2);=C2=A0=C2=A0=C2=A0 // OK</p><p class=3D"=
MsoNormal">=C2=A0=C2=A0 =E2=80=A6 max(right: p1, left: p2);=C2=A0=C2=A0=C2=
=A0=C2=A0 // OK</p><p class=3D"MsoNormal">=C2=A0=C2=A0 =E2=80=A6 max(p1, ri=
ght: p2);=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// ERROR -missing label</p><p class=3D"MsoNormal">=C2=A0=C2=
=A0 =E2=80=A6 max(p1, p2);=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=C2=
=A0=C2=A0=C2=A0=C2=A0 // ERROR -no labels </p><p class=3D"MsoNormal">}</p><=
p class=3D"MsoNormal">=C2=A0</p><p class=3D"MsoNormal">I couldn=E2=80=99t f=
ind anything like this on the internets.</p><p class=3D"MsoNormal">=C2=A0</=
p><p class=3D"MsoNormal">Another question to consider is whether we should =
allow right-most labels to be missing:</p><p class=3D"MsoNormal">=C2=A0</p>=
<p class=3D"MsoNormal">int min(args: int arg1, int arg2, int arg3);</p><p c=
lass=3D"MsoNormal">=C2=A0</p><p class=3D"MsoNormal">=C2=A0=C2=A0 =E2=80=A6m=
in(args: 1, 2, 3);=C2=A0 // OK</p><p class=3D"MsoNormal">=C2=A0=C2=A0 =E2=
=80=A6min(1, args: 2, 3);=C2=A0 // ERROR =E2=80=93 non-labeled arguments mu=
st not preced labeled ones</p><p class=3D"MsoNormal">=C2=A0</p><p class=3D"=
MsoNormal">In other words, a label may be omitted for those parameters for =
which a default value may also be specified.=C2=A0 I=E2=80=99m not sure abo=
ut the soundness of this, but thought I=E2=80=99d put it out there.</p><p c=
lass=3D"MsoNormal">=C2=A0</p><p class=3D"MsoNormal">--Zem</p><p class=3D"Ms=
oNormal">=C2=A0</p><p class=3D"MsoNormal">=C2=A0</p><p class=3D"MsoNormal">=
=C2=A0</p></div></div></blockquote><div><br></div><div><br></div><div>See:=
=C2=A0http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0671r2.html<=
/div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4e2e9987-99df-4d35-972c-51e9e0402c6d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4e2e9987-99df-4d35-972c-51e9e0402c6d=
%40isocpp.org</a>.<br />
------=_Part_558_1525344856.1540837232124--
------=_Part_557_1450547232.1540837232124--
.
Author: Henry Miller <hank@millerfarm.com>
Date: Mon, 29 Oct 2018 14:02:30 -0500
Raw View
This is a multi-part message in MIME format.
--_----------=_154083975025804170
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
There have been many, all died because of opposition to the idea. You
have a syntax, but you need to convince people that there isn't a
better way.
Strong types are generally preferred. Why not=20
max(left_t left, right_t right)=20
This does everything you wanted, plus as a user I can use my own names.
void fub() {
left_t foo(99);
right_t bar(getFuzzSize);
max(bar, foo) ;=20
}=20
The above passes code review, the variable names are meaningful in
context. Convert to named papamarers and it compiles. However as written
it won't compile because there is a real error.
For any proposal to be accepted you need to convince a lot of people
that the above objection is balanced by the greater good. Once you have
that we can bikeshed on syntax, there are many ideas.
--
Henry Miller
hank@millerfarm.com
On Mon, Oct 29, 2018, at 12:50 PM, ziemowit.laski@gmail.com wrote:
> Hello C++-ers,
> =20
> I=E2=80=99d like to propose named parameter functionality for C++.
> =20
> I see that there have been previous attempts to add named parameter
> functionality to C++ but led to syntactic ambiguities.> =20
> However, I think/hope I=E2=80=99ve come up with something that might work=
,
> namely PARAMETER LABELS:> =20
> int max(left: int, right: int); // declaration
> int max(left: int left, right: int right); // OK
> int max(p1: int, p2: int); // ERROR -labels must match> int=
max(int p1, p2: int p2); // ERROR -missing left label> =20
> int max(left: int l, right: int r) {
> return l > r? l: r;
> }
> =20
> int foo(int p1, intp2) {
> =E2=80=A6 max(left: p1, right: p2); // OK
> =E2=80=A6 max(right: p1, left: p2); // OK
> =E2=80=A6 max(p1, right: p2); // ERROR -missing label
> =E2=80=A6 max(p1, p2); // ERROR -no labels
> }
> =20
> I couldn=E2=80=99t find anything like this on the internets.
> =20
> Another question to consider is whether we should allow right-most
> labels to be missing:> =20
> int min(args: int arg1, int arg2, int arg3);
> =20
> =E2=80=A6min(args: 1, 2, 3); // OK
> =E2=80=A6min(1, args: 2, 3); // ERROR =E2=80=93 non-labeled arguments=
must not
> preced labeled ones> =20
> In other words, a label may be omitted for those parameters for which
> a default value may also be specified. I=E2=80=99m not sure about the
> soundness of this, but thought I=E2=80=99d put it out there.> =20
> --Zem
> =20
> =20
> =20
> =20
>=20
> --
> You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.> To unsubscribe fro=
m 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/00c801d46fa=
f%24dc525450%2494f6fcf0%24%40gmail.com[1].
Links:
1. https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/00c801d46=
faf%24dc525450%2494f6fcf0%24%40gmail.com?utm_medium=3Demail&utm_source=3Dfo=
oter
--=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/1540839750.2580417.1558674040.678FE689%40webmail=
..messagingengine.com.
--_----------=_154083975025804170
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="UTF-8"
<!DOCTYPE html>
<html>
<head>
<title></title>
<style type=3D"text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style>
</head>
<body><div style=3D"font-family:Arial;">There have been many, all died beca=
use of opposition to the idea. You have a syntax, but you need to convince =
people that there isn't a better way. </div>
<div style=3D"font-family:Arial;"><br></div>
<div style=3D"font-family:Arial;">Strong types are generally preferred. Why=
not <br></div>
<div style=3D"font-family:Arial;"><br></div>
<div style=3D"font-family:Arial;">max(left_t left, right_t right) <br>=
</div>
<div style=3D"font-family:Arial;"><br></div>
<div style=3D"font-family:Arial;">This does everything you wanted, plus as =
a user I can use my own names. <br></div>
<div style=3D"font-family:Arial;"><br></div>
<div style=3D"font-family:Arial;">void fub() {<br></div>
<div style=3D"font-family:Arial;">left_t foo(99);<br></div>
<div style=3D"font-family:Arial;">right_t bar(getFuzzSize);<br></div>
<div style=3D"font-family:Arial;">max(bar, foo) ; <br></div>
<div style=3D"font-family:Arial;">} <br></div>
<div style=3D"font-family:Arial;"><br></div>
<div style=3D"font-family:Arial;">The above passes code review, the variabl=
e names are meaningful in context. Convert to named papamarers and it compi=
les. However as written it won't compile because there is a real error.&nbs=
p;<br></div>
<div style=3D"font-family:Arial;"><br></div>
<div style=3D"font-family:Arial;">For any proposal to be accepted you need =
to convince a lot of people that the above objection is balanced by the gre=
ater good. Once you have that we can bikeshed on syntax, there are ma=
ny ideas. </div>
<div style=3D"font-family:Arial;"><br></div>
<div id=3D"sig11221025"><div class=3D"signature">--<br></div>
<div class=3D"signature"> Henry Miller<br></div>
<div class=3D"signature"> hank@millerfarm.com<br></div>
<div class=3D"signature"><br></div>
</div>
<div><br></div>
<div><br></div>
<div>On Mon, Oct 29, 2018, at 12:50 PM, <a style=3D"text-decoration: underl=
ine; color: blue;" href=3D"mailto:ziemowit.laski@gmail.com" class=3D"">ziem=
owit.laski@gmail.com</a> wrote:<br></div>
<blockquote type=3D"cite"><div><p style=3D"margin: 0in 0in 0.0001pt;"><span=
class=3D"font" style=3D"font-family:Calibri, sans-serif"><span class=3D"si=
ze" style=3D"font-size:11pt">Hello C++-ers,</span></span><br></p><p style=
=3D"margin: 0in 0in 0.0001pt;"><span class=3D"font" style=3D"font-family:Ca=
libri, sans-serif"><span class=3D"size" style=3D"font-size:11pt"> </sp=
an></span><br></p><p style=3D"margin: 0in 0in 0.0001pt;"><span class=3D"fon=
t" style=3D"font-family:Calibri, sans-serif"><span class=3D"size" style=3D"=
font-size:11pt">I=E2=80=99d like to propose named parameter functionality f=
or C++.</span></span><br></p><p style=3D"margin: 0in 0in 0.0001pt;"><span c=
lass=3D"font" style=3D"font-family:Calibri, sans-serif"><span class=3D"size=
" style=3D"font-size:11pt"> </span></span><br></p><p style=3D"margin: =
0in 0in 0.0001pt;"><span class=3D"font" style=3D"font-family:Calibri, sans-=
serif"><span class=3D"size" style=3D"font-size:11pt">I see that there have =
been previous attempts to add named parameter functionality to C++ but led =
to syntactic ambiguities.</span></span><br></p><p style=3D"margin: 0in 0in =
0.0001pt;"><span class=3D"font" style=3D"font-family:Calibri, sans-serif"><=
span class=3D"size" style=3D"font-size:11pt"> </span></span><br></p><p=
style=3D"margin: 0in 0in 0.0001pt;"><span class=3D"font" style=3D"font-fam=
ily:Calibri, sans-serif"><span class=3D"size" style=3D"font-size:11pt">Howe=
ver, I think/hope I=E2=80=99ve come up with something that might work, name=
ly PARAMETER LABELS:</span></span><br></p><p style=3D"margin: 0in 0in 0.000=
1pt;"><span class=3D"font" style=3D"font-family:Calibri, sans-serif"><span =
class=3D"size" style=3D"font-size:11pt"> </span></span><br></p><p styl=
e=3D"margin: 0in 0in 0.0001pt;"><span class=3D"font" style=3D"font-family:C=
alibri, sans-serif"><span class=3D"size" style=3D"font-size:11pt">int max(l=
eft: int, right: int); // d=
eclaration</span></span><br></p><p style=3D"margin: 0in 0in 0.0001pt;"><spa=
n class=3D"font" style=3D"font-family:Calibri, sans-serif"><span class=3D"s=
ize" style=3D"font-size:11pt">int max(left: int left, right: int right);&nb=
sp; // OK</span></span><br></p><p style=3D"margin: 0in 0i=
n 0.0001pt;"><span class=3D"font" style=3D"font-family:Calibri, sans-serif"=
><span class=3D"size" style=3D"font-size:11pt">int max(p1: int, p2: int);&n=
bsp;  =
; // ERROR -labels must match</span></span><br></p><p style=3D"margin=
: 0in 0in 0.0001pt;"><span class=3D"font" style=3D"font-family:Calibri, san=
s-serif"><span class=3D"size" style=3D"font-size:11pt">int max(int p1, p2: =
int p2); // ERR=
OR -missing left label</span></span><br></p><p style=3D"margin: 0in 0in 0.0=
001pt;"><span class=3D"font" style=3D"font-family:Calibri, sans-serif"><spa=
n class=3D"size" style=3D"font-size:11pt"> </span></span><br></p><p st=
yle=3D"margin: 0in 0in 0.0001pt;"><span class=3D"font" style=3D"font-family=
:Calibri, sans-serif"><span class=3D"size" style=3D"font-size:11pt">int max=
(left: int l, right: int r) {</span></span><br></p><p style=3D"margin: 0in =
0in 0.0001pt;"><span class=3D"font" style=3D"font-family:Calibri, sans-seri=
f"><span class=3D"size" style=3D"font-size:11pt"> return l > r? l:=
r;</span></span><br></p><p style=3D"margin: 0in 0in 0.0001pt;"><span class=
=3D"font" style=3D"font-family:Calibri, sans-serif"><span class=3D"size" st=
yle=3D"font-size:11pt">}</span></span><br></p><p style=3D"margin: 0in 0in 0=
..0001pt;"><span class=3D"font" style=3D"font-family:Calibri, sans-serif"><s=
pan class=3D"size" style=3D"font-size:11pt"> </span></span><br></p><p =
style=3D"margin: 0in 0in 0.0001pt;"><span class=3D"font" style=3D"font-fami=
ly:Calibri, sans-serif"><span class=3D"size" style=3D"font-size:11pt">int f=
oo(int p1, intp2) {</span></span><br></p><p style=3D"margin: 0in 0in 0.0001=
pt;"><span class=3D"font" style=3D"font-family:Calibri, sans-serif"><span c=
lass=3D"size" style=3D"font-size:11pt"> =E2=80=A6 max(left: p1,=
right: p2); // OK</span></span><br></p><p style=3D"margi=
n: 0in 0in 0.0001pt;"><span class=3D"font" style=3D"font-family:Calibri, sa=
ns-serif"><span class=3D"size" style=3D"font-size:11pt"> =E2=80=
=A6 max(right: p1, left: p2); // OK</span></span><b=
r></p><p style=3D"margin: 0in 0in 0.0001pt;"><span class=3D"font" style=3D"=
font-family:Calibri, sans-serif"><span class=3D"size" style=3D"font-size:11=
pt"> =E2=80=A6 max(p1, right: p2);  =
; // ERROR -missing label</=
span></span><br></p><p style=3D"margin: 0in 0in 0.0001pt;"><span class=3D"f=
ont" style=3D"font-family:Calibri, sans-serif"><span class=3D"size" style=
=3D"font-size:11pt"> =E2=80=A6 max(p1, p2); &n=
bsp;  =
; // ERROR -no labels</span=
></span><br></p><p style=3D"margin: 0in 0in 0.0001pt;"><span class=3D"font"=
style=3D"font-family:Calibri, sans-serif"><span class=3D"size" style=3D"fo=
nt-size:11pt">}</span></span><br></p><p style=3D"margin: 0in 0in 0.0001pt;"=
><span class=3D"font" style=3D"font-family:Calibri, sans-serif"><span class=
=3D"size" style=3D"font-size:11pt"> </span></span><br></p><p style=3D"=
margin: 0in 0in 0.0001pt;"><span class=3D"font" style=3D"font-family:Calibr=
i, sans-serif"><span class=3D"size" style=3D"font-size:11pt">I couldn=E2=80=
=99t find anything like this on the internets.</span></span><br></p><p styl=
e=3D"margin: 0in 0in 0.0001pt;"><span class=3D"font" style=3D"font-family:C=
alibri, sans-serif"><span class=3D"size" style=3D"font-size:11pt"> </s=
pan></span><br></p><p style=3D"margin: 0in 0in 0.0001pt;"><span class=3D"fo=
nt" style=3D"font-family:Calibri, sans-serif"><span class=3D"size" style=3D=
"font-size:11pt">Another question to consider is whether we should allow ri=
ght-most labels to be missing:</span></span><br></p><p style=3D"margin: 0in=
0in 0.0001pt;"><span class=3D"font" style=3D"font-family:Calibri, sans-ser=
if"><span class=3D"size" style=3D"font-size:11pt"> </span></span><br><=
/p><p style=3D"margin: 0in 0in 0.0001pt;"><span class=3D"font" style=3D"fon=
t-family:Calibri, sans-serif"><span class=3D"size" style=3D"font-size:11pt"=
>int min(args: int arg1, int arg2, int arg3);</span></span><br></p><p style=
=3D"margin: 0in 0in 0.0001pt;"><span class=3D"font" style=3D"font-family:Ca=
libri, sans-serif"><span class=3D"size" style=3D"font-size:11pt"> </sp=
an></span><br></p><p style=3D"margin: 0in 0in 0.0001pt;"><span class=3D"fon=
t" style=3D"font-family:Calibri, sans-serif"><span class=3D"size" style=3D"=
font-size:11pt"> =E2=80=A6min(args: 1, 2, 3); // OK</span=
></span><br></p><p style=3D"margin: 0in 0in 0.0001pt;"><span class=3D"font"=
style=3D"font-family:Calibri, sans-serif"><span class=3D"size" style=3D"fo=
nt-size:11pt"> =E2=80=A6min(1, args: 2, 3); // ERROR =E2=
=80=93 non-labeled arguments must not preced labeled ones</span></span><br>=
</p><p style=3D"margin: 0in 0in 0.0001pt;"><span class=3D"font" style=3D"fo=
nt-family:Calibri, sans-serif"><span class=3D"size" style=3D"font-size:11pt=
"> </span></span><br></p><p style=3D"margin: 0in 0in 0.0001pt;"><span =
class=3D"font" style=3D"font-family:Calibri, sans-serif"><span class=3D"siz=
e" style=3D"font-size:11pt">In other words, a label may be omitted for thos=
e parameters for which a default value may also be specified. I=E2=80=
=99m not sure about the soundness of this, but thought I=E2=80=99d put it o=
ut there.</span></span><br></p><p style=3D"margin: 0in 0in 0.0001pt;"><span=
class=3D"font" style=3D"font-family:Calibri, sans-serif"><span class=3D"si=
ze" style=3D"font-size:11pt"> </span></span><br></p><p style=3D"margin=
: 0in 0in 0.0001pt;"><span class=3D"font" style=3D"font-family:Calibri, san=
s-serif"><span class=3D"size" style=3D"font-size:11pt">--Zem</span></span><=
br></p><p style=3D"margin: 0in 0in 0.0001pt;"><span class=3D"font" style=3D=
"font-family:Calibri, sans-serif"><span class=3D"size" style=3D"font-size:1=
1pt"> </span></span><br></p><p style=3D"margin: 0in 0in 0.0001pt;"><sp=
an class=3D"font" style=3D"font-family:Calibri, sans-serif"><span class=3D"=
size" style=3D"font-size:11pt"> </span></span><br></p><p style=3D"marg=
in: 0in 0in 0.0001pt;"><span class=3D"font" style=3D"font-family:Calibri, s=
ans-serif"><span class=3D"size" style=3D"font-size:11pt"> </span></spa=
n><br></p><p style=3D"margin: 0in 0in 0.0001pt;"><span class=3D"font" style=
=3D"font-family:Calibri, sans-serif"><span class=3D"size" style=3D"font-siz=
e:11pt"> </span></span><br></p></div>
<p><br></p><div style=3D"font-family:Arial;">--<br></div>
<div style=3D"font-family:Arial;"> You received this message because you ar=
e subscribed to the Google Groups "ISO C++ Standard - Future Proposals" gro=
up.<br></div>
<div style=3D"font-family:Arial;"> To unsubscribe from this group and stop =
receiving emails from it, send an email to <a style=3D"text-decoration: und=
erline; color: blue;" href=3D"mailto:std-proposals+unsubscribe@isocpp.org">=
std-proposals+unsubscribe@isocpp.org</a>.<br></div>
<div style=3D"font-family:Arial;"> To post to this group, send email to <a =
style=3D"text-decoration: underline; color: blue;" href=3D"mailto:std-propo=
sals@isocpp.org">std-proposals@isocpp.org</a>.<br></div>
<div style=3D"font-family:Arial;"> To view this discussion on the web visit=
<a style=3D"text-decoration: underline; color: blue;" href=3D"https://grou=
ps.google.com/a/isocpp.org/d/msgid/std-proposals/00c801d46faf%24dc525450%24=
94f6fcf0%24%40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https:/=
/groups.google.com/a/isocpp.org/d/msgid/std-proposals/00c801d46faf%24dc5254=
50%2494f6fcf0%24%40gmail.com</a>.<br></div>
</blockquote></body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1540839750.2580417.1558674040.678FE68=
9%40webmail.messagingengine.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1540839750.258041=
7.1558674040.678FE689%40webmail.messagingengine.com</a>.<br />
--_----------=_154083975025804170--
.
Author: <ziemowit.laski@gmail.com>
Date: Mon, 29 Oct 2018 12:27:50 -0700
Raw View
This is a multipart message in MIME format.
------=_NextPart_000_00FB_01D46F82.CF202910
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Ok, something along those lines. Is this being formally investigated?
=20
From: mihailnajdenov@gmail.com <mihailnajdenov@gmail.com>=20
Sent: Monday, October 29, 2018 11:14 AM
To: ISO C++ Standard - Future Proposals <std-proposals@isocpp.org>
Cc: ziemowit.laski@gmail.com
Subject: Re: [std-proposals] Named parameters
=20
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/wz0a7NrwnGQ/iBpN=
8pYMFQAJ
=20
On Monday, October 29, 2018 at 7:50:26 PM UTC+2, ziemowi...@gmail.com <mail=
to:ziemowi...@gmail.com> wrote:
Hello C++-ers,
=20
I=E2=80=99d like to propose named parameter functionality for C++.
=20
I see that there have been previous attempts to add named parameter functio=
nality to C++ but led to syntactic ambiguities.
=20
However, I think/hope I=E2=80=99ve come up with something that might work, =
namely PARAMETER LABELS:
=20
int max(left: int, right: int); // declaration
int max(left: int left, right: int right); // OK
int max(p1: int, p2: int); // ERROR -labels must match
int max(int p1, p2: int p2); // ERROR -missing left label
=20
int max(left: int l, right: int r) {
return l > r? l: r;
}
=20
int foo(int p1, intp2) {
=E2=80=A6 max(left: p1, right: p2); // OK
=E2=80=A6 max(right: p1, left: p2); // OK
=E2=80=A6 max(p1, right: p2); // ERROR -missing label
=E2=80=A6 max(p1, p2); // ERROR -no labels=20
}
=20
I couldn=E2=80=99t find anything like this on the internets.
=20
Another question to consider is whether we should allow right-most labels t=
o be missing:
=20
int min(args: int arg1, int arg2, int arg3);
=20
=E2=80=A6min(args: 1, 2, 3); // OK
=E2=80=A6min(1, args: 2, 3); // ERROR =E2=80=93 non-labeled arguments m=
ust not preced labeled ones
=20
In other words, a label may be omitted for those parameters for which a def=
ault value may also be specified. I=E2=80=99m not sure about the soundness=
of this, but thought I=E2=80=99d put it out there.
=20
--Zem
=20
=20
=20
=20
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/00fa01d46fbd%247b7d0540%2472770fc0%24%40gmail.co=
m.
------=_NextPart_000_00FB_01D46F82.CF202910
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Dutf-8"><meta name=3DGenerator content=3D"Microsoft=
Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;}
..MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3D"#0563C1=
" vlink=3D"#954F72"><div class=3DWordSection1><p class=3DMsoNormal>Ok, some=
thing along those lines.=C2=A0 Is this being formally investigated?<o:p></o=
:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal style=
=3D'margin-left:.5in'><b>From:</b> mihailnajdenov@gmail.com <mihailnajde=
nov@gmail.com> <br><b>Sent:</b> Monday, October 29, 2018 11:14 AM<br><b>=
To:</b> ISO C++ Standard - Future Proposals <std-proposals@isocpp.org>=
;<br><b>Cc:</b> ziemowit.laski@gmail.com<br><b>Subject:</b> Re: [std-propos=
als] Named parameters<o:p></o:p></p><p class=3DMsoNormal style=3D'margin-le=
ft:.5in'><o:p> </o:p></p><div><p class=3DMsoNormal style=3D'margin-lef=
t:.5in'><a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposa=
ls/wz0a7NrwnGQ/iBpN8pYMFQAJ">https://groups.google.com/a/isocpp.org/d/msg/s=
td-proposals/wz0a7NrwnGQ/iBpN8pYMFQAJ</a><o:p></o:p></p><div><p class=3DMso=
Normal style=3D'margin-left:.5in'><o:p> </o:p></p></div><div><p class=
=3DMsoNormal style=3D'margin-left:.5in'><br><br>On Monday, October 29, 2018=
at 7:50:26 PM UTC+2, <a href=3D"mailto:ziemowi...@gmail.com">ziemowi...@gm=
ail.com</a> wrote:<o:p></o:p></p><blockquote style=3D'border:none;border-le=
ft:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-t=
op:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><p class=3DMsoNorm=
al style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:=
..5in'>Hello C++-ers,<o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin=
-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'> <o:p></o:p=
></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-botto=
m-alt:auto;margin-left:.5in'>I=E2=80=99d like to propose named parameter fu=
nctionality for C++.<o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin=
-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'> <o:p></o:p=
></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-botto=
m-alt:auto;margin-left:.5in'>I see that there have been previous attempts t=
o add named parameter functionality to C++ but led to syntactic ambiguities=
..<o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-m=
argin-bottom-alt:auto;margin-left:.5in'> <o:p></o:p></p><p class=3DMso=
Normal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-l=
eft:.5in'>However, I think/hope I=E2=80=99ve come up with something that mi=
ght work, namely PARAMETER LABELS:<o:p></o:p></p><p class=3DMsoNormal style=
=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>&n=
bsp;<o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;ms=
o-margin-bottom-alt:auto;margin-left:.5in'>int max(left: int, right: int);&=
nbsp; // declaration<o:p></o:p></=
p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;margin-left:.5in'>int max(left: int left, right: int right); &=
nbsp; // OK<o:p></o:p></p><p class=3DMsoNormal style=3D'mso-mar=
gin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>int max(p1: i=
nt, p2: int); &n=
bsp; // ERROR -labels must match<o:p></o:p></p><p class=
=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;ma=
rgin-left:.5in'>int max(int p1, p2: int p2); &=
nbsp; // ERROR -missing left label<o:p></o:p></p><p=
class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:a=
uto;margin-left:.5in'> <o:p></o:p></p><p class=3DMsoNormal style=3D'ms=
o-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>int max(=
left: int l, right: int r) {<o:p></o:p></p><p class=3DMsoNormal style=3D'ms=
o-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'> r=
eturn l > r? l: r;<o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margi=
n-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>}<o:p></o:p></p=
><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-al=
t:auto;margin-left:.5in'> <o:p></o:p></p><p class=3DMsoNormal style=3D=
'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>int f=
oo(int p1, intp2) {<o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-=
top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'> =E2=
=80=A6 max(left: p1, right: p2); // OK<o:p></o:p></p><p c=
lass=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:aut=
o;margin-left:.5in'> =E2=80=A6 max(right: p1, left: p2); &=
nbsp; // OK<o:p></o:p></p><p class=3DMsoNormal style=3D'mso-mar=
gin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'> =
=E2=80=A6 max(p1, right: p2); &nb=
sp; // ERROR -missing label<o:p></o:p></p><p c=
lass=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:aut=
o;margin-left:.5in'> =E2=80=A6 max(p1, p2); &n=
bsp;  =
; // ERROR -no labels <o:p>=
</o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-=
bottom-alt:auto;margin-left:.5in'>}<o:p></o:p></p><p class=3DMsoNormal styl=
e=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>&=
nbsp;<o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;m=
so-margin-bottom-alt:auto;margin-left:.5in'>I couldn=E2=80=99t find anythin=
g like this on the internets.<o:p></o:p></p><p class=3DMsoNormal style=3D'm=
so-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'> <=
o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-mar=
gin-bottom-alt:auto;margin-left:.5in'>Another question to consider is wheth=
er we should allow right-most labels to be missing:<o:p></o:p></p><p class=
=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;ma=
rgin-left:.5in'> <o:p></o:p></p><p class=3DMsoNormal style=3D'mso-marg=
in-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>int min(args: =
int arg1, int arg2, int arg3);<o:p></o:p></p><p class=3DMsoNormal style=3D'=
mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'> =
<o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-ma=
rgin-bottom-alt:auto;margin-left:.5in'> =E2=80=A6min(args: 1, 2=
, 3); // OK<o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-to=
p-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'> =E2=80=
=A6min(1, args: 2, 3); // ERROR =E2=80=93 non-labeled arguments must =
not preced labeled ones<o:p></o:p></p><p class=3DMsoNormal style=3D'mso-mar=
gin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'> <o:p></=
o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bo=
ttom-alt:auto;margin-left:.5in'>In other words, a label may be omitted for =
those parameters for which a default value may also be specified. I=
=E2=80=99m not sure about the soundness of this, but thought I=E2=80=99d pu=
t it out there.<o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-=
alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'> <o:p></o:p></p>=
<p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt=
:auto;margin-left:.5in'>--Zem<o:p></o:p></p><p class=3DMsoNormal style=3D'm=
so-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'> <=
o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-mar=
gin-bottom-alt:auto;margin-left:.5in'> <o:p></o:p></p><p class=3DMsoNo=
rmal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-lef=
t:.5in'> <o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-a=
lt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'> <o:p></o:p></p><=
/div></div></blockquote></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" 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/00fa01d46fbd%247b7d0540%2472770fc0%24=
%40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/00fa01d46fbd%247b7d0540%2472770fc0%2=
4%40gmail.com</a>.<br />
------=_NextPart_000_00FB_01D46F82.CF202910--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Mon, 29 Oct 2018 15:33:15 -0400
Raw View
--000000000000a1b36e05796324a6
Content-Type: text/plain; charset="UTF-8"
On Mon, Oct 29, 2018 at 3:02 PM Henry Miller <hank@millerfarm.com> wrote:
> There have been many, all died because of opposition to the idea. You have
> a syntax, but you need to convince people that there isn't a better way.
> Strong types are generally preferred.
>
Please don't passive voice into implying that everyone agrees with this.
I very much disagree. I want named parameters in the style of Ada.
Why not
>
max(left_t left, right_t right)
> This does everything you wanted, plus as a user I can use my own names.
>
> void fub() {
> left_t foo(99);
> right_t bar(getFuzzSize);
> max(bar, foo) ;
> }
>
> The above passes code review, the variable names are meaningful in
> context. Convert to named papamarers and it compiles. However as written it
> won't compile because there is a real error.
>
I don't even understand this, much less want it. One of the purposes of
named parameters
is to make argument associations visible at the call site. This doesn't do
that at 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/CAHSYqdZrptw44O%2Brzt8GePh36Fih8xr-0eqctJ-rvYOJrJHB4g%40mail.gmail.com.
--000000000000a1b36e05796324a6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Oct 29=
, 2018 at 3:02 PM Henry Miller <<a href=3D"mailto:hank@millerfarm.com">h=
ank@millerfarm.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
u></u>
<div><div style=3D"font-family:Arial">There have been many, all died becaus=
e of opposition to the idea. You have a syntax, but you need to convince pe=
ople that there isn't a better way.=C2=A0</div>
<div style=3D"font-family:Arial">Strong types are generally preferred.</div=
></div></blockquote><div><br>Please don't passive voice into implying t=
hat everyone agrees with this.<br>I very much disagree.=C2=A0 I want named =
parameters in the style of Ada.<br><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div><div style=3D"font-family:Arial"> Why not=C2=A0</div></div></blockquo=
te><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div>
<div style=3D"font-family:Arial">max(left_t left, right_t right)=C2=A0</div=
>
<div style=3D"font-family:Arial">This does everything you wanted, plus as a=
user I can use my own names.<br></div></div></blockquote><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div><div style=3D"font-family:Arial"><br></div>
<div style=3D"font-family:Arial">void fub() {<br></div>
<div style=3D"font-family:Arial">left_t foo(99);<br></div>
<div style=3D"font-family:Arial">right_t bar(getFuzzSize);<br></div>
<div style=3D"font-family:Arial">max(bar, foo) ;=C2=A0<br></div>
<div style=3D"font-family:Arial">}=C2=A0<br></div>
<div style=3D"font-family:Arial"><br></div>
<div style=3D"font-family:Arial">The above passes code review, the variable=
names are meaningful in context. Convert to named papamarers and it compil=
es. However as written it won't compile because there is a real error.=
=C2=A0<br></div></div></blockquote><div><br>I don't even understand thi=
s, much less want it.=C2=A0 One of the purposes of named parameters<br>is t=
o make argument associations visible at the call site.=C2=A0 This doesn'=
;t do that at all.</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZrptw44O%2Brzt8GePh36Fih8xr-0e=
qctJ-rvYOJrJHB4g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZrptw44O=
%2Brzt8GePh36Fih8xr-0eqctJ-rvYOJrJHB4g%40mail.gmail.com</a>.<br />
--000000000000a1b36e05796324a6--
.
Author: Henry Miller <hank@millerfarm.com>
Date: Mon, 29 Oct 2018 18:46:35 -0500
Raw View
This is a multi-part message in MIME format.
--_----------=_1540856795950590
Content-Type: text/plain; charset="UTF-8"
The idea is controversial. Many people want names parameters for various
reasons. Many others oppose them for various reasons.
On Mon, Oct 29, 2018, at 2:33 PM, Hyman Rosen wrote:
> On Mon, Oct 29, 2018 at 3:02 PM Henry Miller
> <hank@millerfarm.com> wrote:>> __
>> There have been many, all died because of opposition to the idea. You
>> have a syntax, but you need to convince people that there isn't a
>> better way.>> Strong types are generally preferred.
>
> Please don't passive voice into implying that everyone agrees
> with this.> I very much disagree. I want named parameters in the style of Ada.
>> Why not
>> max(left_t left, right_t right)
>> This does everything you wanted, plus as a user I can use my
>> own names.>>
>> void fub() {
>> left_t foo(99);
>> right_t bar(getFuzzSize);
>> max(bar, foo) ;
>> }
>>
>> The above passes code review, the variable names are meaningful in
>> context. Convert to named papamarers and it compiles. However as
>> written it won't compile because there is a real error.>
> I don't even understand this, much less want it. One of the purposes
> of named parameters> is to make argument associations visible at the call site. This
> doesn't do that at 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/CAHSYqdZrptw44O%2Brzt8GePh36Fih8xr-0eqctJ-rvYOJrJHB4g%40mail.gmail.com[1].
Links:
1. https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZrptw44O%2Brzt8GePh36Fih8xr-0eqctJ-rvYOJrJHB4g%40mail.gmail.com?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/1540856795.95059.1558981472.55BA4D81%40webmail.messagingengine.com.
--_----------=_1540856795950590
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="UTF-8"
<!DOCTYPE html>
<html>
<head>
<title></title>
<style type=3D"text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style>
</head>
<body><div style=3D"font-family:Arial;">The idea is controversial. Many peo=
ple want names parameters for various reasons. Many others oppose them for =
various reasons. </div>
<div id=3D"sig11221025"><div class=3D"signature"><br></div>
</div>
<div><br></div>
<div><br></div>
<div>On Mon, Oct 29, 2018, at 2:33 PM, Hyman Rosen wrote:<br></div>
<blockquote type=3D"cite"><div dir=3D"ltr"><div defang_data-gmailquote=3D"y=
es"><div dir=3D"ltr">On Mon, Oct 29, 2018 at 3:02 PM Henry Miller <<a hr=
ef=3D"mailto:hank@millerfarm.com">hank@millerfarm.com</a>> wrote:<br></d=
iv>
<blockquote defang_data-gmailquote=3D"yes" style=3D"margin-top:0px;margin-r=
ight:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-l=
eft-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><di=
v style=3D"font-family:Arial;"><u></u><br></div>
<div><div style=3D"font-family:Arial;">There have been many, all died becau=
se of opposition to the idea. You have a syntax, but you need to convince p=
eople that there isn't a better way. <br></div>
<div style=3D"font-family:Arial;">Strong types are generally preferred.<br>=
</div>
</div>
</blockquote><div><div style=3D"font-family:Arial;"><br></div>
<div style=3D"font-family:Arial;">Please don't passive voice into implying =
that everyone agrees with this.<br></div>
<div style=3D"font-family:Arial;">I very much disagree. I want named =
parameters in the style of Ada.<br></div>
</div>
<blockquote defang_data-gmailquote=3D"yes" style=3D"margin-top:0px;margin-r=
ight:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-l=
eft-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><di=
v><div style=3D"font-family:Arial;">Why not <br></div>
</div>
</blockquote><blockquote defang_data-gmailquote=3D"yes" style=3D"margin-top=
:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width=
:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-l=
eft:1ex;"><div><div style=3D"font-family:Arial;">max(left_t left, right_t r=
ight) <br></div>
<div style=3D"font-family:Arial;">This does everything you wanted, plus as =
a user I can use my own names.<br></div>
</div>
</blockquote><blockquote defang_data-gmailquote=3D"yes" style=3D"margin-top=
:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width=
:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-l=
eft:1ex;"><div><div style=3D"font-family:Arial;"><br></div>
<div style=3D"font-family:Arial;">void fub() {<br></div>
<div style=3D"font-family:Arial;">left_t foo(99);<br></div>
<div style=3D"font-family:Arial;">right_t bar(getFuzzSize);<br></div>
<div style=3D"font-family:Arial;">max(bar, foo) ; <br></div>
<div style=3D"font-family:Arial;">} <br></div>
<div style=3D"font-family:Arial;"><br></div>
<div style=3D"font-family:Arial;">The above passes code review, the variabl=
e names are meaningful in context. Convert to named papamarers and it compi=
les. However as written it won't compile because there is a real error.&nbs=
p;<br></div>
</div>
</blockquote><div><div style=3D"font-family:Arial;"><br></div>
<div style=3D"font-family:Arial;">I don't even understand this, much less w=
ant it. One of the purposes of named parameters<br></div>
<div style=3D"font-family:Arial;">is to make argument associations visible =
at the call site. This doesn't do that at all.<br></div>
</div>
<blockquote defang_data-gmailquote=3D"yes" style=3D"margin-top:0px;margin-r=
ight:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-l=
eft-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><br=
></blockquote></div>
</div>
<p><br></p><div style=3D"font-family:Arial;">--<br></div>
<div style=3D"font-family:Arial;"> You received this message because you ar=
e subscribed to the Google Groups "ISO C++ Standard - Future Proposals" gro=
up.<br></div>
<div style=3D"font-family:Arial;"> To unsubscribe from this group and stop =
receiving emails from it, send an email to <a href=3D"mailto:std-proposals+=
unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br></div>
<div style=3D"font-family:Arial;"> To post to this group, send email to <a =
href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br><=
/div>
<div style=3D"font-family:Arial;"> To view this discussion on the web visit=
<a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA=
HSYqdZrptw44O%2Brzt8GePh36Fih8xr-0eqctJ-rvYOJrJHB4g%40mail.gmail.com?utm_me=
dium=3Demail&utm_source=3Dfooter">https://groups.google.com/a/isocpp.or=
g/d/msgid/std-proposals/CAHSYqdZrptw44O%2Brzt8GePh36Fih8xr-0eqctJ-rvYOJrJHB=
4g%40mail.gmail.com</a>.<br></div>
</blockquote></body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1540856795.95059.1558981472.55BA4D81%=
40webmail.messagingengine.com?utm_medium=3Demail&utm_source=3Dfooter">https=
://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1540856795.95059.15=
58981472.55BA4D81%40webmail.messagingengine.com</a>.<br />
--_----------=_1540856795950590--
.
Author: Izzy Coding <matthew.i.greenwood@gmail.com>
Date: Tue, 30 Oct 2018 00:14:26 -0700 (PDT)
Raw View
------=_Part_826_15763406.1540883666966
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I would love to see named parameters at some point.
My point of view is from a library writing one where, with named parameters=
, I could reduce my line count by almost half.
This is where I provide a major =E2=80=9Cworking=E2=80=9D function and then=
several wrapper methods that allow for the different flavours of calling.
From a build perspective the wrapping methods are likely inclined, but if m=
y observation is correct (which it is probably not; could be missing a buil=
d flag or something), there is still lots of linking to be done at compile =
time.
If however, I could define (my opinion would be using an attribute for the =
parameters as this is really only a compiler hook rather than a language fe=
ature) a method like so:
`public: int MyFunc(int one, int two =3D 0, [Named] int three =3D 0, [Named=
]...);`
Notice though that it would only be allowed on optional parameters and, lik=
e optional parameters, it must be defined for all subsequent parameters. Ot=
herwise the program should be ill-formed.
This would allow me to have a clean codebase without all the wrappers (afte=
r all if my method decides to support another type then another zillion wra=
ppers are required).
Also when using my library (assuming it=E2=80=99s not statically linked), u=
sers only have 1 method to link against for each =E2=80=9Cunit-of-work=E2=
=80=9D provided by my library.
Of course, I am not one with the standard so there are probably lots of thi=
ngs I am missing to make my life easier.
--=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/a716e8f8-c4a1-4d53-9866-6ce1c9592aa8%40isocpp.or=
g.
------=_Part_826_15763406.1540883666966--
.
Author: David Brown <david@westcontrol.com>
Date: Tue, 30 Oct 2018 10:27:29 +0100
Raw View
On 29/10/18 20:02, Henry Miller wrote:
> There have been many, all died because of opposition to the idea. You
> have a syntax, but you need to convince people that there isn't a better
> way.=20
>=20
> Strong types are generally preferred.=20
No, they are not generally preferred. At the moment, they are all we've
got.
Strong types certainly have their uses, and their advantages over other
solutions. They also have their disadvantages.
A great many people want a simple, clean and optional method of naming
parameters. It could be nothing more than a compile-time check, but it
needs a convenient syntax. More advanced requirements - re-ordering
parameters, forcing the use of names, etc., gets more controversial.
Parameter naming is not an alternative to strong types, nor are strong
types an alternative to parameter naming - they are complements.
> Why not=20
>=20
> max(left_t left, right_t right)=20
>=20
> This does everything you wanted, plus as a user I can use my own names.=
=20
>=20
It most certainly does not do what /I/ want.
> void fub() {
> left_t foo(99);
> right_t bar(getFuzzSize);
> max(bar, foo) ;=20
> }=20
This separates the declarations from the call site, spoiling the point
completely. Better would be:
max(right_t(getFussSize), left_t(99));
(Giving the same compile-time error.)
But let us be more realistic. Suppose "max" is in the namespace
"stuff". Types "left_t" and "right_t" are specific to the function
"max" here, and should be in a nested namespace "max_params" so that
they are independent from "left_t" and "right_t" for other functions.
That gives us:
stuff::max(
stuff::max_params::right_t(getFussSize),
stuff::max_params::left_t(99)
);
Compare that to a named parameter solution of :
stuff::max(right: getFussSize, left: 99);
There is simply no contest.
If there is to be a sane use of strong types as a way of implementing
named parameters, we need two things.
First, we need a "function parameter scope" for lookups, so that within
function parameters the identifier lookup starts with a scope for
function. This should also include scopes related to the parameters (if
a function takes an enum parameter, you should be able to use enum
constants of that type directly without giving the scope details).
This gets us to a call:
stuff::max(right_t(getFussSize), left_t(99));
Secondly, we need syntactic sugar so that when declaring stuff::max, we
don't need to define the parameter types and scopes manually.
mvh.,
David
>=20
> The above passes code review, the variable names are meaningful in
> context. Convert to named papamarers and it compiles. However as written
> it won't compile because there is a real error.=20
>=20
> For any proposal to be accepted you need to convince a lot of people
> that the above objection is balanced by the greater good. Once you have
> that we can bikeshed on syntax, there are many ideas.=20
>=20
> --
> Henry Miller
> hank@millerfarm.com
>=20
>=20
>=20
> On Mon, Oct 29, 2018, at 12:50 PM, ziemowit.laski@gmail.com
> <mailto:ziemowit.laski@gmail.com> wrote:
>>
>> Hello C++-ers,
>>
>> =20
>>
>> I=E2=80=99d like to propose named parameter functionality for C++.
>>
>> =20
>>
>> I see that there have been previous attempts to add named parameter
>> functionality to C++ but led to syntactic ambiguities.
>>
>> =20
>>
>> However, I think/hope I=E2=80=99ve come up with something that might wor=
k,
>> namely PARAMETER LABELS:
>>
>> =20
>>
>> int max(left: int, right: int); // declaration
>>
>> int max(left: int left, right: int right); // OK
>>
>> int max(p1: int, p2: int); // ERROR -labels must match
>>
>> int max(int p1, p2: int p2); // ERROR -missing left label
>>
>> =20
>>
>> int max(left: int l, right: int r) {
>>
>> return l > r? l: r;
>>
>> }
>>
>> =20
>>
>> int foo(int p1, intp2) {
>>
>> =E2=80=A6 max(left: p1, right: p2); // OK
>>
>> =E2=80=A6 max(right: p1, left: p2); // OK
>>
>> =E2=80=A6 max(p1, right: p2); // ERROR -missing label
>>
>> =E2=80=A6 max(p1, p2); // ERROR -no labels
>>
>> }
>>
>> =20
>>
>> I couldn=E2=80=99t find anything like this on the internets.
>>
>> =20
>>
>> Another question to consider is whether we should allow right-most
>> labels to be missing:
>>
>> =20
>>
>> int min(args: int arg1, int arg2, int arg3);
>>
>> =20
>>
>> =E2=80=A6min(args: 1, 2, 3); // OK
>>
>> =E2=80=A6min(1, args: 2, 3); // ERROR =E2=80=93 non-labeled argument=
s must not
>> preced labeled ones
>>
>> =20
>>
>> In other words, a label may be omitted for those parameters for which
>> a default value may also be specified. I=E2=80=99m not sure about the
>> soundness of this, but thought I=E2=80=99d put it out there.
>>
>> =20
>>
>> --Zem
>>
--=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/pr981u%24jlr%241%40blaine.gmane.org.
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Tue, 30 Oct 2018 11:12:48 -0400
Raw View
--00000000000006ef5b0579739f9e
Content-Type: text/plain; charset="UTF-8"
On Tue, Oct 30, 2018 at 5:27 AM David Brown <david@westcontrol.com> wrote:
> A great many people want a simple, clean and optional method of naming
> parameters. It could be nothing more than a compile-time check, but it
> needs a convenient syntax. More advanced requirements - re-ordering
> parameters, forcing the use of names, etc., gets more controversial.
>
Ada-style named parameters have call expressions contain 0 or more
positional
arguments followed by 0 or more named argument associations. The named
arguments are used in overload matching, and they are reordered as needed.
(Ada overloads by return type, so that also affects overload resolution in
concert
with the other factors.)
/* 1 */ void f(int a = 0, int b = 0);
/* 2 */ void f(int c = 0);
f(1, 2); // calls #1
f(a => 1); // calls #1 f(1, 0)
f(b => 2); // calls #1 f(0, 2)
f(c => 3); // calls #2
f(4); // ambiguous
C++ has unnamed parameters and allows multiple declarations of the same
function
using different parameter names, so Ada style doesn't carry over exactly.
A reasonable
and simple-to-specify rule is that a parameter name may be used in a named
association
if the name is used for only one parameter in all declarations of the same
function.
There don't need to be any additional requirements for parameters to have
default values.
void aim(double radius, double inclination, double azimuth);
aim(azimuth => 30_deg, inclination => 70_deg, radius => 5_mi);
This style of named parameters does not need any ABI changes. It operates
strictly
within the compiler. C++ currently leaves order of evaluation of function
arguments
unspecified, so reordering based on named association does not introduce
any new
opportunities for ambiguity.
I believe that there should be no syntax to opt in or opt out of named
argument
association (short of not naming parameters).
--
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/CAHSYqdYtMgS6qoP5BFEO%3DAn6gBUt_9zPfOQONmmkfS97jApKCQ%40mail.gmail.com.
--00000000000006ef5b0579739f9e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Oct 30=
, 2018 at 5:27 AM David Brown <<a href=3D"mailto:david@westcontrol.com">=
david@westcontrol.com</a>> wrote:</div><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A great many people want a simple, clean and optional method of naming<br>
parameters.=C2=A0 It could be nothing more than a compile-time check, but i=
t<br>
needs a convenient syntax.=C2=A0 More advanced requirements - re-ordering<b=
r>
parameters, forcing the use of names, etc., gets more controversial.<br></b=
lockquote><div><br>=C2=A0Ada-style named parameters have call expressions c=
ontain 0 or more positional<br>arguments followed by 0 or more named argume=
nt associations.=C2=A0 The named<br>arguments are used in overload matching=
, and they are reordered as needed.<br>(Ada overloads by return type, so th=
at also affects overload resolution in concert<br>with the other factors.)<=
br><font face=3D"monospace, monospace">=C2=A0 =C2=A0 /* 1 */ void f(int a =
=3D 0, int b =3D 0);<br>=C2=A0 =C2=A0 /* 2 */ void f(int c =3D 0);<br>=C2=
=A0 =C2=A0 f(1, 2);=C2=A0 =C2=A0 // calls #1<br>=C2=A0 =C2=A0 f(a =3D> 1=
);=C2=A0 // calls #1 f(1, 0)<br>=C2=A0 =C2=A0 f(b =3D> 2);=C2=A0 // call=
s #1 f(0, 2)<br>=C2=A0 =C2=A0 f(c =3D> 3);=C2=A0 // calls #2<br>=C2=A0 =
=C2=A0 f(4);=C2=A0 =C2=A0 =C2=A0 =C2=A0// ambiguous</font><br><br>C++ has u=
nnamed parameters and allows multiple declarations of the same function<br>=
using different parameter names, so Ada style doesn't carry over exactl=
y.=C2=A0 A reasonable<br>and simple-to-specify rule is that a parameter nam=
e may be used in a named association<br>if the name is used for only one pa=
rameter in all declarations of the same function.<br><br>There don't ne=
ed to be any additional requirements for parameters to have default values.=
<br><font face=3D"monospace, monospace">=C2=A0 =C2=A0 void aim(double radiu=
s, double inclination, double azimuth);</font><br><font face=3D"monospace, =
monospace">=C2=A0 =C2=A0 aim(azimuth =3D> 30_deg, inclination =3D> 70=
_deg, radius =3D> 5_mi);</font><br><font face=3D"arial, helvetica, sans-=
serif"><br>This style of named parameters does not need any ABI changes.=C2=
=A0 It operates strictly<br>within the compiler.=C2=A0 C++ currently leaves=
order of evaluation of function arguments<br>unspecified, so reordering ba=
sed on named association does not introduce any new<br>opportunities for am=
biguity.<br><br>I believe that there should be no syntax to opt in or opt o=
ut of named argument<br>association (short of not naming parameters).<br></=
font></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYtMgS6qoP5BFEO%3DAn6gBUt_9zPfO=
QONmmkfS97jApKCQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYtMgS6qo=
P5BFEO%3DAn6gBUt_9zPfOQONmmkfS97jApKCQ%40mail.gmail.com</a>.<br />
--00000000000006ef5b0579739f9e--
.
Author: Henry Miller <hank@millerfarm.com>
Date: Tue, 30 Oct 2018 18:55:11 -0500
Raw View
On Tue, Oct 30, 2018, at 4:27 AM, David Brown wrote:
> On 29/10/18 20:02, Henry Miller wrote:
> > There have been many, all died because of opposition to the idea. You
> > have a syntax, but you need to convince people that there isn't a bette=
r
> > way.=20
> >=20
> > Strong types are generally preferred.=20
>=20
> No, they are not generally preferred. At the moment, they are all we've
> got.
>=20
> Strong types certainly have their uses, and their advantages over other
> solutions. They also have their disadvantages.
I haven't actually surveyed the committee, but I think that my statement st=
ands. There is a great desire that if the code compiles it is correct.=20
Max(left: varShouldBeRight, right: varShouldBeLeft);
This will compile, but is wrong. In a real program where the variables come=
from someplace and are used in multiple locations it is much more likely t=
hat either it fails to compile, or at least someone catches the error in re=
view. Haskell has a reputation of if it compiles it is right. It would be n=
ice to have the same reputation without the downsides of haskell (which are=
subjective so let's not argue about them)=20
> A great many people want a simple, clean and optional method of naming
> parameters. It could be nothing more than a compile-time check, but it
> needs a convenient syntax. More advanced requirements - re-ordering
> parameters, forcing the use of names, etc., gets more controversial.
Yes, but why? If you can get the same benefit from something else that migh=
t be better.=20
> Parameter naming is not an alternative to strong types, nor are strong
> types an alternative to parameter naming - they are complements.
>=20
> > Why not=20
> >=20
> > max(left_t left, right_t right)=20
> >=20
> > This does everything you wanted, plus as a user I can use my own names.=
=20
> >=20
>=20
> It most certainly does not do what /I/ want.
>=20
> > void fub() {
> > left_t foo(99);
> > right_t bar(getFuzzSize);
> > max(bar, foo) ;=20
> > }=20
>=20
> This separates the declarations from the call site, spoiling the point
> completely. Better would be:
>=20
> max(right_t(getFussSize), left_t(99));
I figured that was obvious, but it fails to show the power of types vs para=
meters: types follow to other contexts in a often useful way that named par=
ameters do not.=20
> (Giving the same compile-time error.)
>=20
> But let us be more realistic. Suppose "max" is in the namespace
> "stuff". Types "left_t" and "right_t" are specific to the function
> "max" here, and should be in a nested namespace "max_params" so that
> they are independent from "left_t" and "right_t" for other functions.
> That gives us:
>=20
> stuff::max(
> stuff::max_params::right_t(getFussSize),
> stuff::max_params::left_t(99)
> );
Should be stuff::right_t. That max takes this isn't a factor. The very nam=
e max implies there is a min which should use the same types. Most likely s=
tuff is a larger name space with lots of functions that take or return left=
_t and/or right_t. They are conceptually the same type and it would make th=
e library hard to use if they were not the same type all the way through.=
=20
> Compare that to a named parameter solution of :
>=20
> stuff::max(right: getFussSize, left: 99);
>=20
> There is simply no contest.
A simple using can bring right_t into the current scope and solve that. Now=
we have the same thing as below.=20
>=20
> If there is to be a sane use of strong types as a way of implementing
> named parameters, we need two things.
>=20
> First, we need a "function parameter scope" for lookups, so that within
> function parameters the identifier lookup starts with a scope for
> function. This should also include scopes related to the parameters (if
> a function takes an enum parameter, you should be able to use enum
> constants of that type directly without giving the scope details).
>=20
> This gets us to a call:
>=20
> stuff::max(right_t(getFussSize), left_t(99));
A proposal to make function call parameters follow different type resolutio=
n rules from the outside scope probably is a good idea. There are some tric=
ky areas in some of the details that need to be worked out, but it seems re=
alistic. I'm not thinking about it, but I see the use.=20
> Secondly, we need syntactic sugar so that when declaring stuff::max, we
> don't need to define the parameter types and scopes manually.
>=20
That is the downside to strong types in current c++. They require something=
ugly (very subjective, some people are happy with their way of overcoming =
the problem some are not)=20
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1540943711.521596.1560297152.15CC3529%40webmail.=
messagingengine.com.
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Wed, 31 Oct 2018 06:47:22 +0100
Raw View
On Tue, Oct 30, 2018 at 06:55:11PM -0500, Henry Miller wrote:
> On Tue, Oct 30, 2018, at 4:27 AM, David Brown wrote:
> > On 29/10/18 20:02, Henry Miller wrote:
> >
> > But let us be more realistic. Suppose "max" is in the namespace
> > "stuff". Types "left_t" and "right_t" are specific to the function
> > "max" here, and should be in a nested namespace "max_params" so that
> > they are independent from "left_t" and "right_t" for other functions.
> > That gives us:
> >
> > stuff::max(
> > stuff::max_params::right_t(getFussSize),
> > stuff::max_params::left_t(99)
> > );
>
> Should be stuff::right_t. That max takes this isn't a factor. The very name
> max implies there is a min which should use the same types. Most likely stuff
> is a larger name space with lots of functions that take or return left_t
> and/or right_t. They are conceptually the same type and it would make the
> library hard to use if they were not the same type all the way through.
>
> > Compare that to a named parameter solution of :
> >
> > stuff::max(right: getFussSize, left: 99);
> >
> > There is simply no contest.
>
> A simple using can bring right_t into the current scope and solve that. Now
> we have the same thing as below.
Here you are willfully ignoring the problem - you have to assume that there is
an unrelated "results" namespace that also contain a right_t that is needed
in this scope and you can't have both stuff::right_t and results::right_t
known as right_t.
(For the record I think this is where the usefulness of this simple
example breaks down - max is most certainly a function that shouldn't
have named arguments since they all are interchangeable anyway)
> >
> > If there is to be a sane use of strong types as a way of implementing
> > named parameters, we need two things.
> >
> > First, we need a "function parameter scope" for lookups, so that within
> > function parameters the identifier lookup starts with a scope for
> > function. This should also include scopes related to the parameters (if
> > a function takes an enum parameter, you should be able to use enum
> > constants of that type directly without giving the scope details).
> >
> > This gets us to a call:
> >
> > stuff::max(right_t(getFussSize), left_t(99));
>
> A proposal to make function call parameters follow different type resolution
> rules from the outside scope probably is a good idea. There are some tricky
> areas in some of the details that need to be worked out, but it seems
> realistic. I'm not thinking about it, but I see the use.
I agree and I see that proposal as more important than named parameters and
as independent of them.
/MF
--
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/20181031054722.GA11481%40noemi.
.
Author: David Brown <david@westcontrol.com>
Date: Wed, 31 Oct 2018 10:17:10 +0100
Raw View
On 31/10/18 00:55, Henry Miller wrote:
>
>
>
>
> On Tue, Oct 30, 2018, at 4:27 AM, David Brown wrote:
>> On 29/10/18 20:02, Henry Miller wrote:
>>> There have been many, all died because of opposition to the idea.
>>> You have a syntax, but you need to convince people that there
>>> isn't a better way.
>>>
>>> Strong types are generally preferred.
>>
>> No, they are not generally preferred. At the moment, they are all
>> we've got.
>>
>> Strong types certainly have their uses, and their advantages over
>> other solutions. They also have their disadvantages.
>
> I haven't actually surveyed the committee, but I think that my
> statement stands.
I haven't seen anything from the committee either. But even if they
have a firm opinion, there is a long way from that to claiming that one
method is "generally preferred". The fact that these threads are
brought up here again and again, and that there are multiple proposals
flying around, shows that there is a great interest in getting named
parameters in place and that strong types - or strong types alone - is
/not/ the generally preferred. We /have/ strong types today in C++ - it
is very, very far from good enough for named parameters.
> There is a great desire that if the code compiles
> it is correct.
>
On that, I think we all agree!
> Max(left: varShouldBeRight, right: varShouldBeLeft);
>
> This will compile, but is wrong.
That claim makes no sense. Since the syntax does not exist today, it is
a matter of how it is implemented. Getting the parameter order wrong
will either be a compile-time error, or will be accepted with parameter
re-ordering - the jury is still out on which is the best. Silently
compiling the incorrect code is not suggested by anyone - that is what
we have today, and what we are trying to get away from!
Given the declaration:
max(int left, int right);
and the call:
max(right: 12, left: 20);
then there are two acceptable options. One is a compile-time error.
The second is to treat the call exactly as if it had been written:
max(left: 20, right: 12);
Everything else is bike-shedding. People disagree on the syntax for the
declaration, or if the parameter information should be part of the
mangled name of the function, or if it should be possible to have
different names for the "named parameters" and the "formal parameter" in
the declaration or definition of the function. Some people want to
complicate matters with using names to overload functions, others want
to keep it simpler.
The fact is that most other good, modern programming languages have
named parameters. They can make the code clearer, and reduce errors.
It can be done in a simple, optional manner that will suffice for the
great majority of cases. And it is a frustrating thing to see people
arguing about the number of angels that can dance on the head of this
pin, instead of just making the clear and obvious solution that people
can use today.
> In a real program where the
> variables come from someplace and are used in multiple locations it
> is much more likely that either it fails to compile, or at least
> someone catches the error in review. Haskell has a reputation of if
> it compiles it is right. It would be nice to have the same reputation
> without the downsides of haskell (which are subjective so let's not
> argue about them)
Ada has that reputation too - and it manages named parameters in a
simple manner without strong types.
You talk about "real programs". In "real programs", people are not
going to go out of their way to make strong types for parameters except
in a few extreme cases. When you try to make a solution that requires
extra effort on the part of programmers, people will not use it! Make
it simple, make it optional, make it work with today's code, and it will
be used.
>
>> A great many people want a simple, clean and optional method of
>> naming parameters. It could be nothing more than a compile-time
>> check, but it needs a convenient syntax. More advanced
>> requirements - re-ordering parameters, forcing the use of names,
>> etc., gets more controversial.
>
> Yes, but why? If you can get the same benefit from something else
> that might be better.
"Better" for this means simpler to use, with clear syntax and little
extra effort.
Let those that want strong typing use that - there are cases where it is
a good idea, it works today (with lots of boilerplate and ugly code),
and no one is taking it away.
And for the majority of cases, use a simple system.
>
>> Parameter naming is not an alternative to strong types, nor are
>> strong types an alternative to parameter naming - they are
>> complements.
>>
>>> Why not
>>>
>>> max(left_t left, right_t right)
>>>
>>> This does everything you wanted, plus as a user I can use my own
>>> names.
>>>
>>
>> It most certainly does not do what /I/ want.
>>
>>> void fub() { left_t foo(99); right_t bar(getFuzzSize); max(bar,
>>> foo) ; }
>>
>> This separates the declarations from the call site, spoiling the
>> point completely. Better would be:
>>
>> max(right_t(getFussSize), left_t(99));
>
> I figured that was obvious, but it fails to show the power of types
> vs parameters: types follow to other contexts in a often useful way
> that named parameters do not.
>
I don't care.
Really, I don't.
What I care about is being able to make a function call in a manner the
same as today, with the /option/ of being able to include the parameter
names in some way as self-documentation for the code and as an extra
check that I have got the order right.
>> (Giving the same compile-time error.)
>>
>> But let us be more realistic. Suppose "max" is in the namespace
>> "stuff". Types "left_t" and "right_t" are specific to the
>> function "max" here, and should be in a nested namespace
>> "max_params" so that they are independent from "left_t" and
>> "right_t" for other functions. That gives us:
>>
>> stuff::max( stuff::max_params::right_t(getFussSize),
>> stuff::max_params::left_t(99) );
>
> Should be stuff::right_t.
No, it should not.
"max" is a silly example here, as are "right" and "left".
A better example would be:
guilib::drawbox(int x1, int y1, int x2, int y2);
Are you telling me you think "x1_t", "x2_t", "y1_t" and "y2_t" should
all be types within the "guilib" namespace? Are you telling me that
there should a type within the "guilib" namespace for each of the
parameters for each of the hundred functions in that namespace? Are you
telling me that the "x2_t" type for parameter "x2" in the "drawbox" call
should be the same as the type for parameter "x2" in the "beziercurve"
call where it means a subtly different thing? What about in the
"sheartransform" call in which "x2" is now a floating point type rather
than an integer type?
> That max takes this isn't a factor. The
> very name max implies there is a min which should use the same types.
> Most likely stuff is a larger name space with lots of functions that
> take or return left_t and/or right_t. They are conceptually the same
> type and it would make the library hard to use if they were not the
> same type all the way through.
You are talking about a different thing entirely.
You are not talking about using strong types for parameter naming - you
are talking about using strong types in programming in general.
Strong types are, of course, a good idea. (The C++ language today makes
it too difficult to make them - it takes too much manual coding. Some
standardised libraries for the purpose would be a good idea, but maybe
it should wait until metaclasses are in place.)
But strong types of the sort you are describing are /not/ an alternative
to named parameters - they are a complement.
So for the "guilib::drawbox" example, it would be better to have type
such as "guilib::pixel_coordinate_t", used for the parameters in
"drawbox". (Perhaps this should be split into horizontal and vertical
types, or combined as a point type - that's a minor detail.)
But that does not help in the slightest to get the parameter order
correct. It helps distinguish between a two-point style "drawbox" and a
point plus height/width style "drawbox". But it does not help avoid
mistakes such as "drawbox(x1, x2, y1, y2)".
To do that using strong types, you need a new strong type for each
parameter. For each parameter, in each function call. This is doable,
but would need the kind of changes I proposed in order to be manageable.
>
>> Compare that to a named parameter solution of :
>>
>> stuff::max(right: getFussSize, left: 99);
>>
>> There is simply no contest.
>
> A simple using can bring right_t into the current scope and solve
> that. Now we have the same thing as below.
I don't want to have to add "using" clauses for every parameter of every
function call. Such extra code makes the program harder to read, which
is always a bad thing.
But I /do/ want to be able to add parameter names to every parameter of
every function call, if I feel it makes the code clearer or safer.
>
>>
>> If there is to be a sane use of strong types as a way of
>> implementing named parameters, we need two things.
>>
>> First, we need a "function parameter scope" for lookups, so that
>> within function parameters the identifier lookup starts with a
>> scope for function. This should also include scopes related to the
>> parameters (if a function takes an enum parameter, you should be
>> able to use enum constants of that type directly without giving the
>> scope details).
>>
>> This gets us to a call:
>>
>> stuff::max(right_t(getFussSize), left_t(99));
>
> A proposal to make function call parameters follow different type
> resolution rules from the outside scope probably is a good idea.
> There are some tricky areas in some of the details that need to be
> worked out, but it seems realistic. I'm not thinking about it, but I
> see the use.
I am confident that there would be tricky areas - there are /always/
tricky areas :-) But I am also confident that it could make code
simpler to write and simpler to read.
>
>> Secondly, we need syntactic sugar so that when declaring
>> stuff::max, we don't need to define the parameter types and scopes
>> manually.
>>
>
> That is the downside to strong types in current c++. They require
> something ugly (very subjective, some people are happy with their way
> of overcoming the problem some are not)
>
Yes.
As I mentioned above, I think it might be best to wait until metaclasses
are in place before "solving" this one. I suspect that metaclasses
could be used to give a much neater solution, both from the users'
viewpoint and from the implementers (it would just be a new standard
header or module, rather than changes to the core language), and it
would be a shame to standardise on one method when a better one is
around the corner.
--
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/prbrqm%24p6o%241%40blaine.gmane.org.
.
Author: Henry Miller <hank@millerfarm.com>
Date: Wed, 31 Oct 2018 06:34:45 -0500
Raw View
I think that for the most part we under each other's point of view. If you =
write a proposal you need to be prepared to address this one. My purpose wa=
s in part to "play Devils advocate" to make sure that you have considered t=
he alternatives.=20
I'm working on collecting all of the arguments on both sides, with the idea=
that the committee should have a position on where we want to go.=20
Just some minor things to correct below.=20
On Wed, Oct 31, 2018, at 4:17 AM, David Brown wrote:
> On 31/10/18 00:55, Henry Miller wrote:
> >=20
> >=20
> >=20
> >=20
> > On Tue, Oct 30, 2018, at 4:27 AM, David Brown wrote:
> >> On 29/10/18 20:02, Henry Miller wrote:
> >>> There have been many, all died because of opposition to the idea.
> >>> You have a syntax, but you need to convince people that there
> >>> isn't a better way.
> >>>=20
> >>> Strong types are generally preferred.
> >>=20
> >> No, they are not generally preferred. At the moment, they are all
> >> we've got.
> >>=20
> >> Strong types certainly have their uses, and their advantages over
> >> other solutions. They also have their disadvantages.
> >=20
> > I haven't actually surveyed the committee, but I think that my
> > statement stands.
>=20
> I haven't seen anything from the committee either. But even if they
> have a firm opinion, there is a long way from that to claiming that one
> method is "generally preferred". The fact that these threads are
> brought up here again and again, and that there are multiple proposals
> flying around, shows that there is a great interest in getting named
> parameters in place and that strong types - or strong types alone - is
> /not/ the generally preferred. We /have/ strong types today in C++ - it
> is very, very far from good enough for named parameters.
>=20
> > There is a great desire that if the code compiles
> > it is correct.
> >=20
>=20
> On that, I think we all agree!
>=20
>=20
> > Max(left: varShouldBeRight, right: varShouldBeLeft);
> >=20
> > This will compile, but is wrong.
>=20
> That claim makes no sense. Since the syntax does not exist today, it is
> a matter of how it is implemented. Getting the parameter order wrong
> will either be a compile-time error, or will be accepted with parameter
> re-ordering - the jury is still out on which is the best. Silently
> compiling the incorrect code is not suggested by anyone - that is what
> we have today, and what we are trying to get away from!
>=20
What I'm saying is that if your larger function has variables for left and =
right you can pass the wrong ones in with a named type.=20
> Given the declaration:
>=20
> max(int left, int right);
>=20
> and the call:
>=20
> max(right: 12, left: 20);
>=20
> then there are two acceptable options. One is a compile-time error.
> The second is to treat the call exactly as if it had been written:
>=20
> max(left: 20, right: 12) ;
There is another option: the user meant=20
max(left: 12, right: 20);
Of course when you put a number right in the call like that you have little=
chance of correcting it. However if you are passing variables that are ini=
tialized elsewhere, if you have strong types the entire code flow is more l=
ikely to force the right types.=20
>=20
>=20
> Everything else is bike-shedding. People disagree on the syntax for the
> declaration, or if the parameter information should be part of the
> mangled name of the function, or if it should be possible to have
> different names for the "named parameters" and the "formal parameter" in
> the declaration or definition of the function. Some people want to
> complicate matters with using names to overload functions, others want
> to keep it simpler.
True, but I belive that some of those are compelling things that cannot be =
done without named parameters, while named parameters alone is not compelli=
ng.=20
>=20
>=20
> The fact is that most other good, modern programming languages have
> named parameters. They can make the code clearer, and reduce errors.
> It can be done in a simple, optional manner that will suffice for the
> great majority of cases. And it is a frustrating thing to see people
> arguing about the number of angels that can dance on the head of this
> pin, instead of just making the clear and obvious solution that people
> can use today.
Yes, but if there are other ways to obtain the same end and those other way=
s produce some other gain that is "better", we should prefer the other ways=
..=20
>=20
> > In a real program where the
> > variables come from someplace and are used in multiple locations it
> > is much more likely that either it fails to compile, or at least
> > someone catches the error in review. Haskell has a reputation of if
> > it compiles it is right. It would be nice to have the same reputation
> > without the downsides of haskell (which are subjective so let's not
> > argue about them)
>=20
> Ada has that reputation too - and it manages named parameters in a
> simple manner without strong types.
>=20
> You talk about "real programs". In "real programs", people are not
> going to go out of their way to make strong types for parameters except
> in a few extreme cases. When you try to make a solution that requires
> extra effort on the part of programmers, people will not use it! Make
> it simple, make it optional, make it work with today's code, and it will
> be used.
>=20
>=20
> >=20
> >> A great many people want a simple, clean and optional method of
> >> naming parameters. It could be nothing more than a compile-time
> >> check, but it needs a convenient syntax. More advanced
> >> requirements - re-ordering parameters, forcing the use of names,
> >> etc., gets more controversial.
> >=20
> > Yes, but why? If you can get the same benefit from something else
> > that might be better.
>=20
> "Better" for this means simpler to use, with clear syntax and little
> extra effort.
>=20
> Let those that want strong typing use that - there are cases where it is
> a good idea, it works today (with lots of boilerplate and ugly code),
> and no one is taking it away.
>=20
> And for the majority of cases, use a simple system.
>=20
> >=20
> >> Parameter naming is not an alternative to strong types, nor are
> >> strong types an alternative to parameter naming - they are
> >> complements.
> >>=20
> >>> Why not
> >>>=20
> >>> max(left_t left, right_t right)
> >>>=20
> >>> This does everything you wanted, plus as a user I can use my own
> >>> names.
> >>>=20
> >>=20
> >> It most certainly does not do what /I/ want.
> >>=20
> >>> void fub() { left_t foo(99); right_t bar(getFuzzSize); max(bar,
> >>> foo) ; }
> >>=20
> >> This separates the declarations from the call site, spoiling the
> >> point completely. Better would be:
> >>=20
> >> max(right_t(getFussSize), left_t(99));
> >=20
> > I figured that was obvious, but it fails to show the power of types
> > vs parameters: types follow to other contexts in a often useful way
> > that named parameters do not.
> >=20
>=20
> I don't care.
>=20
> Really, I don't.
>=20
> What I care about is being able to make a function call in a manner the
> same as today, with the /option/ of being able to include the parameter
> names in some way as self-documentation for the code and as an extra
> check that I have got the order right.
>=20
> >> (Giving the same compile-time error.)
> >>=20
> >> But let us be more realistic. Suppose "max" is in the namespace=20
> >> "stuff". Types "left_t" and "right_t" are specific to the
> >> function "max" here, and should be in a nested namespace
> >> "max_params" so that they are independent from "left_t" and
> >> "right_t" for other functions. That gives us:
> >>=20
> >> stuff::max( stuff::max_params::right_t(getFussSize),=20
> >> stuff::max_params::left_t(99) );
> >=20
> > Should be stuff::right_t. =20
>=20
> No, it should not.
>=20
> "max" is a silly example here, as are "right" and "left".
>=20
> A better example would be:
>=20
> guilib::drawbox(int x1, int y1, int x2, int y2);
>=20
> Are you telling me you think "x1_t", "x2_t", "y1_t" and "y2_t" should
> all be types within the "guilib" namespace? Are you telling me that
> there should a type within the "guilib" namespace for each of the
> parameters for each of the hundred functions in that namespace? Are you
> telling me that the "x2_t" type for parameter "x2" in the "drawbox" call
> should be the same as the type for parameter "x2" in the "beziercurve"
> call where it means a subtly different thing? What about in the
> "sheartransform" call in which "x2" is now a floating point type rather
> than an integer type?
>=20
> > That max takes this isn't a factor. The
> > very name max implies there is a min which should use the same types.
> > Most likely stuff is a larger name space with lots of functions that
> > take or return left_t and/or right_t. They are conceptually the same
> > type and it would make the library hard to use if they were not the
> > same type all the way through.
>=20
> You are talking about a different thing entirely.
>=20
> You are not talking about using strong types for parameter naming - you
> are talking about using strong types in programming in general.
>=20
> Strong types are, of course, a good idea. (The C++ language today makes
> it too difficult to make them - it takes too much manual coding. Some
> standardised libraries for the purpose would be a good idea, but maybe
> it should wait until metaclasses are in place.)
>=20
> But strong types of the sort you are describing are /not/ an alternative
> to named parameters - they are a complement.
>=20
> So for the "guilib::drawbox" example, it would be better to have type
> such as "guilib::pixel_coordinate_t", used for the parameters in
> "drawbox". (Perhaps this should be split into horizontal and vertical
> types, or combined as a point type - that's a minor detail.)
>=20
> But that does not help in the slightest to get the parameter order
> correct. It helps distinguish between a two-point style "drawbox" and a
> point plus height/width style "drawbox". But it does not help avoid
> mistakes such as "drawbox(x1, x2, y1, y2)".
>=20
> To do that using strong types, you need a new strong type for each
> parameter. For each parameter, in each function call. This is doable,
> but would need the kind of changes I proposed in order to be manageable.
>=20
>=20
> >=20
> >> Compare that to a named parameter solution of :
> >>=20
> >> stuff::max(right: getFussSize, left: 99);
> >>=20
> >> There is simply no contest.
> >=20
> > A simple using can bring right_t into the current scope and solve
> > that. Now we have the same thing as below.
>=20
> I don't want to have to add "using" clauses for every parameter of every
> function call. Such extra code makes the program harder to read, which
> is always a bad thing.
>=20
> But I /do/ want to be able to add parameter names to every parameter of
> every function call, if I feel it makes the code clearer or safer.
>=20
>=20
> >=20
> >>=20
> >> If there is to be a sane use of strong types as a way of
> >> implementing named parameters, we need two things.
> >>=20
> >> First, we need a "function parameter scope" for lookups, so that
> >> within function parameters the identifier lookup starts with a
> >> scope for function. This should also include scopes related to the
> >> parameters (if a function takes an enum parameter, you should be
> >> able to use enum constants of that type directly without giving the
> >> scope details).
> >>=20
> >> This gets us to a call:
> >>=20
> >> stuff::max(right_t(getFussSize), left_t(99));
> >=20
> > A proposal to make function call parameters follow different type
> > resolution rules from the outside scope probably is a good idea.
> > There are some tricky areas in some of the details that need to be
> > worked out, but it seems realistic. I'm not thinking about it, but I
> > see the use.
>=20
> I am confident that there would be tricky areas - there are /always/
> tricky areas :-) But I am also confident that it could make code
> simpler to write and simpler to read.
>=20
> >=20
> >> Secondly, we need syntactic sugar so that when declaring
> >> stuff::max, we don't need to define the parameter types and scopes
> >> manually.
> >>=20
> >=20
> > That is the downside to strong types in current c++. They require
> > something ugly (very subjective, some people are happy with their way
> > of overcoming the problem some are not)
> >=20
>=20
> Yes.
>=20
> As I mentioned above, I think it might be best to wait until metaclasses
> are in place before "solving" this one. I suspect that metaclasses
> could be used to give a much neater solution, both from the users'
> viewpoint and from the implementers (it would just be a new standard
> header or module, rather than changes to the core language), and it
> would be a shame to standardise on one method when a better one is
> around the corner.
>=20
> --=20
> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> 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=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/prbrqm%24p6o=
%241%40blaine.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/1540985685.743009.1560788792.08DE5A1A%40webmail.=
messagingengine.com.
.
Author: David Brown <david@westcontrol.com>
Date: Wed, 31 Oct 2018 14:34:41 +0100
Raw View
On 31/10/18 06:47, Magnus Fromreide wrote:
> On Tue, Oct 30, 2018 at 06:55:11PM -0500, Henry Miller wrote:
>> On Tue, Oct 30, 2018, at 4:27 AM, David Brown wrote:
<snip>
>>>
>>> If there is to be a sane use of strong types as a way of implementing
>>> named parameters, we need two things.
>>>
>>> First, we need a "function parameter scope" for lookups, so that within
>>> function parameters the identifier lookup starts with a scope for
>>> function. This should also include scopes related to the parameters (if
>>> a function takes an enum parameter, you should be able to use enum
>>> constants of that type directly without giving the scope details).
>>>
>>> This gets us to a call:
>>>
>>> stuff::max(right_t(getFussSize), left_t(99));
>>
>> A proposal to make function call parameters follow different type resolution
>> rules from the outside scope probably is a good idea. There are some tricky
>> areas in some of the details that need to be worked out, but it seems
>> realistic. I'm not thinking about it, but I see the use.
>
> I agree and I see that proposal as more important than named parameters and
> as independent of them.
>
I don't know if I agree that this is more important than named
parameters, but it is certainly of independent importance and use. (And
if a simpler named parameter solution is made, then it would be entirely
independent.)
I want to be able to have something like this:
namespace picture {
enum class Colour { red, blue, green };
void setBackground(Colour c);
}
void foo(void) {
picture::setBackground(green);
}
The easier it is to use stronger types, the more they will be used, and
more bugs will be caught at compile time.
--
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/prcate%24k7m%241%40blaine.gmane.org.
.
Author: David Brown <david@westcontrol.com>
Date: Wed, 31 Oct 2018 15:36:26 +0100
Raw View
On 31/10/18 12:34, Henry Miller wrote:
> I think that for the most part we under each other's point of view.
Did you mean "understand" here? Yes, I think so.
> If you write a proposal you need to be prepared to address this one.
> My purpose was in part to "play Devils advocate" to make sure that
> you have considered the alternatives.
Fair enough - Devil's advocates are essential.
>
> I'm working on collecting all of the arguments on both sides, with
> the idea that the committee should have a position on where we want
> to go.
>
> Just some minor things to correct below.
I've made a few comments to your comments, and snipped a bit for brevity.
>>> There is a great desire that if the code compiles it is correct.
>>>
>>
>> On that, I think we all agree!
(I just left that in because it is important :-) )
>>
>>
>>> Max(left: varShouldBeRight, right: varShouldBeLeft);
>>>
>>> This will compile, but is wrong.
>>
>> That claim makes no sense. Since the syntax does not exist today,
>> it is a matter of how it is implemented. Getting the parameter
>> order wrong will either be a compile-time error, or will be
>> accepted with parameter re-ordering - the jury is still out on
>> which is the best. Silently compiling the incorrect code is not
>> suggested by anyone - that is what we have today, and what we are
>> trying to get away from!
>>
>
> What I'm saying is that if your larger function has variables for
> left and right you can pass the wrong ones in with a named type.
>
Does this mean the same as your next example comment?
>> Given the declaration:
>>
>> max(int left, int right);
>>
>> and the call:
>>
>> max(right: 12, left: 20);
>>
>> then there are two acceptable options. One is a compile-time
>> error. The second is to treat the call exactly as if it had been
>> written:
>>
>> max(left: 20, right: 12) ;
>
> There is another option: the user meant
>
> max(left: 12, right: 20);
>
> Of course when you put a number right in the call like that you have
> little chance of correcting it.
No language change will prevent /all/ errors. We can only aim to reduce
some of them.
> However if you are passing variables
> that are initialized elsewhere, if you have strong types the entire
> code flow is more likely to force the right types.
>
True, but it also leads to a proliferation of types that makes things
awkward.
I have nothing against strong typing, I am looking for convenient and
simple ways to eliminate a large class of possible mistakes and improve
the self-documentation of code. To do that, the solution needs to be
simple and optional - something that can be easily used in parts of code
without affecting existing parts, and something that does not involve
significant extra effort or code lines.
>>
>>
>> Everything else is bike-shedding. People disagree on the syntax
>> for the declaration, or if the parameter information should be part
>> of the mangled name of the function, or if it should be possible to
>> have different names for the "named parameters" and the "formal
>> parameter" in the declaration or definition of the function. Some
>> people want to complicate matters with using names to overload
>> functions, others want to keep it simpler.
>
> True, but I belive that some of those are compelling things that
> cannot be done without named parameters, while named parameters alone
> is not compelling.
>
Named parameters makes it easier to write correct code, and harder to
write incorrect code, with the code being clearer to read and maintain,
compatible with existing code, and with very little extra effort when
writing it. To me, that is /absolutely/ compelling.
The other possibilities, such as using parameter names to overload
functions, are very minor. Yes, it would be nice to have a "Complex"
class take two floating point numbers, and have a convenient way of
distinguishing between x/y and r/theta parameters. But such use-cases
are rare, and they can be handled in other ways - tag types, and strong
types for parameters.
Common usage must be made as simple as possible, even if that means less
common usage is harder.
>>
>>
>> The fact is that most other good, modern programming languages
>> have named parameters. They can make the code clearer, and reduce
>> errors. It can be done in a simple, optional manner that will
>> suffice for the great majority of cases. And it is a frustrating
>> thing to see people arguing about the number of angels that can
>> dance on the head of this pin, instead of just making the clear and
>> obvious solution that people can use today.
>
> Yes, but if there are other ways to obtain the same end and those
> other ways produce some other gain that is "better", we should prefer
> the other ways.
>
I agree with your principle, but I think we disagree about how "better"
is defined here.
--
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/prceh7%2471m%241%40blaine.gmane.org.
.
Author: mutant.sheepdog@gmail.com
Date: Wed, 31 Oct 2018 14:45:07 -0700 (PDT)
Raw View
------=_Part_30_2019332349.1541022307239
Content-Type: multipart/alternative;
boundary="----=_Part_31_709293803.1541022307239"
------=_Part_31_709293803.1541022307239
Content-Type: text/plain; charset="UTF-8"
c++20 already has designated initializers which can do most of what is
needed from named arguments. About the only thing you could ask for is an
option to require people to set all the arguments if you really care about
that.
The following code compiles in clang with -std=c++2a
struct FnArgs
{
bool optionA = false;
bool optionB = false;
bool optionC = false;
};
void Fn(int requiredArg, FnArgs optionalArgs){}
int main()
{
// Setting all args by position:
Fn(0, {false, true, false});
// Setting all args with names:
Fn(0, {.optionA=false, .optionB=true, .optionC=false});
// Setting one named argument:
Fn(0, {.optionB=true});
// Setting no optional args:
Fn(0, {});
return 0;
}
--
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/caa51caf-2bf6-4720-8d4d-3dbe610eadb2%40isocpp.org.
------=_Part_31_709293803.1541022307239
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>c++20 already has designated initializers which can d=
o most of what is needed from named arguments. About the only thing you cou=
ld ask for is an option to require people to set all the arguments if you r=
eally care about that.</div><div>The following code compiles in clang with =
-std=3Dc++2a<br></div><div><span style=3D"font-family: courier new, monospa=
ce;"><br>struct FnArgs<br>{<br>=C2=A0=C2=A0=C2=A0 bool optionA =3D false;<b=
r>=C2=A0=C2=A0=C2=A0 bool optionB =3D false;<br>=C2=A0=C2=A0=C2=A0 bool opt=
ionC =3D false;<br>};<br>void Fn(int requiredArg, FnArgs optionalArgs){}<br=
><br>int main()<br>{<br>=C2=A0=C2=A0=C2=A0 // Setting all args by position:=
<br>=C2=A0=C2=A0=C2=A0 Fn(0, {false, true, false});<br><br>=C2=A0=C2=A0=C2=
=A0 // Setting all args with names:<br>=C2=A0=C2=A0=C2=A0 Fn(0, {.optionA=
=3Dfalse, .optionB=3Dtrue, .optionC=3Dfalse});<br><br>=C2=A0=C2=A0=C2=A0 //=
Setting one named argument:<br>=C2=A0=C2=A0=C2=A0 Fn(0, {.optionB=3Dtrue})=
;<br><br>=C2=A0=C2=A0=C2=A0 // Setting no optional args:<br>=C2=A0=C2=A0=C2=
=A0 Fn(0, {});<br><br>=C2=A0=C2=A0=C2=A0 return 0;<br>}</span></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/caa51caf-2bf6-4720-8d4d-3dbe610eadb2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/caa51caf-2bf6-4720-8d4d-3dbe610eadb2=
%40isocpp.org</a>.<br />
------=_Part_31_709293803.1541022307239--
------=_Part_30_2019332349.1541022307239--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Wed, 31 Oct 2018 18:00:00 -0400
Raw View
--00000000000024a18a05798d6dd1
Content-Type: text/plain; charset="UTF-8"
On Wed, Oct 31, 2018 at 5:45 PM <mutant.sheepdog@gmail.com> wrote:
> About the only thing you could ask for
>
I could ask for named argument association participating in overload
resolution,
which this does not give me. I could also ask to not have to change
function
definitions and declarations to be able to use named associations.
--
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/CAHSYqdYxPrBCgP9102m-N6VsoN87Quo6FC5UeybcL%2BqOde5vgw%40mail.gmail.com.
--00000000000024a18a05798d6dd1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Oct 31=
, 2018 at 5:45 PM <<a href=3D"mailto:mutant.sheepdog@gmail.com">mutant.s=
heepdog@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div>About the only thing you could ask for</div></div></blo=
ckquote><div><br>I could ask for named argument association participating i=
n overload resolution,<br>which this does not give me.=C2=A0 I could also a=
sk to not have to change function<br>definitions and declarations to be abl=
e to use named associations.</div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYxPrBCgP9102m-N6VsoN87Quo6FC5U=
eybcL%2BqOde5vgw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYxPrBCgP=
9102m-N6VsoN87Quo6FC5UeybcL%2BqOde5vgw%40mail.gmail.com</a>.<br />
--00000000000024a18a05798d6dd1--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Wed, 31 Oct 2018 22:08:41 +0000
Raw View
--000000000000ed1d5c05798d8b07
Content-Type: text/plain; charset="UTF-8"
What I like about this solution is that it makes a named-parameter API the
writer's choice, and people can easily create wrappers if they want to use
named parameters with a library that doesn't use them.
The primary reason I want to push for it to be chosen by the library
authors, rather than users, is because there are many legacy libraries with
*horrible* parameter naming conventions, and suddenly they're going to have
to change to thinking about carefully considering the names of parameters
in the same way that they would currently consider the names for methods.
It gives them time to plan their interfaces with the named parameter scheme
in mind - otherwise they would end up stuck with names they didn't really
think about, and changing them would be breaking.
Sure, it's not the biggest issue in the world, and I do have little
sympathy for people who don't write self-documenting interfaces, but I *do*
have sympathy for people who will have to use APIs with silly typos in
parameter names, and for the people who will have to keep replying to repo
issues reminding users that fixing a typo would be a breaking change.
On 31 Oct 2018 21:45, <mutant.sheepdog@gmail.com> wrote:
c++20 already has designated initializers which can do most of what is
needed from named arguments. About the only thing you could ask for is an
option to require people to set all the arguments if you really care about
that.
The following code compiles in clang with -std=c++2a
struct FnArgs
{
bool optionA = false;
bool optionB = false;
bool optionC = false;
};
void Fn(int requiredArg, FnArgs optionalArgs){}
int main()
{
// Setting all args by position:
Fn(0, {false, true, false});
// Setting all args with names:
Fn(0, {.optionA=false, .optionB=true, .optionC=false});
// Setting one named argument:
Fn(0, {.optionB=true});
// Setting no optional args:
Fn(0, {});
return 0;
}
--
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/caa51caf-2bf6-4720-8d4d-3dbe610eadb2%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/caa51caf-2bf6-4720-8d4d-3dbe610eadb2%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/CAC%2B0CCPAJ7Z%2BO3_8bnGxuqaXM1brzeChauJsVnGJSPuUjP7gMw%40mail.gmail.com.
--000000000000ed1d5c05798d8b07
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">What I like about this solution is that it makes a named-=
parameter API the writer's choice, and people can easily create wrapper=
s if they want to use named parameters with a library that doesn't use =
them.<div dir=3D"auto"><br></div><div dir=3D"auto">The primary reason I wan=
t to push for it to be chosen by the library authors, rather than users, is=
because there are many legacy libraries with *horrible* parameter naming c=
onventions, and suddenly they're going to have to change to thinking ab=
out carefully considering the names of parameters in the same way that they=
would currently consider the names for methods. It gives them time to plan=
their interfaces with the named parameter scheme in mind - otherwise they =
would end up stuck with names they didn't really think about, and chang=
ing them would be breaking.</div><div dir=3D"auto"><br></div><div dir=3D"au=
to">Sure, it's not the biggest issue in the world, and I do have little=
sympathy for people who don't write self-documenting interfaces, but I=
*do* have sympathy for people who will have to use APIs with silly typos i=
n parameter names, and for the people who will have to keep replying to rep=
o issues reminding users that fixing a typo would be a breaking change.</di=
v></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 31 Oct=
2018 21:45, <<a href=3D"mailto:mutant.sheepdog@gmail.com">mutant.sheep=
dog@gmail.com</a>> wrote:<br type=3D"attribution"><blockquote class=3D"q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div>c++20 already has designated initializers which ca=
n do most of what is needed from named arguments. About the only thing you =
could ask for is an option to require people to set all the arguments if yo=
u really care about that.</div><div>The following code compiles in clang wi=
th -std=3Dc++2a<br></div><div><span style=3D"font-family:courier new,monosp=
ace"><br>struct FnArgs<br>{<br>=C2=A0=C2=A0=C2=A0 bool optionA =3D false;<b=
r>=C2=A0=C2=A0=C2=A0 bool optionB =3D false;<br>=C2=A0=C2=A0=C2=A0 bool opt=
ionC =3D false;<br>};<br>void Fn(int requiredArg, FnArgs optionalArgs){}<br=
><br>int main()<br>{<br>=C2=A0=C2=A0=C2=A0 // Setting all args by position:=
<br>=C2=A0=C2=A0=C2=A0 Fn(0, {false, true, false});<br><br>=C2=A0=C2=A0=C2=
=A0 // Setting all args with names:<br>=C2=A0=C2=A0=C2=A0 Fn(0, {.optionA=
=3Dfalse, .optionB=3Dtrue, .optionC=3Dfalse});<br><br>=C2=A0=C2=A0=C2=A0 //=
Setting one named argument:<br>=C2=A0=C2=A0=C2=A0 Fn(0, {.optionB=3Dtrue})=
;<br><br>=C2=A0=C2=A0=C2=A0 // Setting no optional args:<br>=C2=A0=C2=A0=C2=
=A0 Fn(0, {});<br><br>=C2=A0=C2=A0=C2=A0 return 0;<br>}</span></div></div><=
div class=3D"quoted-text">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">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" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/caa51caf-2bf6-4720-8d4d-3dbe610eadb2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/caa51caf-2bf6-4720-8d4d-3dbe610eadb2%40isocpp.org</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" 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/CAC%2B0CCPAJ7Z%2BO3_8bnGxuqaXM1brzeCh=
auJsVnGJSPuUjP7gMw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPAJ7=
Z%2BO3_8bnGxuqaXM1brzeChauJsVnGJSPuUjP7gMw%40mail.gmail.com</a>.<br />
--000000000000ed1d5c05798d8b07--
.
Author: mutant.sheepdog@gmail.com
Date: Wed, 31 Oct 2018 18:33:35 -0700 (PDT)
Raw View
------=_Part_76_1288791001.1541036015867
Content-Type: multipart/alternative;
boundary="----=_Part_77_606416847.1541036015867"
------=_Part_77_606416847.1541036015867
Content-Type: text/plain; charset="UTF-8"
I feel very strongly about that too.
Automatically making argument names a part of the function lookup would
mean I wouldn't be able to easily fix any typos or style issues or anything
in parameter names without potentially breaking calling code. It would mean
I couldn't delete parameter names for things no longer needed or even
rename them 'unused'.
It would make it much harder to make things clearer unless you got
everything perfect the first time.
I do not get everything perfect the first time.
On these two points by Hyman:
"I could ask for named argument association participating in overload
resolution,
which this does not give me. I could also ask to not have to change
function
definitions and declarations to be able to use named associations."
While I disagree that they would be good for the language, if you wanted
them I'd suggest asking for anonymous structs to be implicitly created for
each function, and then have the overload rules look for structs that could
be created from the initialiser list.
By that I mean having:
void Fn(int arg1, int arg2, int arg3);
void Fn(int arg4, int arg5, int arg6);
and writing
Fn({.arg2 = 4});
would cause it to call the top function as 'arg2' only exists in the top
one meaning you get overload resolution.
Writing Fn({}); would be an ambiguous call in this case.
Again, I don't think it's a good change, but if you want automatic named
arguments for overload resolution it's perhaps a relatively minimal change.
On Thursday, 1 November 2018 09:08:50 UTC+11, Jake Arkinstall wrote:
> What I like about this solution is that it makes a named-parameter API the
> writer's choice, and people can easily create wrappers if they want to use
> named parameters with a library that doesn't use them.
>
> The primary reason I want to push for it to be chosen by the library
> authors, rather than users, is because there are many legacy libraries with
> *horrible* parameter naming conventions, and suddenly they're going to have
> to change to thinking about carefully considering the names of parameters
> in the same way that they would currently consider the names for methods.
> It gives them time to plan their interfaces with the named parameter scheme
> in mind - otherwise they would end up stuck with names they didn't really
> think about, and changing them would be breaking.
>
> Sure, it's not the biggest issue in the world, and I do have little
> sympathy for people who don't write self-documenting interfaces, but I *do*
> have sympathy for people who will have to use APIs with silly typos in
> parameter names, and for the people who will have to keep replying to repo
> issues reminding users that fixing a typo would be a breaking change.
>
> On 31 Oct 2018 21:45, <mutant....@gmail.com <javascript:>> wrote:
>
> c++20 already has designated initializers which can do most of what is
> needed from named arguments. About the only thing you could ask for is an
> option to require people to set all the arguments if you really care about
> that.
> The following code compiles in clang with -std=c++2a
>
> struct FnArgs
> {
> bool optionA = false;
> bool optionB = false;
> bool optionC = false;
> };
> void Fn(int requiredArg, FnArgs optionalArgs){}
>
> int main()
> {
> // Setting all args by position:
> Fn(0, {false, true, false});
>
> // Setting all args with names:
> Fn(0, {.optionA=false, .optionB=true, .optionC=false});
>
> // Setting one named argument:
> Fn(0, {.optionB=true});
>
> // Setting no optional args:
> Fn(0, {});
>
> return 0;
> }
>
> --
> 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/caa51caf-2bf6-4720-8d4d-3dbe610eadb2%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/caa51caf-2bf6-4720-8d4d-3dbe610eadb2%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/325b84b5-67f7-45b6-8221-e9463c28ac7d%40isocpp.org.
------=_Part_77_606416847.1541036015867
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I feel very strongly about that too.</div><div>Automa=
tically making argument names a part of the function lookup would mean I wo=
uldn't be able to easily fix any typos or style issues or anything in p=
arameter names without potentially breaking calling code. It would mean I c=
ouldn't delete parameter names for things no longer needed or even rena=
me them 'unused'.</div><div>It would make it much harder to make th=
ings clearer unless you got everything perfect the first time.</div><div>I =
do not get everything perfect the first time.</div><div><br></div><div><br>=
</div><div>On these two points by Hyman:<br>"I could ask for named arg=
ument association participating in overload resolution,<br>which this does =
not give me.=C2=A0 I could also ask to not have to change function<br>defin=
itions and declarations to be able to use named associations."</div><d=
iv><br></div><div>While I disagree that they would be good for the language=
, if you wanted them I'd suggest asking for anonymous structs to be imp=
licitly created for each function, and then have the overload rules look fo=
r structs that could be created from the initialiser list.</div><div><br></=
div><div>By that I mean having:</div><div>void Fn(int arg1, int arg2, int a=
rg3);<br>void Fn(int arg4, int arg5, int arg6);</div><div><br>and writing<b=
r>Fn({.arg2 =3D 4});<br><br>would cause it to call the top function as '=
;arg2' only exists in the top one meaning you get overload resolution.<=
br>Writing Fn({}); would be an ambiguous call in this case.<br><br>Again, I=
don't think it's a good change, but if you want automatic named ar=
guments for overload resolution it's perhaps a relatively minimal chang=
e.<br></div><div><br></div><div>On Thursday, 1 November 2018 09:08:50 UTC+1=
1, Jake Arkinstall wrote:</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"auto">What I like about this solution is that it makes a name=
d-parameter API the writer's choice, and people can easily create wrapp=
ers if they want to use named parameters with a library that doesn't us=
e them.<div dir=3D"auto"><br></div><div dir=3D"auto">The primary reason I w=
ant to push for it to be chosen by the library authors, rather than users, =
is because there are many legacy libraries with *horrible* parameter naming=
conventions, and suddenly they're going to have to change to thinking =
about carefully considering the names of parameters in the same way that th=
ey would currently consider the names for methods. It gives them time to pl=
an their interfaces with the named parameter scheme in mind - otherwise the=
y would end up stuck with names they didn't really think about, and cha=
nging them would be breaking.</div><div dir=3D"auto"><br></div><div dir=3D"=
auto">Sure, it's not the biggest issue in the world, and I do have litt=
le sympathy for people who don't write self-documenting interfaces, but=
I *do* have sympathy for people who will have to use APIs with silly typos=
in parameter names, and for the people who will have to keep replying to r=
epo issues reminding users that fixing a typo would be a breaking change.</=
div></div><div><br><div class=3D"gmail_quote">On 31 Oct 2018 21:45, <<a=
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"8lUY73R5Bg=
AJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';retur=
n true;" onclick=3D"this.href=3D'javascript:';return true;">mutant.=
....@gmail.com</a>> wrote:<br type=3D"attribution"><blockquote style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div>c++20 already has designated initializers which can do most of wha=
t is needed from named arguments. About the only thing you could ask for is=
an option to require people to set all the arguments if you really care ab=
out that.</div><div>The following code compiles in clang with -std=3Dc++2a<=
br></div><div><span style=3D"font-family:courier new,monospace"><br>struct =
FnArgs<br>{<br>=C2=A0=C2=A0=C2=A0 bool optionA =3D false;<br>=C2=A0=C2=A0=
=C2=A0 bool optionB =3D false;<br>=C2=A0=C2=A0=C2=A0 bool optionC =3D false=
;<br>};<br>void Fn(int requiredArg, FnArgs optionalArgs){}<br><br>int main(=
)<br>{<br>=C2=A0=C2=A0=C2=A0 // Setting all args by position:<br>=C2=A0=C2=
=A0=C2=A0 Fn(0, {false, true, false});<br><br>=C2=A0=C2=A0=C2=A0 // Setting=
all args with names:<br>=C2=A0=C2=A0=C2=A0 Fn(0, {.optionA=3Dfalse, .optio=
nB=3Dtrue, .optionC=3Dfalse});<br><br>=C2=A0=C2=A0=C2=A0 // Setting one nam=
ed argument:<br>=C2=A0=C2=A0=C2=A0 Fn(0, {.optionB=3Dtrue});<br><br>=C2=A0=
=C2=A0=C2=A0 // Setting no optional args:<br>=C2=A0=C2=A0=C2=A0 Fn(0, {});<=
br><br>=C2=A0=C2=A0=C2=A0 return 0;<br>}</span></div></div><div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" rel=3D"nofollow" target=3D"_blank" gdf-obfu=
scated-mailto=3D"8lUY73R5BgAJ" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" rel=3D"nofollo=
w" target=3D"_blank" gdf-obfuscated-mailto=3D"8lUY73R5BgAJ" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@isocpp.org</a>.<br></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/caa51caf-2bf6-4720-8d4d-3dbe610eadb2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/caa51caf-2bf6-4720-8d4d-3dbe610eadb2%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/caa51caf-2bf6-4720-8d4d-3dbe610eadb2%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/caa51caf-2bf6-4720-<wbr>8d4d-=
3dbe610eadb2%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/325b84b5-67f7-45b6-8221-e9463c28ac7d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/325b84b5-67f7-45b6-8221-e9463c28ac7d=
%40isocpp.org</a>.<br />
------=_Part_77_606416847.1541036015867--
------=_Part_76_1288791001.1541036015867--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Wed, 31 Oct 2018 23:14:59 -0400
Raw View
--000000000000a744ee057991d3c0
Content-Type: text/plain; charset="UTF-8"
On Wed, Oct 31, 2018 at 9:33 PM <mutant.sheepdog@gmail.com> wrote:
> I wouldn't be able to easily fix any typos or style issues or anything in
> parameter names without potentially breaking calling code.
>
It would mean I couldn't delete parameter names for things no longer needed
> or even rename them 'unused'.
> It would make it much harder to make things clearer unless you got
> everything perfect the first time.
>
It's no different than for any other publicly visible names.
You have to get function names, type names, and enumeration literals right.
You can't change them once they're out in the wild without breaking user
code.
So parameter names get to join the club. No big deal.
I'd suggest asking for anonymous structs to be implicitly created for each
> function,
>
and then have the overload rules look for structs that could be created
> from the initialiser list.
>
What does this get me that plain named argument association doesn't?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqda1PeyqNLGU%2B7sBd65CqKGBHk2wuxFOWTJpzaA8vW9M%3DQ%40mail.gmail.com.
--000000000000a744ee057991d3c0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Oct 31=
, 2018 at 9:33 PM <<a href=3D"mailto:mutant.sheepdog@gmail.com">mutant.s=
heepdog@gmail.com</a>> wrote:</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div>I wouldn't be able to easily fix any typos or style iss=
ues or anything in parameter names without potentially breaking calling cod=
e.</div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div>It would mean I couldn't delete parameter names for things no long=
er needed or even rename them 'unused'.</div><div>It would make it =
much harder to make things clearer unless you got everything perfect the fi=
rst time.</div></div></blockquote><div><br></div><div>It's no different=
than for any other publicly visible names.<br>You have to get function nam=
es, type names, and enumeration literals right.<br>You can't change the=
m once they're out in the wild without breaking user code.<br>So parame=
ter names get to join the club.=C2=A0 No big deal.<br><br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div>I'd suggest asking for anonym=
ous structs to be implicitly created for each function,=C2=A0</div></div></=
blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div> and then h=
ave the overload rules look for structs that could be created from the init=
ialiser list.</div></div></blockquote><div><br>What does this get me that p=
lain named argument association doesn't?</div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqda1PeyqNLGU%2B7sBd65CqKGBHk2wux=
FOWTJpzaA8vW9M%3DQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqda1Peyq=
NLGU%2B7sBd65CqKGBHk2wuxFOWTJpzaA8vW9M%3DQ%40mail.gmail.com</a>.<br />
--000000000000a744ee057991d3c0--
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Thu, 1 Nov 2018 09:01:12 +0100
Raw View
On Wed, Oct 31, 2018 at 11:14:59PM -0400, Hyman Rosen wrote:
> On Wed, Oct 31, 2018 at 9:33 PM <mutant.sheepdog@gmail.com> wrote:
>
> > I wouldn't be able to easily fix any typos or style issues or anything in
> > parameter names without potentially breaking calling code.
> >
> It would mean I couldn't delete parameter names for things no longer needed
> > or even rename them 'unused'.
> > It would make it much harder to make things clearer unless you got
> > everything perfect the first time.
> >
>
> It's no different than for any other publicly visible names.
> You have to get function names, type names, and enumeration literals right.
> You can't change them once they're out in the wild without breaking user
> code.
> So parameter names get to join the club. No big deal.
This is where we disagree - i think it is a big deal since it will set in
stone something that up til now was only an implementation detail with no
warning.
/MF
--
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/20181101080112.GA4888%40noemi.
.
Author: David Brown <david@westcontrol.com>
Date: Thu, 01 Nov 2018 12:28:09 +0100
Raw View
On 31/10/18 23:08, Jake Arkinstall wrote:
> What I like about this solution is that it makes a named-parameter API
> the writer's choice, and people can easily create wrappers if they want
> to use named parameters with a library that doesn't use them.
Interesting. One of the things I don't like about this syntax is that
it makes it the API writer's choice, and people have to create wrappers
to use it with existing code.
(I also don't like the ugly separation of the parameters from rest of
the function declaration - it's a step back towards K&R C functions. I
don't like the need to define an extra name for the parameters, I don't
like the inefficiency involved in dealing with a struct instead of
individual parameters, and I don't like the extra code needed in the
function definition.)
Designated initialisers have existed in C for decades, but are rarely
used for named parameters. Why would anyone think they would be popular
as a named parameter solution in C++?
>
> The primary reason I want to push for it to be chosen by the library
> authors, rather than users, is because there are many legacy libraries
> with *horrible* parameter naming conventions, and suddenly they're going
> to have to change to thinking about carefully considering the names of
> parameters in the same way that they would currently consider the names
> for methods. It gives them time to plan their interfaces with the named
> parameter scheme in mind - otherwise they would end up stuck with names
> they didn't really think about, and changing them would be breaking.
Make the parameter names part of the /declaration/, not the function
definition.
The function can be defined as :
void foo(int __a, int __b, int __c) { .... }
(This sort of thing is common in standard headers - you can't use a
parameter name like "width" in case someone has written "#define width
123" before including the header.)
If the last declaration visible at the call site is
void foo(int top, int bottom, int width);
then the named parameters used by the call would be "top", "bottom" and
"width".
Compilers could have a warning to check that the parameter names in a
definition match those in declarations - you'd use that on your own
code, but not for standard library headers.
And if you have a library with unhelpful parameter names, but you want
nicer ones, all you need is a header with new declarations - not wrappers.
--
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/prens6%241ep%241%40blaine.gmane.org.
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Thu, 1 Nov 2018 13:13:47 +0000
Raw View
--000000000000c6300605799a308a
Content-Type: text/plain; charset="UTF-8"
On Thu, 1 Nov 2018, 11:28 David Brown <david@westcontrol.com wrote:
>
>
> Designated initialisers have existed in C for decades, but are rarely
> used for named parameters. Why would anyone think they would be popular
> as a named parameter solution in C++?
>
C function overloading isn't as trivial as C++ function overloading. They'd
have to manually create new functions with different names.
Make the parameter names part of the /declaration/, not the function
> definition.
>
This doesnt solve anything. They can name the members in their definition
whatever they want (unless there are two overloads with the same
signature...), but it's the declaration that is exposed. Modifying the
declaration is a breaking change if parameter names matter.
>
--
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/CAC%2B0CCNjzETCg6tgMeq2WG0yYUbSFFsfNLFsmo%3D3J-b0zPkaGA%40mail.gmail.com.
--000000000000c6300605799a308a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
On Thu, 1 Nov 2018, 11:28 David Brown <<a href=3D"mailto:david@westcontr=
ol.com" target=3D"_blank" rel=3D"noreferrer">david@westcontrol.com</a> wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">=C2=A0<br>
<br>
Designated initialisers have existed in C for decades, but are rarely<br>
used for named parameters.=C2=A0 Why would anyone think they would be popul=
ar<br>
as a named parameter solution in C++?<br></blockquote></div></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">C function overloading isn't as t=
rivial as C++ function overloading. They'd have to manually create new =
functions with different names.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Make th=
e parameter names part of the /declaration/, not the function<br>
definition.<br></blockquote></div></div><div dir=3D"auto"><br></div><div di=
r=3D"auto">This doesnt solve anything. They can name the members in their d=
efinition whatever they want (unless there are two overloads with the same =
signature...), but it's the declaration that is exposed. Modifying the =
declaration is a breaking change if parameter names matter.</div><div dir=
=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNjzETCg6tgMeq2WG0yYUbSFFsfNL=
Fsmo%3D3J-b0zPkaGA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNjzE=
TCg6tgMeq2WG0yYUbSFFsfNLFsmo%3D3J-b0zPkaGA%40mail.gmail.com</a>.<br />
--000000000000c6300605799a308a--
.
Author: David Brown <david@westcontrol.com>
Date: Thu, 01 Nov 2018 15:41:33 +0100
Raw View
On 01/11/18 14:13, Jake Arkinstall wrote:
>
>
> On Thu, 1 Nov 2018, 11:28 David Brown <david@westcontrol.com
> <mailto:david@westcontrol.com> wrote:
>
>
>
> Designated initialisers have existed in C for decades, but are rarely
> used for named parameters. Why would anyone think they would be popular
> as a named parameter solution in C++?
>
>
> C function overloading isn't as trivial as C++ function overloading.
> They'd have to manually create new functions with different names.
True, but irrelevant. The main points of named parameters is to make it
easier to write correct code, harder to write incorrect code, and make
the code you write clearer, more "self-documenting" and safer in
maintenance. This applies whether functions are overloaded or not.
(Overloading based on parameter names is an additional feature some
people want - I am moving towards strongly disapproving of that idea, as
a serious hinder to making a clean and simple named parameter system.)
>
> Make the parameter names part of the /declaration/, not the function
> definition.
>
>
> This doesnt solve anything. They can name the members in their
> definition whatever they want (unless there are two overloads with the
> same signature...), but it's the declaration that is exposed. Modifying
> the declaration is a breaking change if parameter names matter.
>
Yes, that is correct. And it is a /good/ thing. When someone changes
the declaration from "foo(int x, int y)" to "foo(int y, int x)", I will
be /glad/ that my compilation breaks.
--
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/prf36q%24mnh%241%40blaine.gmane.org.
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Thu, 1 Nov 2018 15:57:06 +0100
Raw View
--000000000000928abc05799ba2bc
Content-Type: text/plain; charset="UTF-8"
I am always amazed at the reaction by the c++ community when presented with
the idea of obviously useful language features.
C++ people seem to be unique amongst programmers in resisting progress for
the most pedantic of reasons.
Almost every other popular programming language has named parameters,
asynchronous primitives, featureful libraries, and so on.
All implemented without fuss, very short deprecation times, often there is
breakage between versions. This would be an anathema in the c++ world, and
yet we see no tantrums by java, swift, c#, javascript or python developers
because the implementation of a new feature has required them to refactor a
couple of functions in their code base. They just convert their code and
move on without fuss.
Why are c++ people so determined to argue the minutiae of every irrelevant
detail? Boost moves forward at a good pace, sometimes making logical
mistakes, sometimes rectifying them, while maintaining good backward
compatibility and great take-up and support by the dev community.
I have personally been adapting some code to the new features in ASIO -
it's frankly a pleasure to dump the old code and replace it with the new.
Anyone who has ever written an ASIO service or compound operation with
correct handler execution semantics will know *exactly* what I mean.
Apple's Swift is another example. It's been though, what, 3 iterations now,
with breakage each time? The developers love it (I would personally argue
that it's awful and just a bit better than objective-c, but who am I to
disagree with a global developer community?).
It absolutely stuns and dismays me that standard c++ cannot bring itself to
innovate at this pace.
As for named parameters - it's obviously useful. The compiler has full
visibility of the names (if any) in the declaration. There need be no ABI
breakage at all and no rearranging of argument evaluation order. Simply
match un-named arguments in order of appearance and then named arguments to
the names in the declaration. If there's a logical mismatch, e.g. an
argument has been passed in the un-named set and the named set, it's an
error. Not hard, requires nothing more than a tinkering in the compiler.
Zero breakage with old code. We literally get extra expressiveness for free.
If you want more compile-time checking than that, use custom types. While
we're at it, a std::tagged_value template would go a long way towards *helping
developers to write type-safe code* without ten thousand lines of
boilerplate template effort to cover all the corner cases inherent in this
kind of thing. Anyone who's ever written their own tagged_value (and let's
face it, who hasn't!) understands all too well how hard it is to cover the
bases. If it's this hard, it needs a language feature or at least the
standard library to do it for us. This is just painfully obvious.
Programming languages are there to allow us to express intent. C++ should
be there to allow us to express intent and get close to perfect assembler
as a result. Writing our own template boilerplate is about as productive as
writing assembly language. I stopped doing that commercially 25 years ago
(it would have been 30 years ago, but for reasons of cost I had to reverse
engineer and recycle legacy hardware).
The above (more or less) has worked for python for longer than many here
have been able to write code. No-one complains about it. Who cares about
the irrelevant details of exactly what the syntax should be at the call
site? As long as it's reasonably easy to read and type, people will get
used to it.
Fellow "close to the machine" enthusiasts, we have before us, just outside
our windows, two billion years of evidence which serves only to reinforce
the truth we all know - *In the face of new technology and challenges, you
will adapt, and adapt quickly, or you will die*.
C++ is no different. We all want perfect runtime machine code. Our
employers will not wait for us to argue about how we get it. They will
simply insist that we use something less argumentative, regardless of our
protestations that the indeterminate nature of garbage collection sucks, or
that we won't benefit from RAII. That means nothing in the business world.
Investors and business managers almost always want stuff they can sell -
fast (possible exceptions would be aerospace, but then again I know a guy
who used to write spaceship code in java - who knew?).
I speak as a business owner, who would much prefer to see c++ as the
primary language of our business, but who has been forced to accept that in
anything other than the most rarified industry, the current state of the
art is not cost-effective.
At the root of this is the failure of the language and its custodians to
adapt to the evolution of human understanding about software systems. I
strongly believe that the failure to adapt is directly attributable to the
fact that when young enthusiastic developers want to offer an improvement
to the language, they just bounce off the adamantine wall of intransigence
exhibited, in part, in mailing lists such as this one.
It's a terrible shame to waste all that talent and positive enthusiasm.
R
On Thu, 1 Nov 2018 at 14:13, Jake Arkinstall <jake.arkinstall@gmail.com>
wrote:
>
>
> On Thu, 1 Nov 2018, 11:28 David Brown <david@westcontrol.com wrote:
>
>>
>>
>> Designated initialisers have existed in C for decades, but are rarely
>> used for named parameters. Why would anyone think they would be popular
>> as a named parameter solution in C++?
>>
>
> C function overloading isn't as trivial as C++ function overloading.
> They'd have to manually create new functions with different names.
>
> Make the parameter names part of the /declaration/, not the function
>> definition.
>>
>
> This doesnt solve anything. They can name the members in their definition
> whatever they want (unless there are two overloads with the same
> signature...), but it's the declaration that is exposed. Modifying the
> declaration is a breaking change if parameter names matter.
>
>> --
> 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/CAC%2B0CCNjzETCg6tgMeq2WG0yYUbSFFsfNLFsmo%3D3J-b0zPkaGA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNjzETCg6tgMeq2WG0yYUbSFFsfNLFsmo%3D3J-b0zPkaGA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
Richard Hodges
hodges.r@gmail.com
office: +442032898513
home: +376841522
mobile: +376380212 (this will be *expensive* outside Andorra!)
skype: madmongo
facebook: hodges.r
--
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/CALvx3hbc7YkuFMB54RmxaQ1JdX77aAcnLckFX5M0_9pgXuxy8w%40mail.gmail.com.
--000000000000928abc05799ba2bc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I am always amazed at the reaction by the c++ community wh=
en presented with the idea of obviously useful language features.<div><br><=
/div><div>C++ people seem to be unique amongst programmers in resisting pro=
gress for the most pedantic of reasons.</div><div><br></div><div>Almost eve=
ry other popular programming language has named parameters, asynchronous pr=
imitives, featureful libraries, and so on.</div><div><br></div><div>All imp=
lemented without fuss, very short deprecation times, often there is breakag=
e between versions. This would be an anathema in the c++ world, and yet we =
see no tantrums by java, swift, c#, javascript or python developers because=
the implementation of a new feature has required them to refactor a couple=
of functions in their code base. They just convert their code and move on =
without fuss.=C2=A0</div><div><br></div><div>Why are c++ people so determin=
ed to argue the minutiae of every irrelevant detail? Boost moves forward at=
a good pace, sometimes making logical mistakes, sometimes rectifying them,=
while maintaining good backward compatibility and great take-up and suppor=
t by the dev community.=C2=A0</div><div><br></div><div>I have personally be=
en adapting some code to the new features in ASIO - it's frankly a plea=
sure to dump the old code and replace it with the new. Anyone who has ever =
written an ASIO service or compound operation with correct handler executio=
n semantics will know <u>exactly</u> what I mean.=C2=A0</div><div><br></div=
><div>Apple's Swift is another example. It's been though, what, 3 i=
terations now, with breakage each time? The developers love it (I would per=
sonally argue that it's awful and just a bit better than objective-c, b=
ut who am I to disagree with a global developer community?).=C2=A0</div><di=
v><br></div><div>It absolutely stuns and dismays me that standard c++ canno=
t bring itself to innovate at this pace.</div><div><br></div><div>As for na=
med parameters - it's obviously useful. The compiler has full visibilit=
y of the names (if any) in the declaration. There need be no ABI breakage a=
t all and no rearranging of argument evaluation order. Simply match un-name=
d arguments in order of appearance and then named arguments to the names in=
the declaration.=C2=A0 If there's a logical mismatch, e.g. an argument=
has been passed in the un-named set and the named set, it's an error. =
Not hard, requires nothing more than a tinkering in the compiler. Zero brea=
kage with old code. We literally get extra expressiveness for free.</div><d=
iv><br></div><div>If you want more compile-time checking than that, use cus=
tom types. While we're at it, a <font face=3D"monospace, monospace">std=
::tagged_value</font> template would go a long way towards <u>helping devel=
opers=C2=A0to write type-safe code</u> without ten thousand lines of boiler=
plate template effort to cover all the corner cases inherent in this kind o=
f thing. Anyone who's ever written their own tagged_value (and let'=
s face it, who hasn't!) understands all too well how hard it is to cove=
r the bases. If it's this hard, it needs a language feature or at least=
the standard library to do it for us. This is just painfully obvious. Prog=
ramming languages are there to allow us to express intent. C++ should be th=
ere to allow us to express intent and get close to perfect assembler as a r=
esult. Writing our own template boilerplate is about as productive as writi=
ng assembly language. I stopped doing that commercially 25 years ago (it wo=
uld have been 30 years ago, but for reasons of cost I had to reverse engine=
er and recycle legacy hardware).<br><br>The above (more or less) has worked=
for python for longer than many here have been able to write code. No-one =
complains about it. Who cares about the irrelevant details of exactly what =
the syntax should be at the call site? As long as it's reasonably easy =
to read and type, people will get used to it.<br><br>Fellow "close to =
the machine" enthusiasts, we have before us, just outside our windows,=
two billion years of evidence which serves only to reinforce the truth we =
all know - <i>In the face of new technology and challenges, you will adapt,=
and adapt quickly, or you will die</i>.</div><div><br></div><div>C++ is no=
different. We all want perfect runtime machine code. Our employers will no=
t wait for us to argue about how we get it. They will simply insist that we=
use something less argumentative, regardless of our protestations that the=
indeterminate nature of garbage collection sucks, or that we won't ben=
efit from RAII. That means nothing in the business world. Investors and bus=
iness managers almost always want stuff they can sell - fast (possible exce=
ptions would be aerospace, but then again I know a guy who used to write sp=
aceship code in java - who knew?).</div><div><br></div><div>I speak as a bu=
siness owner, who would much prefer to see c++ as the primary language of o=
ur business, but who has been forced to accept that in anything other than =
the most rarified industry, the current state of the art is not cost-effect=
ive.<br><br>At the root of this is the failure of the language and its cust=
odians to adapt to the evolution of human understanding about software syst=
ems. I strongly believe that the failure to adapt is directly attributable =
to the fact that when young enthusiastic developers want to offer an improv=
ement to the language, they just bounce off the adamantine wall of intransi=
gence exhibited, in part, in mailing lists such as this one.<br><br>It'=
s a terrible shame to waste all that talent and positive enthusiasm.<br><br=
>R</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, 1 Nov=
2018 at 14:13, Jake Arkinstall <<a href=3D"mailto:jake.arkinstall@gmail=
..com">jake.arkinstall@gmail.com</a>> wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><di=
v dir=3D"ltr">On Thu, 1 Nov 2018, 11:28 David Brown <<a href=3D"mailto:d=
avid@westcontrol.com" rel=3D"noreferrer" target=3D"_blank">david@westcontro=
l.com</a> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=C2=A0<br>
<br>
Designated initialisers have existed in C for decades, but are rarely<br>
used for named parameters.=C2=A0 Why would anyone think they would be popul=
ar<br>
as a named parameter solution in C++?<br></blockquote></div></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">C function overloading isn't as t=
rivial as C++ function overloading. They'd have to manually create new =
functions with different names.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Make th=
e parameter names part of the /declaration/, not the function<br>
definition.<br></blockquote></div></div><div dir=3D"auto"><br></div><div di=
r=3D"auto">This doesnt solve anything. They can name the members in their d=
efinition whatever they want (unless there are two overloads with the same =
signature...), but it's the declaration that is exposed. Modifying the =
declaration is a breaking change if parameter names matter.</div><div dir=
=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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/CAC%2B0CCNjzETCg6tgMeq2WG0yYUbSFFsfNL=
Fsmo%3D3J-b0zPkaGA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CAC%2B0CCNjzETCg6tgMeq2WG0yYUbSFFsfNLFsmo%3D3J-b0zPkaGA%40mail.gma=
il.com</a>.<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"l=
tr">Richard Hodges<div><a href=3D"mailto:hodges.r@gmail.com" target=3D"_bla=
nk">hodges.r@gmail.com</a></div><div>office: +442032898513</div><div>home: =
+376841522</div><div>mobile:=C2=A0+376380212 (this will be *expensive* outs=
ide Andorra!)</div><div>skype: madmongo</div><div>facebook: hodges.r</div><=
div><br></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hbc7YkuFMB54RmxaQ1JdX77aAcnLckF=
X5M0_9pgXuxy8w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hbc7YkuFMB5=
4RmxaQ1JdX77aAcnLckFX5M0_9pgXuxy8w%40mail.gmail.com</a>.<br />
--000000000000928abc05799ba2bc--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 1 Nov 2018 17:51:34 +0200
Raw View
On Thu, 1 Nov 2018 at 16:57, Richard Hodges <hodges.r@gmail.com> wrote:
> Apple's Swift is another example. It's been though, what, 3 iterations no=
w, with breakage each time? The developers love it (I would personally argu=
e that it's awful and just a bit better than objective-c, but who am I to d=
isagree with a global developer community?).
There was fair amounts of complaints about those breakages among Swift
developers.
> The above (more or less) has worked for python for longer than many here =
have been able to write code. No-one complains about it. Who cares about th=
e irrelevant details of exactly what the syntax should be at the call site?=
As long as it's reasonably easy to read and type, people will get used to =
it.
Which part of it exactly worked for python? The python 2/3 split
caused heavy friction.
If you want named parameters,
1) make them be declared, not automatically nameable
2) don't make it part of the ABI
3) don't try to introduce overloading by parameter name
and you have a chance of getting most of what you want, for those who
indeed want it. Try to insist on something different,
and be prepared for getting what you have now, i.e. nothing. In case
you insist on something different, then your claim
that how to do it is obvious is, well, obviously false.
--=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/CAFk2RUa3OVbiZFYD4k4WHe%3D7hD0mFOKPLGMqcEVj109FQ=
dhF4w%40mail.gmail.com.
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Thu, 1 Nov 2018 18:03:08 -0400
Raw View
--0000000000002da2de0579a19638
Content-Type: text/plain; charset="UTF-8"
On Thu, Nov 1, 2018 at 11:51 AM Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> 2) don't make it part of the ABI
> 3) don't try to introduce overloading by parameter name
>
Just wanted to mention that overloading by parameter name (Ada style)
does not mean that functions can have the same signature - they still have
to be unique. That is, you can do
void f(int a, int b = 0);
void f(int c);
and use parameter names to distinguish f(a => 0) from f(c => 0) but you
can't do
void f(int a);
void f(int b);
and have those be different functions. That's part of not changing 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/CAHSYqdaXi_%2Bi6n1yk9tjPxsMZ%2BUdjfJV3zDJ8etnO9zBRPW5Ag%40mail.gmail.com.
--0000000000002da2de0579a19638
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Nov 1,=
2018 at 11:51 AM Ville Voutilainen <<a href=3D"mailto:ville.voutilainen=
@gmail.com">ville.voutilainen@gmail.com</a>> wrote:</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
2) don't make it part of the ABI<br>
3) don't try to introduce overloading by parameter name<br></blockquote=
><div><br>Just wanted to mention that overloading by parameter name (Ada st=
yle)<br>does not mean that functions can have the same signature - they sti=
ll have<br>to be unique.=C2=A0 That is, you can do<br><font face=3D"monospa=
ce, monospace">=C2=A0 =C2=A0 void f(int a, int b =3D 0);<br>=C2=A0 =C2=A0 v=
oid f(int c);</font><br>and use parameter names to distinguish <font face=
=3D"monospace, monospace">f(a =3D> 0)</font> from <font face=3D"monospac=
e, monospace">f(c =3D> 0)</font> but you can't do<br><font face=3D"m=
onospace, monospace">=C2=A0 =C2=A0 void f(int a);<br>=C2=A0 =C2=A0 void f(i=
nt b);</font><br>and have those be different functions.=C2=A0 That's pa=
rt of not changing the ABI.<br></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaXi_%2Bi6n1yk9tjPxsMZ%2BUdjfJV=
3zDJ8etnO9zBRPW5Ag%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaXi_%2=
Bi6n1yk9tjPxsMZ%2BUdjfJV3zDJ8etnO9zBRPW5Ag%40mail.gmail.com</a>.<br />
--0000000000002da2de0579a19638--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Thu, 1 Nov 2018 23:12:59 +0100
Raw View
--0000000000006adeb70579a1b98a
Content-Type: text/plain; charset="UTF-8"
On Thu, 1 Nov 2018 at 16:51, Ville Voutilainen <ville.voutilainen@gmail.com>
wrote:
> On Thu, 1 Nov 2018 at 16:57, Richard Hodges <hodges.r@gmail.com> wrote:
> > Apple's Swift is another example. It's been though, what, 3 iterations
> now, with breakage each time? The developers love it (I would personally
> argue that it's awful and just a bit better than objective-c, but who am I
> to disagree with a global developer community?).
>
> There was fair amounts of complaints about those breakages among Swift
> developers.
>
> > The above (more or less) has worked for python for longer than many here
> have been able to write code. No-one complains about it. Who cares about
> the irrelevant details of exactly what the syntax should be at the call
> site? As long as it's reasonably easy to read and type, people will get
> used to it.
>
> Which part of it exactly worked for python? The python 2/3 split
> caused heavy friction.
>
> If you want named parameters,
>
> 1) make them be declared, not automatically nameable
> 2) don't make it part of the ABI
> 3) don't try to introduce overloading by parameter name
>
> and you have a chance of getting most of what you want, for those who
> indeed want it. Try to insist on something different,
> and be prepared for getting what you have now, i.e. nothing. In case
> you insist on something different, then your claim
> that how to do it is obvious is, well, obviously false.
>
>
I think unfortunately you underscore my point - there is only negativity in
this response. The community (at least this part of it) wants progress,
rather than reasons why progress is not possible.
Not just with the triviality of named parameters. It is currently not
possible to express any more than the most basic intent in C++. C++
remains, after 30 years, basically an auto-optimising macro assembler. This
is not good enough to survive the rigours of the modern world.
Yes, we want low level control. And yes, we need to be able to express
intent more naturally.
There are different levels of importance of course. Being unable to name
parameters at the call site is an inconvenience. Being unable to express
asynchronous flow control in terms of logically linear code is a nail in
the coffin for c++ as a server language.
> --
> 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/CAFk2RUa3OVbiZFYD4k4WHe%3D7hD0mFOKPLGMqcEVj109FQdhF4w%40mail.gmail.com
> .
>
--
Richard Hodges
hodges.r@gmail.com
office: +442032898513
home: +376841522
mobile: +376380212 (this will be *expensive* outside Andorra!)
skype: madmongo
facebook: hodges.r
--
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/CALvx3hZD8YMXKbf6CbwD26O5CSH%3DJ%3DQkGJif_hssm8Rud%2BSjaw%40mail.gmail.com.
--0000000000006adeb70579a1b98a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu=
, 1 Nov 2018 at 16:51, Ville Voutilainen <<a href=3D"mailto:ville.voutil=
ainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.com</a>> wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">On Thu, 1 Nov 2018 at 16:57, Ric=
hard Hodges <<a href=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hod=
ges.r@gmail.com</a>> wrote:<br>
> Apple's Swift is another example. It's been though, what, 3 it=
erations now, with breakage each time? The developers love it (I would pers=
onally argue that it's awful and just a bit better than objective-c, bu=
t who am I to disagree with a global developer community?).<br>
<br>
There was fair amounts of complaints about those breakages among Swift<br>
developers.<br>
<br>
> The above (more or less) has worked for python for longer than many he=
re have been able to write code. No-one complains about it. Who cares about=
the irrelevant details of exactly what the syntax should be at the call si=
te? As long as it's reasonably easy to read and type, people will get u=
sed to it.<br>
<br>
Which part of it exactly worked for python? The python 2/3 split<br>
caused heavy friction.<br>
<br>
If you want named parameters,<br>
<br>
1) make them be declared, not automatically nameable<br>
2) don't make it part of the ABI<br>
3) don't try to introduce overloading by parameter name<br>
<br>
and you have a chance of getting most of what you want, for those who<br>
indeed want it. Try to insist on something different,<br>
and be prepared for getting what you have now, i.e. nothing. In case<br>
you insist on something different, then your claim<br>
that how to do it is obvious is, well, obviously false.<br>
<br></blockquote><div><br></div><div>I think unfortunately you underscore m=
y point - there is only negativity in this response. The community (at leas=
t this part of it) wants progress, rather than reasons why progress is not =
possible.</div><div><br></div><div>Not just with the triviality of named pa=
rameters. It is currently not possible to express any more than the most ba=
sic intent in C++. C++ remains, after 30 years, basically an auto-optimisin=
g macro assembler. This is not good enough to survive the rigours of the mo=
dern world.</div><div><br></div><div>Yes, we want low level control. And ye=
s, we need to be able to express intent more naturally.=C2=A0</div><div><br=
></div><div>There are different levels of importance of course. Being unabl=
e to name parameters at the call site is an inconvenience. Being unable to =
express asynchronous flow control in terms of logically linear code is a na=
il in the coffin for c++ as a server language.</div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex">
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@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/CAFk2RUa3OVbiZFYD4k4WHe%3D7hD0mFOKPLG=
MqcEVj109FQdhF4w%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUa3OVbiZFYD=
4k4WHe%3D7hD0mFOKPLGMqcEVj109FQdhF4w%40mail.gmail.com</a>.<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
class=3D"m_-7373997238181907322gmail_signature" data-smartmail=3D"gmail_si=
gnature"><div dir=3D"ltr">Richard Hodges<div><a href=3D"mailto:hodges.r@gma=
il.com" target=3D"_blank">hodges.r@gmail.com</a></div><div>office: +4420328=
98513</div><div>home: +376841522</div><div>mobile:=C2=A0+376380212 (this wi=
ll be *expensive* outside Andorra!)</div><div>skype: madmongo</div><div>fac=
ebook: hodges.r</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" 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/CALvx3hZD8YMXKbf6CbwD26O5CSH%3DJ%3DQk=
GJif_hssm8Rud%2BSjaw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZD8Y=
MXKbf6CbwD26O5CSH%3DJ%3DQkGJif_hssm8Rud%2BSjaw%40mail.gmail.com</a>.<br />
--0000000000006adeb70579a1b98a--
.
Author: Balog Pal <pasa@lib.hu>
Date: Fri, 2 Nov 2018 08:17:26 -0700 (PDT)
Raw View
------=_Part_901_282851862.1541171846206
Content-Type: multipart/alternative;
boundary="----=_Part_902_234429908.1541171846206"
------=_Part_902_234429908.1541171846206
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
2018. november 1., cs=C3=BCt=C3=B6rt=C3=B6k 23:13:14 UTC+1 id=C5=91pontban =
Richard Hodges a=20
k=C3=B6vetkez=C5=91t =C3=ADrta:
>
>
>
> On Thu, 1 Nov 2018 at 16:51, Ville Voutilainen <ville.vo...@gmail.com=20
> <javascript:>> wrote:
>
>> (...) If you want named parameters,
>>
>> 1) make them be declared, not automatically nameable
>> 2) don't make it part of the ABI
>> 3) don't try to introduce overloading by parameter name
>>
>> and you have a chance of getting most of what you want, for those who
>> indeed want it. Try to insist on something different,
>> and be prepared for getting what you have now, i.e. nothing. In case
>> you insist on something different, then your claim
>> that how to do it is obvious is, well, obviously false.
>>
>>
> I think unfortunately you underscore my point - there is only negativity=
=20
> in this response. The community (at least this part of it) wants progress=
,=20
> rather than reasons why progress is not possible.
>
Hmm. I'm almost hearing Ville saying hos usual "I'm just stating the FACT".=
=20
The negativity is only your observation. Try to read the text as it was=20
put: as helpful guiding. If your aim is rally related to the functionality=
=20
and its getting into C++, not just moaning or/or bashing the people who=20
contribute to the standard.
The idea was discussed in public a lot and even at the committee level=20
several times. In great detail too. It did not progress because the=20
concerns were not addressed by the proposers, and the verdict was that the=
=20
benefits fall short. It was not done out of sloth or malice, just through=
=20
simple technical evaluation.=20
Above, Ville summarized the road that lead to the dead end, and even=20
pointed to directions where it DOES have a fighting chance. If you did your=
=20
homework and read up all the history you'd probably arrived to similar=20
conclusions.=20
=20
> Not just with the triviality of named parameters.
>
Well, just reading the last discussion N4172_Named_Function_Arguments=20
discussion=20
<http://wiki.edg.com/bin/view/Wg21urbana-champaign/FunctionFacilities#N4172=
_Named_Function_Arguments> =20
it is pretty far from trivial. Ant there is a lot more just following the=
=20
links from posts 2 and 3 of this topic and their references.=20
It is currently not possible to express any more than the most basic intent=
=20
> in C++. C++ remains, after 30 years, basically an auto-optimising macro=
=20
> assembler. This is not good enough to survive the rigours of the modern=
=20
> world.
>
Well, everyone is entitled to have their opinion, I know a plenty of folks=
=20
who see it a different way.=20
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/46a88b60-7f08-45fb-bbad-30f5be27d28f%40isocpp.or=
g.
------=_Part_902_234429908.1541171846206
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>2018. november 1., cs=C3=BCt=C3=B6rt=C3=B6k 23:13:=
14 UTC+1 id=C5=91pontban Richard Hodges a k=C3=B6vetkez=C5=91t =C3=ADrta:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><br><div cl=
ass=3D"gmail_quote"><div dir=3D"ltr">On Thu, 1 Nov 2018 at 16:51, Ville Vou=
tilainen <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"EFlk1kbIBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascr=
ipt:';return true;" onclick=3D"this.href=3D'javascript:';return=
true;">ville.vo...@gmail.com</a>> wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">(...)=C2=A0 If you want named parameters,<br>
<br>
1) make them be declared, not automatically nameable<br>
2) don't make it part of the ABI<br>
3) don't try to introduce overloading by parameter name<br>
<br>
and you have a chance of getting most of what you want, for those who<br>
indeed want it. Try to insist on something different,<br>
and be prepared for getting what you have now, i.e. nothing. In case<br>
you insist on something different, then your claim<br>
that how to do it is obvious is, well, obviously false.<br>
<br></blockquote><div><br></div><div>I think unfortunately you underscore m=
y point - there is only negativity in this response. The community (at leas=
t this part of it) wants progress, rather than reasons why progress is not =
possible.</div></div></div></blockquote><div><br></div><div>Hmm. I'm al=
most hearing Ville saying hos usual "I'm just stating the FACT&quo=
t;. <br></div><div><br></div><div>The negativity is only your observation. =
Try to read the text as it was put: as helpful guiding.=C2=A0 If your aim i=
s rally related to the functionality and its getting into C++, not just moa=
ning or/or bashing the people who contribute to the standard.</div><div><br=
></div><div>The idea was discussed in public a lot and even at the committe=
e level several times. In great detail too.=C2=A0 It did not progress becau=
se the concerns were not addressed by the proposers, and the verdict was th=
at the benefits fall short. It was not done out of sloth or malice, just th=
rough simple technical evaluation. <br></div><div><br></div><div>Above, Vil=
le summarized the road that lead to the dead end, and even pointed to direc=
tions where it DOES have a fighting chance. If you did your homework and re=
ad up all the history you'd probably arrived to similar conclusions. <b=
r></div><div></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"ltr"><div class=3D"gmail_quote"><div></div><div>Not just =
with the triviality of named parameters.</div></div></div></blockquote><div=
><br></div><div>Well, just reading the last discussion <a href=3D"http://wi=
ki.edg.com/bin/view/Wg21urbana-champaign/FunctionFacilities#N4172_Named_Fun=
ction_Arguments">N4172_Named_Function_Arguments discussion</a>=C2=A0 it is =
pretty far from trivial. Ant there is a lot more just following the links f=
rom posts 2 and 3 of this topic and their references. <br></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 clas=
s=3D"gmail_quote"><div> It is currently not possible to express any more th=
an the most basic intent in C++. C++ remains, after 30 years, basically an =
auto-optimising macro assembler. This is not good enough to survive the rig=
ours of the modern world.</div></div></div></blockquote><div><br></div><div=
>Well, everyone is entitled to have their opinion, I know a plenty of folks=
who see it a different way. <br></div><div><br></div><div><br></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" 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/46a88b60-7f08-45fb-bbad-30f5be27d28f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/46a88b60-7f08-45fb-bbad-30f5be27d28f=
%40isocpp.org</a>.<br />
------=_Part_902_234429908.1541171846206--
------=_Part_901_282851862.1541171846206--
.
Author: Francis Grizzly Smit <grizzly@smit.id.au>
Date: Sat, 3 Nov 2018 06:29:02 +1100
Raw View
This is a multi-part message in MIME format.
--------------10DE7C6C8CF9B2493B9C9966
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
have a look at julia=20
https://docs.julialang.org/en/v1/manual/functions/#Keyword-Arguments-1=20
basically they put all their keyword args after a different symbol i.e. ;
so a named arg looks like f(arg1, arg2, ... ; namedarg1=3Dvalue2,=20
namedarg2=3Dvalue2...)
so for us that would look like
type_0 f(type_1 arg1, type_2 arg2, ....., type_n argn ; type_n1=20
namedarg1=3Dvalue1, type_n2 namedarg2=3Dvalue2, .....)
or we could invent another symbol for the divider i.e. ;| say
so we could have
T0 f(T1 a, T2 b, T3 c=3Dval3 ;| =C2=A0=C2=A0 T4 d=3Dval4, T5 e=3Dval5)
and then it's called like so x =3D f(val1, val2 ;| e=3Dval5_dashed)
or x =3D f(val1, val2, val3_dashed ;| e=3Dval5_dashed, d=3Dval4_dashed)
so basically we just redefine argspeclist:
argspeclist ::=3D normalargspeclist [ nameddivider namedspeclist ]
normalargspeclist ::=3D /* what it always was */
nameddivider ::=3D ";|"
namedspeclist ::=3D /* empty */ | namedspeclist ',' namedspec
namedspec ::=3D typespec identifier '=3D' value
please for give my rusty grammar spec it's been a long time
On 30/10/2018 04:50, ziemowit.laski@gmail.com wrote:
>
> Hello C++-ers,
>
> I=E2=80=99d like to propose named parameter functionality for C++.
>
> I see that there have been previous attempts to add named parameter=20
> functionality to C++ but led to syntactic ambiguities.
>
> However, I think/hope I=E2=80=99ve come up with something that might work=
,=20
> namely PARAMETER LABELS:
>
> int max(left: int, right: int);=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 // declaration
>
> int max(left: int left, right: int right);=C2=A0=C2=A0=C2=A0=C2=A0 // OK
>
> int max(p1: int, p2: int);=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 // ERROR -labels must match
>
> int max(int p1, p2: int p2);=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 // ERROR -missing left label
>
> int max(left: int l, right: int r) {
>
> =C2=A0 return l > r? l: r;
>
> }
>
> int foo(int p1, intp2) {
>
> =C2=A0=C2=A0 =E2=80=A6 max(left: p1, right: p2);=C2=A0=C2=A0=C2=A0 // OK
>
> =C2=A0=C2=A0 =E2=80=A6 max(right: p1, left: p2);=C2=A0=C2=A0=C2=A0=C2=A0 =
// OK
>
> =C2=A0=C2=A0 =E2=80=A6 max(p1, right: p2);=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// ERROR -missing label
>
> =C2=A0=C2=A0 =E2=80=A6 max(p1, p2); // ERROR -no labels
>
> }
>
> I couldn=E2=80=99t find anything like this on the internets.
>
> Another question to consider is whether we should allow right-most=20
> labels to be missing:
>
> int min(args: int arg1, int arg2, int arg3);
>
> =C2=A0=C2=A0 =E2=80=A6min(args: 1, 2, 3);=C2=A0 // OK
>
> =C2=A0=C2=A0 =E2=80=A6min(1, args: 2, 3);=C2=A0 // ERROR =E2=80=93 non-la=
beled arguments must not=20
> preced labeled ones
>
> In other words, a label may be omitted for those parameters for which=20
> a default value may also be specified.=C2=A0 I=E2=80=99m not sure about t=
he=20
> soundness of this, but thought I=E2=80=99d put it out there.
>
> --Zem
>
> --=20
> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> an email to std-proposals+unsubscribe@isocpp.org=20
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org=20
> <mailto:std-proposals@isocpp.org>.
> To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/00c801d46faf=
%24dc525450%2494f6fcf0%24%40gmail.com=20
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/00c801d46fa=
f%24dc525450%2494f6fcf0%24%40gmail.com?utm_medium=3Demail&utm_source=3Dfoot=
er>.
--=20
.~. In my life God comes first....
/V\ but Linux is pretty high after that :-D
/( )\ Francis (Grizzly) Smit
^^-^^ http://www.smit.id.au/
--=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/a79fc57c-88a4-e255-adf7-643286958c48%40smit.id.a=
u.
--------------10DE7C6C8CF9B2493B9C9966
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<p>have a look at julia
<a class=3D"moz-txt-link-freetext" href=3D"https://docs.julialang.org=
/en/v1/manual/functions/#Keyword-Arguments-1">https://docs.julialang.org/en=
/v1/manual/functions/#Keyword-Arguments-1</a>
basically they put all their keyword args after a different symbol
i.e. ; <br>
</p>
<p>so a named arg looks like f(arg1, arg2, ... ; namedarg1=3Dvalue2,
namedarg2=3Dvalue2...)</p>
<p>so for us that would look like <br>
</p>
<p>type_0 f(type_1 arg1, type_2 arg2, ....., type_n argn ; type_n1
namedarg1=3Dvalue1, type_n2 namedarg2=3Dvalue2, .....)</p>
<p>or we could invent another symbol for the divider i.e. ;| say</p>
<p>so we could have <br>
T0 f(T1 a, T2 b, T3 c=3Dval3 ;| =C2=A0=C2=A0 T4 d=3Dval4, T5 e=3Dval5=
)</p>
<p>and then it's called like so x =3D f(val1, val2 ;| e=3Dval5_dashed)<=
/p>
<p>or x =3D f(val1, val2, val3_dashed ;| e=3Dval5_dashed, d=3Dval4_dash=
ed)</p>
<p>so basically we just redefine argspeclist:</p>
<p>argspeclist ::=3D normalargspeclist [ nameddivider namedspeclist ]</=
p>
<p>normalargspeclist ::=3D /* what it always was */</p>
<p>nameddivider ::=3D ";|"</p>
<p>namedspeclist ::=3D /* empty */ | namedspeclist ',' namedspec</p>
<p>namedspec ::=3D typespec identifier '=3D' value<br>
</p>
<p>please for give my rusty grammar spec it's been a long time <br>
</p>
<div class=3D"moz-cite-prefix">On 30/10/2018 04:50,
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:ziemowit.laski@g=
mail.com">ziemowit.laski@gmail.com</a> wrote:<br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:00c801d46faf$dc525450$94f6fcf0$@gmail.com">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF=
-8">
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;}
..MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hello C++-ers,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal">I=E2=80=99d like to propose named parameter
functionality for C++.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal">I see that there have been previous
attempts to add named parameter functionality to C++ but led
to syntactic ambiguities.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal">However, I think/hope I=E2=80=99ve come up w=
ith
something that might work, namely PARAMETER LABELS:<o:p></o:p></p=
>
<p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal">int max(left: int, right: int);=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 //
declaration<o:p></o:p></p>
<p class=3D"MsoNormal">int max(left: int left, right: int
right);=C2=A0=C2=A0=C2=A0=C2=A0 // OK<o:p></o:p></p>
<p class=3D"MsoNormal">int max(p1: int, p2: int);=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 //
ERROR -labels must match<o:p></o:p></p>
<p class=3D"MsoNormal">int max(int p1, p2: int p2);=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 //
ERROR -missing left label<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal">int max(left: int l, right: int r) {<o:p></o=
:p></p>
<p class=3D"MsoNormal">=C2=A0 return l > r? l: r;<o:p></o:p></p>
<p class=3D"MsoNormal">}<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal">int foo(int p1, intp2) {<o:p></o:p></p>
<p class=3D"MsoNormal">=C2=A0=C2=A0 =E2=80=A6 max(left: p1, right: =
p2);=C2=A0=C2=A0=C2=A0 // OK<o:p></o:p></p>
<p class=3D"MsoNormal">=C2=A0=C2=A0 =E2=80=A6 max(right: p1, left: =
p2);=C2=A0=C2=A0=C2=A0=C2=A0 // OK<o:p></o:p></p>
<p class=3D"MsoNormal">=C2=A0=C2=A0 =E2=80=A6 max(p1, right: p2);=
=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//
ERROR -missing label<o:p></o:p></p>
<p class=3D"MsoNormal">=C2=A0=C2=A0 =E2=80=A6 max(p1, p2);=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=C2=A0=C2=A0=C2=A0=C2=A0
// ERROR -no labels <o:p></o:p></p>
<p class=3D"MsoNormal">}<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal">I couldn=E2=80=99t find anything like this o=
n the
internets.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal">Another question to consider is whether we
should allow right-most labels to be missing:<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal">int min(args: int arg1, int arg2, int
arg3);<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal">=C2=A0=C2=A0 =E2=80=A6min(args: 1, 2, 3);=C2=
=A0 // OK<o:p></o:p></p>
<p class=3D"MsoNormal">=C2=A0=C2=A0 =E2=80=A6min(1, args: 2, 3);=C2=
=A0 // ERROR =E2=80=93
non-labeled arguments must not preced labeled ones<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal">In other words, a label may be omitted for
those parameters for which a default value may also be
specified.=C2=A0 I=E2=80=99m not sure about the soundness of this=
, but
thought I=E2=80=99d put it out there.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal">--Zem<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p>
</div>
-- <br>
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it,
send an email to <a
href=3D"mailto:std-proposals+unsubscribe@isocpp.org"
moz-do-not-send=3D"true">std-proposals+unsubscribe@isocpp.org</a>.<=
br>
To post to this group, send email to <a
href=3D"mailto:std-proposals@isocpp.org" moz-do-not-send=3D"true">s=
td-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/00c801=
d46faf%24dc525450%2494f6fcf0%24%40gmail.com?utm_medium=3Demail&utm_sour=
ce=3Dfooter"
moz-do-not-send=3D"true">https://groups.google.com/a/isocpp.org/d/m=
sgid/std-proposals/00c801d46faf%24dc525450%2494f6fcf0%24%40gmail.com</a>.<b=
r>
</blockquote>
<div class=3D"moz-signature">-- <br>
<pre> .~. In my life God comes first....
/V\ but Linux is pretty high after that :-D
/( )\ Francis (Grizzly) Smit
^^-^^ <a class=3D"moz-txt-link-freetext" href=3D"http://www.smit.id.au=
/">http://www.smit.id.au/</a>
</pre>
</div>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a79fc57c-88a4-e255-adf7-643286958c48%=
40smit.id.au?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a79fc57c-88a4-e255-adf7-643286958c48=
%40smit.id.au</a>.<br />
--------------10DE7C6C8CF9B2493B9C9966--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 2 Nov 2018 15:55:58 -0400
Raw View
--000000000000475c450579b3ed4c
Content-Type: text/plain; charset="UTF-8"
On Fri, Nov 2, 2018 at 3:29 PM Francis Grizzly Smit <grizzly@smit.id.au>
wrote:
> have a look at julia basically they put all their keyword args after a
> different symbol i.e. ;
>
> so a named arg looks like f(arg1, arg2, ... ; namedarg1=value2,
> namedarg2=value2...)
>
Why do we need such a thing?
--
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/CAHSYqdZdppJ2LovqpgJKnMnKyk64WXDf7FTj_KRgavDDcqNH1g%40mail.gmail.com.
--000000000000475c450579b3ed4c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Nov 2,=
2018 at 3:29 PM Francis Grizzly Smit <<a href=3D"mailto:grizzly@smit.id=
..au">grizzly@smit.id.au</a>> wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p>have a look at julia=C2=A0basically they put all their keyword args =
after a different symbol
i.e. ; <br>
</p>
<p>so a named arg looks like f(arg1, arg2, ... ; namedarg1=3Dvalue2,
namedarg2=3Dvalue2...)</p></div></blockquote><div>Why do we need such=
a thing?=C2=A0</div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZdppJ2LovqpgJKnMnKyk64WXDf7FTj=
_KRgavDDcqNH1g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZdppJ2Lovq=
pgJKnMnKyk64WXDf7FTj_KRgavDDcqNH1g%40mail.gmail.com</a>.<br />
--000000000000475c450579b3ed4c--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Fri, 2 Nov 2018 20:01:53 +0000
Raw View
--0000000000007df9680579b4022d
Content-Type: text/plain; charset="UTF-8"
On Fri, 2 Nov 2018, 19:56 Hyman Rosen <hyman.rosen@gmail.com wrote:
> On Fri, Nov 2, 2018 at 3:29 PM Francis Grizzly Smit <grizzly@smit.id.au>
> wrote:
>
>> have a look at julia basically they put all their keyword args after a
>> different symbol i.e. ;
>>
>> so a named arg looks like f(arg1, arg2, ... ; namedarg1=value2,
>> namedarg2=value2...)
>>
> Why do we need such a thing?
>
> --
> 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/CAHSYqdZdppJ2LovqpgJKnMnKyk64WXDf7FTj_KRgavDDcqNH1g%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZdppJ2LovqpgJKnMnKyk64WXDf7FTj_KRgavDDcqNH1g%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
Ironically my facial expression somewhat resembled the suggested syntax ;|
- I have not got much hope for the squinty frog separator. Especially when
we can rather easily distinguish which are named and which are unnamed by a
parameter-by-parameter approach, e.g. Emulating the member access operator
with (.name=value, ...). With python, for example, no unnamed parameter is
allowed after a named parameter. Its probably a sensible restriction,
though whether or not that makes sense in C++ depends on which one of the
many, many potential approaches we take.
>
--
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/CAC%2B0CCNyk98Vm9ZbFoei2w4riFRvK_Huo4eDM8O0mYSaGam6DA%40mail.gmail.com.
--0000000000007df9680579b4022d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
On Fri, 2 Nov 2018, 19:56 Hyman Rosen <<a href=3D"mailto:hyman.rosen@gma=
il.com">hyman.rosen@gmail.com</a> wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, =
Nov 2, 2018 at 3:29 PM Francis Grizzly Smit <<a href=3D"mailto:grizzly@s=
mit.id.au" target=3D"_blank" rel=3D"noreferrer">grizzly@smit.id.au</a>> =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p>have a look at julia=C2=A0basically they put all their keyword args =
after a different symbol
i.e. ; <br>
</p>
<p>so a named arg looks like f(arg1, arg2, ... ; namedarg1=3Dvalue2,
namedarg2=3Dvalue2...)</p></div></blockquote><div>Why do we need such=
a thing?=C2=A0</div></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">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" rel=3D"noreferrer">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/CAHSYqdZdppJ2LovqpgJKnMnKyk64WXDf7FTj=
_KRgavDDcqNH1g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
target=3D"_blank" rel=3D"noreferrer">https://groups.google.com/a/isocpp.or=
g/d/msgid/std-proposals/CAHSYqdZdppJ2LovqpgJKnMnKyk64WXDf7FTj_KRgavDDcqNH1g=
%40mail.gmail.com</a>.<br></blockquote></div></div><div dir=3D"auto"><br></=
div><div dir=3D"auto">Ironically my facial expression somewhat resembled th=
e suggested syntax ;| - I have not got much hope for the squinty frog separ=
ator. Especially when we can rather easily distinguish which are named and =
which are unnamed by a parameter-by-parameter approach, e.g. Emulating the =
member access operator with (.name=3Dvalue, ...). With python, for example,=
no unnamed parameter is allowed after a named parameter. Its probably a se=
nsible restriction, though whether or not that makes sense in C++ depends o=
n which one of the many, many potential approaches we take.</div><div dir=
=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNyk98Vm9ZbFoei2w4riFRvK_Huo4=
eDM8O0mYSaGam6DA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNyk98V=
m9ZbFoei2w4riFRvK_Huo4eDM8O0mYSaGam6DA%40mail.gmail.com</a>.<br />
--0000000000007df9680579b4022d--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Fri, 2 Nov 2018 21:51:32 +0100
Raw View
--00000000000002c9f00579b4b450
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Fri, 2 Nov 2018 at 16:17, Balog Pal <pasa@lib.hu> wrote:
>
>
> 2018. november 1., cs=C3=BCt=C3=B6rt=C3=B6k 23:13:14 UTC+1 id=C5=91pontba=
n Richard Hodges a
> k=C3=B6vetkez=C5=91t =C3=ADrta:
>>
>>
>>
>> On Thu, 1 Nov 2018 at 16:51, Ville Voutilainen <ville.vo...@gmail.com>
>> wrote:
>>
>>> (...) If you want named parameters,
>>>
>>> 1) make them be declared, not automatically nameable
>>> 2) don't make it part of the ABI
>>> 3) don't try to introduce overloading by parameter name
>>>
>>> and you have a chance of getting most of what you want, for those who
>>> indeed want it. Try to insist on something different,
>>> and be prepared for getting what you have now, i.e. nothing. In case
>>> you insist on something different, then your claim
>>> that how to do it is obvious is, well, obviously false.
>>>
>>>
>> I think unfortunately you underscore my point - there is only negativity
>> in this response. The community (at least this part of it) wants progres=
s,
>> rather than reasons why progress is not possible.
>>
>
> Hmm. I'm almost hearing Ville saying hos usual "I'm just stating the
> FACT".
>
> The negativity is only your observation. Try to read the text as it was
> put: as helpful guiding. If your aim is rally related to the functionali=
ty
> and its getting into C++, not just moaning or/or bashing the people who
> contribute to the standard.
>
> The idea was discussed in public a lot and even at the committee level
> several times. In great detail too. It did not progress because the
> concerns were not addressed by the proposers, and the verdict was that th=
e
> benefits fall short. It was not done out of sloth or malice, just through
> simple technical evaluation.
>
> Above, Ville summarized the road that lead to the dead end, and even
> pointed to directions where it DOES have a fighting chance. If you did yo=
ur
> homework and read up all the history you'd probably arrived to similar
> conclusions.
>
>
>> Not just with the triviality of named parameters.
>>
>
> Well, just reading the last discussion N4172_Named_Function_Arguments
> discussion
> <http://wiki.edg.com/bin/view/Wg21urbana-champaign/FunctionFacilities#N41=
72_Named_Function_Arguments>
> it is pretty far from trivial. Ant there is a lot more just following the
> links from posts 2 and 3 of this topic and their references.
>
> It is currently not possible to express any more than the most basic
>> intent in C++. C++ remains, after 30 years, basically an auto-optimising
>> macro assembler. This is not good enough to survive the rigours of the
>> modern world.
>>
>
> Well, everyone is entitled to have their opinion, I know a plenty of folk=
s
> who see it a different way.
>
I think something we can agree on is that other languages are surging
forward in terms of powerful functionality, while the c++ community mumbles
about ABI breakage and backward compatibility.
These are obstacles for sure, but I have always had the impression that c++
guys were the bright ones. There are answers. We are clearly at the end of
the road in terms of modern features coupled with backward compatibility
(which we don't have anyway - auto_ptr is no more!). Those answers will
involve modifying 20 year old code if we insist on compiling it with an
ultra-modern compiler. So what?
The old generation of "it can't be done, we talked about it at a committee
meeting" are doing a disservice to the new generation of bright young
things.
If you can't do it, leave it to someone else.
>
>
>
> --
> 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/46a88b60-7f0=
8-45fb-bbad-30f5be27d28f%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/46a88b60-7f=
08-45fb-bbad-30f5be27d28f%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=20
Richard Hodges
hodges.r@gmail.com
office: +442032898513
home: +376841522
mobile: +376380212 (this will be *expensive* outside Andorra!)
skype: madmongo
facebook: hodges.r
--=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/CALvx3hbxCy9MAZQ2zbGZg5mBp8u9dtVDAv36CYc-b0zjhbC=
XNA%40mail.gmail.com.
--00000000000002c9f00579b4b450
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri=
, 2 Nov 2018 at 16:17, Balog Pal <<a href=3D"mailto:pasa@lib.hu">pasa@li=
b.hu</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><br><br>2018. november 1., cs=C3=BCt=C3=B6rt=C3=B6k 23:13:14 UTC+1 id=C5=
=91pontban Richard Hodges a k=C3=B6vetkez=C5=91t =C3=ADrta:<blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><br><br><div class=3D"gmail_quote"=
><div dir=3D"ltr">On Thu, 1 Nov 2018 at 16:51, Ville Voutilainen <<a rel=
=3D"nofollow">ville.vo...@gmail.com</a>> wrote:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">(...)=C2=A0 If you want named parameters,<br>
<br>
1) make them be declared, not automatically nameable<br>
2) don't make it part of the ABI<br>
3) don't try to introduce overloading by parameter name<br>
<br>
and you have a chance of getting most of what you want, for those who<br>
indeed want it. Try to insist on something different,<br>
and be prepared for getting what you have now, i.e. nothing. In case<br>
you insist on something different, then your claim<br>
that how to do it is obvious is, well, obviously false.<br>
<br></blockquote><div><br></div><div>I think unfortunately you underscore m=
y point - there is only negativity in this response. The community (at leas=
t this part of it) wants progress, rather than reasons why progress is not =
possible.</div></div></div></blockquote><div><br></div><div>Hmm. I'm al=
most hearing Ville saying hos usual "I'm just stating the FACT&quo=
t;. <br></div><div><br></div><div>The negativity is only your observation. =
Try to read the text as it was put: as helpful guiding.=C2=A0 If your aim i=
s rally related to the functionality and its getting into C++, not just moa=
ning or/or bashing the people who contribute to the standard.</div><div><br=
></div><div>The idea was discussed in public a lot and even at the committe=
e level several times. In great detail too.=C2=A0 It did not progress becau=
se the concerns were not addressed by the proposers, and the verdict was th=
at the benefits fall short. It was not done out of sloth or malice, just th=
rough simple technical evaluation. <br></div><div><br></div><div>Above, Vil=
le summarized the road that lead to the dead end, and even pointed to direc=
tions where it DOES have a fighting chance. If you did your homework and re=
ad up all the history you'd probably arrived to similar conclusions. <b=
r></div><div></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"ltr"><div class=3D"gmail_quote"><div></div><div>Not just with =
the triviality of named parameters.</div></div></div></blockquote><div><br>=
</div><div>Well, just reading the last discussion <a href=3D"http://wiki.ed=
g.com/bin/view/Wg21urbana-champaign/FunctionFacilities#N4172_Named_Function=
_Arguments" target=3D"_blank">N4172_Named_Function_Arguments discussion</a>=
=C2=A0 it is pretty far from trivial. Ant there is a lot more just followin=
g the links from posts 2 and 3 of this topic and their references. <br></di=
v><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 class=3D"gmail_quote"><div> It is currently not possible to express any=
more than the most basic intent in C++. C++ remains, after 30 years, basic=
ally an auto-optimising macro assembler. This is not good enough to survive=
the rigours of the modern world.</div></div></div></blockquote><div><br></=
div><div>Well, everyone is entitled to have their opinion, I know a plenty =
of folks who see it a different way. <br></div></div></blockquote><div><br>=
</div><div>I think something we can agree on is that other languages are su=
rging forward in terms of powerful functionality, while the c++ community m=
umbles about ABI breakage and backward compatibility.=C2=A0</div><div><br><=
/div><div>These are obstacles for sure, but I have always had the impressio=
n that c++ guys were the bright ones. There are answers. We are clearly at =
the end of the road in terms of modern features coupled with backward compa=
tibility (which we don't have anyway - auto_ptr is no more!). Those ans=
wers will involve modifying 20 year old code if we insist on compiling it w=
ith an ultra-modern compiler. So what?</div><div><br></div><div>The old gen=
eration of "it can't be done, we talked about it at a committee me=
eting" are doing a disservice to the new generation of bright young th=
ings.</div><div><br></div><div>If you can't do it, leave it to someone =
else.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div></div><div><br></div><div><br></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" 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/46a88b60-7f08-45fb-bbad-30f5be27d28f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/46a88b60-7f08-=
45fb-bbad-30f5be27d28f%40isocpp.org</a>.<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"l=
tr">Richard Hodges<div><a href=3D"mailto:hodges.r@gmail.com" target=3D"_bla=
nk">hodges.r@gmail.com</a></div><div>office: +442032898513</div><div>home: =
+376841522</div><div>mobile:=C2=A0+376380212 (this will be *expensive* outs=
ide Andorra!)</div><div>skype: madmongo</div><div>facebook: hodges.r</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" 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/CALvx3hbxCy9MAZQ2zbGZg5mBp8u9dtVDAv36=
CYc-b0zjhbCXNA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hbxCy9MAZQ2=
zbGZg5mBp8u9dtVDAv36CYc-b0zjhbCXNA%40mail.gmail.com</a>.<br />
--00000000000002c9f00579b4b450--
.
Author: Francis Grizzly Smit <grizzly@smit.id.au>
Date: Sat, 3 Nov 2018 08:42:05 +1100
Raw View
This is a multi-part message in MIME format.
--------------0EB012DD13EBF1467D6AFC5D
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
I just thought that if we must have named args that we should do it in=20
the simplest way possible all the other suggestions, looked clunky and=20
kludgey, basically=C2=A0 using a A-Bomb to kill a mosquito, I thought just=
=20
use the time honoured trick of inventing some thing that would be a=20
compile-time error now to introduce the new thing that way we don't have=20
to change the traditional part of the argument list at all
On 03/11/2018 06:55, Hyman Rosen wrote:
> On Fri, Nov 2, 2018 at 3:29 PM Francis Grizzly Smit=20
> <grizzly@smit.id.au <mailto:grizzly@smit.id.au>> wrote:
>
> have a look at julia=C2=A0basically they put all their keyword args
> after a different symbol i.e. ;
>
> so a named arg looks like f(arg1, arg2, ... ; namedarg1=3Dvalue2,
> namedarg2=3Dvalue2...)
>
> Why do we need such a thing?
> --=20
> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> an email to std-proposals+unsubscribe@isocpp.org=20
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org=20
> <mailto:std-proposals@isocpp.org>.
> To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZdppJ=
2LovqpgJKnMnKyk64WXDf7FTj_KRgavDDcqNH1g%40mail.gmail.com=20
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZdpp=
J2LovqpgJKnMnKyk64WXDf7FTj_KRgavDDcqNH1g%40mail.gmail.com?utm_medium=3Demai=
l&utm_source=3Dfooter>.
--=20
.~. In my life God comes first....
/V\ but Linux is pretty high after that :-D
/( )\ Francis (Grizzly) Smit
^^-^^ http://www.smit.id.au/
--=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/f1b5f957-745f-1a1f-e359-caa17c9bbec0%40smit.id.a=
u.
--------------0EB012DD13EBF1467D6AFC5D
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<p>I just thought that if we must have named args that we should do
it in the simplest way possible all the other suggestions, looked
clunky and kludgey, basically=C2=A0 using a A-Bomb to kill a mosquito=
,=C2=A0
I thought just use the time honoured trick of inventing some thing
that would be a compile-time error now to introduce the new thing
that way we don't have to change the traditional part of the
argument list at all<br>
</p>
<div class=3D"moz-cite-prefix">On 03/11/2018 06:55, Hyman Rosen wrote:<=
br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:CAHSYqdZdppJ2LovqpgJKnMnKyk64WXDf7FTj_KRgavDDcqNH1g@mail.gmail.=
com">
<div dir=3D"ltr">
<div class=3D"gmail_quote">
<div dir=3D"ltr">On Fri, Nov 2, 2018 at 3:29 PM Francis Grizzly
Smit <<a href=3D"mailto:grizzly@smit.id.au"
moz-do-not-send=3D"true">grizzly@smit.id.au</a>> wrote:<br=
>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p>have a look at julia=C2=A0basically they put all their
keyword args after a different symbol i.e. ; <br>
</p>
<p>so a named arg looks like f(arg1, arg2, ... ;
namedarg1=3Dvalue2, namedarg2=3Dvalue2...)</p>
</div>
</blockquote>
<div>Why do we need such a thing?=C2=A0</div>
</div>
</div>
-- <br>
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it,
send an email to <a
href=3D"mailto:std-proposals+unsubscribe@isocpp.org"
moz-do-not-send=3D"true">std-proposals+unsubscribe@isocpp.org</a>.<=
br>
To post to this group, send email to <a
href=3D"mailto:std-proposals@isocpp.org" moz-do-not-send=3D"true">s=
td-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYq=
dZdppJ2LovqpgJKnMnKyk64WXDf7FTj_KRgavDDcqNH1g%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter"
moz-do-not-send=3D"true">https://groups.google.com/a/isocpp.org/d/m=
sgid/std-proposals/CAHSYqdZdppJ2LovqpgJKnMnKyk64WXDf7FTj_KRgavDDcqNH1g%40ma=
il.gmail.com</a>.<br>
</blockquote>
<div class=3D"moz-signature">-- <br>
<pre> .~. In my life God comes first....
/V\ but Linux is pretty high after that :-D
/( )\ Francis (Grizzly) Smit
^^-^^ <a class=3D"moz-txt-link-freetext" href=3D"http://www.smit.id.au=
/">http://www.smit.id.au/</a>
</pre>
</div>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f1b5f957-745f-1a1f-e359-caa17c9bbec0%=
40smit.id.au?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f1b5f957-745f-1a1f-e359-caa17c9bbec0=
%40smit.id.au</a>.<br />
--------------0EB012DD13EBF1467D6AFC5D--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Fri, 2 Nov 2018 16:42:47 -0700 (PDT)
Raw View
------=_Part_1083_1114104623.1541202167187
Content-Type: multipart/alternative;
boundary="----=_Part_1084_1031956372.1541202167188"
------=_Part_1084_1031956372.1541202167188
Content-Type: text/plain; charset="UTF-8"
>
> Here is a long paper I wrote on the subject, which uses a semicolon
> separator. The complete paper is attached, here is the introduction:
This proposal is based on opt-in both on the declaration and the call site
sides. Both annotations consist of a semicolon in the
parameter list. On the declaration side the semicolon separates potentially
positional from name-only parameters. On the callsite
side the semicolon separates positional from named arguments.
Any signature which does not have a semicolon works as before, only
allowing positional arguments and no parameter names in the
mangled function name. For signatures with a semicolon in the declaration
all names are significant and can be named at call sites.
All names are included in the mangled name.
At the call site arguments before the semicolon are positional and
assignment operators work like today. Arguments after the
semicolon are parsed differently, with a special <name> = <expression>
production creating named arguments. As an optional feature just a
name can be allowed, to set a bool parameter to true. Another option could
be to allow arithmetic assignment operators (+= and the
like) instead of the plain = if the parameter has a default value. This can
be useful to express things like "one more than the
default" or "double the default" without having to repeat the default
expression at the call site.
Variadic templates can allow variadic unnamed and/or named parameters.
Names can be picked up in the function body using small
extensions of the already proposed reflection system.
Perfect forwarding is a tricky issue, and this proposal shows has no
_perfect_ solution unless a special core-language operator is
introduced.
--
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/b5a87d0b-b9d4-4e0d-b634-6704708912fb%40isocpp.org.
------=_Part_1084_1031956372.1541202167188
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;">Here is a lon=
g paper I wrote on the subject, which uses a semicolon separator. The compl=
ete paper is attached, here is the introduction:</blockquote><div><br></div=
><div>=C2=A0</div><div><br></div><div>This proposal is based on opt-in both=
on the declaration and the call site sides. Both annotations consist of a =
semicolon in the</div><div>parameter list. On the declaration side the semi=
colon separates potentially positional from name-only parameters. On the ca=
llsite</div><div>side the semicolon separates positional from named argumen=
ts.</div><div><br></div><div>Any signature which does not have a semicolon =
works as before, only allowing positional arguments and no parameter names =
in the</div><div>mangled function name. For signatures with a semicolon in =
the declaration all names are significant and can be named at call sites.</=
div><div>All names are included in the mangled name.</div><div><br></div><d=
iv>At the call site arguments before the semicolon are positional and assig=
nment operators work like today. Arguments after the</div><div>semicolon ar=
e parsed differently, with a special <name> =3D <expression> pr=
oduction creating named arguments. As an optional feature just a</div><div>=
name can be allowed, to set a bool parameter to true. Another option could =
be to allow arithmetic assignment operators (+=3D and the</div><div>like) i=
nstead of the plain =3D if the parameter has a default value. This can be u=
seful to express things like "one more than the</div><div>default"=
; or "double the default" without having to repeat the default ex=
pression at the call site.</div><div><br></div><div>Variadic templates can =
allow variadic unnamed and/or named parameters. Names can be picked up in t=
he function body using small</div><div>extensions of the already proposed r=
eflection system.</div><div><br></div><div>Perfect forwarding is a tricky i=
ssue, and this proposal shows has no _perfect_ solution unless a special co=
re-language operator is</div><div>introduced.</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" 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/b5a87d0b-b9d4-4e0d-b634-6704708912fb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b5a87d0b-b9d4-4e0d-b634-6704708912fb=
%40isocpp.org</a>.<br />
------=_Part_1084_1031956372.1541202167188--
------=_Part_1083_1114104623.1541202167187
Content-Type: text/markdown; charset=US-ASCII; name=named_arguments.md
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=named_arguments.md
X-Attachment-Id: 25a14137-0ae4-4c65-9e0a-7526210df1ce
Content-ID: <25a14137-0ae4-4c65-9e0a-7526210df1ce>
Named function parameters in C++
================================
Being able to call functions with named function arguments has been requested for many years. So far no practical solution has been
found. This has mainly to do with the fact that assignment operators are allowed in the argument expressions, thus using up the
syntax space that would be most logical for giving named arguments their values. Another issue is whether the argument names are to
be part of the function signature. The rationale for this is that it makes it possible to overload functions based on parameter
names, even if the sequence of parameter types is the same. This desire clashes with the old possibility to declare the same
function with different parameter name. Finally it is not immediately obvious how function overload resolution should work for call
sites which name parameters.
Thus something more elaborate than just "allowing it" needs to be invented. The consensus seems to be that we need to make this
feature opt-in on the function declaration side and maybe also on the call side.
Overview of the proposal
------------------------
This proposal is based on opt-in both on the declaration and the call site sides. Both annotations consist of a semicolon in the
parameter list. On the declaration side the semicolon separates potentially positional from name-only parameters. On the callsite
side the semicolon separates positional from named arguments.
Any signature which does not have a semicolon works as before, only allowing positional arguments and no parameter names in the
mangled function name. For signatures with a semicolon in the declaration all names are significant and can be named at call sites.
All names are included in the mangled name.
At the call site arguments before the semicolon are positional and assignment operators work like today. Arguments after the
semicolon are parsed differently, with a special <name> = <expression> production creating named arguments. As an option just a
name can be allowed, to set a bool parameter to true. Another option could be to allow arithmetic assignment operators (+= and the
like) instead of the plain = if the parameter has a default value. This can be useful to express things like "one more than the
default" or "double the default" without having to repeat the default expression at the call site.
Variadic templates can allow variadic unnamed and/or named parameters. Names can be picked up in the function body using small
extensions of the already proposed reflection system.
Perfect forwarding is a tricky issue, and this proposal shows has no _perfect_ solution unless a special core-language operator is
introduced.
Examples
--------
This section shows some simple examples of how this could work.
void funtion(int, int); // #1 Legacy function
void function(int a = 2, int b;); // #2 Function with named parameters (distinct from the one above).
void function(int a, int c; int d = 0); // #3 Function overloaded only on another name, but with an extra, optional named parameter.
function(1, 2); // Call #1: legacy function wins when no semicolon at site.
function(2; b = 3); // Call #2: mix of positional and named arguments. #2 selected due to the name b
function(;b=2); // Call #2: use defaulted a value
function(1; c = 3); // Call #3 as a value for a parameter named c is given.
function(1, 2; d = 5); // Call #3 as a value for a parameter named d is given.
void open_window(int width, int height; bool ontop); // A function with a bool named parameter
open_window(100, 100; ontop); // Open a window with the ontop parameter true.
function(1, 3; d += 2); // Call #3 with d == 2
Additional examples involving template functions, perfect forwarding and variadic templates as well as using names in the callee are
shown in succeding chapters.
Analysis of different aspects
-----------------------------
In the recent discussions on the std-proposals list several issues have been exposed. The following chapters examines how these
would be handled by this proposal.
Perfect forwarding
------------------
The basic idea for perfect forwarding is that a name given at the call site can be retrieved from the formal in the called
function. The problem is that we can't discern at the call site between a name to be forwarded and a name to be used for overload
resolution:
void func(int a;); // #1
template<typename T> func(T b; ); // #2
func(; c = 1); // Call #2 with the formal name b bound to the actual name c
func(; a = 1); // Call #1 or call #2 with formal name b bound to actual name a?
This apparent conflict is resolved so that #1 is called: If a signature with a matching name is found it is always called. Another
case is when there are two template signatures:
template<typename T> func(T c; ); // #3
func(1.0); // Ambiguous, #2 and #3 equally suitable
func(;b = 1.0); // Call #2
func(;c = 1.0); // Call #3
func(;d = 1.0); // Ambiguous, #2 and #3 equally suitable
Name use can be implemented using reflection and code insertion but this gets cumbersome and therefore a perfect
forwarding operator is proposed. In the simplest case only the name is variable. It is unclear whether this should be allowed or if
this feature should only be allowed for template parameters.
void func(int a;);
No this does not make sense: we just called the parameter a, so this function may obviously not be called specifying another name.
The only really reasonable case is variadic:
template<typename... Ts> void func(Ts&&... ts; );
As the name ts now denotes a pack it is reasonable that it has a formal name but still matches unnamed or named parameters. But
what if we want to limit ourselves to one named parameter.
template<typename T> void func(T&& t; );
This is still reasonable if the rule limits the name pickup possibility to when xvalues are passed. Part of the reason is that this
signature is a "last resort" already: if there are any other func signatures which can be called they will be. What we do here is
to extend this to names: if there are any other signatures which are callable due to
void func(int&& t);
Here the && does not denote an xvalue but a rvalue, so to maintain overloadability between this function and some other func with
an int of another name only call sites which actually call the argument t or does not name its parameter should match this
signature.
To actually get the name inside the definition of the function reflection can be used: Template xvale parameters matched to named
call site arguments specialize a special reflection aspect to allow something like reflexpr(t)::arg_name or similar, depending on
which general reflection syntax is incorporated. This allows the use of the name as a compile time string, but to actually do the
forwarding we must be able to paste this name as an identifier much like a macro parameter is used. Other proposals allow this
using a -> { $expr } syntax. While this could work it is a lot of boilerplate to forward a potentially named parameter. It is also
unclear if a _if constexpr_ is needed to handle the unnamed versus named difference, which indicates that a forwarding operator
which just works is a more attractive option:
template<typename T> void func(T&& t; ) {
MyFunc(->t); // Forward the t uncluding its name to MyFunc.
}
func(3); // Forwards as if MyFunc(3);
func(; x = 2); // Forwards as if MyFunc(; x = 2);
XValue parameters after a semicolon picks up names but requires there to be a name:
template<typename T> void func(; T&& t) {
MyFunc(; ->t); // Unclear if this leading ; is required as it would be added anyway by the above rule.
}
func(3); // Error
func(; x = 2); // Forwards as if MyFunc(; x = 2);
Perfect forwarding and variadics
--------------------------------
To perform perfect forwarding in a world with named arguments we need to be able to transfer the name sent to the outer function to
its call to the inner function. The typical example is make_unique() where the name of the parameter needs to be forwarded along
with the type.
std::make_unique<Point>(;radius = 30, angle = 90);
// This must call the constructor like this to resolve ambiguity:
Point(radius = 30, angle = 90);
To achieve this we need to adjust the rules for template parameter deduction when the function (make_unique) is declared to have named parameters:
template<typename C, typename... Ts, typename... Ns> unique_ptr<C> make_unique(Ts&&... ts; Ns&&... ns);
This means that make_unique have any number of unnamed parameters followed by any number of named parameters. Inside the function
reflection can be used to get the names of the Ns
template<typename C, typename... Ts, typename... Ns> unique_ptr<C> make_unique(Ts&&... ts; Ns&&... ns) {
return unique_ptr<C>(new C(std::forward<Ts>(ts)...; reflexpr(ns).arg_name = std::forward<Ns>(ns)...));
}
Note that the subdivision between ts and ns is controlled from the call site of make_unique, it is not necessarily consistent with
the subdivision of the named and unnamed parameters of the constructor being called, as positional parameters can be given names at
the call site. But as the rule is that all named arguments are after the ; this just works as intended.
One issue here is if the reflexpr(ns).arg_name part can actually be written in this position, the problem being that the arg_name
must have a type, which is presumably some kind of compile time string, not an _identifier_. There are proposals to allow this
using some kind of code generation facility such as -> { <code> } where the <code> can contain names of compile time strings prefixed
for instance by a $ character. In our case this gets rather messy as we now have to write:
template<typename C, typename... Ts, typename... Ns> unique_ptr<C> make_unique(Ts&&... ts; Ns&&... ns) {
return unique_ptr<C>(new C(std::forward<Ts>(ts)...; -> { $reflexpr(ns).arg_name } = std::forward<Ns>(ns)...));
}
With a built in forwarding operator, here tentatively written as a prefix -> token we can craft its definition to include the name
if one was present and when expanding a pack to place a imaginary semicolon between unnamed and named parameters from the call site.
template<typename C, typename... Ts> unique_ptr<C> make_unique(Ts... ts;) {
return unique_ptr<C>(new C(->ts...));
}
Note the rule about semicolon in a declaration: All parameters before the semicolon can be specified by name or by position. This
means that all these call sites match this make_unique declaration:
make_unique<MyType>(3);
make_unique<MyType>(3; a = 4);
make_unique<MyType>(; a = 4);
And they all create calls to MyType constructors as if those constructor calls would have been done directly. With the name only
and arithmetic assignment options pertinent information needs also to be carried over by the compiler in the data structure
describing the pack argument. When the pack is expanded using a -> operator the set of pack values, names and semicolon placement
is included. As it is possible to
Variadic parameters
-------------------
Variadic parameters can be allowed before or after the semicolon of the declaration, and indeed in both places at once. This means that
excess unnamed parameters are captured by the ellipsis before the semicolon and additional named parameters with _any_ name are
captured by an ellipsis after the semicolon. It is assumed here that at the call site all unnamed parameters must preceed all named
parameters, which is a simple rule required also to make overload resolution feasible.
There are a few cases to cover, depending on whether there are ellipsis before and/or after the semicolon, when it comes to
alotting named parameters:
If there is an ellipsis before the semicolon but not after named parameters with unknown names are not allowed.
If there is an ellipsis after the semicolon but not before named parameters with unknown names are subsumed by the ellipsis after
the semicolon. Additional unnamed parameters beyond those declared before the semicolon are not allowed.
If there are ellipses both before and after the semicolon extraneous unnamed arguments are subsumed by the first ellipsis and
unknown names are subsumed by the second ellipsis.
Working with argument names
---------------------------
The argname(x) construct gives the name of x at compile time if x is a template parameter of a function with named parameters declared after the semicolon:
template<typename T> void fun(;T x);
The name returned by argname must be an identifier if it is to be useful when forwarding the named parameter like this:
innerFun(argname(x) = x);
There should be a way to transform the name to a compile time string literals so that we can get nice syntax for filling in
containers of arbitrary key/value pairs, such as std::maps. One possiblity would be to have a argstring(x) construct in parallel to
argname(x) but a better solution is probably to extend how the upcoming reflection system allows the program to access names of
functions, types and variables. One way could be to let reflexpr(x) return a constexpr struct containing name as a constexpr string
literal. And maybe the meta programming functionality allows us to go from such a string to an identifer. However, we could still
not write a convenient argname function as we would have to use the _built in_ forwarding operator.
// "meta" function (see P0707) which injects the name of the parameter instead of the call site during compilation. Note that
// argname is declared as taking named functions so the call site must use -> to perfectly forward its parameter, name and all.
// If this was not done argname would always inject the token 'arg' into the token stream!
template<typename T> constexpr void argname(T arg;)
{
// -> { code } injects code snippet at call site.
// $ is used to insert compile time strings into a fixed code snippet
// This may not be exactly as in P0707 as it has another notion of reflection.
-> { $reflexpr(arg).name$ }
}
template<typename T> void fwd(T&& par)
{
destination_fun(argname(->par) = par);
}
Default parameter values
------------------------
A function marked as having named parameters (i.e. with a semicolon in the formal parameter list) allows any parameter to have
default values. This is true also for parameters before the semicolon as it is allowed to give such parameters values using the
names. Thus this is valid code:
int fun(int a = 1, b = 2;);
fun();
fun(2);
fun(1, 2);
fun(a = 2);
fun(b = 3);
fun(1, b = 3);
// Not allowed
fun(1, a=3); // Error: a already has a value
fun(a=2, 3); // Error: positional argument after named argument.
It would be possible to allow manipulation of default values using compound assignment operators. This has some merit as you may
want to tweak the value rather than replace it:
void fun(int min = 0, int max = 20;);
fun(min += 1, max -= 1);
The main motivation for this is that we don't want min = 1 to be a named parameter while min += 1 assigns to a local min variable
and forwards the result as a positional parameter. If the formal does not have a default value this is of course not possible. This
should probably be a hard error noted _after_ overload resolution rather than a SFINAE style error excluding the signature from the
overload set.
Note that even though function redeclaration with different names now declares different overloads redeclaring adding more default
values is still possible using the same rules as before. So there can't be anything like SFINAE in this case.
Overload resolution
-------------------
Immediately when seeing the ( of a function call the compiler must check if any of the overloaded functions are named argument
functions. If so the parsing of the actual parameter list treats = operators differently as these denoted named actual expressions
rather than assignment to locally available variables. This can only be done in the second parsing phase of template parameter
function bodies as the overload sets may differ even if the function name is the same. This should not be a big problem in the
first parsing pass as the allowed syntax is the same regardless of if there are named argument functions in the overload set or
not, it is only the semantics that differs.
Overload resolution proceeds in two steps. First the set of eligible overloads is filtered out and then the best candidate is
selected. Named parameter functions affects both steps. In the first step overloads where the explicitly given names don't appear
are filtered out. This is in addition to the usual rule that the actual parameter count must be in the acceptable range of the
overload, which can be summed up to a rule that all parameters must have values from the call site or from default values. This of
course means that any name only parameters without default values must have explcitly named arguments at the call site.
In the second step the actuals are matched against that overload's formals. For each matched parameter the usual rules apply when
it comes to scalar type promotion and pointer/reference inheritance rules. Also, as usual, a single parameter is a better match
than making the actual part of a variadic parameter pack.
A new rule is needed for name only parameter packs vs. named parameters preceeding it: In keeping with existing rules a match where
the name is given in the declaration is considered better than a match into a variadic parameter pack. If two or more declarations
have ellipsis after the semicolon but different sets of defaulted explicitly named parameters call sites which don't mention the
named parameters are ambiguous. A call site with one or more matched names is considered better than one which hasn't but if more
than one has the call is ambigous again. Example:
template<typename... Ts> void fun(;int a=1, Ts... ts); // Note: ts are name only as they are after semicolon
template<typename... Ts> void fun(;int b=2, Ts... ts); // Note: ts are name only as they are after semicolon
fun(c=3); // Ambigous, neither a nor b is given a value, so no way to know which one to call.
fun(a=1, c=3); // Call first overload even as second overload is also callable.
fun(a=1, b=2, c=3); // Ambiguous as both are callable and have at least one explictly named parameter given a value.
There may be other, more logical rules to this sticky point, but this at least would work. Overloading like this will likely be
very rare.
Overriding virtual functions
----------------------------
I don't think this will cause trouble: A function with a certain set of names is distinct from other functions with other names or
types of their parameters, and also distinct from a function without named parameters. Overriding, as usual, requires repeating the
signature's types and for named parameter functions their names. If names mismatch we can use override to make errors obvious.
Function pointers
-----------------
Note that this section does not offer a solution to the problem of passing an overload set to a function. Instead it solves the
issue of sending a specified overload to a function taking an templated function pointer (or overloads for more than one at least).
I propose that a function pointer continues to be a pointer to a function taking a certain list of parameters with certain types.
It seems unduly restrictive to say that the names must match when assigning to the function pointer. When calling through the
function pointer named arguments are available if the _function pointer_ declaration has them.
A problem with this approach is that it might be error prone that the parameter names in the function pointer and assigned function
are not related. This is solved for template cases (such as make_unique) by the perfect forwarding mechanism.
Another problem that needs to be solved is how to define which function out of an overload set to use. Today we can pick one
function out of an overload set when assigning to a function pointer by checking the parameter list of the function pointer and
picking the right overload. When the function type is templated you can't just name an overloaded function as the call would be
ambiguous. With functions overloaded on parameter names similar ambiguity can arise also when assigning to a function pointer or
when specifying a non-template function parameter. It seems worthwhile to solve both of these problems with one feature, I know
many of us have had to make forwarding stubs with awkward names to get around the overload problem for templates.
Here is an example:
template<typename F> caller(F f) { f(2); }
void test(int) { std::cout << "int"; }
void test(float) { std::cout << "float"; }
caller(&test); // Ambiguous
// Use decltype and cast
caller(static_cast<decltype(test(1))>(test)); // NO: Tried to cast to void, i.e. the return type of test(1).
caller<int(*)(int)>(&test); // This should work, but is quite ugly.
// Similar with named args
void test(int x;);
void test(int y;);
caller<int(*)(int x;)>(test); // Selects the one with an x argument
This way of selecting an overload by explicitly stating the corresponding type is fairly intimidating to beginners. It would be
nice if something akin to decltype was available. In fact if & allowed a formal declaration, not just a function name we should be
able to disambiguate more easily:
caller(&test(int)); // For regular overloaded functions, also encompasses named argument functions unless ambiguous.
caller(&test(int x;)); // For named argument function with function name x.
There could be some most-vexing-parse like issues with this but I don't see them right now. In case ther are we could fall back to
using && instead of & to get a function pointer when types are specified.
Conclusion
----------
It seems feasble to get named function paramters without resorting to .name=value notation at the call sites by subdividing
functions into legacy and named parameter functions. Named parameter functions have parameter names mangled into their linker names.
The main remaining work relates to digging down into the corner cases of overload resolution, which was only cursorily treated
above. There may well be need for additional arbiting rules, but hopefully a decently small set of rules can be found.
Handling of function pointers, perfect forwarding and even filling maps from named parameters seems to be doable, especially if a
perfect forwarding operator and overload selection operators are considered.
------=_Part_1083_1114104623.1541202167187--
.