--0000000000005b3a27057bc68741
Content-Type: text/plain; charset="UTF-8"

It seems to me that a function that takes a struct combined with C++20
designated initializers gets us very close to named parameters:

struct FooParameters {
    int bar;
    float baz;
};
float foo(FooParameters params) {
   return (params.bar + 3) * params.baz;
}
int main() {
   foo({bar: 4, baz: 3.2});
}

If we added some syntactic sugar that...
1. Removed the need to give the parameter struct type a name
2. Introduced the parameter struct members into the function definition
scope.

....we would get pretty close:

float foo(struct { int bar; float baz }) {
    return (bar + 3) * baz;
}
int main() {
   foo({bar: 4, baz:3.2});
}

I'd need to take a look to see if it is ambiguous, but I think we can drop
the struct keyword from the above:

float foo({int bar; float baz}) {
    return (bar + 3) * baz;
}
int main() {
   foo({bar: 4, baz:3.2});
}

This would be equivalent to:

struct __A { int bar; float baz };
float foo(__A __a) {
   auto&& [bar,baz] = __a;
    return (bar + 3) * baz;
}
int main() {
   foo({bar: 4, baz:3.2});
}

From a teachability perspective its pretty easy to explain that "a
brace-enclosed function parameter is the body of an anonymous struct, the
members of which are introduced into the function definition scope."

This also seems easy to implement.

Thoughts?  Worth pursuing?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHLe6zDPRreF2q0zQptUgrO0-_u8VrAOA7Du%2B_KHxhGUnw%40mail.gmail.com.

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

<div dir=3D"ltr">It seems to me that a function that takes a struct combine=
d with C++20 designated initializers gets us very close to named parameters=
:<div><br></div><div>struct FooParameters {</div><div>=C2=A0 =C2=A0 int bar=
;</div><div>=C2=A0 =C2=A0 float baz;</div><div>};</div><div>float foo(FooPa=
rameters params) {</div><div>=C2=A0 =C2=A0return (params.bar=C2=A0+ 3) * pa=
rams.baz;</div><div>}</div><div>int main() {</div><div>=C2=A0 =C2=A0foo({ba=
r: 4, baz: 3.2});</div><div>}</div><div><br></div><div>If we added some syn=
tactic sugar that...</div><div>1. Removed the need to give the parameter st=
ruct type a name</div><div>2. Introduced the parameter struct members into =
the function definition scope.</div><div><br></div><div>...we would get pre=
tty close:</div><div><br></div><div>float foo(struct { int bar; float baz }=
) {</div><div>=C2=A0 =C2=A0 return (bar=C2=A0+ 3) * baz;</div><div>}</div><=
div>int main() {</div><div>=C2=A0 =C2=A0foo({bar: 4, baz:3.2});</div><div>}=
</div><div><br></div><div>I&#39;d need to take a look to see if it is ambig=
uous, but I think we can drop the struct keyword from the above:</div><div>=
<br></div><div><div>float foo({int bar; float baz}) {</div><div>=C2=A0 =C2=
=A0 return (bar=C2=A0+ 3) * baz;</div><div>}</div><div>int main() {</div><d=
iv>=C2=A0 =C2=A0foo({bar: 4, baz:3.2});</div><div>}</div><br class=3D"gmail=
-Apple-interchange-newline"></div><div>This would be equivalent to:</div><d=
iv><br></div><div>struct __A { int bar; float baz };</div><div>float foo(__=
A __a) {</div><div>=C2=A0 =C2=A0auto&amp;&amp; [bar,baz] =3D __a;</div><div=
><div>=C2=A0 =C2=A0 return (bar=C2=A0+ 3) * baz;</div></div><div>}</div><di=
v><div>int main() {</div><div>=C2=A0 =C2=A0foo({bar: 4, baz:3.2});</div><di=
v>}</div></div><div><br></div><div>From a teachability perspective its pret=
ty easy to explain that &quot;a brace-enclosed function parameter is the bo=
dy of an anonymous struct, the members of which are introduced into the fun=
ction definition scope.&quot;</div><div><br></div><div>This also seems easy=
 to implement.</div><div><br></div><div>Thoughts?=C2=A0 Worth pursuing?</di=
v><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHLe6zDPRreF2q0zQptUgrO0-_u8Vr=
AOA7Du%2B_KHxhGUnw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHLe6z=
DPRreF2q0zQptUgrO0-_u8VrAOA7Du%2B_KHxhGUnw%40mail.gmail.com</a>.<br />

--0000000000005b3a27057bc68741--

.

On Thu, Nov 29, 2018 at 02:57:55PM +1000, Andrew Tomazos wrote:
> It seems to me that a function that takes a struct combined with C++20
> designated initializers gets us very close to named parameters:
>
> struct FooParameters {
>     int bar;
>     float baz;
> };
> float foo(FooParameters params) {
>    return (params.bar + 3) * params.baz;
> }
> int main() {
>    foo({bar: 4, baz: 3.2});
> }
>
> If we added some syntactic sugar that...
> 1. Removed the need to give the parameter struct type a name
> 2. Introduced the parameter struct members into the function definition
> scope.

I think this misses a lot of benefits and would propose two other rules:

1. Allow anonymous structs
   Similar to anonymous unions.
   This is already done by VC++ and as an extension by g++ and clang++.
2. Implicitly assume that a call to a function wants to call a function named
   thus and see if some overload could fit the provieded tokens, this would
   allow
   void fun(enum { something, other } x);
   to do the right thing as well.

/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/20181129060523.GA21632%40noemi.bahnhof.se.

.

--000000000000c5ecb6057bc7aa69
Content-Type: text/plain; charset="UTF-8"

On Thu, Nov 29, 2018 at 4:05 PM Magnus Fromreide <magfr@lysator.liu.se>
wrote:

> On Thu, Nov 29, 2018 at 02:57:55PM +1000, Andrew Tomazos wrote:
> > It seems to me that a function that takes a struct combined with C++20
> > designated initializers gets us very close to named parameters:
> >
> > struct FooParameters {
> >     int bar;
> >     float baz;
> > };
> > float foo(FooParameters params) {
> >    return (params.bar + 3) * params.baz;
> > }
> > int main() {
> >    foo({bar: 4, baz: 3.2});
> > }
> >
> > If we added some syntactic sugar that...
> > 1. Removed the need to give the parameter struct type a name
> > 2. Introduced the parameter struct members into the function definition
> > scope.
>
> I think this misses a lot of benefits


To which benefits do you refer?


> and would propose two other rules:


> 1. Allow anonymous structs
>    Similar to anonymous unions.
>    This is already done by VC++ and as an extension by g++ and clang++.
>

$ cat > t.cc
void f(struct {}) {}
$ g++ t.cc
error: types may not be defined in parameter types
 void f(struct {}) {}

