------=_Part_9_29781317.1380871129033
Content-Type: text/plain; charset=ISO-8859-1

I've been thinking about named arguments support in C++ with a simple,
non-intrusive syntax. I've posted a formatted version of the idea
here https://github.com/berkus/cpp_named_args

I would like to hear what do you think is wrong with this approach and why
would it not work, before I jump to patch up LLVM to support this feature?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_9_29781317.1380871129033
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I've been thinking about named arguments support in C++ wi=
th a simple, non-intrusive syntax. I've posted a formatted version of the i=
dea here&nbsp;https://github.com/berkus/cpp_named_args<div><br></div><div>I=
 would like to hear what do you think is wrong with this approach and why w=
ould it not work, before I jump to patch up LLVM to support this feature?</=
div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_9_29781317.1380871129033--

.

--001a11c37e3008031904e7e8a8bc
Content-Type: text/plain; charset=ISO-8859-1

On 4 October 2013 10:18, Berkus Infinitus <berkus@gmail.com> wrote:

> I've been thinking about named arguments support in C++ with a simple,
> non-intrusive syntax. I've posted a formatted version of the idea here
> https://github.com/berkus/cpp_named_args
>
> I would like to hear what do you think is wrong with this approach and why
> would it not work, before I jump to patch up LLVM to support this feature?
>
>
>
How is this different from previous proposals for named arguments?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c37e3008031904e7e8a8bc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 4 October 2013 10:18, Berkus Infinitus <span dir=3D"ltr">&lt;<a =
href=3D"mailto:berkus@gmail.com" target=3D"_blank">berkus@gmail.com</a>&gt;=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I&#39;ve been thinking abou=
t named arguments support in C++ with a simple, non-intrusive syntax. I&#39=
;ve posted a formatted version of the idea here=A0<a href=3D"https://github=
..com/berkus/cpp_named_args" target=3D"_blank">https://github.com/berkus/cpp=
_named_args</a><div>
<br></div><div>I would like to hear what do you think is wrong with this ap=
proach and why would it not work, before I jump to patch up LLVM to support=
 this feature?</div></div><span class=3D"HOEnZb"><font color=3D"#888888">

<p></p>

<br></font></span></blockquote><div><br></div><div>How is this different fr=
om previous proposals for named arguments? <br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c37e3008031904e7e8a8bc--

.

------=_Part_5_29101099.1380870254144
Content-Type: text/plain; charset=ISO-8859-1

I've been pondering at an idea for named arguments in C++ and have a
formatted description of how it would look like
here https://github.com/berkus/cpp_named_args

I would like to hear your opinions about it and why it would not work
before I jump to patch LLVM to accept such syntax.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_5_29101099.1380870254144
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I've been pondering at an idea for named arguments in C++ =
and have a formatted description of how it would look like here&nbsp;https:=
//github.com/berkus/cpp_named_args<div><br></div><div>I would like to hear =
your opinions about it and why it would not work before I jump to patch LLV=
M to accept such syntax.</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5_29101099.1380870254144--

.

------=_Part_768_16000074.1380926530427
Content-Type: text/plain; charset=ISO-8859-1

Can you point as to the previous proposal for named arguments?

On Friday, 4 October 2013 21:32:24 UTC+10, Ville Voutilainen wrote:
>
>
>
>
> On 4 October 2013 10:18, Berkus Infinitus <ber...@gmail.com <javascript:>>wrote:
>
>> I've been thinking about named arguments support in C++ with a simple,
>> non-intrusive syntax. I've posted a formatted version of the idea here
>> https://github.com/berkus/cpp_named_args
>>
>> I would like to hear what do you think is wrong with this approach and
>> why would it not work, before I jump to patch up LLVM to support this
>> feature?
>>
>>
>>
> How is this different from previous proposals for named arguments?
>
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_768_16000074.1380926530427
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Can you point as to the previous proposal for named argume=
nts?<br><br>On Friday, 4 October 2013 21:32:24 UTC+10, Ville Voutilainen  w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div=
><br><br><div class=3D"gmail_quote">On 4 October 2013 10:18, Berkus Infinit=
us <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"WBdKjtaKFeoJ">ber...@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I've been thinking about na=
med arguments support in C++ with a simple, non-intrusive syntax. I've post=
ed a formatted version of the idea here&nbsp;<a href=3D"https://github.com/=
berkus/cpp_named_args" target=3D"_blank">https://github.com/<wbr>berkus/cpp=
_named_args</a><div>
<br></div><div>I would like to hear what do you think is wrong with this ap=
proach and why would it not work, before I jump to patch up LLVM to support=
 this feature?</div></div><span><font color=3D"#888888">

<p></p>

<br></font></span></blockquote><div><br></div><div>How is this different fr=
om previous proposals for named arguments? <br></div></div><br></div></div>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_768_16000074.1380926530427--

.

--047d7bb04bc25e4cfb04e7f249ea
Content-Type: text/plain; charset=ISO-8859-1

On 5 October 2013 01:42, Troy Heron <troy.heron@hixxy.org> wrote:

> Can you point as to the previous proposal for named arguments?
>
>
Oh, this is surprising. I can't find a proposal paper for it. D&E gives
some explanation
about why named parameters weren't adopted and proposes using something
along the lines of
http://www.parashift.com/c++-faq/named-parameter-idiom.html
instead. So, any new proposal would have to consider the reasons given in
D&E not
to adopt named parameters, I think.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7bb04bc25e4cfb04e7f249ea
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 5 October 2013 01:42, Troy Heron <span dir="ltr">&lt;<a href="mailto:troy.heron@hixxy.org" target="_blank">troy.heron@hixxy.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Can you point as to the previous proposal for named arguments?<br><br></div></blockquote>
<div><br></div><div>Oh, this is surprising. I can&#39;t find a proposal paper for it. D&amp;E gives some explanation<br>about why named parameters weren&#39;t adopted and proposes using something<br>along the lines of<br>
<a href="http://www.parashift.com/c++-faq/named-parameter-idiom.html">http://www.parashift.com/c++-faq/named-parameter-idiom.html</a><br></div><div>instead. So, any new proposal would have to consider the reasons given in D&amp;E not<br>
to adopt named parameters, I think. <br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

--047d7bb04bc25e4cfb04e7f249ea--

.

--047d7b33daa88b9ae804e7f28fb3
Content-Type: text/plain; charset=ISO-8859-1

Shame that's only useful for objects, not free functions, and seems like
another hack to use as an excuse for not making language levels changes to
the standard.


On Sat, Oct 5, 2013 at 9:01 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