Does this work in VC++?  Whats the gcc extension called?


> 2. Implicitly assume that a call to a function wants to call a function
> named
>    thus


I don't quite follow sorry.  My proposal doesn't make any changes to name
lookup of a function call or overload resolution, what changes to overload
resolution are you proposing?


> and see if some overload could fit the provieded tokens, this would
>    allow
>    void fun(enum { something, other } x);
>    to do the right thing as well.


And what is the right thing?  I'm not sure I see how this is related?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHLNKgefS3mn%2BtrH1_Yb1QBi-%2B8VvdHNos57g1a_8hJ6KQ%40mail.gmail.com.

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

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><br><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr">On Thu, Nov 29, 2018 at 4:05 PM Magnus Fromreid=
e &lt;<a href=3D"mailto:magfr@lysator.liu.se">magfr@lysator.liu.se</a>&gt; =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, N=
ov 29, 2018 at 02:57:55PM +1000, Andrew Tomazos wrote:<br>
&gt; It seems to me that a function that takes a struct combined with C++20=
<br>
&gt; designated initializers gets us very close to named parameters:<br>
&gt; <br>
&gt; struct FooParameters {<br>
&gt;=C2=A0 =C2=A0 =C2=A0int bar;<br>
&gt;=C2=A0 =C2=A0 =C2=A0float baz;<br>
&gt; };<br>
&gt; float foo(FooParameters params) {<br>
&gt;=C2=A0 =C2=A0 return (params.bar + 3) * params.baz;<br>
&gt; }<br>
&gt; int main() {<br>
&gt;=C2=A0 =C2=A0 foo({bar: 4, baz: 3.2});<br>
&gt; }<br>
&gt; <br>
&gt; If we added some syntactic sugar that...<br>
&gt; 1. Removed the need to give the parameter struct type a name<br>
&gt; 2. Introduced the parameter struct members into the function definitio=
n<br>
&gt; scope.<br>
<br>
I think this misses a lot of benefits</blockquote><div><br></div><div>To wh=
ich benefits do you refer?</div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex">and would propose two other rules:</blockquote><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">
<br>
1. Allow anonymous structs<br>
=C2=A0 =C2=A0Similar to anonymous unions.<br>
=C2=A0 =C2=A0This is already done by VC++ and as an extension by g++ and cl=
ang++.<br></blockquote><div><br></div><div><div>$ cat &gt; t.cc=C2=A0</div>=
<div>void f(struct {}) {}</div></div><div>$ g++ t.cc</div><div><div>error: =
types may not be defined in parameter types</div><div>=C2=A0void f(struct {=
}) {}</div></div><div><br></div><div>Does this work in VC++?=C2=A0 Whats th=
e gcc extension called?</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">
2. Implicitly assume that a call to a function wants to call a function nam=
ed<br>
=C2=A0 =C2=A0thus</blockquote><div><br></div><div>I don&#39;t quite follow =
sorry.=C2=A0 My proposal doesn&#39;t make any changes to name lookup of a f=
unction call or overload resolution, what changes to overload resolution ar=
e you proposing?</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">and see if some overload could fit the provieded tokens, this=
 would<br>
=C2=A0 =C2=A0allow<br>
=C2=A0 =C2=A0void fun(enum { something, other } x);<br>
=C2=A0 =C2=A0to do the right thing as well.</blockquote><div>=C2=A0</div><d=
iv>And what is the right thing?=C2=A0 I&#39;m not sure I see how this is re=
lated?</div><div><br></div></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHLNKgefS3mn%2BtrH1_Yb1QBi-%2B=
8VvdHNos57g1a_8hJ6KQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHLN=
KgefS3mn%2BtrH1_Yb1QBi-%2B8VvdHNos57g1a_8hJ6KQ%40mail.gmail.com</a>.<br />

--000000000000c5ecb6057bc7aa69--

.

--0000000000002e589b057bcfa465
Content-Type: text/plain; charset="UTF-8"

On Wed, Nov 28, 2018 at 11:58 PM Andrew Tomazos <andrewtomazos@gmail.com>
wrote:

> It seems to me that a function that takes a struct combined with C++20
>
designated initializers gets us very close to named parameters
> This also seems easy to implement.
> Thoughts?  Worth pursuing?
>

I think named argument association should be sui generis, not implemented
by weird class equivalents.  Doing the latter hearkens back to the days of
OO,
where everything was defined in terms of virtual functions.  We should
define
the behavior we want, not try for an equivalence that may or may not have
dark
corners that don't quite match.

--
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/CAHSYqdZOye%3DG4N4aVcQj7P2GoJVgEbXcrDCtCSW5uCxDnq4%2BZQ%40mail.gmail.com.

--0000000000002e589b057bcfa465
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, Nov 28=
, 2018 at 11:58 PM Andrew Tomazos &lt;<a href=3D"mailto:andrewtomazos@gmail=
..com">andrewtomazos@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr">It seems to me that a function that takes a stru=
ct combined with C++20</div></blockquote><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr">designated initializers gets us very close to named parameter=
s<div>This also seems easy to implement.</div><div>Thoughts?=C2=A0 Worth pu=
rsuing?</div></div></blockquote><div><br></div><div>I think named argument =
association should be sui generis, not implemented<br>by weird class equiva=
lents.=C2=A0 Doing the latter hearkens back to the days of OO,<br>where eve=
rything was defined in terms of virtual functions.=C2=A0 We should define<b=
r>the behavior we want, not try for an equivalence that may or may not have=
 dark<br>corners that don&#39;t quite match.</div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZOye%3DG4N4aVcQj7P2GoJVgEbXcrD=
CtCSW5uCxDnq4%2BZQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZOye%3=
DG4N4aVcQj7P2GoJVgEbXcrDCtCSW5uCxDnq4%2BZQ%40mail.gmail.com</a>.<br />

--0000000000002e589b057bcfa465--

.

On Thu, 29 Nov 2018 at 17:50, Hyman Rosen <hyman.rosen@gmail.com> wrote:
>
> On Wed, Nov 28, 2018 at 11:58 PM Andrew Tomazos <andrewtomazos@gmail.com> wrote:
>>
>> It seems to me that a function that takes a struct combined with C++20
>>
>> designated initializers gets us very close to named parameters
>> This also seems easy to implement.
>> Thoughts?  Worth pursuing?
>
>
> I think named argument association should be sui generis, not implemented
> by weird class equivalents.  Doing the latter hearkens back to the days of OO,
> where everything was defined in terms of virtual functions.  We should define
> the behavior we want, not try for an equivalence that may or may not have dark
> corners that don't quite match.

I don't see how an automatic struct wrapper is necessarily a good
solution to the problem, since it changes the arity
of the function. This has practical consequences; the function is no
longer callable with separate unnamed
arguments, which is a horrible loss of functionality.

--
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/CAFk2RUby8T9tfLiS%3DVy31GQ1Nsbk%3DMBEGpZ9XiASzX8Ksv7KTw%40mail.gmail.com.

.

------=_Part_2944_682202211.1543526955762
Content-Type: multipart/alternative;
 boundary="----=_Part_2945_2001995475.1543526955762"

------=_Part_2945_2001995475.1543526955762
Content-Type: text/plain; charset="UTF-8"

And it also misses the possibility to call different function overloads
depending on the names provided at the call site.

Den torsdag 29 november 2018 kl. 16:57:21 UTC+1 skrev Ville Voutilainen:
>
> On Thu, 29 Nov 2018 at 17:50, Hyman Rosen <hyman...@gmail.com
> <javascript:>> wrote:
> >
> > On Wed, Nov 28, 2018 at 11:58 PM Andrew Tomazos <andrew...@gmail.com
> <javascript:>> wrote:
> >>
> >> It seems to me that a function that takes a struct combined with C++20
> >>
> >> designated initializers gets us very close to named parameters
> >> This also seems easy to implement.
> >> Thoughts?  Worth pursuing?
> >
> >
> > I think named argument association should be sui generis, not
> implemented
> > by weird class equivalents.  Doing the latter hearkens back to the days
> of OO,
> > where everything was defined in terms of virtual functions.  We should
> define
> > the behavior we want, not try for an equivalence that may or may not
> have dark
> > corners that don't quite match.
>
> I don't see how an automatic struct wrapper is necessarily a good
> solution to the problem, since it changes the arity
> of the function. This has practical consequences; the function is no
> longer callable with separate unnamed
> arguments, which is a horrible loss of functionality.
>

--
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/d2bedde3-3b25-454d-acdd-96392d886343%40isocpp.org.

------=_Part_2945_2001995475.1543526955762
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">And it also misses the possibility to call different funct=
ion overloads depending on the names provided at the call site.<br><br>Den =
torsdag 29 november 2018 kl. 16:57:21 UTC+1 skrev Ville Voutilainen:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">On Thu, 29 Nov 2018 at 17:50, Hyman R=
osen &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"CxC1yio_AgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:=
&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;">hyman...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt; On Wed, Nov 28, 2018 at 11:58 PM Andrew Tomazos &lt;<a href=3D"jav=
ascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"CxC1yio_AgAJ" rel=3D"n=
ofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onc=
lick=3D"this.href=3D&#39;javascript:&#39;;return true;">andrew...@gmail.com=
</a>&gt; wrote:
<br>&gt;&gt;
<br>&gt;&gt; It seems to me that a function that takes a struct combined wi=
th C++20
<br>&gt;&gt;
<br>&gt;&gt; designated initializers gets us very close to named parameters
<br>&gt;&gt; This also seems easy to implement.
<br>&gt;&gt; Thoughts? =C2=A0Worth pursuing?
<br>&gt;
<br>&gt;
<br>&gt; I think named argument association should be sui generis, not impl=
emented
<br>&gt; by weird class equivalents. =C2=A0Doing the latter hearkens back t=
o the days of OO,
<br>&gt; where everything was defined in terms of virtual functions. =C2=A0=
We should define
<br>&gt; the behavior we want, not try for an equivalence that may or may n=
ot have dark
<br>&gt; corners that don&#39;t quite match.
<br>
<br>I don&#39;t see how an automatic struct wrapper is necessarily a good
<br>solution to the problem, since it changes the arity
<br>of the function. This has practical consequences; the function is no
<br>longer callable with separate unnamed
<br>arguments, which is a horrible loss of functionality.
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d2bedde3-3b25-454d-acdd-96392d886343%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d2bedde3-3b25-454d-acdd-96392d886343=
%40isocpp.org</a>.<br />

------=_Part_2945_2001995475.1543526955762--

------=_Part_2944_682202211.1543526955762--

.

On Thu, Nov 29, 2018 at 04:19:25PM +1000, Andrew Tomazos wrote:
> On Thu, Nov 29, 2018 at 4:05 PM Magnus Fromreide <magfr@lysator.liu.se>
> wrote:
>
> > On Thu, Nov 29, 2018 at 02:57:55PM +1000, Andrew Tomazos wrote:
> > > It seems to me that a function that takes a struct combined with C++20
> > > designated initializers gets us very close to named parameters:
> > >
> > > struct FooParameters {
> > >     int bar;
> > >     float baz;
> > > };
> > > float foo(FooParameters params) {
> > >    return (params.bar + 3) * params.baz;
> > > }
> > > int main() {
> > >    foo({bar: 4, baz: 3.2});
> > > }
> > >
> > > If we added some syntactic sugar that...
> > > 1. Removed the need to give the parameter struct type a name
> > > 2. Introduced the parameter struct members into the function definition
> > > scope.
> >
> > I think this misses a lot of benefits
>
>
> To which benefits do you refer?
>
>
> > and would propose two other rules:
>
>
> > 1. Allow anonymous structs
> >    Similar to anonymous unions.
> >    This is already done by VC++ and as an extension by g++ and clang++.
> >
>
> $ cat > t.cc
> void f(struct {}) {}
> $ g++ t.cc
> error: types may not be defined in parameter types
>  void f(struct {}) {}
>
> Does this work in VC++?  Whats the gcc extension called?

The parts are independent, the first part is about allowing anonymous structs
in places where structs are allowed today.

>
> > 2. Implicitly assume that a call to a function wants to call a function
> > named
> >    thus
>
>
> I don't quite follow sorry.  My proposal doesn't make any changes to name
> lookup of a function call or overload resolution, what changes to overload
> resolution are you proposing?

Consider

void f(struct { int a = 0; int b; });
void f(struct { int b; int c = 0; });

Which one should each of the following call?

f({a: 1, b: 2 }):
f({b: 1, c: 2 });
f({b: 1});

>
> > and see if some overload could fit the provieded tokens, this would
> >    allow
> >    void fun(enum { something, other } x);
> >    to do the right thing as well.
>
> And what is the right thing?  I'm not sure I see how this is related?

Look up types in the argument lsts  of the possible functions.

I will readily admit that I have failed to convey the idea here.

/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/20181130020338.GA2787%40noemi.bahnhof.se.

.

--000000000000ffd4a7057bd8b0a8
Content-Type: text/plain; charset="UTF-8"

In the case of ambiguities, the compiler can error as it currently does
with ambiguous function overloads. But given the work that would go into
making that happen, a deeper language change without the indirection
through structs might be better.

One thing I like about the struct idea is that it gives the control over
named parameters to the API author, not to the user. Another benefit I see
is that we don't need a change to function mangling, whereas function calls
with parameters of the same types but different names would require such a
change.