>
>
>
> On 5 October 2013 01:42, Troy Heron <troy.heron@hixxy.org> wrote:
>
>> Can you point as to the previous proposal for named arguments?
>>
>>
> Oh, this is surprising. I can't find a proposal paper for it. D&E gives
> some explanation
> about why named parameters weren't adopted and proposes using something
> along the lines of
> http://www.parashift.com/c++-faq/named-parameter-idiom.html
> instead. So, any new proposal would have to consider the reasons given in
> D&E not
> to adopt named parameters, I think.
>
>  --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7b33daa88b9ae804e7f28fb3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Shame that&#39;s only useful for objects, not free fu=
nctions, and seems like another hack to use as an excuse for not making lan=
guage levels changes to the standard.</div><div class=3D"gmail_extra"><br><=
/div>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Oct 5, 20=
13 at 9:01 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D"mailto:vi=
lle.voutilainen@gmail.com" target=3D"_blank" onclick=3D"window.open(&#39;ht=
tps://mail.google.com/mail/?view=3Dcm&amp;tf=3D1&amp;to=3Dville.voutilainen=
@gmail.com&amp;cc=3D&amp;bcc=3D&amp;su=3D&amp;body=3D&#39;,&#39;_blank&#39;=
);return false;">ville.voutilainen@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div class=3D"im">On 5 October 2013 =
01:42, Troy Heron <span dir=3D"ltr">&lt;<a href=3D"mailto:troy.heron@hixxy.=
org" target=3D"_blank" onclick=3D"window.open(&#39;https://mail.google.com/=
mail/?view=3Dcm&amp;tf=3D1&amp;to=3Dtroy.heron@hixxy.org&amp;cc=3D&amp;bcc=
=3D&amp;su=3D&amp;body=3D&#39;,&#39;_blank&#39;);return false;">troy.heron@=
hixxy.org</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Can you =
point as to the previous proposal for named arguments?<br><br></div></block=
quote>

<div><br></div></div><div>Oh, this is surprising. I can&#39;t find a propos=
al paper for it. D&amp;E gives some explanation<br>about why named paramete=
rs weren&#39;t adopted and proposes using something<br>along the lines of<b=
r>

<a href=3D"http://www.parashift.com/c++-faq/named-parameter-idiom.html" tar=
get=3D"_blank">http://www.parashift.com/c++-faq/named-parameter-idiom.html<=
/a><br></div><div>instead. So, any new proposal would have to consider the =
reasons given in D&amp;E not<br>

to adopt named parameters, I think. <br></div></div><span class=3D"HOEnZb">=
<font color=3D"#888888"><br></font></span></div></div><span class=3D"HOEnZb=
"><font color=3D"#888888">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank" onclick=3D"window.open(&#39;https://mail.google.com/mail/?view=3Dc=
m&amp;tf=3D1&amp;to=3Dstd-proposals%2Bunsubscribe@isocpp.org&amp;cc=3D&amp;=
bcc=3D&amp;su=3D&amp;body=3D&#39;,&#39;_blank&#39;);return false;">std-prop=
osals+unsubscribe@isocpp.org</a>.</font></span><div class=3D"HOEnZb">
<div class=3D"h5"><br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" onclick=3D"window.open(&#39;https://mail.google.com=
/mail/?view=3Dcm&amp;tf=3D1&amp;to=3Dstd-proposals@isocpp.org&amp;cc=3D&amp=
;bcc=3D&amp;su=3D&amp;body=3D&#39;,&#39;_blank&#39;);return false;">std-pro=
posals@isocpp.org</a>.<br>

Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b33daa88b9ae804e7f28fb3--

.

--001a11c22634a8605304e7f2aa2e
Content-Type: text/plain; charset=ISO-8859-1

On 5 October 2013 02:21, Troy Heron <troy.heron@hixxy.org> wrote:

> Shame that's only useful for objects, not free functions, and seems like
> another hack to use as an excuse for not
>

The technique can be used with free functions as well.


> making language levels changes to the standard.
>
>
>
The argument against named parameters has for a long time been that they
are not important
enough to justify having the core language change when an arguably
palatable work-around
can be used.

I would certainly welcome a library addition to the standard that would
make the work-around
easier to write, if a language change remains unattainable. Having to write
the work-around
from scratch is unacceptable for quite many cases where it would serve a
purpose, because
it leads to a proliferation of custom solutions. And I don't think
http://www.boost.org/doc/libs/1_54_0/libs/parameter/doc/html/index.html
helps much, as technically good a solution as it may be, since the amount
of boilerplate
written is still over the top.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c22634a8605304e7f2aa2e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 5 October 2013 02:21, Troy Heron <span dir=3D"ltr">&lt;<a href=
=3D"mailto:troy.heron@hixxy.org" target=3D"_blank">troy.heron@hixxy.org</a>=
&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Sha=
me that&#39;s only useful for objects, not free functions, and seems like a=
nother hack to use as an excuse for not </div>
</div></blockquote><div><br></div><div>The technique can be used with free =
functions as well.<br>=A0<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
<div dir=3D"ltr"><div>making language levels changes to the standard.</div>=
<div class=3D"gmail_extra"><br><br></div></div></blockquote><div><br></div>=
<div>The argument against named parameters has for a long time been that th=
ey are not important<br>
enough to justify having the core language change when an arguably palatabl=
e work-around<br>can be used.<br><br></div><div>I would certainly welcome a=
 library addition to the standard that would make the work-around<br>easier=
 to write, if a language change remains unattainable. Having to write the w=
ork-around<br>
from scratch is unacceptable for quite many cases where it would serve a pu=
rpose, because<br>it leads to a proliferation of custom solutions. And I do=
n&#39;t think<br><a href=3D"http://www.boost.org/doc/libs/1_54_0/libs/param=
eter/doc/html/index.html">http://www.boost.org/doc/libs/1_54_0/libs/paramet=
er/doc/html/index.html</a><br>
</div><div>helps much, as technically good a solution as it may be, since t=
he amount of boilerplate<br></div><div>written is still over the top. <br><=
/div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c22634a8605304e7f2aa2e--

.

--001a11c1c4a67a11f204e7f2d037
Content-Type: text/plain; charset=ISO-8859-1

FWIW, in Clang (which support C99's designated initializers in C++), you
can do this sort of thing already:

struct rect {
  struct ltwh { int left = 0, top = 0, width = 0, height = 0; };
  struct ltrb { int left, top, right, bottom; };
  rect(ltwh);
  rect(ltrb);
};

rect r({ .width = 200, .height = 100 });
rect r2({ .left = 0, .right = 200, .top = 0, .bottom = 100 });

On Fri, Oct 4, 2013 at 4:28 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

>
>
>
> On 5 October 2013 02:21, Troy Heron <troy.heron@hixxy.org> wrote:
>
>> Shame that's only useful for objects, not free functions, and seems like
>> another hack to use as an excuse for not
>>
>
> The technique can be used with free functions as well.
>
>
>> making language levels changes to the standard.
>>
>>
>>
> The argument against named parameters has for a long time been that they
> are not important
> enough to justify having the core language change when an arguably
> palatable work-around
> can be used.
>
> I would certainly welcome a library addition to the standard that would
> make the work-around
> easier to write, if a language change remains unattainable. Having to
> write the work-around
> from scratch is unacceptable for quite many cases where it would serve a
> purpose, because
> it leads to a proliferation of custom solutions. And I don't think
> http://www.boost.org/doc/libs/1_54_0/libs/parameter/doc/html/index.html
> helps much, as technically good a solution as it may be, since the amount
> of boilerplate
> written is still over the top.
>
>  --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c1c4a67a11f204e7f2d037
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">FWIW, in Clang (which support C99&#39;s designated initial=
izers in C++), you can do this sort of thing already:<div><br></div><div>st=
ruct rect {</div><div>=A0 struct ltwh { int left =3D 0, top =3D 0, width =
=3D 0, height =3D 0; };</div>
<div>=A0 struct ltrb { int left, top, right, bottom; };</div><div>=A0 rect(=
ltwh);</div><div>=A0 rect(ltrb);</div><div>};</div><div><br></div><div>rect=
 r({ .width =3D 200, .height =3D 100 });</div><div>rect r2({ .left =3D 0, .=
right =3D 200, .top =3D 0, .bottom =3D 100 });</div>
<div><br></div><div><div class=3D"gmail_extra"><div class=3D"gmail_quote">O=
n Fri, Oct 4, 2013 at 4:28 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilai=
nen@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div class=3D"im">On 5 October 2013 =
02:21, Troy Heron <span dir=3D"ltr">&lt;<a href=3D"mailto:troy.heron@hixxy.=
org" target=3D"_blank">troy.heron@hixxy.org</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Sha=
me that&#39;s only useful for objects, not free functions, and seems like a=
nother hack to use as an excuse for not </div>

</div></blockquote><div><br></div></div><div>The technique can be used with=
 free functions as well.<br>=A0<br></div><div class=3D"im"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">

<div dir=3D"ltr"><div>making language levels changes to the standard.</div>=
<div class=3D"gmail_extra"><br><br></div></div></blockquote><div><br></div>=
</div><div>The argument against named parameters has for a long time been t=
hat they are not important<br>

enough to justify having the core language change when an arguably palatabl=
e work-around<br>can be used.<br><br></div><div>I would certainly welcome a=
 library addition to the standard that would make the work-around<br>easier=
 to write, if a language change remains unattainable. Having to write the w=
ork-around<br>

from scratch is unacceptable for quite many cases where it would serve a pu=
rpose, because<br>it leads to a proliferation of custom solutions. And I do=
n&#39;t think<br><a href=3D"http://www.boost.org/doc/libs/1_54_0/libs/param=
eter/doc/html/index.html" target=3D"_blank">http://www.boost.org/doc/libs/1=
_54_0/libs/parameter/doc/html/index.html</a><br>

</div><div>helps much, as technically good a solution as it may be, since t=
he amount of boilerplate<br></div><div>written is still over the top. <br><=
/div></div><br></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c1c4a67a11f204e7f2d037--

.

--089e0160bf70c2a74404e7f30974
Content-Type: text/plain; charset=ISO-8859-1

I think Dave Abrahams has proposed

On Friday, October 4, 2013, Ville Voutilainen wrote:

>
>
>
> On 5 October 2013 01:42, Troy Heron <troy.heron@hixxy.org<javascript:_e({}, 'cvml', 'troy.heron@hixxy.org');>
> > wrote:
>
>> Can you point as to the previous proposal for named arguments?
>>
>>
> Oh, this is surprising. I can't find a proposal paper for it. D&E gives
> some explanation
> about why named parameters weren't adopted and proposes using something
> along the lines of
> http://www.parashift.com/c++-faq/named-parameter-idiom.html
> instead. So, any new proposal would have to consider the reasons given in
> D&E not
> to adopt named parameters, I think.
>
>  --
>
> ---
> 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 <javascript:_e({}, 'cvml',
> 'std-proposals%2Bunsubscribe@isocpp.org');>.
> To post to this group, send email to std-proposals@isocpp.org<javascript:_e({}, 'cvml', 'std-proposals@isocpp.org');>
> .
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e0160bf70c2a74404e7f30974
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I=A0think Dave Abrahams has proposed<span></span><br><br>On Friday, October=
 4, 2013, Ville Voutilainen  wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr">
<br><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On 5 Octo=
ber 2013 01:42, Troy Heron <span dir=3D"ltr">&lt;<a href=3D"javascript:_e({=
}, &#39;cvml&#39;, &#39;troy.heron@hixxy.org&#39;);" target=3D"_blank">troy=
..heron@hixxy.org</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Can you =
point as to the previous proposal for named arguments?<br><br></div></block=
quote>

<div><br></div><div>Oh, this is surprising. I can&#39;t find a proposal pap=
er for it. D&amp;E gives some explanation<br>about why named parameters wer=
en&#39;t adopted and proposes using something<br>along the lines of<br>

<a href=3D"http://www.parashift.com/c++-faq/named-parameter-idiom.html" tar=
get=3D"_blank">http://www.parashift.com/c++-faq/named-parameter-idiom.html<=
/a><br></div><div>instead. So, any new proposal would have to consider the =
reasons given in D&amp;E not<br>

to adopt named parameters, I think. <br></div></div><br></div></div>

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:_e({}, &#39;cvml&#39;, &#39;std-proposals%2Bu=
nsubscribe@isocpp.org&#39;);" target=3D"_blank">std-proposals+unsubscribe@i=
socpp.org</a>.<br>

To post to this group, send email to <a href=3D"javascript:_e({}, &#39;cvml=
&#39;, &#39;std-proposals@isocpp.org&#39;);" target=3D"_blank">std-proposal=
s@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0160bf70c2a74404e7f30974--

.

--047d7b15acc9f6b1b404e7f31b09
Content-Type: text/plain; charset=ISO-8859-1

I've seen a mention on the boost mailing list a long while ago about a
desire for this to be proposed by Dave Abrahams, I can't find a proposal
anywhere though.

Ville: There is a multitude of problems with that named parameter idiom
(which I've never used, so I'm mentioning these problems just based on a
quick glance at the url):

Drawbacks of named parameter idiom:

* This idiom implies that all parameters not passed directly to the
constructor all have default
values as equivalent to being 'T variable = value' inside the constructor
parameter list.
This is most often not the intended behaviour when defining a constructor.

* As all the member variables having been initialised by a default value
due to the problem
in 1, they will be twice initialised when having their value set via a
named member function.
This is often unacceptable.

* It's not possible to have a named parameter that is required to have a
value passed to it.
As per 1, they're all defaulted whether that is your intention or not. You
also can't guarantee
that the user is going to call the named method and this isn't enforceable
at compile time.

* I still don't see how this is usable for free functions.


Troy


On Sat, Oct 5, 2013 at 9:55 AM, Fernando Pelliccioni <fpelliccioni@gmail.com
> wrote:

> I think Dave Abrahams has proposed
>
>
> On Friday, October 4, 2013, Ville Voutilainen wrote:
>
>>
>>
>>
>> On 5 October 2013 01:42, Troy Heron <troy.heron@hixxy.org> wrote:
>>
>>> Can you point as to the previous proposal for named arguments?
>>>
>>>
>> Oh, this is surprising. I can't find a proposal paper for it. D&E gives
>> some explanation
>> about why named parameters weren't adopted and proposes using something
>> along the lines of
>> http://www.parashift.com/c++-faq/named-parameter-idiom.html
>> instead. So, any new proposal would have to consider the reasons given in
>> D&E not
>> to adopt named parameters, I think.
>>
>>  --
>>
>> ---
>> 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.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>  --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7b15acc9f6b1b404e7f31b09
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;ve seen a mention on the boost mailing list a long w=
hile ago about a desire for this to be proposed by Dave Abrahams, I can&#39=
;t find a proposal anywhere though.<div><br></div><div>Ville: There is a mu=
ltitude of problems with that named parameter idiom (which I&#39;ve never u=
sed, so I&#39;m mentioning these problems just based on a quick glance at t=
he url):</div>
<div><br></div><div><div><div>Drawbacks of named parameter idiom:</div><div=
><br></div><div>* This idiom implies that all parameters not passed directl=
y to the constructor all have default</div><div>values as equivalent to bei=
ng &#39;T variable =3D value&#39; inside the constructor parameter list.</d=
iv>
<div>This is most often not the intended behaviour when defining a construc=
tor.</div><div><br></div><div>* As all the member variables having been ini=
tialised by a default value due to the problem</div><div>in 1, they will be=
 twice initialised when having their value set via a named member function.=
</div>
<div>This is often unacceptable.</div><div><br></div><div>* It&#39;s not po=
ssible to have a named parameter that is required to have a value passed to=
 it.</div><div>As per 1, they&#39;re all defaulted whether that is your int=
ention or not. You also can&#39;t guarantee</div>
<div>that the user is going to call the named method and this isn&#39;t enf=
orceable at compile time.</div><div><br></div><div>* I still don&#39;t see =
how this is usable for free functions.</div></div></div><div><br></div>
<div><br></div><div>Troy</div></div><div class=3D"gmail_extra"><br><br><div=
 class=3D"gmail_quote">On Sat, Oct 5, 2013 at 9:55 AM, Fernando Pelliccioni=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:fpelliccioni@gmail.com" target=3D"=
_blank">fpelliccioni@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">I=A0think Dave Abrahams has proposed<div cla=
ss=3D"HOEnZb"><div class=3D"h5"><span></span><br><br>On Friday, October 4, =
2013, Ville Voutilainen  wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">
<br><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On 5 Octo=
ber 2013 01:42, Troy Heron <span dir=3D"ltr">&lt;<a>troy.heron@hixxy.org</a=
>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Can you =
point as to the previous proposal for named arguments?<br><br></div></block=
quote>


<div><br></div><div>Oh, this is surprising. I can&#39;t find a proposal pap=
er for it. D&amp;E gives some explanation<br>about why named parameters wer=
en&#39;t adopted and proposes using something<br>along the lines of<br>


<a href=3D"http://www.parashift.com/c++-faq/named-parameter-idiom.html" tar=
get=3D"_blank">http://www.parashift.com/c++-faq/named-parameter-idiom.html<=
/a><br></div><div>instead. So, any new proposal would have to consider the =
reasons given in D&amp;E not<br>


to adopt named parameters, I think. <br></div></div><br></div></div>

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a>std-proposals+unsubscribe@isocpp.org</a>.<br>

To post to this group, send email to <a>std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote>

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b15acc9f6b1b404e7f31b09--

.

--001a11c227e8073cc004e7f86f2e
Content-Type: text/plain; charset=ISO-8859-1

On 5 October 2013 03:00, Troy Heron <troy.heron@hixxy.org> wrote:

> I've seen a mention on the boost mailing list a long while ago about a
> desire for this to be proposed by Dave Abrahams, I can't find a proposal
> anywhere though.
>
> Ville: There is a multitude of problems with that named parameter idiom
> (which I've never used, so I'm mentioning these problems just based on a
> quick glance at the url):
>

Trust me, I'm aware of its problems.


>
> Drawbacks of named parameter idiom:
>
> * This idiom implies that all parameters not passed directly to the
> constructor all have default
> values as equivalent to being 'T variable = value' inside the constructor
> parameter list.
> This is most often not the intended behaviour when defining a constructor.
>

What you do with parameters not passed to a constructor is your decision..


>
> * As all the member variables having been initialised by a default value
> due to the problem
> in 1, they will be twice initialised when having their value set via a
> named member function.
> This is often unacceptable.
>

You can use a parameter struct that contains optionals if that's an issue.


>
> * It's not possible to have a named parameter that is required to have a
> value passed to it.
> As per 1, they're all defaulted whether that is your intention or not. You
> also can't guarantee
> that the user is going to call the named method and this isn't enforceable
> at compile time.
>

Sure, that isn't enforceable at compile time, but you can still enforce it,
so the "it's not
possible" part does not hold.


>
> * I still don't see how this is usable for free functions.
>
>
>
I don't quite understand why you think so. It's a matter of having
void f(ChainableParameterStruct);
or
void MyClass::memberFunc(ChainableParameterStruct);
or
MyClass::MyClass(ChainableParameterStruct);
The same technique applies equally to members and free functions.
If a  constructor chooses to use the parameter struct for member
initialization,
that's its business, but nothing prevents a free function using such a
parameter
struct for other purposes.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c227e8073cc004e7f86f2e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 5 October 2013 03:00, Troy Heron <span dir=3D"ltr">&lt;<a href=
=3D"mailto:troy.heron@hixxy.org" target=3D"_blank">troy.heron@hixxy.org</a>=
&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">I&#39;ve=
 seen a mention on the boost mailing list a long while ago about a desire f=
or this to be proposed by Dave Abrahams, I can&#39;t find a proposal anywhe=
re though.<div>
<br></div><div>Ville: There is a multitude of problems with that named para=
meter idiom (which I&#39;ve never used, so I&#39;m mentioning these problem=
s just based on a quick glance at the url):</div></div></blockquote><div>
<br></div><div>Trust me, I&#39;m aware of its problems.<br>=A0<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">
<div><br></div><div><div><div>Drawbacks of named parameter idiom:</div><div=
><br></div><div>* This idiom implies that all parameters not passed directl=
y to the constructor all have default</div><div>values as equivalent to bei=
ng &#39;T variable =3D value&#39; inside the constructor parameter list.</d=
iv>

<div>This is most often not the intended behaviour when defining a construc=
tor.</div></div></div></div></blockquote><div><br></div><div>What you do wi=
th parameters not passed to a constructor is your decision..<br>=A0<br></di=
v>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><di=
v><div><br></div><div>* As all the member variables having been initialised=
 by a default value due to the problem</div>
<div>in 1, they will be twice initialised when having their value set via a=
 named member function.</div>
<div>This is often unacceptable.</div></div></div></div></blockquote><div><=
br></div><div>You can use a parameter struct that contains optionals if tha=
t&#39;s an issue.<br>=A0<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
<div dir=3D"ltr"><div><div><div><br></div><div>* It&#39;s not possible to h=
ave a named parameter that is required to have a value passed to it.</div><=
div>As per 1, they&#39;re all defaulted whether that is your intention or n=
ot. You also can&#39;t guarantee</div>

<div>that the user is going to call the named method and this isn&#39;t enf=
orceable at compile time.</div></div></div></div></blockquote><div><br></di=
v><div>Sure, that isn&#39;t enforceable at compile time, but you can still =
enforce it, so the &quot;it&#39;s not<br>
</div><div>possible&quot; part does not hold.<br>=A0<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div><div><br></=
div>
<div>* I still don&#39;t see how this is usable for free functions.</div></=
div></div><span class=3D""><font color=3D"#888888"><div><br><br></div></fon=
t></span></div></blockquote><div><br></div><div>I don&#39;t quite understan=
d why you think so. It&#39;s a matter of having<br>
</div><div>void f(ChainableParameterStruct);<br></div><div>or<br></div><div=
>void MyClass::memberFunc(ChainableParameterStruct);<br></div><div>or<br>My=
Class::MyClass(ChainableParameterStruct);<br></div><div>The same technique =
applies equally to members and free functions.<br>
</div><div>If a=A0 constructor chooses to use the parameter struct for memb=
er initialization,<br>that&#39;s its business, but nothing prevents a free =
function using such a parameter<br>struct for other purposes.<br></div></di=
v>
<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c227e8073cc004e7f86f2e--

.

------=_Part_52_19686313.1381167125060
Content-Type: text/plain; charset=ISO-8859-1

Agree, pointers to previous proposals would be nice since I'm not very
familiar with isocpp processes.

Also, it has been pointed out that the mandatory naming for named arguments
becomes a little bit redundant in cases like

bool isReliable = /* some calculations */;
writeData(data, isReliable: isReliable); // oops, tautology

To fix this I was thinking about removing the requirement for naming the
argument if it has an lvalue passed to it. This becomes more cumbersome as
it imposes restrictions on e.g. order of arguments (I wouldn't want make a
compiler guess for example what a localised variable name means).

The "named-parameter-idiom" from parashift.com is actually more like a
fluent interface and has been mentioned in my draft. While it's sometimes
viable, I think it's an abuse of the idiom.


About the question why my syntax is better than the previous ones (without
actually reading about any previous proposals): I think it uses a "label"
semantic inside function call site, which has some sense, at least to me,
for the potentially arbitrarily placed arguments.


On Saturday, October 5, 2013 1:42:10 AM UTC+3, Troy Heron wrote:
>
> Can you point as to the previous proposal for named arguments?
>
> On Friday, 4 October 2013 21:32:24 UTC+10, Ville Voutilainen wrote:
>>
>>
>>
>>
>> On 4 October 2013 10:18, Berkus Infinitus <ber...@gmail.com> wrote:
>>
>>> I've been thinking about named arguments support in C++ with a simple,
>>> non-intrusive syntax. I've posted a formatted version of the idea here
>>> https://github.com/berkus/cpp_named_args
>>>
>>> I would like to hear what do you think is wrong with this approach and
>>> why would it not work, before I jump to patch up LLVM to support this
>>> feature?
>>>
>>>
>>>
>> How is this different from previous proposals for named arguments?
>>
>>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_52_19686313.1381167125060
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Agree, pointers to previous proposals would be nice since =
I'm not very familiar with isocpp processes.<div><br></div><div>Also, it ha=
s been pointed out that the mandatory naming for named arguments becomes a =
little bit redundant in cases like</div><div><br></div><div>bool isReliable=
 =3D /* some calculations */;</div><div>writeData(data, isReliable: isRelia=
ble); // oops, tautology</div><div><br></div><div>To fix this I was thinkin=
g about removing the requirement for naming the argument if it has an lvalu=
e passed to it. This becomes more cumbersome as it imposes restrictions on =
e.g. order of arguments (I wouldn't want make a compiler guess for example =
what a localised variable name means).</div><div><br></div><div>The "named-=
parameter-idiom" from parashift.com is actually more like a fluent interfac=
e and has been mentioned in my draft. While it's sometimes viable, I think =
it's an abuse of the idiom.</div><div><br></div><div><br></div><div>About t=
he question why my syntax is better than the previous ones (without actuall=
y reading about any previous proposals): I think it uses a "label" semantic=
 inside function call site, which has some sense, at least to me, for the p=
otentially arbitrarily placed arguments.</div><div><br></div><div><br>On Sa=
turday, October 5, 2013 1:42:10 AM UTC+3, Troy Heron wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr">Can you point as to the previ=
ous proposal for named arguments?<br><br>On Friday, 4 October 2013 21:32:24=
 UTC+10, Ville Voutilainen  wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><br><div><br><br><div class=3D"gmail_quote">On 4 October =
2013 10:18, Berkus Infinitus <span dir=3D"ltr">&lt;<a>ber...@gmail.com</a>&=
gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I've been thinking about na=
med arguments support in C++ with a simple, non-intrusive syntax. I've post=
ed a formatted version of the idea here&nbsp;<a href=3D"https://github.com/=
berkus/cpp_named_args" target=3D"_blank">https://github.com/<wbr>berkus/cpp=
_named_args</a><div>
<br></div><div>I would like to hear what do you think is wrong with this ap=
proach and why would it not work, before I jump to patch up LLVM to support=
 this feature?</div></div><span><font color=3D"#888888">

<p></p>

<br></font></span></blockquote><div><br></div><div>How is this different fr=
om previous proposals for named arguments? <br></div></div><br></div></div>
</blockquote></div></blockquote></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_52_19686313.1381167125060--

.

------=_Part_284_8229686.1381181299011
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

@Berkus: What's the reason for requiring a colon in the parameter=20
definition? I think this feature would be much more useful if it was=20
allowed for any function call.

Presently labels are not allowed inside an expression so there should be no=
=20
syntactic problem there.

One problem would be that the formal names are allowed to be different in=
=20
different declarations. A simple rule to counteract this problem would be=
=20
to disallow the "label" from naming a parameter which is in different=20
positions in different declarations (for any overload of the function).

The big problem is overloaded functions, as overloads just match the type=
=20
combination of the arguments at the call site. With named parameters we=20
don't really know the type combination until we have selected an overload.=
=20
But maybe this is not an unpassable obstacle. First we can rule out all=20
signatures which don't have all the "labels" named in the call site. When=
=20
this is done we can try to match each of the remaining signatures with the=
=20
actuals, performing permutations of the actuals based on the name order of=
=20
that particular candidate function. Some signatures may be ruled out as=20
uncallable by this step, just as for any signature selection. FInally the=
=20
"best" candidate should be possible to select using the same rules as for=
=20
current call sites, with the same rules for ambiguous calls.

Remains to be defined is what happens if we have unnamed arguments after a=
=20
named one in the call site. One simple idea is to forbid this (A). I think=
=20
this may be the best choice as it is easy to understand. Another=20
possibility (B) is to have a "cursor" in the formal parameter list which is=
=20
incremented after each argument and moved by a label. This is also quite=20
easy to understand but is a bit error prone as you may get confused if=20
different overloads have different subsequent parameters after a like-named=
=20
one. A third alternative (C) would be to have a "cursor" which only=20
increments after unnamed actuals, so that named arguments can be written=20
anywhere in the actuals list without affecting the enumeration of unnamed=
=20
arguments. This I think is really scary.

Both the two latter options create the possibility that the same formal=20
parameter gets two different values at the call site. The issue is if this=
=20
is only to rule out the particular overload where it happens or if it is=20
misformed totally. A similar case in the B alternative is that you may=20
state too many unnamed arguments after a labeled one. This is very similar=
=20
to stating too many unnamed arguments today, in which case the signatures=
=20
taking fewer parameters are ruled out. This suggests that these cases=20
should be treated similarly as the call site may still be valid for some=20
other overload.

As an extra feature it would be nice if you could just state the name of a=
=20
bool parameter to set it to true. I don't think this would be possible as=
=20
the same name may be defined in the scope of the call site, but with a=20
trailing colon character it could work. This would not look as nice but=20
still better than having to write "myBoolParameter: true" every time.

I have actually implemented named parameters in an entirely different way,=
=20
but that used a macro for the function name so it was really not a very=20
good approach. The macro lifted its (variadic) parameters into a lambda=20
where they were preceeded by a using of a special namespace containing the=
=20
parameter names as functions. The syntax at the call site became something=
=20
like this Window(Title("My Window"), CloseButton, Colour(0x404080)). Window=
=20
is the macro name and the other names are hidden in a namespace. The macro=
=20
expansion contains an object of a special type with an operator,() which=20
picks up the results of all the argument functions. The boolean "turn on"=
=20
feature CloseButton is implemented as a static object in the namespace.=20
However ugly the implementation the appearance at the call site was quite=
=20
nice...

To implement this without using a macro something like "reverse ADL lookup"=
=20
would be needed. By this I mean that in the argument list of a function=20
call site you can use names from the namespace of the called function (or=
=20
class of the method, even). I haven't given this much thought really, but=
=20
it seems to be unworkable as the names like Colour in my example could be=
=20
defined in the call site context and so changes the meaning of lots of=20
code. Possibly reverse ADL could kick in only if everything else fails, but=
=20
that's not how normal ADL works, is it? Ideally it should be allowed to=20
write Colour(Colour) in keeping with what is allowed in ctor initializer=20
lists, but that does not seem reasonable to expect, as it needs more than a=
=20
reverse ADL. One possibility would be to allow a "using namespace xyz;"=20
inside the formals list to explicitly call for a reverse ADL to be allowed.=
=20
Still a lot of boilerplate as each named parameter must be a ctor of some=
=20
type and the called function be a variadic template which calls methods in=
=20
all these objects with "this" as a parameter. Lots of overhead there...

This was an aside, more as a starting point for someone else to think of=20
alternative approaches. Right now I would prefer the labeled arguments=20
idea. Especially if the requirement to change function declarations can be=
=20
lifted it seems like a very useful feature that could be beneficial for=20
many cases. There would be no overhead whatsoever to make functions=20
callable in this way which compared to Boosts macros and boilerplate or the=
=20
runtime overhead of the .function().function() approach much easier to=20
understand when looking at a call site. Note also that you can't use the=20
function().function() approach for constructors of named variables:

MyWindow window("Title").WithBorder().Sunken(); // Error!

Bikeshed: I think that by calling this idea "labeled arguments" programmers=
=20
will immediately understand what is meant. Well, at least the few that=20
remember goto and labels (none, I wish!).


Den m=E5ndagen den 7:e oktober 2013 kl. 19:32:05 UTC+2 skrev Berkus Infinit=
us:
>
> Agree, pointers to previous proposals would be nice since I'm not very=20
> familiar with isocpp processes.
>
> Also, it has been pointed out that the mandatory naming for named=20
> arguments becomes a little bit redundant in cases like
>
> bool isReliable =3D /* some calculations */;
> writeData(data, isReliable: isReliable); // oops, tautology
>
> To fix this I was thinking about removing the requirement for naming the=
=20
> argument if it has an lvalue passed to it. This becomes more cumbersome a=
s=20
> it imposes restrictions on e.g. order of arguments (I wouldn't want make =
a=20
> compiler guess for example what a localised variable name means).
>
> The "named-parameter-idiom" from parashift.com is actually more like a=20
> fluent interface and has been mentioned in my draft. While it's sometimes=
=20
> viable, I think it's an abuse of the idiom.
>
>
> About the question why my syntax is better than the previous ones (withou=
t=20
> actually reading about any previous proposals): I think it uses a "label"=
=20
> semantic inside function call site, which has some sense, at least to me,=
=20
> for the potentially arbitrarily placed arguments.
>
>
> On Saturday, October 5, 2013 1:42:10 AM UTC+3, Troy Heron wrote:
>>
>> Can you point as to the previous proposal for named arguments?
>>
>> On Friday, 4 October 2013 21:32:24 UTC+10, Ville Voutilainen wrote:
>>>
>>>
>>>
>>>
>>> On 4 October 2013 10:18, Berkus Infinitus <ber...@gmail.com> wrote:
>>>
>>>> I've been thinking about named arguments support in C++ with a simple,=
=20
>>>> non-intrusive syntax. I've posted a formatted version of the idea here=
=20
>>>> https://github.com/berkus/cpp_named_args
>>>>
>>>> I would like to hear what do you think is wrong with this approach and=
=20
>>>> why would it not work, before I jump to patch up LLVM to support this=
=20
>>>> feature?
>>>>
>>>>
>>>>
>>> How is this different from previous proposals for named arguments?=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_284_8229686.1381181299011
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">@Berkus: What's the reason for requiring a colon in the pa=
rameter definition? I think this feature would be much more useful if it wa=
s allowed for any function call.<div><br></div><div>Presently labels are no=
t allowed inside an expression so there should be no syntactic problem ther=
e.</div><div><br></div><div>One problem would be that the formal names are =
allowed to be different in different declarations. A simple rule to counter=
act this problem would be to disallow the "label" from naming a parameter w=
hich is in different positions in different declarations (for any overload =
of the function).</div><div><br></div><div>The big problem is overloaded fu=
nctions, as overloads just match the type combination of the arguments at t=
he call site. With named parameters we don't really know the type combinati=
on until we have selected an overload. But maybe this is not an unpassable =
obstacle. First we can rule out all signatures which don't have all the "la=
bels" named in the call site. When this is done we can try to match each of=
 the remaining signatures with the actuals, performing permutations of the =
actuals based on the name order of that particular candidate function. Some=
 signatures may be ruled out as uncallable by this step, just as for any si=
gnature selection. FInally the "best" candidate should be possible to selec=
t using the same rules as for current call sites, with the same rules for a=
mbiguous calls.</div><div><br></div><div>Remains to be defined is what happ=
ens if we have unnamed arguments after a named one in the call site. One si=
mple idea is to forbid this (A). I think this may be the best choice as it =
is easy to understand. Another possibility (B) is to have a "cursor" in the=
 formal parameter list which is incremented after each argument and moved b=
y a label. This is also quite easy to understand but is a bit error prone a=
s you may get confused if different overloads have different subsequent par=
ameters after a like-named one. A third alternative (C) would be to have a =
"cursor" which only increments after unnamed actuals, so that named argumen=
ts can be written anywhere in the actuals list without affecting the enumer=
ation of unnamed arguments. This I think is really scary.</div><div><br></d=
iv><div>Both the two latter options create the possibility that the same fo=
rmal parameter gets two different values at the call site. The issue is if =
this is only to rule out the particular overload where it happens or if it =
is misformed totally. A similar case in the B alternative is that you may s=
tate too many unnamed arguments after a labeled one. This is very similar t=
o stating too many unnamed arguments today, in which case the signatures ta=
king fewer parameters are ruled out. This suggests that these cases should =
be treated similarly as the call site may still be valid for some other ove=
rload.</div><div><br></div><div>As an extra feature it would be nice if you=
 could just state the name of a bool parameter to set it to true. I don't t=
hink this would be possible as the same name may be defined in the scope of=
 the call site, but with a trailing colon character it could work. This wou=
ld not look as nice but still better than having to write "myBoolParameter:=
 true" every time.</div><div><br></div><div>I have actually implemented nam=
ed parameters in an entirely different way, but that used a macro for the f=
unction name so it was really not a very good approach. The macro lifted it=
s (variadic) parameters into a lambda where they were preceeded by a using =
of a special namespace containing the parameter names as functions. The syn=
tax at the call site became something like this Window(Title("My Window"), =
CloseButton, Colour(0x404080)). Window is the macro name and the other name=
s are hidden in a namespace. The macro expansion contains an object of a sp=
ecial type with an operator,() which picks up the results of all the argume=
nt functions. The boolean "turn on" feature CloseButton is implemented as a=
 static object in the namespace. However ugly the implementation the appear=
ance at the call site was quite nice...</div><div><br></div><div>To impleme=
nt this without using a macro something like "reverse ADL lookup" would be =
needed. By this I mean that in the argument list of a function call site yo=
u can use names from the namespace of the called function (or class of the =
method, even). I haven't given this much thought really, but it seems to be=
 unworkable as the names like Colour in my example could be defined in the =
call site context and so changes the meaning of lots of code. Possibly reve=
rse ADL could kick in only if everything else fails, but that's not how nor=
mal ADL works, is it? Ideally it should be allowed to write Colour(Colour) =
in keeping with what is allowed in ctor initializer lists, but that does no=
t seem reasonable to expect, as it needs more than a reverse ADL. One possi=
bility would be to allow a "using namespace xyz;" inside the formals list t=
o explicitly call for a reverse ADL to be allowed. Still a lot of boilerpla=
te as each named parameter must be a ctor of some type and the called funct=
ion be a variadic template which calls methods in all these objects with "t=
his" as a parameter. Lots of overhead there...</div><div><br></div><div>Thi=
s was an aside, more as a starting point for someone else to think of alter=
native approaches. Right now I would prefer the labeled arguments idea. Esp=
ecially if the requirement to change function declarations can be lifted it=
 seems like a very useful feature that could be beneficial for many cases. =
There would be no overhead whatsoever to make functions callable in this wa=
y which compared to Boosts macros and boilerplate or the runtime overhead o=
f the .function().function() approach much easier to understand when lookin=
g at a call site. Note also that you can't use the function().function() ap=
proach for constructors of named variables:</div><div><br></div><div>MyWind=
ow window("Title").WithBorder().Sunken(); // Error!</div><div><br></div><di=
v>Bikeshed: I think that by calling this idea "labeled arguments" programme=
rs will immediately understand what is meant. Well, at least the few that r=
emember goto and labels (none, I wish!).</div><div><br><br>Den m=E5ndagen d=
en 7:e oktober 2013 kl. 19:32:05 UTC+2 skrev Berkus Infinitus:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Agree, pointers to previou=
s proposals would be nice since I'm not very familiar with isocpp processes=
..<div><br></div><div>Also, it has been pointed out that the mandatory namin=
g for named arguments becomes a little bit redundant in cases like</div><di=
v><br></div><div>bool isReliable =3D /* some calculations */;</div><div>wri=
teData(data, isReliable: isReliable); // oops, tautology</div><div><br></di=
v><div>To fix this I was thinking about removing the requirement for naming=
 the argument if it has an lvalue passed to it. This becomes more cumbersom=
e as it imposes restrictions on e.g. order of arguments (I wouldn't want ma=
ke a compiler guess for example what a localised variable name means).</div=
><div><br></div><div>The "named-parameter-idiom" from <a href=3D"http://par=
ashift.com" target=3D"_blank">parashift.com</a> is actually more like a flu=
ent interface and has been mentioned in my draft. While it's sometimes viab=
le, I think it's an abuse of the idiom.</div><div><br></div><div><br></div>=
<div>About the question why my syntax is better than the previous ones (wit=
hout actually reading about any previous proposals): I think it uses a "lab=
el" semantic inside function call site, which has some sense, at least to m=
e, for the potentially arbitrarily placed arguments.</div><div><br></div><d=
iv><br>On Saturday, October 5, 2013 1:42:10 AM UTC+3, Troy Heron wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Can you point as to th=
e previous proposal for named arguments?<br><br>On Friday, 4 October 2013 2=
1:32:24 UTC+10, Ville Voutilainen  wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><br><div><br><br><div class=3D"gmail_quote">On 4 Oct=
ober 2013 10:18, Berkus Infinitus <span dir=3D"ltr">&lt;<a>ber...@gmail.com=
</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I've been thinking about na=
med arguments support in C++ with a simple, non-intrusive syntax. I've post=
ed a formatted version of the idea here&nbsp;<a href=3D"https://github.com/=
berkus/cpp_named_args" target=3D"_blank">https://github.com/<wbr>berkus/cpp=
_named_args</a><div>
<br></div><div>I would like to hear what do you think is wrong with this ap=
proach and why would it not work, before I jump to patch up LLVM to support=
 this feature?</div></div><span><font color=3D"#888888">

<p></p>

<br></font></span></blockquote><div><br></div><div>How is this different fr=
om previous proposals for named arguments? <br></div></div><br></div></div>
</blockquote></div></blockquote></div></div></blockquote></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_284_8229686.1381181299011--

.

--089e013a132a35dce404e82e3796
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 7, 2013 at 2:28 PM, Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:

> @Berkus: What's the reason for requiring a colon in the parameter
> definition? I think this feature would be much more useful if it was
> allowed for any function call.
>

Please no. If you allow existing parameter names to gain semantics like
this, then renaming parameters becomes an ABI breaking change. Functions
should be required to opt into their parameter names having meaning.


> Presently labels are not allowed inside an expression so there should be
> no syntactic problem there.
>
> One problem would be that the formal names are allowed to be different in
> different declarations. A simple rule to counteract this problem would be
> to disallow the "label" from naming a parameter which is in different
> positions in different declarations (for any overload of the function).
>
> The big problem is overloaded functions, as overloads just match the type
> combination of the arguments at the call site. With named parameters we
> don't really know the type combination until we have selected an overload=
..
> But maybe this is not an unpassable obstacle. First we can rule out all
> signatures which don't have all the "labels" named in the call site. When
> this is done we can try to match each of the remaining signatures with th=
e
> actuals, performing permutations of the actuals based on the name order o=
f
> that particular candidate function. Some signatures may be ruled out as
> uncallable by this step, just as for any signature selection. FInally the
> "best" candidate should be possible to select using the same rules as for
> current call sites, with the same rules for ambiguous calls.
>
> Remains to be defined is what happens if we have unnamed arguments after =
a
> named one in the call site. One simple idea is to forbid this (A). I thin=
k
> this may be the best choice as it is easy to understand. Another
> possibility (B) is to have a "cursor" in the formal parameter list which =
is
> incremented after each argument and moved by a label. This is also quite
> easy to understand but is a bit error prone as you may get confused if
> different overloads have different subsequent parameters after a like-nam=
ed
> one. A third alternative (C) would be to have a "cursor" which only
> increments after unnamed actuals, so that named arguments can be written
> anywhere in the actuals list without affecting the enumeration of unnamed
> arguments. This I think is really scary.
>
> Both the two latter options create the possibility that the same formal
> parameter gets two different values at the call site. The issue is if thi=
s
> is only to rule out the particular overload where it happens or if it is
> misformed totally. A similar case in the B alternative is that you may
> state too many unnamed arguments after a labeled one. This is very simila=
r
> to stating too many unnamed arguments today, in which case the signatures
> taking fewer parameters are ruled out. This suggests that these cases
> should be treated similarly as the call site may still be valid for some
> other overload.
>
> As an extra feature it would be nice if you could just state the name of =
a
> bool parameter to set it to true. I don't think this would be possible as
> the same name may be defined in the scope of the call site, but with a
> trailing colon character it could work. This would not look as nice but
> still better than having to write "myBoolParameter: true" every time.
>
> I have actually implemented named parameters in an entirely different way=
,
> but that used a macro for the function name so it was really not a very
> good approach. The macro lifted its (variadic) parameters into a lambda
> where they were preceeded by a using of a special namespace containing th=
e
> parameter names as functions. The syntax at the call site became somethin=
g
> like this Window(Title("My Window"), CloseButton, Colour(0x404080)). Wind=
ow
> is the macro name and the other names are hidden in a namespace. The macr=
o
> expansion contains an object of a special type with an operator,() which
> picks up the results of all the argument functions. The boolean "turn on"
> feature CloseButton is implemented as a static object in the namespace.
> However ugly the implementation the appearance at the call site was quite
> nice...
>
> To implement this without using a macro something like "reverse ADL
> lookup" would be needed. By this I mean that in the argument list of a
> function call site you can use names from the namespace of the called
> function (or class of the method, even). I haven't given this much though=
t
> really, but it seems to be unworkable as the names like Colour in my
> example could be defined in the call site context and so changes the
> meaning of lots of code. Possibly reverse ADL could kick in only if
> everything else fails, but that's not how normal ADL works, is it? Ideall=
y
> it should be allowed to write Colour(Colour) in keeping with what is
> allowed in ctor initializer lists, but that does not seem reasonable to
> expect, as it needs more than a reverse ADL. One possibility would be to
> allow a "using namespace xyz;" inside the formals list to explicitly call
> for a reverse ADL to be allowed. Still a lot of boilerplate as each named
> parameter must be a ctor of some type and the called function be a variad=
ic
> template which calls methods in all these objects with "this" as a
> parameter. Lots of overhead there...
>
> This was an aside, more as a starting point for someone else to think of
> alternative approaches. Right now I would prefer the labeled arguments
> idea. Especially if the requirement to change function declarations can b=
e
> lifted it seems like a very useful feature that could be beneficial for
> many cases. There would be no overhead whatsoever to make functions
> callable in this way which compared to Boosts macros and boilerplate or t=
he
> runtime overhead of the .function().function() approach much easier to
> understand when looking at a call site. Note also that you can't use the
> function().function() approach for constructors of named variables:
>
> MyWindow window("Title").WithBorder().Sunken(); // Error!
>
> Bikeshed: I think that by calling this idea "labeled arguments"
> programmers will immediately understand what is meant. Well, at least the
> few that remember goto and labels (none, I wish!).
>
>
> Den m=E5ndagen den 7:e oktober 2013 kl. 19:32:05 UTC+2 skrev Berkus
> Infinitus:
>
>> Agree, pointers to previous proposals would be nice since I'm not very
>> familiar with isocpp processes.
>>
>> Also, it has been pointed out that the mandatory naming for named
>> arguments becomes a little bit redundant in cases like
>>
>> bool isReliable =3D /* some calculations */;
>> writeData(data, isReliable: isReliable); // oops, tautology
>>
>> To fix this I was thinking about removing the requirement for naming the
>> argument if it has an lvalue passed to it. This becomes more cumbersome =
as
>> it imposes restrictions on e.g. order of arguments (I wouldn't want make=
 a
>> compiler guess for example what a localised variable name means).
>>
>> The "named-parameter-idiom" from parashift.com is actually more like a
>> fluent interface and has been mentioned in my draft. While it's sometime=
s
>> viable, I think it's an abuse of the idiom.
>>
>>
>> About the question why my syntax is better than the previous ones
>> (without actually reading about any previous proposals): I think it uses=
 a
>> "label" semantic inside function call site, which has some sense, at lea=
st
>> to me, for the potentially arbitrarily placed arguments.
>>
>>
>> On Saturday, October 5, 2013 1:42:10 AM UTC+3, Troy Heron wrote:
>>>
>>> Can you point as to the previous proposal for named arguments?
>>>
>>> On Friday, 4 October 2013 21:32:24 UTC+10, Ville Voutilainen wrote:
>>>>
>>>>
>>>>
>>>>
>>>> On 4 October 2013 10:18, Berkus Infinitus <ber...@gmail.com> wrote:
>>>>
>>>>> I've been thinking about named arguments support in C++ with a simple=
,
>>>>> non-intrusive syntax. I've posted a formatted version of the idea her=
e
>>>>> https://github.com/**berkus/cpp_named_args<https://github.com/berkus/=
cpp_named_args>
>>>>>
>>>>> I would like to hear what do you think is wrong with this approach an=
d
>>>>> why would it not work, before I jump to patch up LLVM to support this
>>>>> feature?
>>>>>
>>>>>
>>>>>
>>>> How is this different from previous proposals for named arguments?
>>>>
>>>>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--089e013a132a35dce404e82e3796
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Oct 7, 2013 at 2:28 PM, Bengt Gustafsson <span dir=
=3D"ltr">&lt;<a href=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_bl=
ank">bengt.gustafsson@beamways.com</a>&gt;</span> wrote:<br><div class=3D"g=
mail_extra">
<div class=3D"gmail_quote"><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">=
@Berkus: What&#39;s the reason for requiring a colon in the parameter defin=
ition? I think this feature would be much more useful if it was allowed for=
 any function call.</div>
</blockquote><div><br></div><div>Please no. If you allow existing parameter=
 names to gain semantics like this, then renaming parameters becomes an ABI=
 breaking change. Functions should be required to opt into their parameter =
names having meaning.<br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Pr=
esently labels are not allowed inside an expression so there should be no s=
yntactic problem there.</div>
<div><br></div><div>One problem would be that the formal names are allowed =
to be different in different declarations. A simple rule to counteract this=
 problem would be to disallow the &quot;label&quot; from naming a parameter=
 which is in different positions in different declarations (for any overloa=
d of the function).</div>
<div><br></div><div>The big problem is overloaded functions, as overloads j=
ust match the type combination of the arguments at the call site. With name=
d parameters we don&#39;t really know the type combination until we have se=
lected an overload. But maybe this is not an unpassable obstacle. First we =
can rule out all signatures which don&#39;t have all the &quot;labels&quot;=
 named in the call site. When this is done we can try to match each of the =
remaining signatures with the actuals, performing permutations of the actua=
ls based on the name order of that particular candidate function. Some sign=
atures may be ruled out as uncallable by this step, just as for any signatu=
re selection. FInally the &quot;best&quot; candidate should be possible to =
select using the same rules as for current call sites, with the same rules =
for ambiguous calls.</div>
<div><br></div><div>Remains to be defined is what happens if we have unname=
d arguments after a named one in the call site. One simple idea is to forbi=
d this (A). I think this may be the best choice as it is easy to understand=
.. Another possibility (B) is to have a &quot;cursor&quot; in the formal par=
ameter list which is incremented after each argument and moved by a label. =
This is also quite easy to understand but is a bit error prone as you may g=
et confused if different overloads have different subsequent parameters aft=
er a like-named one. A third alternative (C) would be to have a &quot;curso=
r&quot; which only increments after unnamed actuals, so that named argument=
s can be written anywhere in the actuals list without affecting the enumera=
tion of unnamed arguments. This I think is really scary.</div>
<div><br></div><div>Both the two latter options create the possibility that=
 the same formal parameter gets two different values at the call site. The =
issue is if this is only to rule out the particular overload where it happe=
ns or if it is misformed totally. A similar case in the B alternative is th=
at you may state too many unnamed arguments after a labeled one. This is ve=
ry similar to stating too many unnamed arguments today, in which case the s=
ignatures taking fewer parameters are ruled out. This suggests that these c=
ases should be treated similarly as the call site may still be valid for so=
me other overload.</div>
<div><br></div><div>As an extra feature it would be nice if you could just =
state the name of a bool parameter to set it to true. I don&#39;t think thi=
s would be possible as the same name may be defined in the scope of the cal=
l site, but with a trailing colon character it could work. This would not l=
ook as nice but still better than having to write &quot;myBoolParameter: tr=
ue&quot; every time.</div>
<div><br></div><div>I have actually implemented named parameters in an enti=
rely different way, but that used a macro for the function name so it was r=
eally not a very good approach. The macro lifted its (variadic) parameters =
into a lambda where they were preceeded by a using of a special namespace c=
ontaining the parameter names as functions. The syntax at the call site bec=
ame something like this Window(Title(&quot;My Window&quot;), CloseButton, C=
olour(0x404080)). Window is the macro name and the other names are hidden i=
n a namespace. The macro expansion contains an object of a special type wit=
h an operator,() which picks up the results of all the argument functions. =
The boolean &quot;turn on&quot; feature CloseButton is implemented as a sta=
tic object in the namespace. However ugly the implementation the appearance=
 at the call site was quite nice...</div>
<div><br></div><div>To implement this without using a macro something like =
&quot;reverse ADL lookup&quot; would be needed. By this I mean that in the =
argument list of a function call site you can use names from the namespace =
of the called function (or class of the method, even). I haven&#39;t given =
this much thought really, but it seems to be unworkable as the names like C=
olour in my example could be defined in the call site context and so change=
s the meaning of lots of code. Possibly reverse ADL could kick in only if e=
verything else fails, but that&#39;s not how normal ADL works, is it? Ideal=
ly it should be allowed to write Colour(Colour) in keeping with what is all=
owed in ctor initializer lists, but that does not seem reasonable to expect=
, as it needs more than a reverse ADL. One possibility would be to allow a =
&quot;using namespace xyz;&quot; inside the formals list to explicitly call=
 for a reverse ADL to be allowed. Still a lot of boilerplate as each named =
parameter must be a ctor of some type and the called function be a variadic=
 template which calls methods in all these objects with &quot;this&quot; as=
 a parameter. Lots of overhead there...</div>
<div><br></div><div>This was an aside, more as a starting point for someone=
 else to think of alternative approaches. Right now I would prefer the labe=
led arguments idea. Especially if the requirement to change function declar=
ations can be lifted it seems like a very useful feature that could be bene=
ficial for many cases. There would be no overhead whatsoever to make functi=
ons callable in this way which compared to Boosts macros and boilerplate or=
 the runtime overhead of the .function().function() approach much easier to=
 understand when looking at a call site. Note also that you can&#39;t use t=
he function().function() approach for constructors of named variables:</div=
>
<div><br></div><div>MyWindow window(&quot;Title&quot;).WithBorder().Sunken(=
); // Error!</div><div><br></div><div>Bikeshed: I think that by calling thi=
s idea &quot;labeled arguments&quot; programmers will immediately understan=
d what is meant. Well, at least the few that remember goto and labels (none=
, I wish!).</div>
<div><br><br>Den m=E5ndagen den 7:e oktober 2013 kl. 19:32:05 UTC+2 skrev B=
erkus Infinitus:<div><div class=3D"h5"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex">
<div dir=3D"ltr">Agree, pointers to previous proposals would be nice since =
I&#39;m not very familiar with isocpp processes.<div><br></div><div>Also, i=
t has been pointed out that the mandatory naming for named arguments become=
s a little bit redundant in cases like</div>
<div><br></div><div>bool isReliable =3D /* some calculations */;</div><div>=
writeData(data, isReliable: isReliable); // oops, tautology</div><div><br><=
/div><div>To fix this I was thinking about removing the requirement for nam=
ing the argument if it has an lvalue passed to it. This becomes more cumber=
some as it imposes restrictions on e.g. order of arguments (I wouldn&#39;t =
want make a compiler guess for example what a localised variable name means=
).</div>
<div><br></div><div>The &quot;named-parameter-idiom&quot; from <a href=3D"h=
ttp://parashift.com" target=3D"_blank">parashift.com</a> is actually more l=
ike a fluent interface and has been mentioned in my draft. While it&#39;s s=
ometimes viable, I think it&#39;s an abuse of the idiom.</div>
<div><br></div><div><br></div><div>About the question why my syntax is bett=
er than the previous ones (without actually reading about any previous prop=
osals): I think it uses a &quot;label&quot; semantic inside function call s=
ite, which has some sense, at least to me, for the potentially arbitrarily =
placed arguments.</div>
<div><br></div><div><br>On Saturday, October 5, 2013 1:42:10 AM UTC+3, Troy=
 Heron wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Can y=
ou point as to the previous proposal for named arguments?<br>
<br>On Friday, 4 October 2013 21:32:24 UTC+10, Ville Voutilainen  wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div><br><br><div=
 class=3D"gmail_quote">
On 4 October 2013 10:18, Berkus Infinitus <span dir=3D"ltr">&lt;<a>ber...@g=
mail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I&#39;ve been thinking abou=
t named arguments support in C++ with a simple, non-intrusive syntax. I&#39=
;ve posted a formatted version of the idea here=A0<a href=3D"https://github=
..com/berkus/cpp_named_args" target=3D"_blank">https://github.com/<u></u>ber=
kus/cpp_named_args</a><div>

<br></div><div>I would like to hear what do you think is wrong with this ap=
proach and why would it not work, before I jump to patch up LLVM to support=
 this feature?</div></div><span><font color=3D"#888888">

<p></p>

<br></font></span></blockquote><div><br></div><div>How is this different fr=
om previous proposals for named arguments? <br></div></div><br></div></div>
</blockquote></div></blockquote></div></div></blockquote></div></div></div>=
</div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e013a132a35dce404e82e3796--

.

------=_Part_513_17779977.1381214337929
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Le mardi 8 octobre 2013 00:31:39 UTC+2, Richard Smith a =E9crit :

> On Mon, Oct 7, 2013 at 2:28 PM, Bengt Gustafsson <bengt.gu...@beamways.co=
m<javascript:>
> > wrote:
>
>> @Berkus: What's the reason for requiring a colon in the parameter=20
>> definition? I think this feature would be much more useful if it was=20
>> allowed for any function call.
>>
>
> Please no. If you allow existing parameter names to gain semantics like=
=20
> this, then renaming parameters becomes an ABI breaking change. Functions=
=20
> should be required to opt into their parameter names having meaning.
>
> API not ABI I assume?  If not, could you point out the implications I've=
=20
missed? (I agree that it doesn't make a difference, it should be an opt-in)=
..

Thanks,

--=20
Jean-Marc

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_513_17779977.1381214337929
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Le mardi 8 octobre 2013 00:31:39 UTC+2, Richard Smith a =
=E9crit&nbsp;:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">On Mon, Oct 7, 2013 at 2:28 PM, Bengt Gustafsson <span dir=3D"ltr">&lt=
;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"wOioUBI=
hbXcJ">bengt.gu...@beamways.com</a><wbr>&gt;</span> wrote:<br><div>
<div class=3D"gmail_quote"><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">=
@Berkus: What's the reason for requiring a colon in the parameter definitio=
n? I think this feature would be much more useful if it was allowed for any=
 function call.</div>
</blockquote><div><br></div><div>Please no. If you allow existing parameter=
 names to gain semantics like this, then renaming parameters becomes an ABI=
 breaking change. Functions should be required to opt into their parameter =
names having meaning.<br>
</div><div><br></div></div></div></div></blockquote><div>API not ABI I assu=
me? &nbsp;If not, could you point out the implications I've missed? (I agre=
e that it doesn't make a difference, it should be an opt-in).</div><div><br=
></div><div>Thanks,</div><div><br></div><div>--&nbsp;</div><div>Jean-Marc</=
div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_513_17779977.1381214337929--

.

--089e011766e547775104e8378826
Content-Type: text/plain; charset=ISO-8859-1

On 8 October 2013 04:32, Berkus Infinitus <berkus@gmail.com> wrote:

> about removing the requirement for naming the a


I like the idea of named arguments and find them very useful in other
languages. One thing I use a bit in python is perfect forwarding with named
args. It would be worth spending some time to think if this proposal could
work with perfect forwarding.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e011766e547775104e8378826
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 8 October 2013 04:32, Berkus Infinitus <span dir=3D"ltr">&lt;<a href=3D"=
mailto:berkus@gmail.com" target=3D"_blank">berkus@gmail.com</a>&gt;</span> =
wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"> about removing the requirement for naming the a</blockquo=
te>
</div><br>I like the idea of named arguments and find them very useful in o=
ther languages. One thing I use a bit in python is perfect forwarding with =
named args. It would be worth spending some time to think if this proposal =
could work with perfect forwarding.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><div style=
=3D"font-family:arial,sans-serif;font-size:13px"><br></div></div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">
<br></div><div class=3D"gmail_extra"><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e011766e547775104e8378826--

.

--001a11c3657e41022904e83a8cd8
Content-Type: text/plain; charset=ISO-8859-1

As far as I can tell, there are two different use cases for named arguments:

1. Documentation of call parameters. This could easily be faked by adding
comments, as in: write_datagram(buf, size, /* is_reliable */ true)  ugly as
****, but works.

2. Skipping over optional arguments.


This is what I propose:

a) For the documentation problem: If an argument name in a function
declaration is immediately followed by a colon, the argument name must be
present also in all calls. No reordering of arguments is allowed here;
named arguments must stay in the same place as they are in the function
signature. This would reduce the problem as a parsing one: The compiler
should issue an error (maybe a warning) if no name is given for a named
arg, but can forget about the parameter labeling from then on.

b) Skipping over optional arguments. I would follow here the same rules as
for optional args:

      - In a function declaration, if an optional argument name is followed
by a colon, that turns it into a named argument. As with optional args, all
arguments following it must also be named arguments.
      - In a function call, if a named optional argument is labelled, all
arguments from then on must also be labelled. As in case a), arguments must
also be in the same order as in the function declaration.


In both cases, the rule that parameters must keep the same order as in the
function declaration preserves the signature, so no new
ambiguities are introduced. In fact, the function definition must not know
about named args, just as it doesn't know about default values.



A final note about the syntax. I like the use of the colon in the function
declaration, that turns the argument name into a label; but on function
calls I would prefer the equal sign; it makes the purpose clearer:

write_datagram(buf, size, is_reliable: true);

vs

write_datagram(buf, size, is_reliable=true);



2013/10/8 Brendon Costa <brendon.j.costa@gmail.com>

>
> On 8 October 2013 04:32, Berkus Infinitus <berkus@gmail.com> wrote:
>
>> about removing the requirement for naming the a
>
>
> I like the idea of named arguments and find them very useful in other
> languages. One thing I use a bit in python is perfect forwarding with named
> args. It would be worth spending some time to think if this proposal could
> work with perfect forwarding.
>
>
>
>
>
>
>  --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c3657e41022904e83a8cd8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">As far as I can tell, there are two different use cases fo=
r named arguments:<div><br></div><div>1. Documentation of call parameters. =
This could easily be faked by adding comments, as in: write_datagram(buf, s=
ize, /* is_reliable */ true) =A0ugly as ****, but works.</div>


<div><br></div><div>2. Skipping over optional arguments.</div><div><br></di=
v><div><br></div><div style>This is what I propose:</div><div><br></div><di=
v>a) For the documentation problem: If an argument name in a function decla=
ration is immediately followed by a colon, the argument name must be presen=
t also in all calls. No reordering of arguments is allowed here; named argu=
ments must stay in the same place as they are in the function signature. Th=
is would reduce the problem as a parsing one: The compiler should issue an =
error (maybe a warning) if no name is given for a named arg, but can forget=
 about the parameter labeling from then on.</div>