So I'm (tentatively) for it. But at the same time, I know that mine isn't a
popular position.

We really need a poll to find out which named parameter features (and/or
language changes) that people want, which features they don't want, and
work from there. Otherwise what we end up with is many proposals and a
different subset of people for and against each. As an example, I will
defend the notion of authors having control over whether or not their
functions can be called with named parameters until I see evidence that a
strong majority would prefer the user to have that control - at which point
the position becomes indefensible from a standards perspective.

--
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%2B0CCPHC7beENi%3DC0mVcz-cv4tR1w0nejLGp9O8k16i9YC9iQ%40mail.gmail.com.

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

<div dir=3D"auto">In the case of ambiguities, the compiler can error as it =
currently does with ambiguous function overloads. But given the work that w=
ould go into making that happen, a deeper language change without the indir=
ection through structs might be better.<div dir=3D"auto"><br></div><div dir=
=3D"auto">One thing I like about the struct idea is that it gives the contr=
ol over named parameters to the API author, not to the user. Another benefi=
t I see is that we don&#39;t need a change to function mangling, whereas fu=
nction calls with parameters of the same types but different names would re=
quire such a change.</div><div dir=3D"auto"><br></div><div dir=3D"auto">So =
I&#39;m (tentatively) for it. But at the same time, I know that mine isn&#3=
9;t a popular position.</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
We really need a poll to find out which named parameter features (and/or la=
nguage changes) that people want, which features they don&#39;t want, and w=
ork from there. Otherwise what we end up with is many proposals and a diffe=
rent subset of people for and against each. As an example, I will defend th=
e notion of authors having control over whether or not their functions can =
be called with named parameters until I see evidence that a strong majority=
 would prefer the user to have that control - at which point the position b=
ecomes indefensible from a standards perspective.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPHC7beENi%3DC0mVcz-cv4tR1w0n=
ejLGp9O8k16i9YC9iQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPHC7=
beENi%3DC0mVcz-cv4tR1w0nejLGp9O8k16i9YC9iQ%40mail.gmail.com</a>.<br />

--000000000000ffd4a7057bd8b0a8--

.

--000000000000631b20057be3fac3
Content-Type: text/plain; charset="UTF-8"

On Thu, Nov 29, 2018 at 9:38 PM Jake Arkinstall <jake.arkinstall@gmail.com>
wrote:

> One thing I like about the struct idea is that it gives the control over
> named parameters to the API author, not to the user.
>

I think that's a bad idea.  The API author should be supplying good
parameter names just like they supply good function names, good class
names, good
enumeration literals, and so on.  Just because it does not matter now (and
that's not really true, because functions should be documented and the
documentation should be describing the parameters, so they should already
have sensible names) is no reason to allow it to continue not to matter.


> Another benefit I see is that we don't need a change to function mangling,
> whereas function calls with parameters of the same types but different
> names would require such a change.
>

No.  Named arguments (in my preferred and correct Ada style) are handled by
the compiler without any ABI or mangling changes needed.  You cannot
overload based only on different parameter names.  Just as now, multiple
function declarations with the same function name and parameter types will
declare the same function, even if the different declarations use different
parameter names.

Overload resolution at the call site can use named argument association to
help pick a function to call, but parameter names do not generate different
functions.

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

--000000000000631b20057be3fac3
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 29=
, 2018 at 9:38 PM Jake Arkinstall &lt;<a href=3D"mailto:jake.arkinstall@gma=
il.com">jake.arkinstall@gmail.com</a>&gt; wrote:</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"auto"><div dir=3D"auto">One thing I like about the st=
ruct idea is that it gives the control over named parameters to the API aut=
hor, not to the user.</div></div></blockquote><div><br>I think that&#39;s a=
 bad idea.=C2=A0 The API author should be supplying good parameter names ju=
st like they supply good function names, good class names, good<br>enumerat=
ion literals, and so on.=C2=A0 Just because it does not matter now (and tha=
t&#39;s not really true, because functions should be documented and the doc=
umentation should be describing the parameters, so they should already have=
 sensible names) is no reason to allow it to continue not to matter.<br>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto"=
> Another benefit I see is that we don&#39;t need a change to function mang=
ling, whereas function calls with parameters of the same types but differen=
t names would require such a change.</div></div></blockquote><div><br>No.=
=C2=A0 Named arguments (in my preferred and correct Ada style) are handled =
by the compiler without any ABI or mangling changes needed.=C2=A0 You canno=
t overload based only on different parameter names.=C2=A0 Just as now, mult=
iple function declarations=C2=A0with the same function name and parameter t=
ypes will declare the same function, even if the different declarations use=
 different parameter names.</div><div><br></div><div>Overload resolution at=
 the call site can use named argument association to help pick a function t=
o call, but parameter names do not generate different functions.</div></div=
></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaoV0gxVVGYorLJdnq2OxH6MmjsW7c0=
_xZM5bkn%2Byz97A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaoV0gxVV=
GYorLJdnq2OxH6MmjsW7c0_xZM5bkn%2Byz97A%40mail.gmail.com</a>.<br />

--000000000000631b20057be3fac3--

.

--0000000000007bb612057be40d56
Content-Type: text/plain; charset="UTF-8"

On Fri, 30 Nov 2018, 16:06 Hyman Rosen <hyman.rosen@gmail.com wrote:

> On Thu, Nov 29, 2018 at 9:38 PM Jake Arkinstall <jake.arkinstall@gmail.com>
> wrote:
>
>> One thing I like about the struct idea is that it gives the control over
>> named parameters to the API author, not to the user.
>>
>
> I think that's a bad idea.  The API author should be supplying good
> parameter names just like they supply good function names, good class
> names, good
> enumeration literals, and so on.  Just because it does not matter now (and
> that's not really true, because functions should be documented and the
> documentation should be describing the parameters, so they should already
> have sensible names) is no reason to allow it to continue not to matter.
>
>
>> Another benefit I see is that we don't need a change to function
>> mangling, whereas function calls with parameters of the same types but
>> different names would require such a change.
>>
>
> No.  Named arguments (in my preferred and correct Ada style) are handled
> by the compiler without any ABI or mangling changes needed.  You cannot
> overload based only on different parameter names.  Just as now, multiple
> function declarations with the same function name and parameter types will
> declare the same function, even if the different declarations use different
> parameter names.
>
> Overload resolution at the call site can use named argument association to
> help pick a function to call, but parameter names do not generate different
> functions
>

Both of these points are nonetheless opinions. The notion of allowing
overloads of the same types with different parameter names is very much on
the table - again, we have no poll results and no consensus, so the only
thing we ever manage to obtain on these discussions is knowledge that
everyone wants something different.