<div><br></div><div>b) Skipping over optional arguments. I would follow her=
e the same rules as for optional args:</div><div><br></div><div>=A0 =A0 =A0=
 - In a function declaration, if an optional argument name is followed by a=
 colon, that turns it into a named argument. As with optional args, all arg=
uments following it must also be named arguments.</div>


<div>=A0 =A0 =A0 - In a function call, if a named optional argument is labe=
lled, all arguments from then on must also be labelled. As in case a), argu=
ments must also be in the same order as in the function declaration.<br></d=
iv>


<div><br></div><div><br></div><div>In both cases, the rule that parameters =
must keep the same order as in the function declaration preserves the signa=
ture, so no new=A0</div><div>ambiguities are introduced. In fact, the funct=
ion definition must not know about named args, just as it doesn&#39;t know =
about default values.</div>
<div><br></div><div style><br></div><div style><br></div><div style>A final=
 note about the syntax. I like the use of the colon in the function declara=
tion, that turns the argument name into a label; but on function calls I wo=
uld prefer the equal sign; it makes the purpose clearer:</div>
<div style><br></div><div style><pre style=3D"font-family:Consolas,&#39;Lib=
eration Mono&#39;,Courier,monospace;font-size:13px;margin-top:15px;margin-b=
ottom:15px;background-color:rgb(248,248,248);border:1px solid rgb(221,221,2=
21);line-height:19px;overflow:auto;padding:6px 10px;border-top-left-radius:=
3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-botto=
m-left-radius:3px;color:rgb(51,51,51)">
<code style=3D"font-family:Consolas,&#39;Liberation Mono&#39;,Courier,monos=
pace;font-size:12px;margin:0px;padding:0px;border:none;background-color:tra=
nsparent;border-top-left-radius:3px;border-top-right-radius:3px;border-bott=
om-right-radius:3px;border-bottom-left-radius:3px">write_datagram(buf, size=
, is_reliable: true);</code></pre>
</div><div style>vs</div><div style><pre style=3D"font-family:Consolas,&#39=
;Liberation Mono&#39;,Courier,monospace;font-size:13px;margin-top:15px;marg=
in-bottom:15px;background-color:rgb(248,248,248);border:1px solid rgb(221,2=
21,221);line-height:19px;overflow:auto;padding:6px 10px;border-top-left-rad=
ius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-b=
ottom-left-radius:3px;color:rgb(51,51,51)">
<code style=3D"font-family:Consolas,&#39;Liberation Mono&#39;,Courier,monos=
pace;font-size:12px;margin:0px;padding:0px;border:none;background-color:tra=
nsparent;border-top-left-radius:3px;border-top-right-radius:3px;border-bott=
om-right-radius:3px;border-bottom-left-radius:3px">write_datagram(buf, size=
, is_reliable=3Dtrue);</code></pre>
</div>

</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/10=
/8 Brendon Costa <span dir=3D"ltr">&lt;<a href=3D"mailto:brendon.j.costa@gm=
ail.com" target=3D"_blank">brendon.j.costa@gmail.com</a>&gt;</span><br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"im"><br><div clas=
s=3D"gmail_quote">On 8 October 2013 04:32, Berkus Infinitus <span dir=3D"lt=
r">&lt;<a href=3D"mailto:berkus@gmail.com" target=3D"_blank">berkus@gmail.c=
om</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"> about removing the requirement for naming the a</blockquo=
te>

</div><br></div>I like the idea of named arguments and find them very usefu=
l in other languages. One thing I use a bit in python is perfect forwarding=
 with named args. It would be worth spending some time to think if this pro=
posal could work with perfect forwarding.</div>

<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><div style=
=3D"font-family:arial,sans-serif;font-size:13px"><br></div></div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">

<br></div><div class=3D"gmail_extra"><br></div></div><div class=3D"HOEnZb">=
<div class=3D"h5">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c3657e41022904e83a8cd8--

.

--001a11c35c289d2f3804e83ac2bb
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 8 October 2013 16:14, Diego S=E1nchez <dsde71@gmail.com> wrote:

>
>
>
> A final note about the syntax. I like the use of the colon in the functio=
n
> declaration, that turns the argument name into a label; but on function
> calls I would prefer the equal sign; it makes the purpose clearer:
>
> write_datagram(buf, size, is_reliable: true);
>
> vs
>
> write_datagram(buf, size, is_reliable=3Dtrue);
>
>
>
>
'fraid we can't have that. This is already valid:

void f(bool x) {}
int main()
{
    bool x=3Dfalse;
    f(x=3Dtrue);
}

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a11c35c289d2f3804e83ac2bb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 8 October 2013 16:14, Diego S=E1nchez <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:dsde71@gmail.com" target=3D"_blank">dsde71@gmail.com</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br><div=
><br></div><div><br></div><div>A final note about the syntax. I like the us=
e of the colon in the function declaration, that turns the argument name in=
to a label; but on function calls I would prefer the equal sign; it makes t=
he purpose clearer:</div>

<div><br></div><div><pre style=3D"font-family:Consolas,&#39;Liberation Mono=
&#39;,Courier,monospace;font-size:13px;margin-top:15px;margin-bottom:15px;b=
ackground-color:rgb(248,248,248);border:1px solid rgb(221,221,221);line-hei=
ght:19px;overflow:auto;padding:6px 10px;border-radius:3px 3px 3px 3px;color=
:rgb(51,51,51)">
<code style=3D"font-family:Consolas,&#39;Liberation Mono&#39;,Courier,monos=
pace;font-size:12px;margin:0px;padding:0px;border:medium none;background-co=
lor:transparent;border-radius:3px 3px 3px 3px">write_datagram(buf, size, is=
_reliable: true);</code></pre>

</div><div>vs</div><div><pre style=3D"font-family:Consolas,&#39;Liberation =
Mono&#39;,Courier,monospace;font-size:13px;margin-top:15px;margin-bottom:15=
px;background-color:rgb(248,248,248);border:1px solid rgb(221,221,221);line=
-height:19px;overflow:auto;padding:6px 10px;border-radius:3px 3px 3px 3px;c=
olor:rgb(51,51,51)">
<code style=3D"font-family:Consolas,&#39;Liberation Mono&#39;,Courier,monos=
pace;font-size:12px;margin:0px;padding:0px;border:medium none;background-co=
lor:transparent;border-radius:3px 3px 3px 3px">write_datagram(buf, size, is=
_reliable=3Dtrue);</code></pre>

</div>

</div><div class=3D""><div class=3D"h5"><div class=3D"gmail_extra"><br><br>=
</div></div></div></blockquote><div><br></div><div>&#39;fraid we can&#39;t =
have that. This is already valid:<br><br>void f(bool x) {} <br>int main() <=
br>
{<br>=A0=A0=A0 bool x=3Dfalse; <br>=A0=A0=A0 f(x=3Dtrue);<br>}<br></div></d=
iv></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c35c289d2f3804e83ac2bb--

.

------=_Part_308_30287728.1381239254411
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

 Oops!  That should have been obvious.

El martes, 8 de octubre de 2013 15:29:37 UTC+2, Ville Voutilainen escribi=
=F3:
>
>
>
>
> On 8 October 2013 16:14, Diego S=E1nchez <dsd...@gmail.com <javascript:>>=
wrote:
>
>>
>>
>>
>> A final note about the syntax. I like the use of the colon in the=20
>> function declaration, that turns the argument name into a label; but on=
=20
>> function calls I would prefer the equal sign; it makes the purpose clear=
er:
>>
>> write_datagram(buf, size, is_reliable: true);
>>
>> vs
>>
>> write_datagram(buf, size, is_reliable=3Dtrue);
>>
>> =20
>>
>>
> 'fraid we can't have that. This is already valid:
>
> void f(bool x) {}=20
> int main()=20
> {
>     bool x=3Dfalse;=20
>     f(x=3Dtrue);
> }
>

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_308_30287728.1381239254411
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&nbsp;Oops! &nbsp;That should have been obvious.<br><br>El=
 martes, 8 de octubre de 2013 15:29:37 UTC+2, Ville Voutilainen  escribi=F3=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div><br=
><br><div class=3D"gmail_quote">On 8 October 2013 16:14, Diego S=E1nchez <s=
pan dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"f04L1LaAW_QJ">dsd...@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br><div=
><br></div><div><br></div><div>A final note about the syntax. I like the us=
e of the colon in the function declaration, that turns the argument name in=
to a label; but on function calls I would prefer the equal sign; it makes t=
he purpose clearer:</div>

<div><br></div><div><pre style=3D"font-family:Consolas,'Liberation Mono',Co=
urier,monospace;font-size:13px;margin-top:15px;margin-bottom:15px;backgroun=
d-color:rgb(248,248,248);border:1px solid rgb(221,221,221);line-height:19px=
;overflow:auto;padding:6px 10px;border-radius:3px 3px 3px 3px;color:rgb(51,=
51,51)"><code style=3D"font-family:Consolas,'Liberation Mono',Courier,monos=
pace;font-size:12px;margin:0px;padding:0px;border:medium none;background-co=
lor:transparent;border-radius:3px 3px 3px 3px">write_datagram(buf, size, is=
_reliable: true);</code></pre>