>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCP5Zzz5xxvbaT0Wr09EQnq75Wq4xWtsPsv-e%3DO%2Ba9G_WQ%40mail.gmail.com.

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

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, =
30 Nov 2018, 16:06 Hyman Rosen &lt;<a href=3D"mailto:hyman.rosen@gmail.com"=
>hyman.rosen@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"><=
div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Nov 29,=
 2018 at 9:38 PM Jake Arkinstall &lt;<a href=3D"mailto:jake.arkinstall@gmai=
l.com" target=3D"_blank" rel=3D"noreferrer">jake.arkinstall@gmail.com</a>&g=
t; wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div dir=3D=
"auto">One thing I like about the struct idea is that it gives the control =
over named parameters to the API author, not to the user.</div></div></bloc=
kquote><div><br>I think that&#39;s a bad idea.=C2=A0 The API author should =
be supplying good parameter names just like they supply good function names=
, good class names, good<br>enumeration literals, and so on.=C2=A0 Just bec=
ause it does not matter now (and that&#39;s not really true, because functi=
ons should be documented and the documentation should be describing the par=
ameters, so they should already have sensible names) is no reason to allow =
it to continue not to matter.<br>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"auto"><div dir=3D"auto"> Another benefit I see is that we don&=
#39;t need a change to function mangling, whereas function calls with param=
eters of the same types but different names would require such a change.</d=
iv></div></blockquote><div><br>No.=C2=A0 Named arguments (in my preferred a=
nd correct Ada style) are handled by the compiler without any ABI or mangli=
ng changes needed.=C2=A0 You cannot overload based only on different parame=
ter names.=C2=A0 Just as now, multiple function declarations=C2=A0with the =
same function name and parameter types will declare the same function, even=
 if the different declarations use different parameter names.</div><div><br=
></div><div>Overload resolution at the call site can use named argument ass=
ociation to help pick a function to call, but parameter names do not genera=
te different functions</div></div></div></blockquote></div></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Both of these points are nonetheless =
opinions. The notion of allowing overloads of the same types with different=
 parameter names is very much on the table - again, we have no poll results=
 and no consensus, so the only thing we ever manage to obtain on these disc=
ussions is knowledge that everyone wants something different.</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCP5Zzz5xxvbaT0Wr09EQnq75Wq4xW=
tsPsv-e%3DO%2Ba9G_WQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCP5=
Zzz5xxvbaT0Wr09EQnq75Wq4xWtsPsv-e%3DO%2Ba9G_WQ%40mail.gmail.com</a>.<br />

--0000000000007bb612057be40d56--

.

--000000000000427f4c057be5e85a
Content-Type: text/plain; charset="UTF-8"

On Fri, Nov 30, 2018 at 11:11 AM Jake Arkinstall <jake.arkinstall@gmail.com>
wrote:

> Both of these points are nonetheless opinions. The notion of allowing
> overloads of the same types with different parameter names is very much on
> the table - again, we have no poll results and no consensus, so the only
> thing we ever manage to obtain on these discussions is knowledge that
> everyone wants something different.
>

And as exemplified by order of evaluation, we also have a history of coming
to bad decisions, some based on specious arguments.
I'm not convinced that language design by plebiscite produces the best
result (or even a good one).

--
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/CAHSYqdbgP_BGrRNW7qSVXX8GzPRQBPO2cVNU4BQ%3Dy9KDV-Ho3Q%40mail.gmail.com.

--000000000000427f4c057be5e85a
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 30=
, 2018 at 11:11 AM Jake Arkinstall &lt;<a href=3D"mailto:jake.arkinstall@gm=
ail.com">jake.arkinstall@gmail.com</a>&gt; wrote:</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"auto"><div dir=3D"auto">Both of these points are non=
etheless opinions. The notion of allowing overloads of the same types with =
different parameter names is very much on the table - again, we have no pol=
l results and no consensus, so the only thing we ever manage to obtain on t=
hese discussions is knowledge that everyone wants something different.</div=
></div></blockquote><div><br>And as exemplified by order of evaluation, we =
also have a history of coming to bad decisions, some based on specious argu=
ments.<br>I&#39;m not convinced that language design by plebiscite produces=
 the best result (or even a good one).</div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbgP_BGrRNW7qSVXX8GzPRQBPO2cVNU=
4BQ%3Dy9KDV-Ho3Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbgP_BGrR=
NW7qSVXX8GzPRQBPO2cVNU4BQ%3Dy9KDV-Ho3Q%40mail.gmail.com</a>.<br />

--000000000000427f4c057be5e85a--

.

On 29/11/2018 21.03, Magnus Fromreide wrote:
> Consider
>
> void f(struct { int a = 0; int b; });
> void f(struct { int b; int c = 0; });
>
> Which one should each of the following call?
>
> f({a: 1, b: 2 }):
> f({b: 1, c: 2 });
> f({b: 1});

Somewhat OT, but... all of those will fail to compile because they are
not valid syntax.

Why aren't we using correct syntax in this discussion?

  f({.a=1, .b=2}):
  f({.b=1, .c=2});
  f({.b=1});

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/06ae55ce-821f-b584-f96f-69ec5a4622b9%40gmail.com.

.

On 29/11/2018 21.38, Jake Arkinstall wrote:
> In the case of ambiguities, the compiler can error as it currently does
> with ambiguous function overloads. But given the work that would go into
> making that happen, a deeper language change without the indirection
> through structs might be better.
>=20
> One thing I like about the struct idea is that it gives the control over
> named parameters to the API author, not to the user.

P1229 provides that.

> Another benefit I see is that we don't need a change to function
> mangling, whereas function calls with parameters of the same types
> but different names would require such a change.
I have an idea for 'function aliases' that would allow creating a
not-quite-overload=C2=B9 taking P1229 "strongly" named arguments that reall=
y
calls something else. (Usually, the "something else" would be the
ABI-existing version of the function that does not take "strongly" named
arguments.) The down side, however, is users can add such aliases, which
defeats your previous point. (OTOH, users can overload non-member
functions today, so you've already lost that battle. Possibly we could
limit method aliases to appearing in the class definition, which would
mitigate this to at least no worse than it is already.)

Basically, this gives you most of what everyone wants: opt-in, and the
ability to choose between name-based overloading and no ABI change.

(=C2=B9 The not-quite-overload mostly acts like an overload, except it is n=
ot
ambiguous with the signature it aliases.)

> We really need a poll to find out which named parameter features (and/or
> language changes) that people want, which features they don't want, and
> work from there. Otherwise what we end up with is many proposals and a
> different subset of people for and against each.

I actually started writing a paper to this effect, although it remains
to be seen if I actually finish it :-). (Basically, rather than being a
full proposal, the idea is to explain various folks' positions and
suggest how we can compromise... although the latter does end up being a
semi-proposal.)

> As an example, I will defend the notion of authors having control
> over whether or not their functions can be called with named
> parameters until I see evidence that a strong majority would prefer
> the user to have that control - at which point
> the position becomes indefensible from a standards perspective.

I'm on the fence here. In an ideal world, I agree, but I worry about
users wanting to use this feature with libraries that are unmaintained
or otherwise hard to change. That said, I don't think we can stop users
from adding overloads of free functions anyway...

--=20
Matthew

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/8e573c05-68f9-6e31-077d-785e4ac34a51%40gmail.com=
..

.

On 30/11/2018 11.05, Hyman Rosen wrote:
> Named arguments (in my preferred and correct Ada style) are handled by
> the compiler without any ABI or mangling changes needed.  You cannot
> overload based only on different parameter names.

Let's say you have this feature implemented in such manner. How do you
make this (not) work:

  int foo(int: a, int: b);
  std::invoke(foo, .a=5, .c=12); // should be an error

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ddecfa6f-3179-efc6-4787-24708ae516bd%40gmail.com.

.

--0000000000006e0f12057be68d3c
Content-Type: text/plain; charset="UTF-8"

On Fri, Nov 30, 2018 at 2:01 PM Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 30/11/2018 11.05, Hyman Rosen wrote:
> > Named arguments (in my preferred and correct Ada style) are handled by
> > the compiler without any ABI or mangling changes needed.  You cannot
> > overload based only on different parameter names.
>
> Let's say you have this feature implemented in such manner. How do you
> make this (not) work:
>
>   int foo(int: a, int: b);
>   std::invoke(foo, .a=5, .c=12); // should be an error
>

I'm not sure what you're getting at here.  In my version of named argument
association,
the std::invoke function would need to have at least three parameters, two
of which are
named a and b.  The std::invoke call is not a function call of foo, so the
parameter names
of foo are irrelevant.

--
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/CAHSYqdbC2POmioK6H9Fhq3VAZ5si%3D0YY3ek%3DJcPigtMkjsk%3DWA%40mail.gmail.com.

--0000000000006e0f12057be68d3c
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 30=
, 2018 at 2:01 PM Matthew Woehlke &lt;<a href=3D"mailto:mwoehlke.floss@gmai=
l.com">mwoehlke.floss@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">On 30/11/2018 11.05, Hyman Rosen wrote:<br>
&gt; Named arguments (in my preferred and correct Ada style) are handled by=
<br>
&gt; the compiler without any ABI or mangling changes needed.=C2=A0 You can=
not<br>
&gt; overload based only on different parameter names.<br>
<br>
Let&#39;s say you have this feature implemented in such manner. How do you<=
br>
make this (not) work:<br>
<br>
=C2=A0 int foo(int: a, int: b);<br>
=C2=A0 std::invoke(foo, .a=3D5, .c=3D12); // should be an error<br></blockq=
uote><div><br>I&#39;m not sure what you&#39;re getting at here.=C2=A0 In my=
 version of named argument association,<br>the std::invoke function would n=
eed to have at least three parameters, two of which are<br>named a and b.=
=C2=A0 The std::invoke call is not a function call of foo, so the parameter=
 names<br>of foo are irrelevant.</div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbC2POmioK6H9Fhq3VAZ5si%3D0YY3e=
k%3DJcPigtMkjsk%3DWA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbC2P=
OmioK6H9Fhq3VAZ5si%3D0YY3ek%3DJcPigtMkjsk%3DWA%40mail.gmail.com</a>.<br />

--0000000000006e0f12057be68d3c--

.

On 30/11/2018 14.10, Hyman Rosen wrote:
> On Fri, Nov 30, 2018 at 2:01 PM Matthew Woehlke wrote:
>> On 30/11/2018 11.05, Hyman Rosen wrote:
>>> Named arguments (in my preferred and correct Ada style) are handled by
>>> the compiler without any ABI or mangling changes needed.  You cannot
>>> overload based only on different parameter names.
>>
>> Let's say you have this feature implemented in such manner. How do you
>> make this (not) work:
>>
>>   int foo(int: a, int: b);
>>   std::invoke(foo, .a=5, .c=12); // should be an error
>
> In my version of named argument association, the std::invoke function
> would need to have at least three parameters, two of which are named
> a and b.  The std::invoke call is not a function call of foo, so the
> parameter names of foo are irrelevant.
Riiiight... So, what you're saying, is forwarding named arguments
doesn't work. That's a shame. It's also a feature that some people
(myself included) want.

Forwarding named arguments Just Works when names are part of the type
(e.g. P1229).

> I'm not sure what you're getting at here.

Really? std::invoke (and I mean *std::invoke*; I didn't chose that by
accident) transparently forwards its arguments to some other function,
also given in the call site. On its own, it takes whatever arguments you
give it, and just passes them along.

Therefore, it seems "obvious" that I should a) be able to pass named
arguments to std::invoke, and b) that std::invoke should call the
function passed to it using those named arguments. That is:

  int foo(int: a, int: b);
  std::invoke(foo, .a=5, .c=12);

....should result in a compile error, because I am trying to call `foo`
with non-matching arguments. More particularly, the above should have
the exact same effect as:

  foo(.a=5, .c=12);

....which I believe pretty much all of us agree should be a compile error.

I should be able to do something similar with std::apply. More
generally, if I write something like:

  auto t = std::make_tuple(12, .x=7);

....then `t` should continue to "know" that its second element isn't just
an `int`, but one with the 'name' "x".

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b18e4777-8139-2fcb-df71-cb9a560e7472%40gmail.com.

.

--000000000000165d39057c156286
Content-Type: text/plain; charset="UTF-8"

On Fri, Nov 30, 2018 at 3:44 PM Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 30/11/2018 15.31, Hyman Rosen wrote:
> > On Fri, Nov 30, 2018 at 2:56 PM Matthew Woehlke wrote:
> >> Riiiight... So, what you're saying, is forwarding named arguments
> >> doesn't work. That's a shame. It's also a feature that some people
> >> (myself included) want.
> >
> > I don't think that's a good thing to want, but I guess that's just me.
> >
> > I also don't want "pointer to function returning int with double
> parameter
> > named 'a' and string parameter named 's'" as part of the type system.
>
> I think I could go either way on that. For instance, if I have:
>
>   template <typename Func>
>   void foo(Func f)
>   {
>     f(.a=5);
>   }
>
> ...don't I want this to be an error?:
>
>   void bar(int: q);
>   foo(&bar);
>
> OTOH, pointers to functions with named arguments should probably
> implicitly convert to pointers to functions with the same signature sans
> name.
>
> > How is your std::invoke call supposed to work, anyway?  Even if argument
> > names were part of the function type (which they should not be), how is a
> > named argument association supposed to pass through the std::invoke call?
>
> ...because a named argument has a different type than an unnamed
> argument. See P1229. IOW, the argument type to invoke isn't `int`, it's
> something like `std::arg<"x", int>`.
>
> > Are you suggesting that a named argument association is a special object
> > that carries the name with it, and can be passed to a function that
> doesn't
> > have such a named parameter but can be passed along to something else
> that
> > does?
>
> Yes, exactly.
>
> > I think we're once again in the land of "hey, this should do that!" and I
> > think that's a bad way to design language features.
>
> I don't think I can agree. If I expect a feature to work in a certain
> way, and a proposed design doesn't give me that, doesn't that indicate
> that maybe the design has a problem?
>
> In my mind, it would be surprising if invoke/apply either didn't accept
> named arguments at all, or effectively circumvented the protection (and
> maybe other features?) that named arguments are supposed to provide.
>
> I'd like to propose the opposite question... besides the above comment
> about pointer types, and if this was implemented in a way that made it
> *possible* to have named arguments in functions whose ABI does not
> include the name, what objections do you have to argument names being
> visible at the type system level?
>
> --
> Matthew
>