</div><div>vs</div><div><pre style=3D"font-family:Consolas,'Liberation Mono=
',Courier,monospace;font-size:13px;margin-top:15px;margin-bottom:15px;backg=
round-color:rgb(248,248,248);border:1px solid rgb(221,221,221);line-height:=
19px;overflow:auto;padding:6px 10px;border-radius:3px 3px 3px 3px;color:rgb=
(51,51,51)"><code style=3D"font-family:Consolas,'Liberation Mono',Courier,m=
onospace;font-size:12px;margin:0px;padding:0px;border:medium none;backgroun=
d-color:transparent;border-radius:3px 3px 3px 3px">write_datagram(buf, size=
, is_reliable=3Dtrue);</code></pre>

</div>

</div><div><div><div><br><br></div></div></div></blockquote><div><br></div>=
<div>'fraid we can't have that. This is already valid:<br><br>void f(bool x=
) {} <br>int main() <br>
{<br>&nbsp;&nbsp;&nbsp; bool x=3Dfalse; <br>&nbsp;&nbsp;&nbsp; f(x=3Dtrue);=
<br>}<br></div></div></div></div>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_308_30287728.1381239254411--

.

--047d7bdc9c528e732e04e83ad44c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 8 October 2013 16:14, Diego S=E1nchez <dsde71@gmail.com> wrote:

> As far as I can tell, there are two different use cases for named
> arguments:
>
> 1. Documentation of call parameters. This could easily be faked by adding
> comments, as in: write_datagram(buf, size, /* is_reliable */ true)  ugly =
as
> ****, but works.
>
> 2. Skipping over optional arguments.
>
>
> This is what I propose:
>
> a) For the documentation problem: If an argument name in a function
> declaration is immediately followed by a colon, the argument name must be
> present also in all calls. No reordering of arguments is allowed here;
> named arguments must stay in the same place as they are in the function
> signature. This would reduce the problem as a parsing one: The compiler
> should issue an error (maybe a warning) if no name is given for a named
> arg, but can forget about the parameter labeling from then on.
>
> b) Skipping over optional arguments. I would follow here the same rules a=
s
> for optional args:
>
>       - In a function declaration, if an optional argument name is
> followed by a colon, that turns it into a named argument. As with optiona=
l
> args, all arguments following it must also be named arguments.
>       - In a function call, if a named optional argument is labelled, all
> arguments from then on must also be labelled. As in case a), arguments mu=
st
> also be in the same order as in the function declaration.
>
>
> In both cases, the rule that parameters must keep the same order as in th=
e
> function declaration preserves the signature, so no new
> ambiguities are introduced. In fact, the function definition must not kno=
w
> about named args, just as it doesn't know about default values.
>
>
>
Funny. I'd expect

void f(int x : 0, int y : 0, int z : 0);

to be callable as
f(y : 42); // 'unordered' call, use default args for x and z

so I don't quite grasp what the same-order requirement buys. Furthermore,
I'd expect
it to be callable as
f(42); // 'ordered' call, use default args for y and z
and
f(42, 666); // 'ordered' call, use default args for z

What is the interesting question is whether to allow mixing, like

f(666, z : 5); // ' x=3D666, y=3D0, z=3D5

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--047d7bdc9c528e732e04e83ad44c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 8 October 2013 16:14, Diego S=E1nchez <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:dsde71@gmail.com" target=3D"_blank">dsde71@gmail.com</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">As far as I can tell, there=
 are two different use cases for named arguments:<div><br></div><div>1. Doc=
umentation of call parameters. This could easily be faked by adding comment=
s, as in: write_datagram(buf, size, /* is_reliable */ true) =A0ugly as ****=
, but works.</div>



<div><br></div><div>2. Skipping over optional arguments.</div><div><br></di=
v><div><br></div><div>This is what I propose:</div><div><br></div><div>a) F=
or the documentation problem: If an argument name in a function declaration=
 is immediately followed by a colon, the argument name must be present also=
 in all calls. No reordering of arguments is allowed here; named arguments =
must stay in the same place as they are in the function signature. This wou=
ld reduce the problem as a parsing one: The compiler should issue an error =
(maybe a warning) if no name is given for a named arg, but can forget about=
 the parameter labeling from then on.</div>



<div><br></div><div>b) Skipping over optional arguments. I would follow her=
e the same rules as for optional args:</div><div><br></div><div>=A0 =A0 =A0=
 - In a function declaration, if an optional argument name is followed by a=
 colon, that turns it into a named argument. As with optional args, all arg=
uments following it must also be named arguments.</div>



<div>=A0 =A0 =A0 - In a function call, if a named optional argument is labe=
lled, all arguments from then on must also be labelled. As in case a), argu=
ments must also be in the same order as in the function declaration.<br></d=
iv>



<div><br></div><div><br></div><div>In both cases, the rule that parameters =
must keep the same order as in the function declaration preserves the signa=
ture, so no new=A0</div><div>ambiguities are introduced. In fact, the funct=
ion definition must not know about named args, just as it doesn&#39;t know =
about default values.</div>

<div><br><br></div></div></blockquote><div><br></div><div>Funny. I&#39;d ex=
pect<br><br></div><div>void f(int x : 0, int y : 0, int z : 0);<br><br></di=
v><div>to be callable as<br>f(y : 42); // &#39;unordered&#39; call, use def=
ault args for x and z <br>
</div></div><br></div><div class=3D"gmail_extra">so I don&#39;t quite grasp=
 what the same-order requirement buys. Furthermore, I&#39;d expect<br>it to=
 be callable as<br>f(42); // &#39;ordered&#39; call, use default args for y=
 and z<br>
</div><div class=3D"gmail_extra">and<br>f(42, 666); // &#39;ordered&#39; ca=
ll, use default args for z<br><br></div><div class=3D"gmail_extra">What is =
the interesting question is whether to allow mixing, like<br><br></div><div=
 class=3D"gmail_extra">
f(666, z : 5); // &#39; x=3D666, y=3D0, z=3D5<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bdc9c528e732e04e83ad44c--

.

------=_Part_347_25275306.1381241216025
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



El martes, 8 de octubre de 2013 15:34:38 UTC+2, Ville Voutilainen escribi=
=F3:
>
>
>
>
> On 8 October 2013 16:14, Diego S=E1nchez <dsd...@gmail.com <javascript:>>=
wrote:
>
>> As far as I can tell, there are two different use cases for named=20
>> arguments:
>>
>> 1. Documentation of call parameters. This could easily be faked by addin=
g=20
>> comments, as in: write_datagram(buf, size, /* is_reliable */ true)  ugly=
 as=20
>> ****, but works.
>>
>> 2. Skipping over optional arguments.
>>
>>
>> This is what I propose:
>>
>> a) For the documentation problem: If an argument name in a function=20
>> declaration is immediately followed by a colon, the argument name must b=
e=20
>> present also in all calls. No reordering of arguments is allowed here;=
=20
>> named arguments must stay in the same place as they are in the function=
=20
>> signature. This would reduce the problem as a parsing one: The compiler=
=20
>> should issue an error (maybe a warning) if no name is given for a named=
=20
>> arg, but can forget about the parameter labeling from then on.
>>
>> b) Skipping over optional arguments. I would follow here the same rules=
=20
>> as for optional args:
>>
>>       - In a function declaration, if an optional argument name is=20
>> followed by a colon, that turns it into a named argument. As with option=
al=20
>> args, all arguments following it must also be named arguments.
>>       - In a function call, if a named optional argument is labelled, al=
l=20
>> arguments from then on must also be labelled. As in case a), arguments m=
ust=20
>> also be in the same order as in the function declaration.
>>
>>
>> In both cases, the rule that parameters must keep the same order as in=
=20
>> the function declaration preserves the signature, so no new=20
>> ambiguities are introduced. In fact, the function definition must not=20
>> know about named args, just as it doesn't know about default values.
>>
>>
>>
> Funny. I'd expect
>
> void f(int x : 0, int y : 0, int z : 0);
>
> to be callable as
> f(y : 42); // 'unordered' call, use default args for x and z=20
>
> so I don't quite grasp what the same-order requirement buys. Furthermore,=
=20
> I'd expect
> it to be callable as
> f(42); // 'ordered' call, use default args for y and z
> and
> f(42, 666); // 'ordered' call, use default args for z
>
> What is the interesting question is whether to allow mixing, like
>
> f(666, z : 5); // ' x=3D666, y=3D0, z=3D5
>

The idea is that you can call f( y : 42 )  or f ( y :42, z : 666 ), but not=
=20
f( z: 666, y: 42 ). This would preserve the function signature after=20
filling the gaps.

Say you have void g ( int a : 0, float b: 0, bool c : true )

g( b:1, c:false )  is void ()( int, float, bool ) =20
g( c:true, b:2 ) is void ()( int, bool, float )


Regarding mixing, I'm not sure what could be better. My idea was that for=
=20
optional arguments, after you start labeling, you must keep labeling; i.e.:=
=20
f( 5, y:42, z:666 ), but not  f( 5, y:42, 666 ) , but on second thought=20
there is no real need for that; the next argument after y must be z .


--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_347_25275306.1381241216025
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br></div><br>El martes, 8 de octubre de 2013 15:34:3=
8 UTC+2, Ville Voutilainen  escribi=F3:<blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><br><div><br><br><div class=3D"gmail_quote">On 8 =
October 2013 16:14, Diego S=E1nchez <span dir=3D"ltr">&lt;<a href=3D"javasc=
ript:" target=3D"_blank" gdf-obfuscated-mailto=3D"_swMaper9TcJ">dsd...@gmai=
l.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">As far as I can tell, there=
 are two different use cases for named arguments:<div><br></div><div>1. Doc=
umentation of call parameters. This could easily be faked by adding comment=
s, as in: write_datagram(buf, size, /* is_reliable */ true) &nbsp;ugly as *=
***, but works.</div>



<div><br></div><div>2. Skipping over optional arguments.</div><div><br></di=
v><div><br></div><div>This is what I propose:</div><div><br></div><div>a) F=
or the documentation problem: If an argument name in a function declaration=
 is immediately followed by a colon, the argument name must be present also=
 in all calls. No reordering of arguments is allowed here; named arguments =
must stay in the same place as they are in the function signature. This wou=
ld reduce the problem as a parsing one: The compiler should issue an error =
(maybe a warning) if no name is given for a named arg, but can forget about=
 the parameter labeling from then on.</div>



<div><br></div><div>b) Skipping over optional arguments. I would follow her=
e the same rules as for optional args:</div><div><br></div><div>&nbsp; &nbs=
p; &nbsp; - In a function declaration, if an optional argument name is foll=
owed by a colon, that turns it into a named argument. As with optional args=
, all arguments following it must also be named arguments.</div>



<div>&nbsp; &nbsp; &nbsp; - In a function call, if a named optional argumen=
t is labelled, all arguments from then on must also be labelled. As in case=
 a), arguments must also be in the same order as in the function declaratio=
n.<br></div>



<div><br></div><div><br></div><div>In both cases, the rule that parameters =
must keep the same order as in the function declaration preserves the signa=
ture, so no new&nbsp;</div><div>ambiguities are introduced. In fact, the fu=
nction definition must not know about named args, just as it doesn't know a=
bout default values.</div>

<div><br><br></div></div></blockquote><div><br></div><div>Funny. I'd expect=
<br><br></div><div>void f(int x : 0, int y : 0, int z : 0);<br><br></div><d=
iv>to be callable as<br>f(y : 42); // 'unordered' call, use default args fo=
r x and z <br>
</div></div><br></div><div>so I don't quite grasp what the same-order requi=
rement buys. Furthermore, I'd expect<br>it to be callable as<br>f(42); // '=
ordered' call, use default args for y and z<br>
</div><div>and<br>f(42, 666); // 'ordered' call, use default args for z<br>=
<br></div><div>What is the interesting question is whether to allow mixing,=
 like<br><br></div><div>
f(666, z : 5); // ' x=3D666, y=3D0, z=3D5<br></div></div></blockquote><div>=
<br></div><div>The idea is that you can call f( y : 42 ) &nbsp;or f ( y :42=
, z : 666 ), but not f( z: 666, y: 42 ). This would preserve the function s=
ignature after filling the gaps.<br></div><div><br></div><div>Say you have =
void g ( int a : 0, float b: 0, bool c : true )</div><div><br></div><div>g(=
 b:1, c:false ) &nbsp;is void ()( int, float, bool ) &nbsp;</div><div>g( c:=
true, b:2 ) is void ()( int, bool, float )</div><div><br></div><div><br></d=
iv><div>Regarding mixing, I'm not sure what could be better. My idea was th=
at for optional arguments, after you start labeling, you must keep labeling=
; i.e.: f( 5, y:42, z:666 ), but not &nbsp;f( 5, y:42, 666 ) , but on secon=
d thought there is no real need for that; the next argument after y must be=
 z .</div><div><br></div><div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_347_25275306.1381241216025--

.

--047d7bdc9c529e6bf904e83b554d
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 8 October 2013 17:06, Diego S=E1nchez <dsde71@gmail.com> wrote:

>
> Funny. I'd expect
>>
>> void f(int x : 0, int y : 0, int z : 0);
>>
>> to be callable as
>> f(y : 42); // 'unordered' call, use default args for x and z
>>
>> so I don't quite grasp what the same-order requirement buys. Furthermore=
,
>> I'd expect
>> it to be callable as
>> f(42); // 'ordered' call, use default args for y and z
>> and
>> f(42, 666); // 'ordered' call, use default args for z
>>
>> What is the interesting question is whether to allow mixing, like
>>
>> f(666, z : 5); // ' x=3D666, y=3D0, z=3D5
>>
>
> The idea is that you can call f( y : 42 )  or f ( y :42, z : 666 ), but
> not f( z: 666, y: 42 ). This would preserve the function signature after
> filling the gaps.
>

I understand that. I don't think we should have such a restriction about
the order of named
arguments.


>
> Say you have void g ( int a : 0, float b: 0, bool c : true )
>
> g( b:1, c:false )  is void ()( int, float, bool )
> g( c:true, b:2 ) is void ()( int, bool, float )
>

Please, no.


>
>
> Regarding mixing, I'm not sure what could be better. My idea was that for
> optional arguments, after you start labeling, you must keep labeling; i.e=
..:
> f( 5, y:42, z:666 ), but not  f( 5, y:42, 666 ) , but on second thought
> there is no real need for that; the next argument after y must be z .
>
>
>
I would be fine with the restriction that once labeling starts, it can't
stop. Especially if we
don't restrict the ordering of labeled arguments themselves in calls. This
is how it's
done in Lisp, for instance, and it works just fine.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--047d7bdc9c529e6bf904e83b554d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 8 October 2013 17:06, Diego S=E1nchez <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:dsde71@gmail.com" target=3D"_blank">dsde71@gmail.com</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div><div class=3D"h5">=
<blockquote 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"><div><div class=3D"gmail_quote"><div>Funny. I&#39;d expect=
<br><br></div><div>void f(int x : 0, int y : 0, int z : 0);<br><br></div><d=
iv>to be callable as<br>f(y : 42); // &#39;unordered&#39; call, use default=
 args for x and z <br>

</div></div><br></div><div>so I don&#39;t quite grasp what the same-order r=
equirement buys. Furthermore, I&#39;d expect<br>it to be callable as<br>f(4=
2); // &#39;ordered&#39; call, use default args for y and z<br>
</div><div>and<br>f(42, 666); // &#39;ordered&#39; call, use default args f=
or z<br><br></div><div>What is the interesting question is whether to allow=
 mixing, like<br><br></div><div>
f(666, z : 5); // &#39; x=3D666, y=3D0, z=3D5<br></div></div></blockquote><=
div><br></div></div></div><div>The idea is that you can call f( y : 42 ) =
=A0or f ( y :42, z : 666 ), but not f( z: 666, y: 42 ). This would preserve=
 the function signature after filling the gaps.<br>
</div></div></blockquote><div><br></div><div>I understand that. I don&#39;t=
 think we should have such a restriction about the order of named<br>argume=
nts.<br>=A0<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></div><div><br></div><div>Say you have void g ( int a=
 : 0, float b: 0, bool c : true )</div><div><br></div><div>g( b:1, c:false =
) =A0is void ()( int, float, bool ) =A0</div><div>g( c:true, b:2 ) is void =
()( int, bool, float )</div>
</div></blockquote><div><br></div><div>Please, no.<br>=A0<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div><br></div><div>=
Regarding mixing, I&#39;m not sure what could be better. My idea was that f=
or optional arguments, after you start labeling, you must keep labeling; i.=
e.: f( 5, y:42, z:666 ), but not =A0f( 5, y:42, 666 ) , but on second thoug=
ht there is no real need for that; the next argument after y must be z .</d=
iv>
<div><br><br></div></div></blockquote><div><br></div><div>I would be fine w=
ith the restriction that once labeling starts, it can&#39;t stop. Especiall=
y if we<br>don&#39;t restrict the ordering of labeled arguments themselves =
in calls. This is how it&#39;s<br>
done in Lisp, for instance, and it works just fine. <br></div></div><br></d=
iv></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bdc9c529e6bf904e83b554d--

.

On Tue, Oct 8, 2013 at 9:34 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> Funny. I'd expect
>
> void f(int x : 0, int y : 0, int z : 0);
>
> to be callable as
> f(y : 42); // 'unordered' call, use default args for x and z
>
> so I don't quite grasp what the same-order requirement buys. Furthermore,
> I'd expect
> it to be callable as
> f(42); // 'ordered' call, use default args for y and z
> and
> f(42, 666); // 'ordered' call, use default args for z

I hope order call is not supported on named arguments at all.  Python 2
has it, but caused lots of problems, especially when a signature is
changed, the old problem may still run but runtime behavior is silently
changed, which is really horrible, and finally people added "keyword-
only argument" in Python 3.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a11c35c28ad94fb04e83b987f
Content-Type: text/plain; charset=ISO-8859-1

On 8 October 2013 17:22, Zhihao Yuan <zy@miator.net> wrote:

> On Tue, Oct 8, 2013 at 9:34 AM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
> > Funny. I'd expect
> >
> > void f(int x : 0, int y : 0, int z : 0);
> >
> > to be callable as
> > f(y : 42); // 'unordered' call, use default args for x and z
> >
> > so I don't quite grasp what the same-order requirement buys. Furthermore,
> > I'd expect
> > it to be callable as
> > f(42); // 'ordered' call, use default args for y and z
> > and
> > f(42, 666); // 'ordered' call, use default args for z
>
> I hope order call is not supported on named arguments at all.  Python 2
> has it, but caused lots of problems, especially when a signature is
> changed, the old problem may still run but runtime behavior is silently
> changed, which is really horrible, and finally people added "keyword-
> only argument" in Python 3.
>
>
>
It doesn't cause any problem that wasn't always present with functions
ever since c++98. If a user is concerned about that, he should use
named arguments in his calls, but I see no reason to prevent
unnamed arguments for those who wish to use them.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c35c28ad94fb04e83b987f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 8 October 2013 17:22, Zhihao Yuan <span dir=3D"ltr">&lt;<a href=
=3D"mailto:zy@miator.net" target=3D"_blank">zy@miator.net</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Tue, Oct 8, 2013 at 9:34 AM, Ville Voutilainen<br>
&lt;<a href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.=
com</a>&gt; wrote:<br>
&gt; Funny. I&#39;d expect<br>
&gt;<br>
&gt; void f(int x : 0, int y : 0, int z : 0);<br>
&gt;<br>
&gt; to be callable as<br>
&gt; f(y : 42); // &#39;unordered&#39; call, use default args for x and z<b=
r>
&gt;<br>
&gt; so I don&#39;t quite grasp what the same-order requirement buys. Furth=
ermore,<br>
&gt; I&#39;d expect<br>
&gt; it to be callable as<br>
&gt; f(42); // &#39;ordered&#39; call, use default args for y and z<br>
&gt; and<br>
&gt; f(42, 666); // &#39;ordered&#39; call, use default args for z<br>
<br>
</div>I hope order call is not supported on named arguments at all. =A0Pyth=
on 2<br>
has it, but caused lots of problems, especially when a signature is<br>
changed, the old problem may still run but runtime behavior is silently<br>
changed, which is really horrible, and finally people added &quot;keyword-<=
br>
only argument&quot; in Python 3.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br><br></font></span></bloc=
kquote><div><br></div><div>It doesn&#39;t cause any problem that wasn&#39;t=
 always present with functions<br>ever since c++98. If a user is concerned =
about that, he should use<br>
</div><div>named arguments in his calls, but I see no reason to prevent<br>=
</div><div>unnamed arguments for those who wish to use them. <br></div></di=
v><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c35c28ad94fb04e83b987f--

.

On Tue, Oct 8, 2013 at 10:29 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
>> I hope order call is not supported on named arguments at all.  Python 2
>> has it, but caused lots of problems, especially when a signature is
>> changed, the old problem may still run but runtime behavior is silently
>> changed, which is really horrible, and finally people added "keyword-
>> only argument" in Python 3.
>>
>>
>
> It doesn't cause any problem that wasn't always present with functions
> ever since c++98. If a user is concerned about that, he should use
> named arguments in his calls, but I see no reason to prevent
> unnamed arguments for those who wish to use them.

?? I guess you miss understood.

What I mean is, if an argument is declared as named argument:

  void f(int x, int y:);  // y in this example

Call the function with the named argument named works:

  f(3, y: 4);

But with the named argument unnamed should not:

  f(3, 4);  // no!!!

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--089e015371dcd9502a04e83badb7
Content-Type: text/plain; charset=ISO-8859-1

On 8 October 2013 17:32, Zhihao Yuan <zy@miator.net> wrote:

> On Tue, Oct 8, 2013 at 10:29 AM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
> >> I hope order call is not supported on named arguments at all.  Python 2
> >> has it, but caused lots of problems, especially when a signature is
> >> changed, the old problem may still run but runtime behavior is silently
> >> changed, which is really horrible, and finally people added "keyword-
> >> only argument" in Python 3.
> >>
> >>
> >
> > It doesn't cause any problem that wasn't always present with functions
> > ever since c++98. If a user is concerned about that, he should use
> > named arguments in his calls, but I see no reason to prevent
> > unnamed arguments for those who wish to use them.
>
> ?? I guess you miss understood.
>
> What I mean is, if an argument is declared as named argument:
>
>   void f(int x, int y:);  // y in this example
>
> Call the function with the named argument named works:
>
>   f(3, y: 4);
>
> But with the named argument unnamed should not:
>
>   f(3, 4);  // no!!!
>
>

I understood it just fine, and YES, I want that call to work.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e015371dcd9502a04e83badb7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 8 October 2013 17:32, Zhihao Yuan <span dir=3D"ltr">&lt;<a href=
=3D"mailto:zy@miator.net" target=3D"_blank">zy@miator.net</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Tue, Oct 8, 2013 at 10:29 AM, Ville Voutilainen<br>
&lt;<a href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.=
com</a>&gt; wrote:<br>
&gt;&gt; I hope order call is not supported on named arguments at all. =A0P=
ython 2<br>
&gt;&gt; has it, but caused lots of problems, especially when a signature i=
s<br>
&gt;&gt; changed, the old problem may still run but runtime behavior is sil=
ently<br>
&gt;&gt; changed, which is really horrible, and finally people added &quot;=
keyword-<br>
&gt;&gt; only argument&quot; in Python 3.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;<br>
&gt; It doesn&#39;t cause any problem that wasn&#39;t always present with f=
unctions<br>
&gt; ever since c++98. If a user is concerned about that, he should use<br>
&gt; named arguments in his calls, but I see no reason to prevent<br>
&gt; unnamed arguments for those who wish to use them.<br>
<br>
</div>?? I guess you miss understood.<br>
<br>
What I mean is, if an argument is declared as named argument:<br>
<br>
=A0 void f(int x, int y:); =A0// y in this example<br>
<br>
Call the function with the named argument named works:<br>
<br>
=A0 f(3, y: 4);<br>
<br>
But with the named argument unnamed should not:<br>
<br>
=A0 f(3, 4); =A0// no!!!<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><=
br><br></div><div>I understood it just fine, and YES, I want that call to w=
ork.<br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e015371dcd9502a04e83badb7--

.

------=_Part_403_31797593.1381243722123
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Le mardi 8 octobre 2013 16:35:24 UTC+2, Ville Voutilainen a =E9crit :
>
> I understood it just fine, and YES, I want that call to work.
>

And so do I.
Morevoer, it allows to name some previously unnamed arguments in any=20
librabry without breaking the user code. It will only extend the user's=20
possibilities.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_403_31797593.1381243722123
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Le mardi 8 octobre 2013 16:35:24 UTC+2, Ville Voutilainen =
a =E9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div><div class=3D"gmail_quote"><div>I understood it just fine, and YES,=
 I want that call to work.<br></div></div></div></div></blockquote><div><br=
>And so do I.<br>Morevoer, it allows to name some previously unnamed argume=
nts in any librabry without breaking the user code. It will only extend the=
 user's possibilities.<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_403_31797593.1381243722123--

.

--Apple-Mail=_F5CC1F39-FAD6-4A01-BB09-481455A189CC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=windows-1252


On 08 Oct 2013, at 17:06, Diego S=E1nchez <dsde71@gmail.com> wrote:
> The idea is that you can call f( y : 42 )  or f ( y :42, z : 666 ), but n=
ot f( z: 666, y: 42 ). This would preserve the function signature after fil=
ling the gaps.
>=20

I=92d say f(z:666, y:42) is fine, since compiler knows the order, it can fi=
ll the gaps.

In Objective-C, where this seems to come from the =93names=94 of the argume=
nts are part of the method signature (but not the formal argument names). F=
or example renaming an argument in the source code is gonna be a BIC change=
, I=92m afraid, so I=92m cautious about allowing it everywhere, hence the c=
learly distinct =93label=94 syntax.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_F5CC1F39-FAD6-4A01-BB09-481455A189CC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 08 Oc=
t 2013, at 17:06, Diego S=E1nchez &lt;<a href=3D"mailto:dsde71@gmail.com">d=
sde71@gmail.com</a>&gt; wrote:</div><blockquote type=3D"cite"><div dir=3D"l=
tr" style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; f=
ont-variant: normal; font-weight: normal; letter-spacing: normal; line-heig=
ht: normal; orphans: auto; text-align: start; text-indent: 0px; text-transf=
orm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-te=
xt-stroke-width: 0px;"><div>The idea is that you can call f( y : 42 ) &nbsp=
;or f ( y :42, z : 666 ), but not f( z: 666, y: 42 ). This would preserve t=
he function signature after filling the gaps.<br></div><div><br></div></div=
></blockquote></div><br><div>I=92d say f(z:666, y:42) is fine, since compil=
er knows the order, it can fill the gaps.</div><div><br></div><div>In Objec=
tive-C, where this seems to come from the =93names=94 of the arguments are =
part of the method signature (but not the formal argument names). For examp=
le renaming an argument in the source code is gonna be a BIC change, I=92m =
afraid, so I=92m cautious about allowing it everywhere, hence the clearly d=
istinct =93label=94 syntax.</div></body></html>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_F5CC1F39-FAD6-4A01-BB09-481455A189CC--

.

--089e0149c54626b00604e83ca595
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 8 October 2013 17:48, <morwenn29@gmail.com> wrote:

> Le mardi 8 octobre 2013 16:35:24 UTC+2, Ville Voutilainen a =E9crit :
>
>> I understood it just fine, and YES, I want that call to work.
>>
>
> And so do I.
> Morevoer, it allows to name some previously unnamed arguments in any
> librabry without breaking the user code. It will only extend the user's
> possibilities.
>
>
>
>
It also avoids mucking with the type of such a function declaration, and it
thus allows
function pointers, bind and generic code to just work with it like they
work with
"legacy" functions. The safety is not so important to break old-convention
usages for such functions.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--089e0149c54626b00604e83ca595
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 8 October 2013 17:48,  <span dir=3D"ltr">&lt;<a href=3D"mailto:m=
orwenn29@gmail.com" target=3D"_blank">morwenn29@gmail.com</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">Le mardi 8 octobre 2013 16:35:24 UTC+2, Ville Voutilainen =
a =E9crit=A0:<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr">
<div><div class=3D"gmail_quote"><div>I understood it just fine, and YES, I =
want that call to work.<br></div></div></div></div></blockquote></div><div>=
<br>And so do I.<br>Morevoer, it allows to name some previously unnamed arg=
uments in any librabry without breaking the user code. It will only extend =
the user&#39;s possibilities.<br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

<br><br></div></div></blockquote><div><br></div><div>It also avoids mucking=
 with the type of such a function declaration, and it thus allows <br></div=
><div>function pointers, bind and generic code to just work with it like th=
ey work with<br>
</div><div>&quot;legacy&quot; functions. The safety is not so important to =
break old-convention<br>usages for such functions.<br></div></div><br></div=
></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0149c54626b00604e83ca595--

.

On ter=E7a-feira, 8 de outubro de 2013 17:50:34, Berkus wrote:
> > The idea is that you can call f( y : 42 )  or f ( y :42, z : 666 ), but
> > not f( z: 666, y: 42 ). This would preserve the function signature afte=
r
> > filling the gaps.>
> >=20
>=20
> I=92d say f(z:666, y:42) is fine, since compiler knows the order, it can =
fill
> the gaps.

What happens if you call f(z: w(), y: h())? What is called first, w() or h(=
)?

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--047d7b5d4e5ec2558e04e83cb995
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 8 October 2013 18:44, Thiago Macieira <thiago@macieira.org> wrote:

> On ter=E7a-feira, 8 de outubro de 2013 17:50:34, Berkus wrote:
> > > The idea is that you can call f( y : 42 )  or f ( y :42, z : 666 ), b=
ut
> > > not f( z: 666, y: 42 ). This would preserve the function signature
> after
> > > filling the gaps.>
> > >
> >
> > I=92d say f(z:666, y:42) is fine, since compiler knows the order, it ca=
n
> fill
> > the gaps.
>
> What happens if you call f(z: w(), y: h())? What is called first, w() or
> h()?
>
>
>
Personally I don't mind if that remains unspecified as with normal
functions.
The named parameters are then just syntactic sugar with no additional
magic.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--047d7b5d4e5ec2558e04e83cb995
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 8 October 2013 18:44, Thiago Macieira <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a=
>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On ter=E7a-feira, 8 de out=
ubro de 2013 17:50:34, Berkus wrote:<br>
&gt; &gt; The idea is that you can call f( y : 42 ) =A0or f ( y :42, z : 66=
6 ), but<br>
&gt; &gt; not f( z: 666, y: 42 ). This would preserve the function signatur=
e after<br>
&gt; &gt; filling the gaps.&gt;<br>
&gt; &gt;<br>
&gt;<br>
&gt; I=92d say f(z:666, y:42) is fine, since compiler knows the order, it c=
an fill<br>
&gt; the gaps.<br>
<br>
</div>What happens if you call f(z: w(), y: h())? What is called first, w()=
 or h()?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br><br></font></span></bloc=
kquote><div><br></div><div>Personally I don&#39;t mind if that remains unsp=
ecified as with normal functions.<br></div><div>The named parameters are th=
en just syntactic sugar with no additional<br>
</div><div>magic. <br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b5d4e5ec2558e04e83cb995--

.

------=_Part_213_16801195.1381251308020
Content-Type: text/plain; charset=ISO-8859-1


I also agree that naming parameters at call place should be optional.
Compilers could implement a warning to alert the user if a named parameter
goes unnamed, but that should remain optional and disabled by default.

Anyhow, following Bengt Gustafsson 's concern, suppose we have something
like this:

void f( a:0, b:0, c:0, d:0, e:0, f:0 );

A user may want to write f( c:2, 3, a:7, 4 );

The most obvious interpretation is that a = 7, b =4, c = 2, d = 3, e = 0, f
= 0. But this is error prone and obscures more than clarifies the code.

And taking it one step beyond:  f( c:2, 3, a:7, 4, 5 );

Now c has been specified twice.

That's why I proposed to forbid reordering, but if a rule exists that once
you start labeling you must keep labeling this problem is probably solved.

Now a couple points to consider:

 What if a library writer wants to define an argument to be mandatory but
wants to provide a label for it? That would mean that the user must name
that and all remaining parameters for the function.

f( int a, bool b:, int c = 0, int d = 0 );

This would be invalid, since there is no way you could name c or d. So the
library writer must declare the function as:

f( int a, bool b:, int c: = 0, int d: = 0 );

And, if a user wants to name the boolean, she must write:

f( 12, b:true, c:1, d:2 );

which may be cumbersome if the function has a lot of arguments, all of them
with long, descriptive names; this would probably lead the user to
completely drop the label.



Another point I would like considered is: would this seamlessly extend into
template 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_213_16801195.1381251308020
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br></div><div>I also agree that naming parameters at=
 call place should be optional. Compilers could implement a warning to aler=
t the user if a named parameter goes unnamed, but that should remain option=
al and disabled by default.</div><div><br></div><div>Anyhow, following Beng=
t<span style=3D"color: rgb(192, 192, 192);"> </span>Gustafsson 's concern, =
suppose we have something like this:</div><div><br></div><div>void f( a:0, =
b:0, c:0, d:0, e:0, f:0 );</div><div><br></div><div>A user may want to writ=
e f( c:2, 3, a:7, 4 );</div><div><br></div><div>The most obvious interpreta=
tion is that a =3D 7, b =3D4, c =3D 2, d =3D 3, e =3D 0, f =3D 0. But this =
is error prone and obscures more than clarifies the code.</div><div><br></d=
iv><div>And taking it one step beyond: &nbsp;f( c:2, 3, a:7, 4, 5 );</div><=
div><br></div><div>Now c has been specified twice.</div><div><br></div><div=
>That's why I proposed to forbid reordering, but if a rule exists that once=
 you start labeling you must keep labeling this problem is probably solved.=
</div><div><br></div><div>Now a couple points to consider:</div><div><br></=
div><div>&nbsp;What if a library writer wants to define an argument to be m=
andatory but wants to provide a label for it? That would mean that the user=
 must name that and all remaining parameters for the function.</div><div><b=
r></div><div>f( int a, bool b:, int c =3D 0, int d =3D 0 );</div><div><br><=
/div><div>This would be invalid, since there is no way you could name c or =
d. So the library writer must declare the function as:</div><div><br></div>=
<div>f( int a, bool b:, int c: =3D 0, int d: =3D 0 );<br></div><div><br></d=
iv><div>And, if a user wants to name the boolean, she must write:</div><div=
><br></div><div>f( 12, b:true, c:1, d:2 );</div><div><br></div><div>which m=
ay be cumbersome if the function has a lot of arguments, all of them with l=
ong, descriptive names; this would probably lead the user to completely dro=
p the label.<br></div><div><br></div><div><br></div><div><br></div><div>Ano=
ther point I would like considered is: would this seamlessly extend into te=
mplate parameters?</div><div><br></div><div><br></div>
</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_213_16801195.1381251308020--

.

--047d7bdc9c52766e0904e83db6a6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 8 October 2013 19:55, Diego S=E1nchez <dsde71@gmail.com> wrote:

>
> Now a couple points to consider:
>
>  What if a library writer wants to define an argument to be mandatory but
> wants to provide a label for it? That would mean that the user must name
> that and all remaining parameters for the function.
>
> f( int a, bool b:, int c =3D 0, int d =3D 0 );
>
> This would be invalid, since there is no way you could name c or d. So th=
e
> library writer must declare the function as:
>
> f( int a, bool b:, int c: =3D 0, int d: =3D 0 );
>

Yes.


>
> And, if a user wants to name the boolean, she must write:
>
> f( 12, b:true, c:1, d:2 );
>

Assuming that the user didn't want to use the default arguments for c and
d, yes.


>
> which may be cumbersome if the function has a lot of arguments, all of
> them with long, descriptive names; this would probably lead the user to
> completely drop the label.
>

All things considered, I don't consider this a problem worth solving at the
cost of other things.



>
> Another point I would like considered is: would this seamlessly extend
> into template parameters?
>
>
>
I guess it should.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--047d7bdc9c52766e0904e83db6a6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 8 October 2013 19:55, Diego S=E1nchez <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:dsde71@gmail.com" target=3D"_blank">dsde71@gmail.com</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div>Now a couple point=
s to consider:</div><div><br></div><div>=A0What if a library writer wants t=
o define an argument to be mandatory but wants to provide a label for it? T=
hat would mean that the user must name that and all remaining parameters fo=
r the function.</div>
<div><br></div><div>f( int a, bool b:, int c =3D 0, int d =3D 0 );</div><di=
v><br></div><div>This would be invalid, since there is no way you could nam=
e c or d. So the library writer must declare the function as:</div><div><br=
>
</div><div>f( int a, bool b:, int c: =3D 0, int d: =3D 0 );<br></div></div>=
</blockquote><div><br></div><div>Yes.<br>=A0<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></div><div><br></div><div>And, if a user wants to nam=
e the boolean, she must write:</div><div><br></div><div>f( 12, b:true, c:1,=
 d:2 );</div></div></blockquote><div><br></div><div>Assuming that the user =
didn&#39;t want to use the default arguments for c and d, yes.<br>
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div=
><div>which may be cumbersome if the function has a lot of arguments, all o=
f them with long, descriptive names; this would probably lead the user to c=
ompletely drop the label.<br>
</div></div></blockquote><div><br></div><div>All things considered, I don&#=
39;t consider this a problem worth solving at the cost of other things.<br>=
<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div></div><div><br></div><div>Another point I would like =
considered is: would this seamlessly extend into template parameters?</div>=
<div><br><br></div></div></blockquote><div><br></div><div>I guess it should=
.. <br>
</div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bdc9c52766e0904e83db6a6--

.

Counter question: what happens if you call f(w(), h())? What is called firs=
t, w() or h()?

I think it is best left unspecified as for the general function argument ev=
aluation order. The order that the compiler =93knows" and that I was talkin=
g about is the order of function arguments, not their evaluation order. Giv=
en f(z: 666, y: 42) it=92s fairly easy to see the only missing defaulted ar=
gument is x and fill that in. This can actually help a bit for the defaulte=
d arguments order, e.g.

int fun_with_def(int x, int y: =3D 22, int z: =3D 33);

Usually you cannot run fun_with_def() without specifying y, because default=
ed arguments require you specify them in order. However, with named argumen=
ts you could have this valid code:

fun_with_def(10, z: 55);=20



On 08 Oct 2013, at 18:44, Thiago Macieira <thiago@macieira.org> wrote:

> On ter=E7a-feira, 8 de outubro de 2013 17:50:34, Berkus wrote:
>>> The idea is that you can call f( y : 42 )  or f ( y :42, z : 666 ), but
>>> not f( z: 666, y: 42 ). This would preserve the function signature afte=
r
>>> filling the gaps.>
>>>=20
>>=20
>> I=92d say f(z:666, y:42) is fine, since compiler knows the order, it can=
 fill
>> the gaps.
>=20
> What happens if you call f(z: w(), y: h())? What is called first, w() or =
h()?
>=20
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>   Software Architect - Intel Open Source Technology Center
>      PGP/GPG: 0x6EF45358; fingerprint:
>      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>=20
> --=20
>=20
> ---=20
> You received this message because you are subscribed to a topic in the Go=
ogle Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.=
org/d/topic/std-proposals/zA5PyUx8l0w/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to std-p=
roposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--001a1133e3300577ca04e83f9779
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 9 October 2013 00:14, Diego S=E1nchez <dsde71@gmail.com> wrote:

> Skipping over optional argument


I don't see the reason for the restrictions or the declaration markup. What
we are saying is that we can only call functions that are marked up in the
declaration with keyword arguments? I.e. Named arg calls cant be applied to
existing functions.

Why do we need to decorate the declaration at all?

Why cant we have:
void f(int x, int y=3D0, int z=3D0);

and be able to call it like:
f(x:3, z:12);
f(z:12, x:3); // Order does not matter for named params
f(1,2,3);
f(1, z:0);

f(2, x:12); // Compile error

If the reason is that existing declarations can already have multiple
different arg names, then that could easily become a compile error when
attempting to use named arg calls with those functions. All other functions
written in a sensible way could be called using the named arg syntax. You
can thus use legacy code, or code written in C etc.

This would not change anything about a function declaration or ABI or API
in a non-backwards compatible way. It only adds extra ways to be used at
the call site.

Surely this can be resolved easily:
* First resolve non-named args (holes not allowed, must come before named
args)
* Second resolve named args
* Resolve any defaults
* If any args in the function call don't have a value then it is a compile
error

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a1133e3300577ca04e83f9779
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 9 October 2013 00:14, Diego S=E1nchez <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:dsde71@gmail.com" target=3D"_blank">dsde71@gmail.com</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex">
Skipping over optional argument</blockquote></div><br>I don&#39;t see the r=
eason for the restrictions or the declaration markup. What we are saying is=
 that we can only call functions that are marked up in the declaration with=
 keyword arguments? I.e. Named arg calls cant be applied to existing functi=
ons.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Why do we n=
eed to decorate the declaration at all?</div><div class=3D"gmail_extra"><br=
></div><div class=3D"gmail_extra">Why cant we have:</div><div class=3D"gmai=
l_extra">
<span style=3D"font-family:arial,sans-serif;font-size:13px">void f(int x, i=
nt y=3D0, int z=3D0);</span><br></div><div class=3D"gmail_extra"><span styl=
e=3D"font-family:arial,sans-serif;font-size:13px"><br></span></div><div cla=
ss=3D"gmail_extra">
<span style=3D"font-family:arial,sans-serif;font-size:13px">and be able to =
call it like:</span></div><div class=3D"gmail_extra"><span style=3D"font-fa=
mily:arial,sans-serif;font-size:13px">f(x:3, z:12);</span></div><div class=
=3D"gmail_extra">
<span style=3D"font-family:arial,sans-serif;font-size:13px">f(z:12,=A0</spa=
n><span style=3D"font-family:arial,sans-serif;font-size:13px">x:3</span><sp=
an style=3D"font-family:arial,sans-serif;font-size:13px">); // Order does n=
ot matter for named params</span></div>
<div class=3D"gmail_extra"><span style=3D"font-family:arial,sans-serif;font=
-size:13px">f(1,2,3);</span><br></div><div class=3D"gmail_extra"><span styl=
e=3D"font-family:arial,sans-serif;font-size:13px">f(1, z:0);</span></div><d=
iv class=3D"gmail_extra">
<span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span></di=
v><div class=3D"gmail_extra"><span style=3D"font-family:arial,sans-serif;fo=
nt-size:13px">f(2, x:12); // Compile error</span></div><div class=3D"gmail_=
extra">
<br></div><div class=3D"gmail_extra">If the reason is that existing declara=
tions can already have multiple different arg names, then that could easily=
 become a compile error when attempting to use named arg calls with those f=
unctions. All other functions written in a sensible way could be called usi=
ng the named arg syntax. You can thus use legacy code, or code written in C=
 etc.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">This would =
not change anything about a function declaration or ABI or API in a non-bac=
kwards compatible way. It only adds extra ways to be used at the call site.=
</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Surely this=
 can be resolved easily:</div><div class=3D"gmail_extra">* First resolve no=
n-named args (holes not allowed, must come before named args)</div><div cla=
ss=3D"gmail_extra">
* Second resolve named args</div><div class=3D"gmail_extra">* Resolve any d=
efaults</div><div class=3D"gmail_extra">* If any args in the function call =
don&#39;t have a value then it is a compile error</div><div class=3D"gmail_=
extra">
<br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><=
br></div><div class=3D"gmail_extra"><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1133e3300577ca04e83f9779--

.

On Tue, Oct 8, 2013 at 3:15 PM, Brendon Costa <brendon.j.costa@gmail.com> wrote:
> Why do we need to decorate the declaration at all?
>
> Why cant we have:
> void f(int x, int y=0, int z=0);
>
> and be able to call it like:
> f(x:3, z:12);

Python has it and receives lots of criticisms.  Parameter
names are implementation details unless explicitly exposed.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a11c3657e0d885404e83fd172
Content-Type: text/plain; charset=ISO-8859-1

This is the second time you mention Python. Could you please ellaborate on
what kind of problems have they found? We can always learn from other's
mistakes.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c3657e0d885404e83fd172
Content-Type: text/html; charset=ISO-8859-1

<p dir="ltr">This is the second time you mention Python. Could you please ellaborate on what kind of problems have they found? We can always learn from other&#39;s mistakes.</p>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

--001a11c3657e0d885404e83fd172--

.

--001a11c2409c149afe04e8404077
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

One example is with unused parameters: Static code checkers often warn
about these and to mark them as intentionally unused you can introduce a
special convention, like prefixing them with "unused". However, that breaks
in subtle ways if some caller uses named arguments.
In most programming languages, parameters and function-local variables are
similar in their behavior, e.g. they have the same scope and you can rename
them freely without breaking anything. If you generally allow named
arguments for all parameters like Python does, this assumption breaks. This
is not necessarily bad, but people need to be aware of it. For C++, it
seems especially impossible to just enable named arguments for existing
functions, because of ABI breakage (name mangling), assumptions about the
type of functions and function pointers, and documentation vs. code issues
(many standard library implementations use a double-underscore prefix for
all parameters because users cannot legally redefine such names).
I like named arguments in Python, but for C++ I'd rather lean towards
allowing record syntax ({ .attr =3D value }). This avoids breakage, is
compatible with existing "options" parameter conventions, and is compatible
with C. The amount of additional syntax required (dots plus a set of
braces) seems sustainable as well.


2013/10/8 Diego S=E1nchez <dsde71@gmail.com>

> This is the second time you mention Python. Could you please ellaborate o=
n
> what kind of problems have they found? We can always learn from other's
> mistakes.
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a11c2409c149afe04e8404077
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">One example is with unused parameters: Static code checker=
s often warn about these and to mark them as intentionally unused you can i=
ntroduce a special convention, like prefixing them with &quot;unused&quot;.=
 However, that breaks in subtle ways if some caller uses named arguments.<d=
iv>
In most programming languages, parameters and function-local variables are =
similar in their behavior, e.g. they have the same scope and you can rename=
 them freely without breaking anything. If you generally allow named argume=
nts for all parameters like Python does, this assumption breaks. This is no=
t necessarily bad, but people need to be aware of it. For C++, it seems esp=
ecially impossible to just enable named arguments for existing functions, b=
ecause of ABI breakage (name mangling), assumptions about the type of funct=
ions and function pointers, and documentation vs. code issues (many standar=
d library implementations use a double-underscore prefix for all parameters=
 because users cannot legally redefine such names).</div>
<div>I like named arguments in Python, but for C++ I&#39;d rather lean towa=
rds allowing record syntax ({ .attr =3D value }). This avoids breakage, is =
compatible with existing &quot;options&quot; parameter conventions, and is =
compatible with C. The amount of additional syntax required (dots plus a se=
t of braces) seems sustainable as well.</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/10=
/8 Diego S=E1nchez <span dir=3D"ltr">&lt;<a href=3D"mailto:dsde71@gmail.com=
" target=3D"_blank">dsde71@gmail.com</a>&gt;</span><br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">
<p dir=3D"ltr">This is the second time you mention Python. Could you please=
 ellaborate on what kind of problems have they found? We can always learn f=
rom other&#39;s mistakes.</p><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c2409c149afe04e8404077--

.

--047d7b6783f6001a9904e84044db
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 7, 2013 at 11:38 PM, Jean-Marc Bourguet
<jm.bourguet@gmail.com>wrote:

> Le mardi 8 octobre 2013 00:31:39 UTC+2, Richard Smith a =E9crit :
>
> On Mon, Oct 7, 2013 at 2:28 PM, Bengt Gustafsson <bengt.gu...@beamways.co=
m
>> **> wrote:
>>
>>> @Berkus: What's the reason for requiring a colon in the parameter
>>> definition? I think this feature would be much more useful if it was
>>> allowed for any function call.
>>>
>>
>> Please no. If you allow existing parameter names to gain semantics like
>> this, then renaming parameters becomes an ABI breaking change. Functions
>> should be required to opt into their parameter names having meaning.
>>
>> API not ABI I assume?  If not, could you point out the implications I've
> missed? (I agree that it doesn't make a difference, it should be an opt-i=
n).
>

Yes, sorry, I meant API, not ABI. But depending on the exact rules, it
could be both. For instance, the parameter names might need to be included
in some mangled names, because they could affect which overload is
selected. And in some corner cases, it will be an ABI break no matter what
else we decide:

// library
int f(int a); // #1
double f(double d);

// user code
void g(decltype(f(d:0)) x);

Changing the parameter name of #1 from 'a' to 'd' changes the type of 'g'.

Fundamentally, it's a really really bad idea to take part of a declaration
that was previously just documentation, and promote it to being part of the
semantics without any kind of opt-in. We have no reason to think that
existing parameter names are designed for this, and we'd suddenly be making
them *part of the interface*.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--047d7b6783f6001a9904e84044db
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Oct 7, 2013 at 11:38 PM, Jean-Marc Bourguet <span =
dir=3D"ltr">&lt;<a href=3D"mailto:jm.bourguet@gmail.com" target=3D"_blank">=
jm.bourguet@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><=
div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Le mardi 8 octobre 2013 00:=
31:39 UTC+2, Richard Smith a =E9crit=A0:<div class=3D"im"><br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex">
<div dir=3D"ltr">On Mon, Oct 7, 2013 at 2:28 PM, Bengt Gustafsson <span dir=
=3D"ltr">&lt;<a>bengt.gu...@beamways.com</a><u></u>&gt;</span> wrote:<br><d=
iv>
<div class=3D"gmail_quote"><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">=
@Berkus: What&#39;s the reason for requiring a colon in the parameter defin=
ition? I think this feature would be much more useful if it was allowed for=
 any function call.</div>

</blockquote><div><br></div><div>Please no. If you allow existing parameter=
 names to gain semantics like this, then renaming parameters becomes an ABI=
 breaking change. Functions should be required to opt into their parameter =
names having meaning.<br>

</div><div><br></div></div></div></div></blockquote></div><div>API not ABI =
I assume? =A0If not, could you point out the implications I&#39;ve missed? =
(I agree that it doesn&#39;t make a difference, it should be an opt-in).</d=
iv>
</div></blockquote><div><br></div><div>Yes, sorry, I meant API, not ABI. Bu=
t depending on the exact rules, it could be both. For instance, the paramet=
er names might need to be included in some mangled names, because they coul=
d affect which overload is selected. And in some corner cases, it will be a=
n ABI break no matter what else we decide:</div>
<div><br></div><div>// library</div><div>int f(int a); // #1</div><div>doub=
le f(double d);</div><div><br></div><div>// user code</div><div>void g(decl=
type(f(d:0)) x);</div><div><br></div><div>Changing the parameter name of #1=
 from &#39;a&#39; to &#39;d&#39; changes the type of &#39;g&#39;.</div>
<div><br></div><div>Fundamentally, it&#39;s a really really bad idea to tak=
e part of a declaration that was previously just documentation, and promote=
 it to being part of the semantics without any kind of opt-in. We have no r=
eason to think that existing parameter names are designed for this, and we&=
#39;d suddenly be making them <b>part of the interface</b>.</div>
</div></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b6783f6001a9904e84044db--

.

On Tue, Oct 8, 2013 at 3:31 PM, Diego S=E1nchez <dsde71@gmail.com> wrote:
> This is the second time you mention Python. Could you please ellaborate o=
n
> what kind of problems have they found? We can always learn from other's
> mistakes.

Python2 's arguments look like this:

  def f(x, y):

you can call it through

  f(3, 4)
  f(3, y=3D4)
  f(y=3D4, x=3D3)

When the argument list grows, this become unmaintainable because
you must do not break existing code (which may always uses
sequential calls).  For example, if you have an argument list like this:

  connect(database, timeout, detect_types, isolation_level,
     check_same_thread, factory, cached_statements)

Then you can only extend the list by appending.

So there was a trick around, which captures all named arguments
passed in by a dict (with **kwargs) and forwards then to an internal
function, so that those parameters are "keyword-only".

But obviously it makes the implementation ugly, so Python 3 added
keyword-only arguments directly:

  http://www.python.org/dev/peps/pep-3102/

So that

  def f(a, b, *, c):

All parameters after the special '*' can only be called with names.

Another problem is that parameter names are unnecessarily
exposed.  Basically, if you see a parameter in the standard
which is poorly named (like "s"), then that parameter is intended
to be called without name.  There is also a trick to forward
sequential arguments, but Python has a tradition like relay
on naming, so such a trick has not become a language feature.
Instead, they have a whole library extension to solve those
confusions:

  http://www.python.org/dev/peps/pep-0362/

Signature object.  So that you can use
Parameter.POSITIONAL_ONLY,
Parameter.POSITIONAL_OR_KEYWORD, and
Parameter.KEYWORD_ONLY to annotate a function.
There we go.

--=20
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--089e0112c136d9254304e8409379
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2013/10/8 Zhihao Yuan <zy@miator.net>

> On Tue, Oct 8, 2013 at 3:31 PM, Diego S=E1nchez <dsde71@gmail.com> wrote:
> > This is the second time you mention Python. Could you please ellaborate
> on
> > what kind of problems have they found? We can always learn from other's
> > mistakes.
>
> Python2 's arguments look like this:
>
>   def f(x, y):
>
> you can call it through
>
>   f(3, 4)
>   f(3, y=3D4)
>   f(y=3D4, x=3D3)
>
> When the argument list grows, this become unmaintainable because
> you must do not break existing code (which may always uses
> sequential calls).  For example, if you have an argument list like this:
>
>   connect(database, timeout, detect_types, isolation_level,
>      check_same_thread, factory, cached_statements)
>
> Then you can only extend the list by appending.
>
> So there was a trick around, which captures all named arguments
> passed in by a dict (with **kwargs) and forwards then to an internal
> function, so that those parameters are "keyword-only".
>
> But obviously it makes the implementation ugly,


Also it means that missing or unknown arguments are not detected at the
interface level, but somewhere deep in the implementation. It's not
uncommon to see several levels where the kwargs are only passed around and
then finally investigated by an internal functions. That means errors in
the argument list lead to a stack trace where the actual problem is
somewhere in the middle rather than at the top. (Similar to C++'s issues
with unrestricted template parameters where compiler errors point to some
internal function.)


> so Python 3 added
> keyword-only arguments directly:
>
>   http://www.python.org/dev/peps/pep-3102/
>
> So that
>
>   def f(a, b, *, c):
>
> All parameters after the special '*' can only be called with names.
>

Which makes passing around the kwargs to internal functions much more
cumbersome. Often a dedicated options type (e.g. a namedtuple) is better
than a large number of keyword arguments.


>
> Another problem is that parameter names are unnecessarily
> exposed.