I think that having named argument association objects be things that
aren't just
the same as the arguments themselves, and allowing named arguments to flow
through function calls into other function calls is just a recipe for
disaster.  It strikes
me as causing similar issues to operator dot, namely, when does a name
apply to
the thing itself and when does it apply to something else instead?
Furthermore,
initializer lists were implemented in the way you suggest, with strange
interpolated
class objects, and that has not led to great satisfaction.

The beautiful thing about doing named argument association the Ada way is
that
it's kept *out* of the type system.  It lets you reorder arguments on
invocation, lets
you specify only those defaulted parameters that you want, and lets you
document
your function calls at the call site.  You get overload resolution just to
the extent
needed by the rest of these features. And you don't have to change any ABIs.

I promise you that making it part of the type system will end in tears,
just like so
many other features of C++.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbSUV5TPHKR-dCamdrCA%3D3Z8UiVde4zt7iGaPBhPTscew%40mail.gmail.com.

--000000000000165d39057c156286
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 30=
, 2018 at 3:44 PM Matthew Woehlke &lt;<a href=3D"mailto:mwoehlke.floss@gmai=
l.com">mwoehlke.floss@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">On 30/11/2018 15.31, Hyman Rosen wrote:<br>
&gt; On Fri, Nov 30, 2018 at 2:56 PM Matthew Woehlke wrote:<br>
&gt;&gt; Riiiight... So, what you&#39;re saying, is forwarding named argume=
nts<br>
&gt;&gt; doesn&#39;t work. That&#39;s a shame. It&#39;s also a feature that=
 some people<br>
&gt;&gt; (myself included) want.<br>
&gt; <br>
&gt; I don&#39;t think that&#39;s a good thing to want, but I guess that&#3=
9;s just me.<br>
&gt; <br>
&gt; I also don&#39;t want &quot;pointer to function returning int with dou=
ble parameter<br>
&gt; named &#39;a&#39; and string parameter named &#39;s&#39;&quot; as part=
 of the type system.<br>
<br>
I think I could go either way on that. For instance, if I have:<br>
<br>
=C2=A0 template &lt;typename Func&gt;<br>
=C2=A0 void foo(Func f)<br>
=C2=A0 {<br>
=C2=A0 =C2=A0 f(.a=3D5);<br>
=C2=A0 }<br>
<br>
....don&#39;t I want this to be an error?:<br>
<br>
=C2=A0 void bar(int: q);<br>
=C2=A0 foo(&amp;bar);<br>
<br>
OTOH, pointers to functions with named arguments should probably<br>
implicitly convert to pointers to functions with the same signature sans<br=
>
name.<br>
<br>
&gt; How is your std::invoke call supposed to work, anyway?=C2=A0 Even if a=
rgument<br>
&gt; names were part of the function type (which they should not be), how i=
s a<br>
&gt; named argument association supposed to pass through the std::invoke ca=
ll?<br>
<br>
....because a named argument has a different type than an unnamed<br>
argument. See P1229. IOW, the argument type to invoke isn&#39;t `int`, it&#=
39;s<br>
something like `std::arg&lt;&quot;x&quot;, int&gt;`.<br>
<br>
&gt; Are you suggesting that a named argument association is a special obje=
ct<br>
&gt; that carries the name with it, and can be passed to a function that do=
esn&#39;t<br>
&gt; have such a named parameter but can be passed along to something else =
that<br>
&gt; does?<br>
<br>
Yes, exactly.<br>
<br>
&gt; I think we&#39;re once again in the land of &quot;hey, this should do =
that!&quot; and I<br>
&gt; think that&#39;s a bad way to design language features.<br>
<br>
I don&#39;t think I can agree. If I expect a feature to work in a certain<b=
r>
way, and a proposed design doesn&#39;t give me that, doesn&#39;t that indic=
ate<br>
that maybe the design has a problem?<br>
<br>
In my mind, it would be surprising if invoke/apply either didn&#39;t accept=
<br>
named arguments at all, or effectively circumvented the protection (and<br>
maybe other features?) that named arguments are supposed to provide.<br>
<br>
I&#39;d like to propose the opposite question... besides the above comment<=
br>
about pointer types, and if this was implemented in a way that made it<br>
*possible* to have named arguments in functions whose ABI does not<br>
include the name, what objections do you have to argument names being<br>
visible at the type system level?<br>
<br>
-- <br>
Matthew<br></blockquote><div><br>I think that having named argument associa=
tion objects be things that aren&#39;t just<br>the same as the arguments th=
emselves, and allowing named arguments to flow<br>through function calls in=
to other function calls is just a recipe for disaster.=C2=A0 It strikes<br>=
me as causing similar issues to operator dot, namely, when does a name appl=
y to<br>the thing itself and when does it apply to something else instead?=
=C2=A0 Furthermore,<br>initializer lists were implemented in the way you su=
ggest, with strange interpolated<br>class objects, and that has not led to =
great satisfaction.<br><br>The beautiful thing about doing named argument a=
ssociation the Ada way is that<br>it&#39;s kept *out* of the type system.=
=C2=A0 It lets you reorder arguments on invocation, lets<br>you specify onl=
y those defaulted parameters that you want, and lets you document</div><div=
>your function calls at the call site.=C2=A0 You get overload resolution ju=
st to the extent</div><div>needed by the rest of these features. And you do=
n&#39;t have to change any ABIs.<br><br>I promise you that making it part o=
f the type system will end in tears, just like so<br>many other features of=
 C++.</div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbSUV5TPHKR-dCamdrCA%3D3Z8UiVde=
4zt7iGaPBhPTscew%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbSUV5TPH=
KR-dCamdrCA%3D3Z8UiVde4zt7iGaPBhPTscew%40mail.gmail.com</a>.<br />

--000000000000165d39057c156286--

.

On 02/12/2018 22.02, Hyman Rosen wrote:
> The beautiful thing about doing named argument association the Ada
> way is that it's kept *out* of the type system.  It lets you reorder
> arguments on invocation, lets you specify only those defaulted
> parameters that you want, and lets you document your function calls
> at the call site.
Having names be part of the type does not preclude any of this.

I'm on the fence about reordering, though...

One of my "eventual" objectives for named arguments is to replace
designated initializers with an "as if it existed" ctor rule. I believe
this can be done with no noticeable change in existing code. However, if
we do that, and then add reordering, we are reopening a can of worms as
far as designated initializers.

My preference is to get in a feature *without* reordering, first, and
then people that want reordering can try to add it later.

> And you don't have to change any ABIs.

I have a solution to that, that also allows you to add named arguments
to functions that don't already have them. You might not be able to
overload on name, though (I haven't fully thought it through, but I
think if you try to add an overload that would require named
overloading, you'll necessarily wind up with an ambiguous overload).

> I promise you that making it part of the type system will end in tears,
> just like so many other features of C++.

You keep saying that, but I haven't seen any *concrete* reason. Just a
lot of unspecific muttering.

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ec755b99-02dd-f3a9-9d86-2600b864d0d5%40gmail.com.

.

--000000000000d9a1a7057c36434e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 4, 2018 at 10:53 AM Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> You keep saying that, but I haven't seen any *concrete* reason. Just a lo=
t
> of unspecific muttering.
>

Here are some specific mutters:

int &a();
int &b();
a() <<=3D b();
a() <<  b();
a() <   b();

std::vector<int>         vi{3};
std::vector<std::string> vs{3};

std::vector<int>         zi{0};
std::vector<std::string> zs{0};

unsigned short u1 =3D 60001u;
unsigned short u2 =3D 59999u;
unsigned long u =3D u1 * u2;


For the sake of exposition, the library clauses sometimes annotate
constructors with EXPLICIT. Such a
constructor is conditionally declared as either explicit or non-explicit
(15.3.1). [ Note: This is typically
implemented by declaring two such constructors, of which at most one
participates in overload resolution.
=E2=80=94end note ]

[ptr.launder]

I could come up with more.  It's a history of bad decisions, bad designs,
and bad object models.
Part of it is excessive cleverness and part of it is inchoate "make this
mean that" design, both of
which I find in your preferred version of named argument association.

--=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/CAHSYqdZZPE%2B69vKXVkFTb9W0t9bHcaXN-7GdMy3MeJwpJ=
Bq9Jg%40mail.gmail.com.

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

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"lt=
r">On Tue, Dec 4, 2018 at 10:53 AM Matthew Woehlke &lt;<a href=3D"mailto:mw=
oehlke.floss@gmail.com">mwoehlke.floss@gmail.com</a>&gt; wrote:</div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex">
You keep saying that, but I haven&#39;t seen any *concrete* reason. Just a =
lot of unspecific muttering.<br></blockquote><div><br>Here are some specifi=
c mutters:<br><br></div></div></div><blockquote style=3D"margin:0 0 0 40px;=
border:none;padding:0px"><div><div class=3D"gmail_quote"><div><font face=3D=
"monospace, monospace">int &amp;a();</font></div></div></div><div><div clas=
s=3D"gmail_quote"><div><font face=3D"monospace, monospace">int &amp;b();</f=
ont></div></div></div><div><div class=3D"gmail_quote"><div><font face=3D"mo=
nospace, monospace">a() &lt;&lt;=3D b();</font></div></div></div><div><div =
class=3D"gmail_quote"><div><font face=3D"monospace, monospace">a() &lt;&lt;=
=C2=A0 b();</font></div></div></div><div><div class=3D"gmail_quote"><div><f=
ont face=3D"monospace, monospace">a() &lt;=C2=A0 =C2=A0b();</font></div></d=
iv></div><div><div class=3D"gmail_quote"><div><br></div></div></div><div><d=
iv class=3D"gmail_quote"><div><font face=3D"monospace, monospace">std::vect=
or&lt;int&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vi{3};</font></div></div></d=
iv><div><div class=3D"gmail_quote"><div><font face=3D"monospace, monospace"=
>std::vector&lt;std::string&gt; vs{3};</font></div></div></div><div><div cl=
ass=3D"gmail_quote"><div><font face=3D"monospace, monospace"><br></font></d=
iv></div></div><div><div class=3D"gmail_quote"><div><font face=3D"monospace=
, monospace">std::vector&lt;int&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0zi{0};=
</font></div></div></div><div><div class=3D"gmail_quote"><div><font face=3D=
"monospace, monospace">std::vector&lt;std::string&gt; zs{0};</font></div></=
div></div><div><div class=3D"gmail_quote"><div><font face=3D"monospace, mon=
ospace"><br></font></div></div></div><div><div class=3D"gmail_quote"><div><=
font face=3D"monospace, monospace">unsigned short u1 =3D 60001u;</font></di=
v></div></div><div><div class=3D"gmail_quote"><div><font face=3D"monospace,=
 monospace">unsigned short u2 =3D 59999u;</font></div></div></div><div><div=
 class=3D"gmail_quote"><div><font face=3D"monospace, monospace">unsigned lo=
ng u =3D u1 * u2;</font></div></div></div></blockquote><div dir=3D"ltr"><di=
v class=3D"gmail_quote"><div><br></div></div><blockquote style=3D"margin:0p=
x 0px 0px 40px;border:none;padding:0px"><div class=3D"gmail_quote"><div>For=
 the sake of exposition, the library clauses sometimes annotate constructor=
s with EXPLICIT. Such a</div><div>constructor is conditionally declared as =
either explicit or non-explicit (15.3.1). [ Note: This is typically</div><d=
iv>implemented by declaring two such constructors, of which at most one par=
ticipates in overload resolution.</div><div>=E2=80=94end note ]</div><div><=
br></div></div></blockquote><blockquote style=3D"margin:0px 0px 0px 40px;bo=
rder:none;padding:0px"><div class=3D"gmail_quote"><div>[ptr.launder]</div><=
div><br></div></div></blockquote>I could come up with more.=C2=A0 It&#39;s =
a history of bad decisions, bad designs, and bad object models.<br>Part of =
it is excessive cleverness and part of it is inchoate &quot;make this mean =
that&quot; design, both of<br>which I find in your preferred version of nam=
ed argument association.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZZPE%2B69vKXVkFTb9W0t9bHcaXN-7=
GdMy3MeJwpJBq9Jg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZZPE%2B6=
9vKXVkFTb9W0t9bHcaXN-7GdMy3MeJwpJBq9Jg%40mail.gmail.com</a>.<br />

--000000000000d9a1a7057c36434e--

.