Arguably that could be applied for other names as well. It looks like we
treat parameter names as internal purely because of historical
circumstances ("mathematics does it that 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--089e0112c136d9254304e8409379
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">2013/10/8 Zhihao Yuan <span dir=3D"ltr">&lt;<a href=3D"mailto:zy@mi=
ator.net" target=3D"_blank">zy@miator.net</a>&gt;</span><br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
<div class=3D"im">On Tue, Oct 8, 2013 at 3:31 PM, Diego S=E1nchez &lt;<a hr=
ef=3D"mailto:dsde71@gmail.com">dsde71@gmail.com</a>&gt; wrote:<br>
&gt; This is the second time you mention Python. Could you please ellaborat=
e on<br>
&gt; what kind of problems have they found? We can always learn from other&=
#39;s<br>
&gt; mistakes.<br>
<br>
</div>Python2 &#39;s arguments look like this:<br>
<br>
=A0 def f(x, y):<br>
<br>
you can call it through<br>
<br>
=A0 f(3, 4)<br>
=A0 f(3, y=3D4)<br>
=A0 f(y=3D4, x=3D3)<br>
<br>
When the argument list grows, this become unmaintainable because<br>
you must do not break existing code (which may always uses<br>
sequential calls). =A0For example, if you have an argument list like this:<=
br>
<br>
=A0 connect(database, timeout, detect_types, isolation_level,<br>
=A0 =A0 =A0check_same_thread, factory, cached_statements)<br>
<br>
Then you can only extend the list by appending.<br>
<br>
So there was a trick around, which captures all named arguments<br>
passed in by a dict (with **kwargs) and forwards then to an internal<br>
function, so that those parameters are &quot;keyword-only&quot;.<br>
<br>
But obviously it makes the implementation ugly,</blockquote><div><br></div>=
<div>Also it means that missing or unknown arguments are not detected at th=
e interface level, but somewhere deep in the implementation. It&#39;s not u=
ncommon to see several levels where the kwargs are only passed around and t=
hen finally investigated by an internal functions. That means errors in the=
 argument list lead to a stack trace where the actual problem is somewhere =
in the middle rather than at the top. (Similar to C++&#39;s issues with unr=
estricted template parameters where compiler errors point to some internal =
function.)</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"> so Python 3 added<br>
keyword-only arguments directly:<br>
<br>
=A0 <a href=3D"http://www.python.org/dev/peps/pep-3102/" target=3D"_blank">=
http://www.python.org/dev/peps/pep-3102/</a><br>
<br>
So that<br>
<br>
=A0 def f(a, b, *, c):<br>
<br>
All parameters after the special &#39;*&#39; can only be called with names.=
<br></blockquote><div><br></div><div>Which makes passing around the kwargs =
to internal functions much more cumbersome. Often a dedicated options type =
(e.g. a namedtuple) is better than a large number of keyword arguments.</di=
v>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
<br>
Another problem is that parameter names are unnecessarily<br>
exposed.</blockquote><div><br></div><div>Arguably that could be applied for=
 other names as well. It looks like we treat parameter names as internal pu=
rely because of historical circumstances (&quot;mathematics does it that wa=
y&quot;).</div>
</div></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0112c136d9254304e8409379--

.

On Tue, Oct 8, 2013 at 4:26 PM, Philipp Stephani <p.stephani2@gmail.com> wrote:
> Often a dedicated options type (e.g. a namedtuple) is better
> than a large number of keyword arguments.

Lua uses this approach.  And they even has a syntax
sugar to use func{ <table> } call instead of
func({ <table> }).  I'm not particularly in favor of this;
sometimes a language extension makes things cleaner.
(And we don't have such convenient struct in C++ I guess).

>> Another problem is that parameter names are unnecessarily
>> exposed.
>
> Arguably that could be applied for other names as well. It looks like we
> treat parameter names as internal purely because of historical circumstances
> ("mathematics does it that way").

Good or bad, this tradition had better be kept, I think.
Otherwise, transitional code can quickly become
non-portable.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--047d7bb04bc2d63e7f04e84114d7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

If I got it right, all those problems steem from the fact that in Python
function definition is declaration.

In c++ the names of the arguments are not part of the signature, so you are
free to define different names for them in your include files; even
different default values in different compilation units.
El 08/10/2013 22:42, "Zhihao Yuan" <zy@miator.net> escribi=F3:

> On Tue, Oct 8, 2013 at 4:26 PM, Philipp Stephani <p.stephani2@gmail.com>
> wrote:
> > Often a dedicated options type (e.g. a namedtuple) is better
> > than a large number of keyword arguments.
>
> Lua uses this approach.  And they even has a syntax
> sugar to use func{ <table> } call instead of
> func({ <table> }).  I'm not particularly in favor of this;
> sometimes a language extension makes things cleaner.
> (And we don't have such convenient struct in C++ I guess).
>
> >> Another problem is that parameter names are unnecessarily
> >> exposed.
> >
> > Arguably that could be applied for other names as well. It looks like w=
e
> > treat parameter names as internal purely because of historical
> circumstances
> > ("mathematics does it that way").
>
> Good or bad, this tradition had better be kept, I think.
> Otherwise, transitional code can quickly become
> non-portable.
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> ___________________________________________________
> 4BSD -- http://4bsd.biz/
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--047d7bb04bc2d63e7f04e84114d7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">If I got it right, all those problems steem from the fact th=
at in Python function definition is declaration.</p>
<p dir=3D"ltr">In c++ the names of the arguments are not part of the signat=
ure, so you are free to define different names for them in your include fil=
es; even different default values in different compilation units.</p>
<div class=3D"gmail_quote">El 08/10/2013 22:42, &quot;Zhihao Yuan&quot; &lt=
;<a href=3D"mailto:zy@miator.net">zy@miator.net</a>&gt; escribi=F3:<br type=
=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Oct 8, 2013 at 4:26 PM, Philipp Stephani &lt;<a href=3D"mailto:p.st=
ephani2@gmail.com">p.stephani2@gmail.com</a>&gt; wrote:<br>
&gt; Often a dedicated options type (e.g. a namedtuple) is better<br>
&gt; than a large number of keyword arguments.<br>
<br>
Lua uses this approach. =A0And they even has a syntax<br>
sugar to use func{ &lt;table&gt; } call instead of<br>
func({ &lt;table&gt; }). =A0I&#39;m not particularly in favor of this;<br>
sometimes a language extension makes things cleaner.<br>
(And we don&#39;t have such convenient struct in C++ I guess).<br>
<br>
&gt;&gt; Another problem is that parameter names are unnecessarily<br>
&gt;&gt; exposed.<br>
&gt;<br>
&gt; Arguably that could be applied for other names as well. It looks like =
we<br>
&gt; treat parameter names as internal purely because of historical circums=
tances<br>
&gt; (&quot;mathematics does it that way&quot;).<br>
<br>
Good or bad, this tradition had better be kept, I think.<br>
Otherwise, transitional code can quickly become<br>
non-portable.<br>
<br>
--<br>
Zhihao Yuan, ID lichray<br>
The best way to predict the future is to invent it.<br>
___________________________________________________<br>
4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_blank">http://4bsd.biz/</a>=
<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bb04bc2d63e7f04e84114d7--

.

------=_Part_408_19959360.1381266303155
Content-Type: text/plain; charset=ISO-8859-1

I think that the strongest argument against allowing non-colon formals to
be called by name has not been mentioned explicitly: The current standard
library implementations don't consistently use the same name for the same
parameter (right?). I assume that they don't and thus any code that uses
one of those formal names would not be portable! The sheer volume of the
standardisation work needed to define all parameter names in the standard
would be over the top. And it would probably not be popular to just state
that "but you can't use this feature for standard library functions". So, I
retract my previous position, even though it would have been nice to just
be able to start using named arguments at call sites...

On the ordering issue I strongly advocate against having to state the
actuals in the same order as the formals. One of the main drivers of having
named arguments is that you don't have to remember the order of the formal
parameters. With this restriction you must remember (or look up) both the
names and the order!

The idea that once you start naming actuals you must continue seems not to
be so restricting, except that in some cases I would suspect that
parameters exist in pairs or groups such as x and y, buf and count or r, g,
b Then you may want to use a shorthand by only naming the first actual of
the group.

The rule for declarations seems very natural, as you expect callers to use
only a portion of the named parameters, so you would not place positional
parameters after them. It is also consistent with the current rules for
default values for parameters. Thus formal parameters fall into three
groups: first positional, undefaulted parameters, then named undefaulted
parameters and finally named defaulted parameters. positional defaulted
parameters can only exist if there are no named parameters. Does this make
sense?

A minor detail is repeated function declarations. Today each default
expression can only be stated in one of a set of repeated declarations seen
by a TU. It seems logical to extend this rule so that only one of the
declarations can have a : on the name (and thus the name used in that
declaration is the official name of the parameter!). Another possibility
would be to ban declaration repetition if any of the repeats have a : in
the parameter list. That would be fine with me.

So far I have been assuming that a function signature is still only the
sequence of types for all its parameters. Is anyone contemplating to allow
both f(int x:) and f(int y:) in the same scope? I hope not, that would be
much larger departure from the current thinking... especially knowing which
is which when defining the functions would be tricky and inconsistent with
current lax rules of parameter names...







Den fredagen den 4:e oktober 2013 kl. 09:18:49 UTC+2 skrev Berkus Infinitus:
>
> I've been thinking about named arguments support in C++ with a simple,
> non-intrusive syntax. I've posted a formatted version of the idea here
> https://github.com/berkus/cpp_named_args
>
> I would like to hear what do you think is wrong with this approach and why
> would it not work, before I jump to patch up LLVM to support this feature?
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_408_19959360.1381266303155
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think that the strongest argument against allowing non-c=
olon formals to be called by name has not been mentioned explicitly: The cu=
rrent standard library implementations don't consistently use the same name=
 for the same parameter (right?). I assume that they don't and thus any cod=
e that uses one of those formal names would not be portable! The sheer volu=
me of the standardisation work needed to define all parameter names in the =
standard would be over the top. And it would probably not be popular to jus=
t state that "but you can't use this feature for standard library functions=
". So, I retract my previous position, even though it would have been nice =
to just be able to start using named arguments at call sites...<div><br></d=
iv><div>On the ordering issue I strongly advocate against having to state t=
he actuals in the same order as the formals. One of the main drivers of hav=
ing named arguments is that you don't have to remember the order of the for=
mal parameters. With this restriction you must remember (or look up) both t=
he names and the order!</div><div><br></div><div>The idea that once you sta=
rt naming actuals you must continue seems not to be so restricting, except =
that in some cases I would suspect that parameters exist in pairs or groups=
 such as x and y, buf and count or r, g, b Then you may want to use a short=
hand by only naming the first actual of the group.</div><div><br></div><div=
>The rule for declarations seems very natural, as you expect callers to use=
 only a portion of the named parameters, so you would not place positional =
parameters after them. It is also consistent with the current rules for def=
ault values for parameters. Thus formal parameters fall into three groups: =
first positional, undefaulted parameters, then named undefaulted parameters=
 and finally named defaulted parameters. positional defaulted parameters ca=
n only exist if there are no named parameters. Does this make sense?</div><=
div><br></div><div>A minor detail is repeated function declarations. Today =
each default expression can only be stated in one of a set of repeated decl=
arations seen by a TU. It seems logical to extend this rule so that only on=
e of the declarations can have a : on the name (and thus the name used in t=
hat declaration is the official name of the parameter!). Another possibilit=
y would be to ban declaration repetition if any of the repeats have a : in =
the parameter list. That would be fine with me.</div><div><br></div><div>So=
 far I have been assuming that a function signature is still only the seque=
nce of types for all its parameters. Is anyone contemplating to allow both =
f(int x:) and f(int y:) in the same scope? I hope not, that would be much l=
arger departure from the current thinking... especially knowing which is wh=
ich when defining the functions would be tricky and inconsistent with curre=
nt lax rules of parameter names...</div><div><br></div><div><br></div><div>=
<br></div><div><br></div><div><br></div><div><div><br><br>Den fredagen den =
4:e oktober 2013 kl. 09:18:49 UTC+2 skrev Berkus Infinitus:<blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr">I've been thinking about name=
d arguments support in C++ with a simple, non-intrusive syntax. I've posted=
 a formatted version of the idea here&nbsp;<a href=3D"https://github.com/be=
rkus/cpp_named_args" target=3D"_blank">https://github.com/<wbr>berkus/cpp_n=
amed_args</a><div><br></div><div>I would like to hear what do you think is =
wrong with this approach and why would it not work, before I jump to patch =
up LLVM to support this feature?</div></div></blockquote></div></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_408_19959360.1381266303155--

.

--001a1135e27e55b20904e84126a1
Content-Type: text/plain; charset=ISO-8859-1

2013/10/8 Richard Smith <richard@metafoo.co.uk>

> Yes, sorry, I meant API, not ABI. But depending on the exact rules, it
> could be both. For instance, the parameter names might need to be included
> in some mangled names, because they could affect which overload is
> selected. And in some corner cases, it will be an ABI break no matter what
> else we decide:
>
> // library
> int f(int a); // #1
> double f(double d);
>
> // user code
> void g(decltype(f(d:0)) x);
>
>

You forgot to mention the include file:


// library
int f(int a) // #1
{
....
}
double f(double d)
{
....
}


// header

int f( int a);
double f( double d );

// user code
void g(decltype(f(d:0)) x);


You can now go and change your library parameter names to whatever you
want; the function signatures will be the same.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1135e27e55b20904e84126a1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">2013/10/8 Richard Smith <span dir=3D"ltr">&lt;<a href=3D"mailto:ric=
hard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</a>&gt;</span><=
br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"im"><span style=3D"color:rgb(34,34,34)">Yes,=
 sorry, I meant API, not ABI. But depending on the exact rules, it could be=
 both. For instance, the parameter names might need to be included in some =
mangled names, because they could affect which overload is selected. And in=
 some corner cases, it will be an ABI break no matter what else we decide:<=
/span><br>
</div><div class=3D"gmail_extra"><div class=3D"gmail_quote">
<div><br></div><div>// library</div><div>int f(int a); // #1</div><div>doub=
le f(double d);</div><div><br></div><div>// user code</div><div>void g(decl=
type(f(d:0)) x);</div><div><br></div></div></div></div></blockquote><div>
<br></div><div><br></div><div>You forgot to mention the include file:</div>=
<div><br></div><div><br></div><div><div>// library</div><div>int f(int a) /=
/ #1</div><div>{</div><div>...</div><div>}</div><div>double f(double d)<br>
</div><div>{</div><div>...</div><div>}</div><div><br></div><div><br></div><=
div>// header</div><div><br></div><div>int f( int a);</div><div>double f( d=
ouble d );</div><div><br></div><div>// user code</div><div>void g(decltype(=
f(d:0)) x);</div>
</div><div><br></div><div>=A0</div><div>You can now go and change your libr=
ary parameter names to whatever you want; the function signatures will be t=
he same.</div></div></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1135e27e55b20904e84126a1--

.

> I think that the strongest argument against allowing non-colon formals to be
> called by name has not been mentioned explicitly: The current standard
> library implementations don't consistently use the same name for the same
> parameter (right?). I assume that they don't and thus any code that uses one

If we introduce named params wether implicit or explicit, I think we
should also standardise STL interfaces anyway. Otherwise it seems
silly to have named args as a language feature and not allow users to
make use of STL with named args (at least on public interfaces).

Many public code interfaces (not STL) already define sensible names
for params in their public interface as a form of documentation. I
know all API's we produce at work do this. It is just a little
annoying that we would have to markup these interfaces to support
named params usage. Especially for the C interfaces being used from
C++ code. This is one reason why I still prefer not requiring
declarations to be marked up. But my point is that regardless, I think
we will want to standardize a lot of STL parameter names.


> On the ordering issue I strongly advocate against having to state the
> actuals in the same order as the formals. One of the main drivers of having

Agreed.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a11c3675e42333704e88d648d
Content-Type: text/plain; charset=ISO-8859-1

2013/10/8 Zhihao Yuan <zy@miator.net>

> On Tue, Oct 8, 2013 at 4:26 PM, Philipp Stephani <p.stephani2@gmail.com>
> wrote:
> > Often a dedicated options type (e.g. a namedtuple) is better
> > than a large number of keyword arguments.
>
> Lua uses this approach.  And they even has a syntax
> sugar to use func{ <table> } call instead of
> func({ <table> }).  I'm not particularly in favor of this;
> sometimes a language extension makes things cleaner.
> (And we don't have such convenient struct in C++ I guess).
>
>
Not yet, we would at least have to adopt C's named initializers:

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

Then we could think of allowing leaving out the outer braces:

f(a, .b = 1, .c = 2)

For other uses, we can adopt C# and VB's feature of auto-generating
anonymous record types:

f(a, new {.b = 1, .c = 2})  // creates a new struct type

Lots of things are still possible with only syntactic sugar and without
modifying the type system in complex ways.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c3675e42333704e88d648d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">2013/10/8 Zhihao Yuan <span dir=3D"ltr">&lt;<a href=3D"mailto:zy@mi=
ator.net" target=3D"_blank">zy@miator.net</a>&gt;</span><br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
<div class=3D"im">On Tue, Oct 8, 2013 at 4:26 PM, Philipp Stephani &lt;<a h=
ref=3D"mailto:p.stephani2@gmail.com">p.stephani2@gmail.com</a>&gt; wrote:<b=
r>
&gt; Often a dedicated options type (e.g. a namedtuple) is better<br>
&gt; than a large number of keyword arguments.<br>
<br>
</div>Lua uses this approach. =A0And they even has a syntax<br>
sugar to use func{ &lt;table&gt; } call instead of<br>
func({ &lt;table&gt; }). =A0I&#39;m not particularly in favor of this;<br>
sometimes a language extension makes things cleaner.<br>
(And we don&#39;t have such convenient struct in C++ I guess).<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><=
br></div><div>Not yet, we would at least have to adopt C&#39;s named initia=
lizers:</div><div><br></div><div>f(a, {.b =3D 1, .c =3D 2})</div><div><br><=
/div>
<div>Then we could think of allowing leaving out the outer braces:</div><di=
v><br></div><div>f(a, .b =3D 1, .c =3D 2)</div><div><br></div><div>For othe=
r uses, we can adopt C# and VB&#39;s feature of auto-generating anonymous r=
ecord types:</div>
<div><br></div><div>f(a, new {.b =3D 1, .c =3D 2}) =A0// creates a new stru=
ct type</div><div><br></div><div>Lots of things are still possible with onl=
y syntactic sugar and without modifying the type system in complex ways.</d=
iv>
</div></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c3675e42333704e88d648d--

.

This is a multi-part message in MIME format.
--------------040402060107050300000000
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 12/10/13 18:04, Philipp Stephani a =E9crit :
>
>
>
> 2013/10/8 Zhihao Yuan <zy@miator.net <mailto:zy@miator.net>>
>
>     On Tue, Oct 8, 2013 at 4:26 PM, Philipp Stephani
>     <p.stephani2@gmail.com <mailto:p.stephani2@gmail.com>> wrote:
>     > Often a dedicated options type (e.g. a namedtuple) is better
>     > than a large number of keyword arguments.
>
>     Lua uses this approach.  And they even has a syntax
>     sugar to use func{ <table> } call instead of
>     func({ <table> }).  I'm not particularly in favor of this;
>     sometimes a language extension makes things cleaner.
>     (And we don't have such convenient struct in C++ I guess).
>
>
> Not yet, we would at least have to adopt C's named initializers:
>
> f(a, {.b =3D 1, .c =3D 2})
>
> Then we could think of allowing leaving out the outer braces:
>
> f(a, .b =3D 1, .c =3D 2)
>
> For other uses, we can adopt C# and VB's feature of auto-generating=20
> anonymous record types:
>
> f(a, new {.b =3D 1, .c =3D 2})  // creates a new struct type
>
> Lots of things are still possible with only syntactic sugar and=20
> without modifying the type system in complex ways.
>
+1

Designated data member initialization + Non static data members=20
initialization ~ Named  parameters.

Vicente



--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--------------040402060107050300000000
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Le 12/10/13 18:04, Philipp Stephani a
      &eacute;crit&nbsp;:<br>
    </div>
    <blockquote
cite="mid:CAArVCkRsuaxaHJtE80PCOF7GoiRoTd=EO-URjFcE+8OGwWk-Dw@mail.gmail.com"
      type="cite">
      <div dir="ltr"><br>
        <div class="gmail_extra"><br>
          <br>
          <div class="gmail_quote">2013/10/8 Zhihao Yuan <span
              dir="ltr">&lt;<a moz-do-not-send="true"
                href="mailto:zy@miator.net" target="_blank">zy@miator.net</a>&gt;</span><br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div class="im">On Tue, Oct 8, 2013 at 4:26 PM, Philipp
                Stephani &lt;<a moz-do-not-send="true"
                  href="mailto:p.stephani2@gmail.com">p.stephani2@gmail.com</a>&gt;
                wrote:<br>
                &gt; Often a dedicated options type (e.g. a namedtuple)
                is better<br>
                &gt; than a large number of keyword arguments.<br>
                <br>
              </div>
              Lua uses this approach. &nbsp;And they even has a syntax<br>
              sugar to use func{ &lt;table&gt; } call instead of<br>
              func({ &lt;table&gt; }). &nbsp;I'm not particularly in favor of
              this;<br>
              sometimes a language extension makes things cleaner.<br>
              (And we don't have such convenient struct in C++ I guess).<br>
              <div class="HOEnZb">
                <div class="h5"><br>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>Not yet, we would at least have to adopt C's named
              initializers:</div>
            <div><br>
            </div>
            <div>f(a, {.b = 1, .c = 2})</div>
            <div><br>
            </div>
            <div>Then we could think of allowing leaving out the outer
              braces:</div>
            <div><br>
            </div>
            <div>f(a, .b = 1, .c = 2)</div>
            <div><br>
            </div>
            <div>For other uses, we can adopt C# and VB's feature of
              auto-generating anonymous record types:</div>
            <div><br>
            </div>
            <div>f(a, new {.b = 1, .c = 2}) &nbsp;// creates a new struct
              type</div>
            <div><br>
            </div>
            <div>Lots of things are still possible with only syntactic
              sugar and without modifying the type system in complex
              ways.</div>
          </div>
        </div>
      </div>
      <br>
    </blockquote>
    +1<br>
    <br>
    Designated data member initialization + Non static data members
    initialization ~ Named&nbsp; parameters. <br>
    <br>
    Vicente<br>
    <br>
    <br>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <pre class="xmp">
</pre>
    <br>
  </body>
</html>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

--------------040402060107050300000000--

.