------=_Part_113_10283476.1402770096488
Content-Type: text/plain; charset=UTF-8

A colleague and I have been working on a proposal to add named arguments to
C++.

The proposal draft can be found here:
http://ehsan.github.io/namedargs/namedargs.html

Any feedback on it is appreciated!

Thanks,
Botond

--

---
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_113_10283476.1402770096488
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">A colleague and I have been working on a proposal to add n=
amed arguments to C++.<br><br>The proposal draft can be found here: http://=
ehsan.github.io/namedargs/namedargs.html<br><br>Any feedback on it is appre=
ciated!<br><br>Thanks,<br>Botond<br></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_113_10283476.1402770096488--

.

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

It is not possible to introduce named arguments in C++ without changing
declarations because parameter names are not part of a function's
signature. In declarations they can be left out entirely or given arbitrary
names; for example most standard library implementations use reserved names
(starting with a double underscore) to avoid interference with macros.
Proposals for names arguments either have to amend the type system
accordingly to allow for parameters whose names are part of the function's
type (requires ABI changes, no benefit for existing functions), or have to
resort to other means. I think the most fruitful approach so far consists
in enabling designated initializers for aggregate classes; this exploits
the fact that member names are part of a class type.

On Sat Jun 14 2014 at 20:21:38, <botond.ballo@gmail.com> wrote:

> A colleague and I have been working on a proposal to add named arguments
> to C++.
>
> The proposal draft can be found here:
> http://ehsan.github.io/namedargs/namedargs.html
>
> Any feedback on it is appreciated!
>
> Thanks,
> Botond
>
> --
>
> ---
> 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/.

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

It is not possible to introduce named arguments in C++ without changing dec=
larations because parameter names are not part of a function&#39;s signatur=
e. In declarations they can be left out entirely or given arbitrary names; =
for example most standard library implementations use reserved names (start=
ing with a double underscore) to avoid interference with macros.<br>
<div>Proposals for names arguments either have to amend the type system acc=
ordingly to allow for parameters whose names are part of the function&#39;s=
 type (requires ABI changes, no benefit for existing functions), or have to=
 resort to other means. I think the most fruitful approach so far consists =
in enabling designated initializers for aggregate classes; this exploits th=
e fact that member names are part of a class type.</div>
<br><div>On Sat Jun 14 2014 at 20:21:38, &lt;<a href=3D"mailto:botond.ballo=
@gmail.com">botond.ballo@gmail.com</a>&gt; wrote:</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">
<div dir=3D"ltr">A colleague and I have been working on a proposal to add n=
amed arguments to C++.<br><br>The proposal draft can be found here: <a href=
=3D"http://ehsan.github.io/namedargs/namedargs.html" target=3D"_blank">http=
://ehsan.github.io/namedargs/namedargs.html</a><br>
<br>Any feedback on it is appreciated!<br><br>Thanks,<br>Botond<br></div>

<p></p>

-- <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+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
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 />
<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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--001a1133f770a2a8b904fbd02c0f--

.

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

Hi Botond,

This is interesting and something I was thinking about just the other day
while looking at Objective-C and Swift.

I think the better approach would be to nominate as part of a function
declaration which arguments are positional and which are named.  This
characteristic of a function parameter, that is, whether it is named or
positional, then becomes part of the function type.  The names of named
parameters also become part of the function type.  Declaration matching
between function declarations/definitions then proceeds as normal by
matching the function type.

The syntax to declare a named parameter could be to insert a colon before
the declarator-id:

    void f(int positional, int: named);     // 1
    void f(int*: foo, char(*: bar)(double)); // 2

The calls are then as you suggest:

    f(x, named: y); // ok calls 1
    f(named: y, x); // ok calls 1
    f(foo: x, bar: y); // ok calls 2
    f(bar: y, foo: x); // ok calls 2

Basically named parameters are unordered and do not take up a position that
influences positional parameters.  Positional and named parameters form two
separate sets of parameters, and named arguments do not have a position
(they have names).  Therefore:

   void f(int: named, int othername); // redeclare 1, declaration matches
   void f(char(*:bar)(double), int*: foo); // redeclare 2, declaration
matches

Enjoy,
Andrew.





On Sat, Jun 14, 2014 at 8:21 PM, <botond.ballo@gmail.com> wrote:

> A colleague and I have been working on a proposal to add named arguments
> to C++.
>
> The proposal draft can be found here:
> http://ehsan.github.io/namedargs/namedargs.html
>
> Any feedback on it is appreciated!
>
> Thanks,
> Botond
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr">Hi Botond,<div><br></div><div>This is interesting and some=
thing I was thinking about just the other day while looking at Objective-C =
and Swift.</div><div><br></div><div>I think the better approach would be to=
 nominate as part of a function declaration which arguments are positional =
and which are named. =C2=A0This characteristic of a function parameter, tha=
t is, whether it is named or positional, then becomes part of the function =
type. =C2=A0The names of named parameters also become part of the function =
type. =C2=A0Declaration matching between function declarations/definitions =
then proceeds as normal by matching the function type.</div>
<div><br></div><div>The syntax to declare a named parameter could be to ins=
ert a colon before the declarator-id:</div><div><br></div><div>=C2=A0 =C2=
=A0 void f(int positional, int: named); =C2=A0 =C2=A0 // 1</div><div>=C2=A0=
 =C2=A0 void f(int*: foo, char(*: bar)(double)); // 2</div>
<div><br></div><div>The calls are then as you suggest:</div><div><br></div>=
<div>=C2=A0 =C2=A0 f(x, named: y); // ok calls 1</div><div>=C2=A0 =C2=A0 f(=
named: y, x); // ok calls 1</div><div><div>=C2=A0 =C2=A0 f(foo: x, bar: y);=
 // ok calls 2</div></div>
<div><div>=C2=A0 =C2=A0 f(bar: y, foo: x); // ok calls 2</div></div><div><b=
r></div><div>Basically named parameters are unordered and do not take up a =
position that influences positional parameters. =C2=A0Positional and named =
parameters form two separate sets of parameters, and named arguments do not=
 have a position (they have names). =C2=A0Therefore:</div>
<div><br></div><div>=C2=A0 =C2=A0void f(int: named, int othername); // rede=
clare 1, declaration matches</div><div><div>=C2=A0 =C2=A0void f(char(*:bar)=
(double),=C2=A0int*: foo); // redeclare 2, declaration matches</div></div><=
div><br></div><div>Enjoy,</div>
<div>Andrew.</div><div><br></div><div><br></div><div>=C2=A0</div></div><div=
 class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat, Jun 14, 2=
014 at 8:21 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:botond.ballo@gmail=
..com" target=3D"_blank">botond.ballo@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">A colleague and I have been=
 working on a proposal to add named arguments to C++.<br><br>The proposal d=
raft can be found here: <a href=3D"http://ehsan.github.io/namedargs/namedar=
gs.html" target=3D"_blank">http://ehsan.github.io/namedargs/namedargs.html<=
/a><br>
<br>Any feedback on it is appreciated!<br><br>Thanks,<br>Botond<span class=
=3D"HOEnZb"><font color=3D"#888888"><br></font></span></div><span class=3D"=
HOEnZb"><font color=3D"#888888">

<p></p>

-- <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+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
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>
</font></span></blockquote></div><br></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--001a11c32c564a09c404fbd05b3b--

.

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

To give an example why named arguments are more than syntactic sugar in C++:

// Translation unit A
void f(int a, int b) {
  // code
}

// Translation unit B
void f(int a, int b);
int main() {
  f(a: 1, b: 2);
}

// Translation unit C
void f(int b, int a);
int main() {
  f(a: 1, b: 2);
}

// Translation unit D
void f(int, int);
int main() {
  f(a: 1, b: 2);
}

All four translation units can be compiled separately. The object code for
A can then be linked with one of B, C, D to produce an executable. Except
for the named arguments all translation units are valid C++. C and D
represent valid cases where your proposal would fail: C would result in a
confusing situation (f is called with a = 2 and b = 1, in contrast to what
the named arguments say), D couldn't be made to compile because the
parameter names are not available. Your proposal needs to address these
cases. Addressing C is especially hard: either the outcome is confusing
(and more confusing cases can be thought of by adding overloads to the
problem), or the compiler somehow has to communicate the parameter and
argument names to the linker, necessitating profound changes in all
toolchains.
Designated initializers, by contrast, suffer from none of these problems,
because ODR already ensures that all involved compilation units see the
same member names.

On Sat Jun 14 2014 at 20:43:47, Philipp Maximilian Stephani <
p.stephani2@gmail.com> wrote:

> It is not possible to introduce named arguments in C++ without changing
> declarations because parameter names are not part of a function's
> signature. In declarations they can be left out entirely or given arbitrary
> names; for example most standard library implementations use reserved names
> (starting with a double underscore) to avoid interference with macros.
> Proposals for names arguments either have to amend the type system
> accordingly to allow for parameters whose names are part of the function's
> type (requires ABI changes, no benefit for existing functions), or have to
> resort to other means. I think the most fruitful approach so far consists
> in enabling designated initializers for aggregate classes; this exploits
> the fact that member names are part of a class type.
>
> On Sat Jun 14 2014 at 20:21:38, <botond.ballo@gmail.com> wrote:
>
>> A colleague and I have been working on a proposal to add named arguments
>> to C++.
>>
>> The proposal draft can be found here: http://ehsan.github.io/
>> namedargs/namedargs.html
>>
>> Any feedback on it is appreciated!
>>
>> Thanks,
>> Botond
>>
>> --
>>
>> ---
>> 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/.

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

To give an example why named arguments are more than syntactic sugar in C++=
:<br><br>// Translation unit A<div>void f(int a, int b) {</div><div>=C2=A0 =
// code</div><div>}</div><div><br></div><div>// Translation unit B</div><di=
v>
void f(int a, int b);</div><div>int main() {</div><div>=C2=A0 f(a: 1, b: 2)=
;</div><div>}</div><div><br></div><div>// Translation unit C</div><div>void=
 f(int b, int a);</div><div>int main() {</div><div>=C2=A0 f(a: 1, b: 2);</d=
iv><div>
}</div><div><br></div><div>// Translation unit D</div><div>void f(int, int)=
;</div><div>int main() {</div><div>=C2=A0 f(a: 1, b: 2);</div><div>}</div><=
div><br></div><div>All four translation units can be compiled separately. T=
he object code for A can then be linked with one of B, C, D to produce an e=
xecutable. Except for the named arguments all translation units are valid C=
++. C and D represent valid cases where your proposal would fail: C would r=
esult in a confusing situation (f is called with a =3D 2 and b =3D 1, in co=
ntrast to what the named arguments say), D couldn&#39;t be made to compile =
because the parameter names are not available. Your proposal needs to addre=
ss these cases. Addressing C is especially hard: either the outcome is conf=
using (and more confusing cases can be thought of by adding overloads to th=
e problem), or the compiler somehow has to communicate the parameter and ar=
gument names to the linker, necessitating profound changes in all toolchain=
s.</div>
<div>Designated initializers, by contrast, suffer from none of these proble=
ms, because ODR already ensures that all involved compilation units see the=
 same member names.</div><br><div>On Sat Jun 14 2014 at 20:43:47, Philipp M=
aximilian Stephani &lt;<a href=3D"mailto:p.stephani2@gmail.com">p.stephani2=
@gmail.com</a>&gt; wrote:</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">It is not possible to introduce named argume=
nts in C++ without changing declarations because parameter names are not pa=
rt of a function&#39;s signature. In declarations they can be left out enti=
rely or given arbitrary names; for example most standard library implementa=
tions use reserved names (starting with a double underscore) to avoid inter=
ference with macros.<br>
<div>Proposals for names arguments either have to amend the type system acc=
ordingly to allow for parameters whose names are part of the function&#39;s=
 type (requires ABI changes, no benefit for existing functions), or have to=
 resort to other means. I think the most fruitful approach so far consists =
in enabling designated initializers for aggregate classes; this exploits th=
e fact that member names are part of a class type.</div>
<br><div>On Sat Jun 14 2014 at 20:21:38, &lt;<a href=3D"mailto:botond.ballo=
@gmail.com" target=3D"_blank">botond.ballo@gmail.com</a>&gt; wrote:</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">
<div dir=3D"ltr">A colleague and I have been working on a proposal to add n=
amed arguments to C++.<br><br>The proposal draft can be found here: <a href=
=3D"http://ehsan.github.io/namedargs/namedargs.html" target=3D"_blank">http=
://ehsan.github.io/<u></u>namedargs/namedargs.html</a><br>
<br>Any feedback on it is appreciated!<br><br>Thanks,<br>Botond<br></div>

<p></p>

-- <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+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<u></u>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/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</blockquote></blockquote>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--047d7b675980739ef004fbd07155--

.

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

One problem with this approach is that it requires ABI changes. Currently
name mangling removes parameter names because they are not part of a
function's signature. This approach requires that toolchains add support
for mangling parameter names. It also means that no existing function can
benefit from named arguments.

On Sat Jun 14 2014 at 20:56:51, Andrew Tomazos <andrewtomazos@gmail.com>
wrote:

> Hi Botond,
>
> This is interesting and something I was thinking about just the other day
> while looking at Objective-C and Swift.
>
> I think the better approach would be to nominate as part of a function
> declaration which arguments are positional and which are named.  This
> characteristic of a function parameter, that is, whether it is named or
> positional, then becomes part of the function type.  The names of named
> parameters also become part of the function type.  Declaration matching
> between function declarations/definitions then proceeds as normal by
> matching the function type.
>
> The syntax to declare a named parameter could be to insert a colon before
> the declarator-id:
>
>     void f(int positional, int: named);     // 1
>     void f(int*: foo, char(*: bar)(double)); // 2
>
> The calls are then as you suggest:
>
>     f(x, named: y); // ok calls 1
>     f(named: y, x); // ok calls 1
>     f(foo: x, bar: y); // ok calls 2
>     f(bar: y, foo: x); // ok calls 2
>
> Basically named parameters are unordered and do not take up a position
> that influences positional parameters.  Positional and named parameters
> form two separate sets of parameters, and named arguments do not have a
> position (they have names).  Therefore:
>
>    void f(int: named, int othername); // redeclare 1, declaration matches
>    void f(char(*:bar)(double), int*: foo); // redeclare 2, declaration
> matches
>
> Enjoy,
> Andrew.
>
>
>
>
>
> On Sat, Jun 14, 2014 at 8:21 PM, <botond.ballo@gmail.com> wrote:
>
>> A colleague and I have been working on a proposal to add named arguments
>> to C++.
>>
>> The proposal draft can be found here:
>> http://ehsan.github.io/namedargs/namedargs.html
>>
>> Any feedback on it is appreciated!
>>
>> Thanks,
>> Botond
>>
>> --
>>
>> ---
>> 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/.

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

One problem with this approach is that it requires ABI changes. Currently n=
ame mangling removes parameter names because they are not part of a functio=
n&#39;s signature. This approach requires that toolchains add support for m=
angling parameter names. It also means that no existing function can benefi=
t from named arguments.<br>
<br><div>On Sat Jun 14 2014 at 20:56:51, Andrew Tomazos &lt;<a href=3D"mail=
to:andrewtomazos@gmail.com">andrewtomazos@gmail.com</a>&gt; wrote:</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">
<div dir=3D"ltr">Hi Botond,<div><br></div><div>This is interesting and some=
thing I was thinking about just the other day while looking at Objective-C =
and Swift.</div><div><br></div><div>I think the better approach would be to=
 nominate as part of a function declaration which arguments are positional =
and which are named. =C2=A0This characteristic of a function parameter, tha=
t is, whether it is named or positional, then becomes part of the function =
type. =C2=A0The names of named parameters also become part of the function =
type. =C2=A0Declaration matching between function declarations/definitions =
then proceeds as normal by matching the function type.</div>

<div><br></div><div>The syntax to declare a named parameter could be to ins=
ert a colon before the declarator-id:</div><div><br></div><div>=C2=A0 =C2=
=A0 void f(int positional, int: named); =C2=A0 =C2=A0 // 1</div><div>=C2=A0=
 =C2=A0 void f(int*: foo, char(*: bar)(double)); // 2</div>

<div><br></div><div>The calls are then as you suggest:</div><div><br></div>=
<div>=C2=A0 =C2=A0 f(x, named: y); // ok calls 1</div><div>=C2=A0 =C2=A0 f(=
named: y, x); // ok calls 1</div><div><div>=C2=A0 =C2=A0 f(foo: x, bar: y);=
 // ok calls 2</div></div>

<div><div>=C2=A0 =C2=A0 f(bar: y, foo: x); // ok calls 2</div></div><div><b=
r></div><div>Basically named parameters are unordered and do not take up a =
position that influences positional parameters. =C2=A0Positional and named =
parameters form two separate sets of parameters, and named arguments do not=
 have a position (they have names). =C2=A0Therefore:</div>

<div><br></div><div>=C2=A0 =C2=A0void f(int: named, int othername); // rede=
clare 1, declaration matches</div><div><div>=C2=A0 =C2=A0void f(char(*:bar)=
(double),=C2=A0int*: foo); // redeclare 2, declaration matches</div></div><=
div><br></div><div>Enjoy,</div>

<div>Andrew.</div><div><br></div><div><br></div><div>=C2=A0</div></div><div=
 class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat, Jun 14, 2=
014 at 8:21 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:botond.ballo@gmail=
..com" target=3D"_blank">botond.ballo@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">A colleague and I have been=
 working on a proposal to add named arguments to C++.<br><br>The proposal d=
raft can be found here: <a href=3D"http://ehsan.github.io/namedargs/namedar=
gs.html" target=3D"_blank">http://ehsan.github.io/namedargs/namedargs.html<=
/a><br>

<br>Any feedback on it is appreciated!<br><br>Thanks,<br>Botond<span><font =
color=3D"#888888"><br></font></span></div><span><font color=3D"#888888">

<p></p>

-- <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+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
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>
</font></span></blockquote></div><br></div>

<p></p>

-- <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+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
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 />
<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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--047d7b3a89d2b79bd004fbd07a20--

.

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

That is correct, yes.  As part of the function type, how many named
parameters a function has, and in lexicographical order, the names and
types of those parameters, would have to be mangled into the symbol.  The
current mangling scheme for functions with only positional parameters could
be left unchanged though.

Yes, existing functions would not benefit, but I think that is unavoidable.
 Parameters in current C++ are by-design positional.  Their position is
part of the function type, not their names.  Trying to retrofit these
positional parameters into named parameters without breaking changes will
be a mess.  I think adding named parameters in the way I proposed as a new
feature for new code is the cleaner approach without breaking changes.

On Sat, Jun 14, 2014 at 9:05 PM, Philipp Maximilian Stephani <
p.stephani2@gmail.com> wrote:

> One problem with this approach is that it requires ABI changes. Currently
> name mangling removes parameter names because they are not part of a
> function's signature. This approach requires that toolchains add support
> for mangling parameter names. It also means that no existing function can
> benefit from named arguments.
>
>
> On Sat Jun 14 2014 at 20:56:51, Andrew Tomazos <andrewtomazos@gmail.com>
> wrote:
>
>> Hi Botond,
>>
>> This is interesting and something I was thinking about just the other day
>> while looking at Objective-C and Swift.
>>
>> I think the better approach would be to nominate as part of a function
>> declaration which arguments are positional and which are named.  This
>> characteristic of a function parameter, that is, whether it is named or
>> positional, then becomes part of the function type.  The names of named
>> parameters also become part of the function type.  Declaration matching
>> between function declarations/definitions then proceeds as normal by
>> matching the function type.
>>
>> The syntax to declare a named parameter could be to insert a colon before
>> the declarator-id:
>>
>>     void f(int positional, int: named);     // 1
>>     void f(int*: foo, char(*: bar)(double)); // 2
>>
>> The calls are then as you suggest:
>>
>>     f(x, named: y); // ok calls 1
>>     f(named: y, x); // ok calls 1
>>     f(foo: x, bar: y); // ok calls 2
>>     f(bar: y, foo: x); // ok calls 2
>>
>> Basically named parameters are unordered and do not take up a position
>> that influences positional parameters.  Positional and named parameters
>> form two separate sets of parameters, and named arguments do not have a
>> position (they have names).  Therefore:
>>
>>    void f(int: named, int othername); // redeclare 1, declaration matches
>>    void f(char(*:bar)(double), int*: foo); // redeclare 2, declaration
>> matches
>>
>> Enjoy,
>> Andrew.
>>
>>
>>
>>
>>
>> On Sat, Jun 14, 2014 at 8:21 PM, <botond.ballo@gmail.com> wrote:
>>
>>> A colleague and I have been working on a proposal to add named arguments
>>> to C++.
>>>
>>> The proposal draft can be found here:
>>> http://ehsan.github.io/namedargs/namedargs.html
>>>
>>> Any feedback on it is appreciated!
>>>
>>> Thanks,
>>> Botond
>>>
>>> --
>>>
>>> ---
>>> 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/.
>

--

---
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/.

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

<div dir=3D"ltr">That is correct, yes. =C2=A0As part of the function type, =
how many named parameters a function has, and in lexicographical order, the=
 names and types of those parameters, would have to be mangled into the sym=
bol. =C2=A0The current mangling scheme for functions with only positional p=
arameters could be left unchanged though.<br>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Yes, existi=
ng functions would not benefit, but I think that is unavoidable. =C2=A0Para=
meters in current C++ are by-design positional. =C2=A0Their position is par=
t of the function type, not their names. =C2=A0Trying to retrofit these pos=
itional parameters into named parameters without breaking changes will be a=
 mess. =C2=A0I think adding named parameters in the way I proposed as a new=
 feature for new code is the cleaner approach without breaking changes.</di=
v>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">On Sat, Jun 14, 2014 at 9:05 PM, Philipp Maximilian Stepha=
ni <span dir=3D"ltr">&lt;<a href=3D"mailto:p.stephani2@gmail.com" target=3D=
"_blank">p.stephani2@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">One problem with this approach is that it re=
quires ABI changes. Currently name mangling removes parameter names because=
 they are not part of a function&#39;s signature. This approach requires th=
at toolchains add support for mangling parameter names. It also means that =
no existing function can benefit from named arguments.<div class=3D"HOEnZb"=
>
<div class=3D"h5"><br>
<br><div>On Sat Jun 14 2014 at 20:56:51, Andrew Tomazos &lt;<a href=3D"mail=
to:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@gmail.com</a>&g=
t; wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr">Hi Botond,<div><br></div><div>This is interesting and some=
thing I was thinking about just the other day while looking at Objective-C =
and Swift.</div><div><br></div><div>I think the better approach would be to=
 nominate as part of a function declaration which arguments are positional =
and which are named. =C2=A0This characteristic of a function parameter, tha=
t is, whether it is named or positional, then becomes part of the function =
type. =C2=A0The names of named parameters also become part of the function =
type. =C2=A0Declaration matching between function declarations/definitions =
then proceeds as normal by matching the function type.</div>


<div><br></div><div>The syntax to declare a named parameter could be to ins=
ert a colon before the declarator-id:</div><div><br></div><div>=C2=A0 =C2=
=A0 void f(int positional, int: named); =C2=A0 =C2=A0 // 1</div><div>=C2=A0=
 =C2=A0 void f(int*: foo, char(*: bar)(double)); // 2</div>


<div><br></div><div>The calls are then as you suggest:</div><div><br></div>=
<div>=C2=A0 =C2=A0 f(x, named: y); // ok calls 1</div><div>=C2=A0 =C2=A0 f(=
named: y, x); // ok calls 1</div><div><div>=C2=A0 =C2=A0 f(foo: x, bar: y);=
 // ok calls 2</div></div>


<div><div>=C2=A0 =C2=A0 f(bar: y, foo: x); // ok calls 2</div></div><div><b=
r></div><div>Basically named parameters are unordered and do not take up a =
position that influences positional parameters. =C2=A0Positional and named =
parameters form two separate sets of parameters, and named arguments do not=
 have a position (they have names). =C2=A0Therefore:</div>


<div><br></div><div>=C2=A0 =C2=A0void f(int: named, int othername); // rede=
clare 1, declaration matches</div><div><div>=C2=A0 =C2=A0void f(char(*:bar)=
(double),=C2=A0int*: foo); // redeclare 2, declaration matches</div></div><=
div><br></div><div>Enjoy,</div>


<div>Andrew.</div><div><br></div><div><br></div><div>=C2=A0</div></div><div=
 class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat, Jun 14, 2=
014 at 8:21 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:botond.ballo@gmail=
..com" target=3D"_blank">botond.ballo@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">A colleague and I have been=
 working on a proposal to add named arguments to C++.<br><br>The proposal d=
raft can be found here: <a href=3D"http://ehsan.github.io/namedargs/namedar=
gs.html" target=3D"_blank">http://ehsan.github.io/namedargs/namedargs.html<=
/a><br>


<br>Any feedback on it is appreciated!<br><br>Thanks,<br>Botond<span><font =
color=3D"#888888"><br></font></span></div><span><font color=3D"#888888">

<p></p>

-- <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+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
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>
</font></span></blockquote></div><br></div>

<p></p>

-- <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+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
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>
<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+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
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 />
<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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--089e0111d1be16d63404fbd0bab0--

.

On 2014-06-15, at 2:56 AM, Andrew Tomazos <andrewtomazos@gmail.com> wrote:

> Hi Botond,
>=20
> This is interesting and something I was thinking about just the other day=
 while looking at Objective-C and Swift.
>=20
> I think the better approach would be to nominate as part of a function de=
claration which arguments are positional and which are named. =20

This is critical information to have.

> This characteristic of a function parameter, that is, whether it is named=
 or positional, then becomes part of the function type.  The names of named=
 parameters also become part of the function type.  Declaration matching be=
tween function declarations/definitions then proceeds as normal by matching=
 the function type.

Types don't currently contain such arbitrary identifiers. It should be suff=
icient to account for identifier name and namedness in the ODR, allowing th=
at a function parameter may be multiply-declared in a single TU, and the de=
clarations, not definitions, must match.

> The syntax to declare a named parameter could be to insert a colon before=
 the declarator-id:

The explicit keyword is available in this context too. Or, the dot would ma=
tch C99 designated initializers syntax. (Well, it's a bike-shed.)

>     void f(int positional, int: named);     // 1
>     void f(int*: foo, char(*: bar)(double)); // 2
>=20
> The calls are then as you suggest:
>=20
>     f(x, named: y); // ok calls 1

What do you think of letting hybrids be ill-formed? This gives me the willi=
es. What other language allows this?

>     f(named: y, x); // ok calls 1

C99 designated initializers have a name jump to a certain point in the list=
, and then successive unnamed elements initialize items succeeding the last=
 one named. If hybrids are allowed, that seems more reasonable behavior.

Also, default arguments don't need to be a trailing subsequence when named =
parameters are interspersed. The proposal touches on this tangentially, but=
 it should state that an assumption made in various parts of the standard w=
ill be broken.

--=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/.

.

On 2014-06-15, at 2:21 AM, botond.ballo@gmail.com wrote:

> Any feedback on it is appreciated!

Got any love for named template 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/.

.

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

On Sat, Jun 14, 2014 at 9:24 PM, David Krauss <potswa@gmail.com> wrote:

> > The syntax to declare a named parameter could be to insert a colon
> before the declarator-id:
>

> The explicit keyword is available in this context too. Or, the dot would
> match C99 designated initializers syntax. (Well, it's a bike-shed.)


I like how the colon matches between the function declaration and the
function call expression:

    void f(int: n); // decl
    f(n: x); // call

Dot doesn't work (as well):

    void f(int. n);
    f(n.x); // member access or named parameter?

Explicit:

    void f(explicit int n);
    f(n: x);

Keyword seems overkill.  Colon looks better to me.

>     void f(int positional, int: named);     // 1
> >     void f(int*: foo, char(*: bar)(double)); // 2
> >
> > The calls are then as you suggest:
> >
> >     f(x, named: y); // ok calls 1
>
> What do you think of letting hybrids be ill-formed? This gives me the
> willies. What other language allows this?


We could say you have to have all positional or all named within one
function, but what about mixing them gives you the willies?

I didn't get this hybrid idea from another language, but the use case I had
in mind is that sometimes a function has obvious natural parameter(s) that
don't need names and other minor parameters that do.  Take a sort function
for example (forget std::sort exists for the moment), obviously it takes a
range that it is sorting, but maybe it takes a custom comparator as well:

    void Sort(Range range, Comparator: comparator = Less);

So you call it:

    Sort(x); // duh its sorting x
    Sort(x, comparator: f); // oh I see, f is a custom comparator

>     f(named: y, x); // ok calls 1
>
> C99 designated initializers have a name jump to a certain point in the
> list, and then successive unnamed elements initialize items succeeding the
> last one named. If hybrids are allowed, that seems more reasonable behavior.
>
> Also, default arguments don't need to be a trailing subsequence when named
> parameters are interspersed. The proposal touches on this tangentially, but
> it should state that an assumption made in various parts of the standard
> will be broken.
>

Yeah, under my version: the rules for default arguments on positional
parameters would ignore any named parameters and, after that, work as they
do now.  Named parameters may have default arguments (regardless of their
syntactic position in the declaration) and have no effect on the
well-formedness of positional parameters:

    void f1(int: x, int: y = 42); // ok
    void f2(int: x = 42, int: y); // ok

    void f3(int x, int y = 42); // ok
    void f4(int x = 42, int y); // error

    void f5(int: x, int y = 42); // ok
    void f6(int x = 42, int: y); // ok

Multiple matched declarations must contain at most one default argument for
a given named parameter N.

I think it all works.

--

---
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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Jun 14, 2014 at 9:24 PM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"=
mailto:potswa@gmail.com" target=3D"_blank">potswa@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"><div class=3D"">&gt; The syntax to declare a named paramet=
er could be to insert a colon before the declarator-id:<br>
</div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border=
-left-style:solid;padding-left:1ex"><div class=3D"">
<br>
</div>The explicit keyword is available in this context too. Or, the dot wo=
uld match C99 designated initializers syntax. (Well, it&#39;s a bike-shed.)=
</blockquote><div><br></div><div>I like how the colon matches between the f=
unction declaration and the function call expression:</div>
<div><br></div><div>=C2=A0 =C2=A0 void f(int: n); // decl</div><div>=C2=A0 =
=C2=A0 f(n: x); // call</div><div><br></div><div>Dot doesn&#39;t work (as w=
ell):</div><div><br></div><div>=C2=A0 =C2=A0 void f(int. n);</div><div>=C2=
=A0 =C2=A0 f(n.x); // member access or named parameter?<br>
</div><div><br></div><div>Explicit:</div><div><br></div><div>=C2=A0 =C2=A0 =
void f(explicit int n);</div><div>=C2=A0 =C2=A0 f(n: x);</div><div><br></di=
v><div>Keyword seems overkill. =C2=A0Colon looks better to me.</div><div><b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style=
:solid;padding-left:1ex">
<div class=3D"">
&gt; =C2=A0 =C2=A0 void f(int positional, int: named); =C2=A0 =C2=A0 // 1<b=
r>
&gt; =C2=A0 =C2=A0 void f(int*: foo, char(*: bar)(double)); // 2<br>
&gt;<br>
&gt; The calls are then as you suggest:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 f(x, named: y); // ok calls 1<br>
<br>
</div>What do you think of letting hybrids be ill-formed? This gives me the=
 willies. What other language allows this?</blockquote><div><br></div><div>=
We could say you have to have all positional or all named within one functi=
on, but what about mixing them gives you the willies?</div>
<div><br></div><div>I didn&#39;t get this hybrid idea from another language=
, but the use case I had in mind is that sometimes a function has obvious n=
atural parameter(s) that don&#39;t need names and other minor parameters th=
at do. =C2=A0Take a sort function for example (forget std::sort exists for =
the moment), obviously it takes a range that it is sorting, but maybe it ta=
kes a custom comparator as well:</div>
<div><br></div><div>=C2=A0 =C2=A0 void Sort(Range range, Comparator: compar=
ator =3D Less);</div><div><br></div><div>So you call it:</div><div><br></di=
v><div>=C2=A0 =C2=A0 Sort(x); // duh its sorting x</div><div>=C2=A0 =C2=A0 =
Sort(x, comparator: f); // oh I see, f is a custom comparator</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div class=3D"">
&gt; =C2=A0 =C2=A0 f(named: y, x); // ok calls 1<br>
<br>
</div>C99 designated initializers have a name jump to a certain point in th=
e list, and then successive unnamed elements initialize items succeeding th=
e last one named. If hybrids are allowed, that seems more reasonable behavi=
or.<br>

<br>
Also, default arguments don&#39;t need to be a trailing subsequence when na=
med parameters are interspersed. The proposal touches on this tangentially,=
 but it should state that an assumption made in various parts of the standa=
rd will be broken.<br>

<div class=3D""><div class=3D"h5"></div></div></blockquote></div><br></div>=
<div class=3D"gmail_extra">Yeah, under my version: the rules for default ar=
guments on positional parameters would ignore any named parameters and, aft=
er that, work as they do now. =C2=A0Named parameters may have default argum=
ents (regardless of their syntactic position in the declaration) and have n=
o effect on the well-formedness of positional parameters:</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">=C2=A0 =C2=
=A0 void f1(int: x, int: y =3D 42); // ok<br></div><div class=3D"gmail_extr=
a"><div class=3D"gmail_extra">=C2=A0 =C2=A0 void f2(int: x =3D 42, int: y);=
 // ok</div><div class=3D"gmail_extra">
<br></div><div><div><div class=3D"gmail_extra">=C2=A0 =C2=A0 void f3(int x,=
 int y =3D 42); // ok</div></div><div class=3D"gmail_extra">=C2=A0 =C2=A0 v=
oid f4(int x =3D 42, int y); // error</div></div><div><br></div><div><div><=
div><div class=3D"gmail_extra">
=C2=A0 =C2=A0 void f5(int: x, int y =3D 42); // ok</div></div><div class=3D=
"gmail_extra">=C2=A0 =C2=A0 void f6(int x =3D 42, int: y); // ok</div></div=
></div><div><br></div><div>Multiple matched declarations must contain at mo=
st one default argument for a given named parameter N.</div>
<div><br></div><div>I think it all works.</div></div><div class=3D"gmail_ex=
tra"><br></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--047d7bd6be02faff3404fbd117f8--

.

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

On Sat, Jun 14, 2014 at 9:27 PM, David Krauss <potswa@gmail.com> wrote:

>
> On 2014-06-15, at 2:21 AM, botond.ballo@gmail.com wrote:
>
> > Any feedback on it is appreciated!
>
> Got any love for named template arguments?


Shrug, why not:

    template<class positional, class: named> struct S {}

    S<T, named: U> x;

The relationship between template declarations and template IDs seems
completely orthogonal to that between function declarations and function
call expressions, at first glance at least.

--

---
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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Jun 14, 2014 at 9:27 PM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"=
mailto:potswa@gmail.com" target=3D"_blank">potswa@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 class=3D""><br>
On 2014-06-15, at 2:21 AM, <a href=3D"mailto:botond.ballo@gmail.com">botond=
..ballo@gmail.com</a> wrote:<br>
<br>
&gt; Any feedback on it is appreciated!<br>
<br>
</div>Got any love for named template arguments?</blockquote><div><br></div=
><div>Shrug, why not:</div><div><br></div><div>=C2=A0 =C2=A0 template&lt;cl=
ass positional, class: named&gt; struct S {}</div><div><br></div><div>=C2=
=A0 =C2=A0 S&lt;T, named: U&gt; x;</div>
<div><br></div><div>The relationship between template declarations and temp=
late IDs seems completely orthogonal to that between function declarations =
and function call expressions, at first glance at least.</div><div><br>
</div></div></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--089e011609f455933a04fbd127fa--

.

------=_Part_109_4161510.1402776257187
Content-Type: text/plain; charset=UTF-8

Could these issues be ameliorated by adding module support to C++?
(Granted, modules are quite complex and unlikely to be standardized soon,
but if they simplify this case, that's just one more reason to push for
modules.)

- Jim

On Saturday, June 14, 2014 2:03:03 PM UTC-5, Philipp Stephani wrote:
>
> To give an example why named arguments are more than syntactic sugar in
> C++:
>
> // Translation unit A
> void f(int a, int b) {
>   // code
> }
>
> // Translation unit B
> void f(int a, int b);
> int main() {
>   f(a: 1, b: 2);
> }
>
> // Translation unit C
> void f(int b, int a);
> int main() {
>   f(a: 1, b: 2);
> }
>
> // Translation unit D
> void f(int, int);
> int main() {
>   f(a: 1, b: 2);
> }
>
> All four translation units can be compiled separately. The object code for
> A can then be linked with one of B, C, D to produce an executable. Except
> for the named arguments all translation units are valid C++. C and D
> represent valid cases where your proposal would fail: C would result in a
> confusing situation (f is called with a = 2 and b = 1, in contrast to what
> the named arguments say), D couldn't be made to compile because the
> parameter names are not available. Your proposal needs to address these
> cases. Addressing C is especially hard: either the outcome is confusing
> (and more confusing cases can be thought of by adding overloads to the
> problem), or the compiler somehow has to communicate the parameter and
> argument names to the linker, necessitating profound changes in all
> toolchains.
> Designated initializers, by contrast, suffer from none of these problems,
> because ODR already ensures that all involved compilation units see the
> same member names.
>
> On Sat Jun 14 2014 at 20:43:47, Philipp Maximilian Stephani <
> p.ste...@gmail.com <javascript:>> wrote:
>
>> It is not possible to introduce named arguments in C++ without changing
>> declarations because parameter names are not part of a function's
>> signature. In declarations they can be left out entirely or given arbitrary
>> names; for example most standard library implementations use reserved names
>> (starting with a double underscore) to avoid interference with macros.
>> Proposals for names arguments either have to amend the type system
>> accordingly to allow for parameters whose names are part of the function's
>> type (requires ABI changes, no benefit for existing functions), or have to
>> resort to other means. I think the most fruitful approach so far consists
>> in enabling designated initializers for aggregate classes; this exploits
>> the fact that member names are part of a class type.
>>
>> On Sat Jun 14 2014 at 20:21:38, <botond...@gmail.com <javascript:>>
>> wrote:
>>
>>> A colleague and I have been working on a proposal to add named arguments
>>> to C++.
>>>
>>> The proposal draft can be found here: http://ehsan.github.io/
>>> namedargs/namedargs.html
>>>
>>> Any feedback on it is appreciated!
>>>
>>> Thanks,
>>> Botond
>>>
>>> --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposal...@isocpp.org <javascript:>.
>>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>>> 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/.

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

<div dir=3D"ltr">Could these issues be ameliorated by adding module support=
 to C++? (Granted, modules are quite complex and unlikely to be standardize=
d soon, but if they simplify this case, that's just one more reason to push=
 for modules.)<br><br>- Jim<br><br>On Saturday, June 14, 2014 2:03:03 PM UT=
C-5, Philipp Stephani wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">To=
 give an example why named arguments are more than syntactic sugar in C++:<=
br><br>// Translation unit A<div>void f(int a, int b) {</div><div>&nbsp; //=
 code</div><div>}</div><div><br></div><div>// Translation unit B</div><div>
void f(int a, int b);</div><div>int main() {</div><div>&nbsp; f(a: 1, b: 2)=
;</div><div>}</div><div><br></div><div>// Translation unit C</div><div>void=
 f(int b, int a);</div><div>int main() {</div><div>&nbsp; f(a: 1, b: 2);</d=
iv><div>
}</div><div><br></div><div>// Translation unit D</div><div>void f(int, int)=
;</div><div>int main() {</div><div>&nbsp; f(a: 1, b: 2);</div><div>}</div><=
div><br></div><div>All four translation units can be compiled separately. T=
he object code for A can then be linked with one of B, C, D to produce an e=
xecutable. Except for the named arguments all translation units are valid C=
++. C and D represent valid cases where your proposal would fail: C would r=
esult in a confusing situation (f is called with a =3D 2 and b =3D 1, in co=
ntrast to what the named arguments say), D couldn't be made to compile beca=
use the parameter names are not available. Your proposal needs to address t=
hese cases. Addressing C is especially hard: either the outcome is confusin=
g (and more confusing cases can be thought of by adding overloads to the pr=
oblem), or the compiler somehow has to communicate the parameter and argume=
nt names to the linker, necessitating profound changes in all toolchains.</=
div>
<div>Designated initializers, by contrast, suffer from none of these proble=
ms, because ODR already ensures that all involved compilation units see the=
 same member names.</div><br><div>On Sat Jun 14 2014 at 20:43:47, Philipp M=
aximilian Stephani &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"ObuUZi2UPfQJ" onmousedown=3D"this.href=3D'javascript:';retur=
n true;" onclick=3D"this.href=3D'javascript:';return true;">p.ste...@gmail.=
com</a>&gt; wrote:</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">It is not possible to introduce named argume=
nts in C++ without changing declarations because parameter names are not pa=
rt of a function's signature. In declarations they can be left out entirely=
 or given arbitrary names; for example most standard library implementation=
s use reserved names (starting with a double underscore) to avoid interfere=
nce with macros.<br>
<div>Proposals for names arguments either have to amend the type system acc=
ordingly to allow for parameters whose names are part of the function's typ=
e (requires ABI changes, no benefit for existing functions), or have to res=
ort to other means. I think the most fruitful approach so far consists in e=
nabling designated initializers for aggregate classes; this exploits the fa=
ct that member names are part of a class type.</div>
<br><div>On Sat Jun 14 2014 at 20:21:38, &lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"ObuUZi2UPfQJ" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;">botond...@gmail.com</a>&gt; wrote:</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">
<div dir=3D"ltr">A colleague and I have been working on a proposal to add n=
amed arguments to C++.<br><br>The proposal draft can be found here: <a href=
=3D"http://ehsan.github.io/namedargs/namedargs.html" target=3D"_blank" onmo=
usedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fehsan.gi=
thub.io%2Fnamedargs%2Fnamedargs.html\46sa\75D\46sntz\0751\46usg\75AFQjCNFl7=
9uriDHY6hDhx4akmXCF4lTgcw';return true;" onclick=3D"this.href=3D'http://www=
..google.com/url?q\75http%3A%2F%2Fehsan.github.io%2Fnamedargs%2Fnamedargs.ht=
ml\46sa\75D\46sntz\0751\46usg\75AFQjCNFl79uriDHY6hDhx4akmXCF4lTgcw';return =
true;">http://ehsan.github.io/<u></u>namedar<wbr>gs/namedargs.html</a><br>
<br>Any feedback on it is appreciated!<br><br>Thanks,<br>Botond<br></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
ObuUZi2UPfQJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">std-proposal...@<u></u>isoc<wb=
r>pp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"ObuUZi2UPfQJ" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">s=
td-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/<u></u>iso<wbr>cpp.org/group/std-<u></u=
>proposals/</a>.<br>
</blockquote></blockquote>
</blockquote></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_109_4161510.1402776257187--

.

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

I think other languages should be observed closely, in particular C99=20
before making a decision. I do think this is a very valuable feature though=
..

To me it would be ok to require that all non-positional=20
parameters/arguments be the first ones in both declaration and call. I=20
don't think writing positional arguments after named ones will happen much=
=20
anyway, so if it makes something easier...

I would throw in a suggestion that if a named parameter has a default value=
=20
you only need to write the name in the call site to get the default value.=
=20
and otherwise a value-constructed object (typically 0). This allows for "by=
=20
mention" flags which are often very convenient. not least in UI libraries=
=20
where long parameter lists are prevalent:

new EntryWidget(my_value, Left, Top, Expand, Password);

I would prefer to not have to put a colon after each property above. On the=
=20
other hand a trailing colon would be a way to tell the compiler to only=20
look for the name among the named parameters of constructors of EntryWidget=
=20
and not in the scope around the new!

My example hints at one possible problem: How does this play with=20
overloads? What if EntryWidget has multiple constructors? I guess that one=
=20
approach would be to exclude all those not having all the names mentioned=
=20
in the argument list from the overload set, but is this rule enough?

For constructors in particular the new delegating constructors may also be=
=20
something to mull over. These were introduced to reduce the long lists of=
=20
member initializations but now we risk ending up with long lists of named=
=20
parameters in multiple function declarations (particularly for=20
constructors, I suspect). Can the interplay between
constructor delegation and named parameters be defined to reduce the risk=
=20
of such long lists somehow?

Finally, POD initializer clauses need to be considered. I don't remember if=
=20
C++11 got a name based system for such POD but in either case the syntax=20
should be at least similar as far as possible.




Den l=C3=B6rdagen den 14:e juni 2014 kl. 21:27:44 UTC+2 skrev David Krauss:
>
>
> On 2014=E2=80=9306=E2=80=9315, at 2:21 AM, botond...@gmail.com <javascrip=
t:> wrote:=20
>
> > Any feedback on it is appreciated!=20
>
> Got any love for named template 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_191_11690699.1402776414508
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think other languages should be observed closely, in par=
ticular C99 before making a decision. I do think this is a very valuable fe=
ature though.<div><br></div><div>To me it would be ok to require that all n=
on-positional parameters/arguments be the first ones in both declaration an=
d call. I don't think writing positional arguments after named ones will ha=
ppen much anyway, so if it makes something easier...</div><div><br></div><d=
iv>I would throw in a suggestion that if a named parameter has a default va=
lue you only need to write the name in the call site to get the default val=
ue. and otherwise a value-constructed object (typically 0). This allows for=
 "by mention" flags which are often very convenient. not least in UI librar=
ies where long parameter lists are prevalent:</div><div><br></div><div>new =
EntryWidget(my_value, Left, Top, Expand, Password);</div><div><br></div><di=
v>I would prefer to not have to put a colon after each property above. On t=
he other hand a trailing colon would be a way to tell the compiler to only =
look for the name among the named parameters of constructors of EntryWidget=
 and not in the scope around the new!</div><div><br></div><div>My example h=
ints at one possible problem: How does this play with overloads? What if En=
tryWidget has multiple constructors? I guess that one approach would be to =
exclude all those not having all the names mentioned in the argument list f=
rom the overload set, but is this rule enough?</div><div><br></div><div>For=
 constructors in particular the new delegating constructors may also be som=
ething to mull over. These were introduced to reduce the long lists of memb=
er initializations but now we risk ending up with long lists of named param=
eters in multiple function declarations (particularly for constructors, I s=
uspect). Can the interplay between</div><div>constructor delegation and nam=
ed parameters be defined to reduce the risk of such long lists somehow?</di=
v><div><br></div><div>Finally, POD initializer clauses need to be considere=
d. I don't remember if C++11 got a name based system for such POD but in ei=
ther case the syntax should be at least similar as far as possible.</div><d=
iv><br></div><div><br></div><div><br><br>Den l=C3=B6rdagen den 14:e juni 20=
14 kl. 21:27:44 UTC+2 skrev David Krauss:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;">
<br>On 2014=E2=80=9306=E2=80=9315, at 2:21 AM, <a href=3D"javascript:" targ=
et=3D"_blank" gdf-obfuscated-mailto=3D"xu4-67X34QAJ" onmousedown=3D"this.hr=
ef=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';retur=
n true;">botond...@gmail.com</a> wrote:
<br>
<br>&gt; Any feedback on it is appreciated!
<br>
<br>Got any love for named template arguments?
<br>
<br></blockquote></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_191_11690699.1402776414508--

.

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

On Sat, Jun 14, 2014 at 10:06 PM, Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:

> I think other languages should be observed closely, in particular C99
> before making a decision. I do think this is a very valuable feature thou=
gh.
>
> To me it would be ok to require that all non-positional
> parameters/arguments be the first ones in both declaration and call. I
> don't think writing positional arguments after named ones will happen muc=
h
> anyway, so if it makes something easier...
>
> I would throw in a suggestion that if a named parameter has a default
> value you only need to write the name in the call site to get the default
> value. and otherwise a value-constructed object (typically 0). This allow=
s
> for "by mention" flags which are often very convenient. not least in UI
> libraries where long parameter lists are prevalent:
>
> new EntryWidget(my_value, Left, Top, Expand, Password);
>

I think design scopes are getting crossed here.  I would suggest that the
solution is:

    enum WidgetSettings { Left, Right, Top, Bottom, Expand, Shrink,
PlainText, Password };
    EntryWidget(T value, some_list_type<WidgetSettings>); // decl

    new EntryWidget(my_value, {Left, Top, Expand, Password});  // call

or maybe:

    EntryWidget(T value, bool: Left, bool: Right, bool: Expand, bool:
Password); // decl

    new EntryWiget(my_value, Left: true, Right: true, Expand: true,
Password: true); // call



> I would prefer to not have to put a colon after each property above. On
> the other hand a trailing colon would be a way to tell the compiler to on=
ly
> look for the name among the named parameters of constructors of EntryWidg=
et
> and not in the scope around the new!
>
> My example hints at one possible problem: How does this play with
> overloads? What if EntryWidget has multiple constructors? I guess that on=
e
> approach would be to exclude all those not having all the names mentioned
> in the argument list from the overload set, but is this rule enough?
>

The interplay between named parameters, overload sets and overload
resolution needs to be studied carefully.  This is something that I would
expect to be best addressed by an attempted wording delta on clause 13
[over].


> For constructors in particular the new delegating constructors may also b=
e
> something to mull over. These were introduced to reduce the long lists of
> member initializations but now we risk ending up with long lists of named
> parameters in multiple function declarations (particularly for
> constructors, I suspect). Can the interplay between
> constructor delegation and named parameters be defined to reduce the risk
> of such long lists somehow?
>
> Finally, POD initializer clauses need to be considered. I don't remember
> if C++11 got a name based system for such POD but in either case the synt=
ax
> should be at least similar as far as possible.
>
>
>
>
> Den l=C3=B6rdagen den 14:e juni 2014 kl. 21:27:44 UTC+2 skrev David Kraus=
s:
>
>>
>> On 2014=E2=80=9306=E2=80=9315, at 2:21 AM, botond...@gmail.com wrote:
>>
>> > Any feedback on it is appreciated!
>>
>> Got any love for named template 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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Jun 14, 2014 at 10:06 PM, Bengt Gustafsson <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_blank">bengt.gustafss=
on@beamways.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 think other languages sho=
uld be observed closely, in particular C99 before making a decision. I do t=
hink this is a very valuable feature though.<div>
<br></div><div>To me it would be ok to require that all non-positional para=
meters/arguments be the first ones in both declaration and call. I don&#39;=
t think writing positional arguments after named ones will happen much anyw=
ay, so if it makes something easier...</div>
<div><br></div><div>I would throw in a suggestion that if a named parameter=
 has a default value you only need to write the name in the call site to ge=
t the default value. and otherwise a value-constructed object (typically 0)=
.. This allows for &quot;by mention&quot; flags which are often very conveni=
ent. not least in UI libraries where long parameter lists are prevalent:</d=
iv>
<div><br></div><div>new EntryWidget(my_value, Left, Top, Expand, Password);=
</div></div></blockquote><div><br></div><div>I think design scopes are gett=
ing crossed here. =C2=A0I would suggest that the solution is:</div><div><br=
>
</div><div>=C2=A0 =C2=A0 enum WidgetSettings { Left, Right, Top, Bottom, Ex=
pand, Shrink, PlainText, Password };</div><div>=C2=A0 =C2=A0 EntryWidget(T =
value, some_list_type&lt;WidgetSettings&gt;); // decl</div><div><br></div><=
div>=C2=A0 =C2=A0 new EntryWidget(my_value, {Left, Top, Expand, Password});=
 =C2=A0// call</div>
<div><br></div><div>or maybe:</div><div><br></div><div>=C2=A0 =C2=A0 EntryW=
idget(T value, bool: Left, bool: Right, bool: Expand, bool: Password); // d=
ecl</div><div><br></div><div>=C2=A0 =C2=A0 new EntryWiget(my_value, Left: t=
rue, Right: true, Expand: true, Password: true); // call</div>
<div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr"><div></div><div>I would prefer to not have to put a colon after each p=
roperty above. On the other hand a trailing colon would be a way to tell th=
e compiler to only look for the name among the named parameters of construc=
tors of EntryWidget and not in the scope around the new!</div>
<div><br></div><div>My example hints at one possible problem: How does this=
 play with overloads? What if EntryWidget has multiple constructors? I gues=
s that one approach would be to exclude all those not having all the names =
mentioned in the argument list from the overload set, but is this rule enou=
gh?</div>
</div></blockquote><div><br></div><div>The interplay between named paramete=
rs, overload sets and overload resolution needs to be studied carefully. =
=C2=A0This is something that I would expect to be best addressed by an atte=
mpted wording delta on clause 13 [over].</div>
<div>=C2=A0</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>For constructors in particular the new delegating constructors may al=
so be something to mull over. These were introduced to reduce the long list=
s of member initializations but now we risk ending up with long lists of na=
med parameters in multiple function declarations (particularly for construc=
tors, I suspect). Can the interplay between</div>
<div>constructor delegation and named parameters be defined to reduce the r=
isk of such long lists somehow?</div><div><br></div><div>Finally, POD initi=
alizer clauses need to be considered. I don&#39;t remember if C++11 got a n=
ame based system for such POD but in either case the syntax should be at le=
ast similar as far as possible.</div>
<div><br></div><div><br></div><div><br><br>Den l=C3=B6rdagen den 14:e juni =
2014 kl. 21:27:44 UTC+2 skrev David Krauss:<div><div class=3D"h5"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex">

<br>On 2014=E2=80=9306=E2=80=9315, at 2:21 AM, <a>botond...@gmail.com</a> w=
rote:
<br>
<br>&gt; Any feedback on it is appreciated!
<br>
<br>Got any love for named template arguments?
<br>
<br></blockquote></div></div></div></div><div class=3D"HOEnZb"><div class=
=3D"h5">

<p></p>

-- <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+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
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 />
<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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--047d7bd6be021fe25604fbd1c515--

.

C++ already has a way to give arguments names: use appropriate types. It seems to me that rather than complicating function signatures it would be better to streamline creation of types, via something like strong typedefs.

Combined with function-declaration-local types (see the current discussion on function-scoped enumerators) this would allow named arguments with no new ABI or type inference required.

Syntax would be slightly different (braces instead of a colon) but that doesn't seem too bad.

--

---
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/.

.

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

I don't get it.  A typical use case for named parameters might be something
like:

    Rect::Rect(int: top, int: bottom, int: left, int: right); // decl

    Rect rect(top: 100, bottom: 500, left: 50, right: 200); // call

How do you see strong typedefs or function-declaration-local types solving
this problem?  Where do the braces go?


On Sun, Jun 15, 2014 at 1:15 AM, Edward Catmur <ed@catmur.co.uk> wrote:

> C++ already has a way to give arguments names: use appropriate types. It
> seems to me that rather than complicating function signatures it would be
> better to streamline creation of types, via something like strong typedefs.
>
> Combined with function-declaration-local types (see the current discussion
> on function-scoped enumerators) this would allow named arguments with no
> new ABI or type inference required.
>
> Syntax would be slightly different (braces instead of a colon) but that
> doesn't seem too bad.
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr">I don&#39;t get it. =C2=A0A typical use case for named par=
ameters might be something like:<div><br></div><div>=C2=A0 =C2=A0 Rect::Rec=
t(int: top, int: bottom, int: left, int: right); // decl</div><div>=C2=A0</=
div><div>=C2=A0 =C2=A0 Rect rect(top: 100, bottom: 500, left: 50, right: 20=
0); // call</div>
<div><br></div><div>How do you see strong typedefs or function-declaration-=
local types solving this problem? =C2=A0Where do the braces go?<br><div cla=
ss=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun, Jun 15, 2014 =
at 1:15 AM, Edward Catmur <span dir=3D"ltr">&lt;<a href=3D"mailto:ed@catmur=
..co.uk" target=3D"_blank">ed@catmur.co.uk</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">C++ already has a way to give arguments name=
s: use appropriate types. It seems to me that rather than complicating func=
tion signatures it would be better to streamline creation of types, via som=
ething like strong typedefs.<br>

<br>
Combined with function-declaration-local types (see the current discussion =
on function-scoped enumerators) this would allow named arguments with no ne=
w ABI or type inference required.<br>
<br>
Syntax would be slightly different (braces instead of a colon) but that doe=
sn&#39;t seem too bad.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><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>
</div></div></blockquote></div><br></div></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--089e011604ba1f109204fbd455b8--

.

--Apple-Mail=_688E7FCA-C7B8-4299-977F-99034DA5D80C
Content-Type: text/plain; charset=ISO-8859-1


On 2014-06-15, at 3:49 AM, Andrew Tomazos <andrewtomazos@gmail.com> wrote:

> On Sat, Jun 14, 2014 at 9:24 PM, David Krauss <potswa@gmail.com> wrote:
> > The syntax to declare a named parameter could be to insert a colon before the declarator-id:
>
> The explicit keyword is available in this context too. Or, the dot would match C99 designated initializers syntax. (Well, it's a bike-shed.)
>
> I like how the colon matches between the function declaration and the function call expression:
>
>     void f(int: n); // decl
>     f(n: x); // call
>
> Dot doesn't work (as well):
>
>     void f(int. n);
>     f(n.x); // member access or named parameter?
>
> Explicit:
>
>     void f(explicit int n);
>     f(n: x);
>
> Keyword seems overkill.  Colon looks better to me.

It's a bit of a bike shed at this point, but matching the C99 designated initializer syntax would yield

f( .n = x );

Calling a constructor by list-initialization would look just like C99 aggregate initialization.

widget boo { .n = x };

This is the only opportunity for self-consistency; the declaration syntax can go in any direction.

--

---
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/.

--Apple-Mail=_688E7FCA-C7B8-4299-977F-99034DA5D80C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<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 2014&=
ndash;06&ndash;15, at 3:49 AM, Andrew Tomazos &lt;<a href=3D"mailto:andrewt=
omazos@gmail.com">andrewtomazos@gmail.com</a>&gt; wrote:</div><br class=3D"=
Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote">On Sat, Jun 14, 2014 at 9:=
24 PM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"mailto:potswa@gmail.co=
m" target=3D"_blank">potswa@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"><div class=3D"">&gt; The syntax to declare a named paramet=
er could be to insert a colon before the declarator-id:<br>
</div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border=
-left-style:solid;padding-left:1ex"><div class=3D"">
<br>
</div>The explicit keyword is available in this context too. Or, the dot wo=
uld match C99 designated initializers syntax. (Well, it's a bike-shed.)</bl=
ockquote><div><br></div><div>I like how the colon matches between the funct=
ion declaration and the function call expression:</div>
<div><br></div><div>&nbsp; &nbsp; void f(int: n); // decl</div><div>&nbsp; =
&nbsp; f(n: x); // call</div><div><br></div><div>Dot doesn't work (as well)=
:</div><div><br></div><div>&nbsp; &nbsp; void f(int. n);</div><div>&nbsp; &=
nbsp; f(n.x); // member access or named parameter?<br>
</div><div><br></div><div>Explicit:</div><div><br></div><div>&nbsp; &nbsp; =
void f(explicit int n);</div><div>&nbsp; &nbsp; f(n: x);</div><div><br></di=
v><div>Keyword seems overkill. &nbsp;Colon looks better to me.</div></div><=
/div></div></blockquote><div><br></div><div>It&rsquo;s a bit of a bike shed=
 at this point, but matching the C99 designated initializer syntax would yi=
eld</div><div><br></div><div><font face=3D"Courier">f( .n =3D x );</font></=
div><div><br></div><div>Calling a constructor by list-initialization would =
look just like C99 aggregate initialization.</div><div><br></div><div><font=
 face=3D"Courier">widget boo { .n =3D x };</font></div><div><br></div><div>=
This is the only opportunity for self-consistency; the declaration syntax c=
an go in any direction.</div></div><br></body></html>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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=_688E7FCA-C7B8-4299-977F-99034DA5D80C--

.

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

With n3515 syntax:

using top = public int;
using bottom = public int;
using left = public int;
using right = public int;
Rect::Rect(top, bottom, left, right);

Rect rect(top{100}, bottom{500}, left{50}, right{200});

Function declaration scoped types would move the typedefs into the
constructor declaration; I'm not too sure of the exact syntax there.
On 15 Jun 2014 00:41, "Andrew Tomazos" <andrewtomazos@gmail.com> wrote:

> I don't get it.  A typical use case for named parameters might be
> something like:
>
>     Rect::Rect(int: top, int: bottom, int: left, int: right); // decl
>
>     Rect rect(top: 100, bottom: 500, left: 50, right: 200); // call
>
> How do you see strong typedefs or function-declaration-local types solving
> this problem?  Where do the braces go?
>
>
> On Sun, Jun 15, 2014 at 1:15 AM, Edward Catmur <ed@catmur.co.uk> wrote:
>
>> C++ already has a way to give arguments names: use appropriate types. It
>> seems to me that rather than complicating function signatures it would be
>> better to streamline creation of types, via something like strong typedefs.
>>
>> Combined with function-declaration-local types (see the current
>> discussion on function-scoped enumerators) this would allow named arguments
>> with no new ABI or type inference required.
>>
>> Syntax would be slightly different (braces instead of a colon) but that
>> doesn't seem too bad.
>>
>> --
>>
>> ---
>> 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 a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/N-K6418wm4w/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> 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/.

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

<p dir=3D"ltr">With n3515 syntax:</p>
<p dir=3D"ltr">using top =3D public int;<br>
using bottom =3D public int;<br>
using left =3D public int;<br>
using right =3D public int;<br>
Rect::Rect(top, bottom, left, right);</p>
<p dir=3D"ltr">Rect rect(top{100}, bottom{500}, left{50}, right{200});</p>
<p dir=3D"ltr">Function declaration scoped types would move the typedefs in=
to the constructor declaration; I&#39;m not too sure of the exact syntax th=
ere. </p>
<div class=3D"gmail_quote">On 15 Jun 2014 00:41, &quot;Andrew Tomazos&quot;=
 &lt;<a href=3D"mailto:andrewtomazos@gmail.com">andrewtomazos@gmail.com</a>=
&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">I don&#39;t get it. =C2=A0A typical use case for named par=
ameters might be something like:<div><br></div><div>=C2=A0 =C2=A0 Rect::Rec=
t(int: top, int: bottom, int: left, int: right); // decl</div><div>=C2=A0</=
div><div>=C2=A0 =C2=A0 Rect rect(top: 100, bottom: 500, left: 50, right: 20=
0); // call</div>

<div><br></div><div>How do you see strong typedefs or function-declaration-=
local types solving this problem? =C2=A0Where do the braces go?<br><div cla=
ss=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun, Jun 15, 2014 =
at 1:15 AM, Edward Catmur <span dir=3D"ltr">&lt;<a href=3D"mailto:ed@catmur=
..co.uk" target=3D"_blank">ed@catmur.co.uk</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">C++ already has a way to give arguments name=
s: use appropriate types. It seems to me that rather than complicating func=
tion signatures it would be better to streamline creation of types, via som=
ething like strong typedefs.<br>


<br>
Combined with function-declaration-local types (see the current discussion =
on function-scoped enumerators) this would allow named arguments with no ne=
w ABI or type inference required.<br>
<br>
Syntax would be slightly different (braces instead of a colon) but that doe=
sn&#39;t seem too bad.<br>
<div><div><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" 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>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/N-K6418wm4w/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/N-K6418wm4w=
/unsubscribe</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@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>
</blockquote></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--001a11394fb4ea6cee04fbd474fc--

.

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

On Sun, Jun 15, 2014 at 1:48 AM, David Krauss <potswa@gmail.com> wrote:

>
> On 2014=E2=80=9306=E2=80=9315, at 3:49 AM, Andrew Tomazos <andrewtomazos@=
gmail.com> wrote:
>
> On Sat, Jun 14, 2014 at 9:24 PM, David Krauss <potswa@gmail.com> wrote:
>
>> > The syntax to declare a named parameter could be to insert a colon
>> before the declarator-id:
>>
>
>> The explicit keyword is available in this context too. Or, the dot would
>> match C99 designated initializers syntax. (Well, it's a bike-shed.)
>
>
> I like how the colon matches between the function declaration and the
> function call expression:
>
>     void f(int: n); // decl
>     f(n: x); // call
>
> Dot doesn't work (as well):
>
>     void f(int. n);
>     f(n.x); // member access or named parameter?
>
> Explicit:
>
>     void f(explicit int n);
>     f(n: x);
>
> Keyword seems overkill.  Colon looks better to me.
>
>
> It=E2=80=99s a bit of a bike shed at this point, but matching the C99 des=
ignated
> initializer syntax would yield
>
> f( .n =3D x );
>
> Calling a constructor by list-initialization would look just like C99
> aggregate initialization.
>
> widget boo { .n =3D x };
>
> This is the only opportunity for self-consistency; the declaration syntax
> can go in any direction.
>

I think the dot in that front position is referring to member access with a
silent LHS.  It's a bit of a stretch to view it as consistency to use it
for named parameters.  SmallTalk, JavaScript, JSON, Objective-C, C# and
Swift all use colons.  Ada and Perl use "=3D>", but that looks too much lik=
e
">=3D" to me.  Scala and Python use "=3D" but we can't.  I can't tell what =
Lisp
does.  Someone else can look up the named parameter implementations in
Coldfusion, Mathematica,PL/SQL, R, Visual Basic and IDL.

--=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/.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Sun, Jun 15, 2014 at 1:48 AM, David Krauss <span dir=3D"ltr">&lt=
;<a href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@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"><div style=3D"word-wrap:break-word"><br><div><div class=3D=
""><div>
On 2014=E2=80=9306=E2=80=9315, at 3:49 AM, Andrew Tomazos &lt;<a href=3D"ma=
ilto:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@gmail.com</a>=
&gt; wrote:</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote">
On Sat, Jun 14, 2014 at 9:24 PM, David Krauss <span dir=3D"ltr">&lt;<a href=
=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</sp=
an> 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"><div>&gt; The syntax to declare a named parameter could be=
 to insert a colon before the declarator-id:<br>

</div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border=
-left-style:solid;padding-left:1ex"><div>
<br>
</div>The explicit keyword is available in this context too. Or, the dot wo=
uld match C99 designated initializers syntax. (Well, it&#39;s a bike-shed.)=
</blockquote><div><br></div><div>I like how the colon matches between the f=
unction declaration and the function call expression:</div>

<div><br></div><div>=C2=A0 =C2=A0 void f(int: n); // decl</div><div>=C2=A0 =
=C2=A0 f(n: x); // call</div><div><br></div><div>Dot doesn&#39;t work (as w=
ell):</div><div><br></div><div>=C2=A0 =C2=A0 void f(int. n);</div><div>=C2=
=A0 =C2=A0 f(n.x); // member access or named parameter?<br>

</div><div><br></div><div>Explicit:</div><div><br></div><div>=C2=A0 =C2=A0 =
void f(explicit int n);</div><div>=C2=A0 =C2=A0 f(n: x);</div><div><br></di=
v><div>Keyword seems overkill. =C2=A0Colon looks better to me.</div></div><=
/div></div></blockquote>
<div><br></div></div><div>It=E2=80=99s a bit of a bike shed at this point, =
but matching the C99 designated initializer syntax would yield</div><div><b=
r></div><div><font face=3D"Courier">f( .n =3D x );</font></div><div><br></d=
iv><div>
Calling a constructor by list-initialization would look just like C99 aggre=
gate initialization.</div><div><br></div><div><font face=3D"Courier">widget=
 boo { .n =3D x };</font></div><div><br></div><div>This is the only opportu=
nity for self-consistency; the declaration syntax can go in any direction.<=
/div>
</div></div></blockquote><div><br></div><div>I think the dot in that front =
position is referring to member access with a silent LHS. =C2=A0It&#39;s a =
bit of a stretch to view it as consistency to use it for named parameters. =
=C2=A0SmallTalk, JavaScript, JSON, Objective-C, C# and Swift all use colons=
.. =C2=A0Ada and Perl use &quot;=3D&gt;&quot;, but that looks too much like =
&quot;&gt;=3D&quot; to me. =C2=A0Scala and Python use &quot;=3D&quot; but w=
e can&#39;t. =C2=A0I can&#39;t tell what Lisp does. =C2=A0Someone else can =
look up the named parameter implementations in Coldfusion, Mathematica,PL/S=
QL, R, Visual Basic and IDL.</div>
<div><br></div><div><br></div></div></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--089e011609f4ef484404fbd541d3--

.

------=_Part_1178_21798319.1402803308487
Content-Type: text/plain; charset=UTF-8

On Saturday, June 14, 2014 12:03:03 PM UTC-7, Philipp Stephani wrote:
>
> To give an example why named arguments are more than syntactic sugar in
> C++:
>
> // Translation unit A
> void f(int a, int b) {
>   // code
> }
>
> // Translation unit B
> void f(int a, int b);
> int main() {
>   f(a: 1, b: 2);
> }
>
> // Translation unit C
> void f(int b, int a);
> int main() {
>   f(a: 1, b: 2);
> }
>
> // Translation unit D
> void f(int, int);
> int main() {
>   f(a: 1, b: 2);
> }
>
> All four translation units can be compiled separately. The object code for
> A can then be linked with one of B, C, D to produce an executable. Except
> for the named arguments all translation units are valid C++. C and D
> represent valid cases where your proposal would fail: C would result in a
> confusing situation (f is called with a = 2 and b = 1, in contrast to what
> the named arguments say), D couldn't be made to compile because the
> parameter names are not available. Your proposal needs to address these
> cases. Addressing C is especially hard: either the outcome is confusing
> (and more confusing cases can be thought of by adding overloads to the
> problem), or the compiler somehow has to communicate the parameter and
> argument names to the linker, necessitating profound changes in all
> toolchains.
> Designated initializers, by contrast, suffer from none of these problems,
> because ODR already ensures that all involved compilation units see the
> same member names.
>

These aren't necessarily problems that the proposal needs to address.  The
proposal does describe the behavior for each of these cases and arguably
that behavior is reasonable.  It seems you just don't like the fact that C
uses different names and doesn't produce a diagnostic.  That is certainly a
downside to the proposal, but not necessarily a fatal flaw.  Consider that
the problem already exists in some sense, independent of named parameters:

// Translation Unit A:
void draw_rect(int top, int left, int width, int height) { }

// Translation Unit B:
void draw_rect(int top, int left, int width, int height);
int main() { draw_rect(10, 10, 50, 50); }

// Translation Unit C:
void draw_rect(int top, int left, int right, int bottom);
int main() { draw_rect(10, 10, 60, 60); } // wrong code because the names
were wrong

// Translation Unit D:
void draw_rect(int, int, int, int);
int main() { draw_rect(/* how do I know what to put here */); }


--

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

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

<div dir=3D"ltr">On Saturday, June 14, 2014 12:03:03 PM UTC-7, Philipp Step=
hani wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">To give an example =
why named arguments are more than syntactic sugar in C++:<br><br>// Transla=
tion unit A<div>void f(int a, int b) {</div><div>&nbsp; // code</div><div>}=
</div><div><br></div><div>// Translation unit B</div><div>
void f(int a, int b);</div><div>int main() {</div><div>&nbsp; f(a: 1, b: 2)=
;</div><div>}</div><div><br></div><div>// Translation unit C</div><div>void=
 f(int b, int a);</div><div>int main() {</div><div>&nbsp; f(a: 1, b: 2);</d=
iv><div>
}</div><div><br></div><div>// Translation unit D</div><div>void f(int, int)=
;</div><div>int main() {</div><div>&nbsp; f(a: 1, b: 2);</div><div>}</div><=
div><br></div><div>All four translation units can be compiled separately. T=
he object code for A can then be linked with one of B, C, D to produce an e=
xecutable. Except for the named arguments all translation units are valid C=
++. C and D represent valid cases where your proposal would fail: C would r=
esult in a confusing situation (f is called with a =3D 2 and b =3D 1, in co=
ntrast to what the named arguments say), D couldn't be made to compile beca=
use the parameter names are not available. Your proposal needs to address t=
hese cases. Addressing C is especially hard: either the outcome is confusin=
g (and more confusing cases can be thought of by adding overloads to the pr=
oblem), or the compiler somehow has to communicate the parameter and argume=
nt names to the linker, necessitating profound changes in all toolchains.</=
div>
<div>Designated initializers, by contrast, suffer from none of these proble=
ms, because ODR already ensures that all involved compilation units see the=
 same member names.</div></blockquote><div><br>These aren't necessarily pro=
blems that the proposal needs to address.&nbsp; The proposal does describe =
the behavior for each of these cases and arguably that behavior is reasonab=
le.&nbsp; It seems you just don't like the fact that C uses different names=
 and doesn't produce a diagnostic.&nbsp; That is certainly a downside to th=
e proposal, but not necessarily a fatal flaw.&nbsp; Consider that the probl=
em already exists in some sense, independent of named parameters:<br><br>//=
 Translation Unit A:<br>void draw_rect(int top, int left, int width, int he=
ight) { }<br><br>// Translation Unit B:<br>void draw_rect(int top, int left=
, int width, int height);<br>int main() { draw_rect(10, 10, 50, 50); }<br><=
br>// Translation Unit C:<br>void draw_rect(int top, int left, int right, i=
nt bottom);<br>int main() { draw_rect(10, 10, 60, 60); } // wrong code beca=
use the names were wrong<br><br>// Translation Unit D:<br>void draw_rect(in=
t, int, int, int);<br>int main() { draw_rect(/* how do I know what to put h=
ere */); }<br><br><br></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_1178_21798319.1402803308487--

.

------=_Part_1122_687560.1402804286929
Content-Type: text/plain; charset=UTF-8

On Saturday, June 14, 2014 11:56:51 AM UTC-7, Andrew Tomazos wrote:
>
>
> I think the better approach would be to nominate as part of a function
> declaration which arguments are positional and which are named.  This
> characteristic of a function parameter, that is, whether it is named or
> positional, then becomes part of the function type.  The names of named
> parameters also become part of the function type.  Declaration matching
> between function declarations/definitions then proceeds as normal by
> matching the function type.
>
> The syntax to declare a named parameter could be to insert a colon before
> the declarator-id:
>
>     void f(int positional, int: named);     // 1
>     void f(int*: foo, char(*: bar)(double)); // 2
>
> The calls are then as you suggest:
>
>     f(x, named: y); // ok calls 1
>     f(named: y, x); // ok calls 1
>     f(foo: x, bar: y); // ok calls 2
>     f(bar: y, foo: x); // ok calls 2
>
> Basically named parameters are unordered and do not take up a position
> that influences positional parameters.  Positional and named parameters
> form two separate sets of parameters, and named arguments do not have a
> position (they have names).  Therefore:
>
>    void f(int: named, int othername); // redeclare 1, declaration matches
>    void f(char(*:bar)(double), int*: foo); // redeclare 2, declaration
> matches
>


Okay, seems pretty reasonable.  Positional parameters have to be specified
by position, and named parameters have to be specified by name.

Do we allow overloading based only on named parameter names, e.g.:

void f(int: a); // 1
void f(int: b); // 2

f(a = 10); // calls 1
f(b = 10); // calls 2

It seems this could be useful and is a natural consequence of making the
parameter names part of the type.

What about function pointers?  Can a pointer to a function with named
parameters be converted to a pointer to a function with only positional
parameters? (I would say the answer should be yes.)

The big issue that hasn't been addressed is how this will interact with
template metaprogramming/perfect forwarding/variadic arguments.  From my
perspective, introducing named parameters without a way to handle them
generically and forward them would be an uncceptable step backward.

Any ideas how this can be supported?

We would similarly need this for named template 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_1122_687560.1402804286929
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, June 14, 2014 11:56:51 AM UTC-7, Andrew Tomaz=
os 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>I think the better approach would be to nominate as part of a function=
 declaration which arguments are positional and which are named. &nbsp;This=
 characteristic of a function parameter, that is, whether it is named or po=
sitional, then becomes part of the function type. &nbsp;The names of named =
parameters also become part of the function type. &nbsp;Declaration matchin=
g between function declarations/definitions then proceeds as normal by matc=
hing the function type.</div>
<div><br></div><div>The syntax to declare a named parameter could be to ins=
ert a colon before the declarator-id:</div><div><br></div><div>&nbsp; &nbsp=
; void f(int positional, int: named); &nbsp; &nbsp; // 1</div><div>&nbsp; &=
nbsp; void f(int*: foo, char(*: bar)(double)); // 2</div>
<div><br></div><div>The calls are then as you suggest:</div><div><br></div>=
<div>&nbsp; &nbsp; f(x, named: y); // ok calls 1</div><div>&nbsp; &nbsp; f(=
named: y, x); // ok calls 1</div><div><div>&nbsp; &nbsp; f(foo: x, bar: y);=
 // ok calls 2</div></div>
<div><div>&nbsp; &nbsp; f(bar: y, foo: x); // ok calls 2</div></div><div><b=
r></div><div>Basically named parameters are unordered and do not take up a =
position that influences positional parameters. &nbsp;Positional and named =
parameters form two separate sets of parameters, and named arguments do not=
 have a position (they have names). &nbsp;Therefore:</div>
<div><br></div><div>&nbsp; &nbsp;void f(int: named, int othername); // rede=
clare 1, declaration matches</div><div><div>&nbsp; &nbsp;void f(char(*:bar)=
(double),&nbsp;int*: foo); // redeclare 2, declaration matches<br></div></d=
iv></div></blockquote><div><br><br>Okay, seems pretty reasonable.&nbsp; Pos=
itional parameters have to be specified by position, and named parameters h=
ave to be specified by name.<br><br>Do we allow overloading based only on n=
amed parameter names, e.g.:<br><br>void f(int: a); // 1<br>void f(int: b); =
// 2<br><br>f(a =3D 10); // calls 1<br>f(b =3D 10); // calls 2<br><br>It se=
ems this could be useful and is a natural consequence of making the paramet=
er names part of the type.<br><br>What about function pointers?&nbsp; Can a=
 pointer to a function with named parameters be converted to a pointer to a=
 function with only positional parameters? (I would say the answer should b=
e yes.)<br><br>The big issue that hasn't been addressed is how this will in=
teract with template metaprogramming/perfect forwarding/variadic arguments.=
&nbsp; From my perspective, introducing named parameters without a way to h=
andle them generically and forward them would be an uncceptable step backwa=
rd.<br><br>Any ideas how this can be supported?<br><br>We would similarly n=
eed this for named template arguments.<br><br></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_1122_687560.1402804286929--

.

--Apple-Mail=_BD4C52EA-3933-4CD7-A65A-E9C8D3DDC87D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-06-15, at 8:47 AM, Andrew Tomazos <andrewtomazos@gmail.com> wrote:

> I think the dot in that front position is referring to member access with=
 a silent LHS. =20

It's reminiscent, yes.

> It's a bit of a stretch to view it as consistency to use it for named par=
ameters.  SmallTalk, JavaScript, JSON, Objective-C, C# and Swift all use co=
lons. =20

JSON isn't a programming language ;) and such usage in JavaScript involves =
packaging the argument list in a POD-like aggregate container object. The m=
ost immediate parallel would be to define an aggregate class to serve as th=
e parameter type, and to pass a braced-init-list using C99 designated initi=
alizers. (It may be entirely possible in C, if "casting" a braced list prod=
uces a temporary, but I can't recall whether that's standardized or a GCC e=
xtension.)

In this light, I think JavaScript could count as a point for either side.

C# uses ":" for parameters and "=3D" for initializing class attributes (agg=
regate members). One of the first Google hits returned from searching "c# n=
amed parameter," and the first StackOverflow hint, involves confusion about=
 this distinction. Even given named parameters, some interfaces still choos=
e to pass aggregate structures instead.

Objective-C borrowed its syntax very incongruously from SmallTalk. Swift ca=
rried the Objective-C influence into more C-like syntax, but it's a bit new=
 to be much of a precedent.

> Ada and Perl use "=3D>", but that looks too much like ">=3D" to me.  Scal=
a and Python use "=3D" but we can't. =20

We can use "=3D" by treating parameter lists analogously to initializer lis=
ts with designated initializers. After all, an initializer in a constructor=
 call is a parameter list.

Never adopting C99 designated initializers and/or not allowing that aggrega=
te initialization syntax a migration path to constructors would be a big op=
portunity lost.

Ada and Perl are, IMHO, ugly.

> I can't tell what Lisp does. =20

According to some quick reading, CLOS uses strong typing and named aggregat=
e initializers using colon. I'd be surprised if many flavors of LISP added =
named parameters in addition to objects, because the prevailing philosophy =
is to minimize redundancy. Anyway, few programmers are coming from that env=
ironment, and those who do, can probably stand some different punctuation.

> Someone else can look up the named parameter implementations in Coldfusio=
n, Mathematica,PL/SQL, R, Visual Basic and IDL.

In the end, self-consistency is more important than coinciding with other l=
anguages. If the precedents show anything, it's that named parameter syntax=
 should serve double duty for named aggregate initializers. And, C99 seems =
to have a perfectly serviceable system for that.

--=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=_BD4C52EA-3933-4CD7-A65A-E9C8D3DDC87D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<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 2014&=
ndash;06&ndash;15, at 8:47 AM, Andrew Tomazos &lt;<a href=3D"mailto:andrewt=
omazos@gmail.com">andrewtomazos@gmail.com</a>&gt; wrote:</div><br class=3D"=
Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">I thi=
nk the dot in that front position is referring to member access with a sile=
nt LHS. &nbsp;</div></blockquote><div><br></div><div>It&rsquo;s reminiscent=
, yes.</div><br><blockquote type=3D"cite"><div dir=3D"ltr">It's a bit of a =
stretch to view it as consistency to use it for named parameters. &nbsp;Sma=
llTalk, JavaScript, JSON, Objective-C, C# and Swift all use colons. &nbsp;<=
/div></blockquote><div><br></div><div>JSON isn&rsquo;t a programming langua=
ge ;) and such usage in JavaScript involves packaging the argument list in =
a POD-like aggregate container object. The most immediate parallel would be=
 to define an aggregate class to serve as the parameter type, and to pass a=
 braced-init-list using C99 designated initializers. (It may be entirely po=
ssible in C, if &ldquo;casting&rdquo; a braced list produces a temporary, b=
ut I can&rsquo;t recall whether that&rsquo;s standardized or a GCC extensio=
n.)</div><div><br></div><div>In this light, I think JavaScript could count =
as a point for either side.</div><div><br></div><div>C# uses &ldquo;:&rdquo=
; for parameters and &ldquo;=3D&rdquo; for initializing class attributes (a=
ggregate members). One of the first Google hits returned from searching &ld=
quo;c# named parameter,&rdquo; and the first StackOverflow hint, involves&n=
bsp;<a href=3D"http://stackoverflow.com/a/12056727/153285">confusion</a>&nb=
sp;about this distinction. Even given named parameters, some interfaces sti=
ll choose to pass aggregate structures instead.</div><div><br></div><div>Ob=
jective-C borrowed its syntax very incongruously from SmallTalk. Swift carr=
ied the Objective-C influence into more C-like syntax, but it&rsquo;s a bit=
 new to be much of a precedent.</div><div><br></div><blockquote type=3D"cit=
e"><div dir=3D"ltr">Ada and Perl use "=3D&gt;", but that looks too much lik=
e "&gt;=3D" to me. &nbsp;Scala and Python use "=3D" but we can't. &nbsp;</d=
iv></blockquote><div><br></div><div>We can use &ldquo;=3D" by treating para=
meter lists analogously to initializer lists with designated initializers. =
After all, an initializer in a constructor call is a parameter list.</div><=
div><br></div><div>Never adopting C99 designated initializers and/or not al=
lowing that aggregate initialization syntax a migration path to constructor=
s would be a big opportunity lost.</div><div><br></div><div>Ada and Perl ar=
e, IMHO, ugly.</div><br><blockquote type=3D"cite"><div dir=3D"ltr">I can't =
tell what Lisp does. &nbsp;</div></blockquote><div><br></div><div>According=
 to some quick reading, CLOS uses strong typing and named aggregate initial=
izers using colon. I&rsquo;d be surprised if many flavors of LISP added nam=
ed parameters in addition to objects, because the prevailing philosophy is =
to minimize redundancy. Anyway, few programmers are coming from that enviro=
nment, and those who do, can probably stand some different punctuation.</di=
v><br><blockquote type=3D"cite"><div dir=3D"ltr">Someone else can look up t=
he named parameter implementations in Coldfusion, Mathematica,PL/SQL, R, Vi=
sual Basic and IDL.<br></div></blockquote><br></div><div>In the end, self-c=
onsistency is more important than coinciding with other languages. If the p=
recedents show anything, it&rsquo;s that named parameter syntax should serv=
e double duty for named aggregate initializers. And, C99 seems to have a pe=
rfectly serviceable system for that.</div><br></body></html>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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=_BD4C52EA-3933-4CD7-A65A-E9C8D3DDC87D--

.

------=_Part_429_7799755.1402810213442
Content-Type: text/plain; charset=UTF-8

I don't think we need ABI changes or name mangling to be involved. The name
matching could be done inline at compile time, via the declaration in the
header file. This means multiple declarations with different names would be
a sort of odr violation. A compiler could flag an error whenever it sees
multiple declarations of the same function visible with different names.
Names could be absent in the definition (for unused arguments), in which
case the unnamed arguments assume the names from the declaration. As an
extension, additional implementation specific bits could be added to object
files to also check the name matching at link time with a linker plugin.

The default values of parameters belong coupled with the function and
should not leak outside of it where they become bugs if the interface
changes.
Function parameters can be optional, this can be common idiom for
constructors. The ways to implement this now involve default arguments and
overloading.  Default arguments have the deficiency that they must be in
order. So if you want to default a middle argument, you have to either copy
the default value from the header to the call site (a sin), or have the
interface provide the defaults some other way such as const/constexpr
constants or static methods. assign in the callee code (a sin, as now we
either leaked the default or have to expose it somehow using constants or
const static methods.), or write an overload which is a lot of boilerplate
and oportunity for bugs (by forgetting to assign all of the data members
correctly for all of the copy paste variants). The overload approach is
inelegant at best, it also doesn't work if multiple arguments have the same
type.

This feature can also make some code much more readable. If at the callsite
you see the names of the parameters being initialized for a function call,
and those parameters are named well, it already tells you a lot immediately
about what the function does before even needing to look it up formally.

If named default arguments can be implemented entirely within the compile
phase and not touch the ABI, I think it could be a huge win.

Another option is separating positional and named arguments as some have
mentioned. We could again do the magic inline in the header, or use the ABI
by creating an anonymous struct with the named arguments and types. Then
the struct initialization syntax can be reused at the call site as well.


On Saturday, June 14, 2014 3:05:38 PM UTC-4, Philipp Stephani wrote:
>
> One problem with this approach is that it requires ABI changes. Currently
> name mangling removes parameter names because they are not part of a
> function's signature. This approach requires that toolchains add support
> for mangling parameter names. It also means that no existing function can
> benefit from named arguments.
>
> On Sat Jun 14 2014 at 20:56:51, Andrew Tomazos <andrew...@gmail.com
> <javascript:>> wrote:
>
>> Hi Botond,
>>
>> This is interesting and something I was thinking about just the other day
>> while looking at Objective-C and Swift.
>>
>> I think the better approach would be to nominate as part of a function
>> declaration which arguments are positional and which are named.  This
>> characteristic of a function parameter, that is, whether it is named or
>> positional, then becomes part of the function type.  The names of named
>> parameters also become part of the function type.  Declaration matching
>> between function declarations/definitions then proceeds as normal by
>> matching the function type.
>>
>> The syntax to declare a named parameter could be to insert a colon before
>> the declarator-id:
>>
>>     void f(int positional, int: named);     // 1
>>     void f(int*: foo, char(*: bar)(double)); // 2
>>
>> The calls are then as you suggest:
>>
>>     f(x, named: y); // ok calls 1
>>     f(named: y, x); // ok calls 1
>>     f(foo: x, bar: y); // ok calls 2
>>     f(bar: y, foo: x); // ok calls 2
>>
>> Basically named parameters are unordered and do not take up a position
>> that influences positional parameters.  Positional and named parameters
>> form two separate sets of parameters, and named arguments do not have a
>> position (they have names).  Therefore:
>>
>>    void f(int: named, int othername); // redeclare 1, declaration matches
>>    void f(char(*:bar)(double), int*: foo); // redeclare 2, declaration
>> matches
>>
>> Enjoy,
>> Andrew.
>>
>>
>>
>>
>>
>> On Sat, Jun 14, 2014 at 8:21 PM, <botond...@gmail.com <javascript:>>
>> wrote:
>>
>>> A colleague and I have been working on a proposal to add named arguments
>>> to C++.
>>>
>>> The proposal draft can be found here:
>>> http://ehsan.github.io/namedargs/namedargs.html
>>>
>>> Any feedback on it is appreciated!
>>>
>>> Thanks,
>>> Botond
>>>
>>> --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposal...@isocpp.org <javascript:>.
>>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> 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/.

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

<div dir=3D"ltr">I don't think we need ABI changes or name mangling to be i=
nvolved. The name matching could be done inline at compile time, via the de=
claration in the header file. This means multiple declarations with differe=
nt names would be a sort of odr violation. A compiler could flag an error w=
henever it sees multiple declarations of the same function visible with dif=
ferent names. Names could be absent in the definition (for unused arguments=
), in which case the unnamed arguments assume the names from the declaratio=
n. As an extension, additional implementation specific bits could be added =
to object files to also check the name matching at link time with a linker =
plugin.<div><br></div><div>The default values of parameters belong coupled =
with the function and should not leak outside of it where they become bugs =
if the interface changes.</div><div>Function parameters can be optional, th=
is can be common idiom for constructors. The ways to implement this now inv=
olve default arguments and overloading. &nbsp;Default arguments have the de=
ficiency that they must be in order. So if you want to default a middle arg=
ument, you have to either copy the default value from the header to the cal=
l site (a sin), or have the interface provide the defaults some other way s=
uch as const/constexpr constants or static methods. assign in the callee co=
de (a sin, as now we either leaked the default or have to expose it somehow=
 using constants or const static methods.), or write an overload which is a=
 lot of boilerplate and oportunity for bugs (by forgetting to assign all of=
 the data members correctly for all of the copy paste variants). The overlo=
ad approach is inelegant at best, it also doesn't work if multiple argument=
s have the same type.</div><div><br></div><div>This feature can also make s=
ome code much more readable. If at the callsite you see the names of the pa=
rameters being initialized for a function call, and those parameters are na=
med well, it already tells you a lot immediately about what the function do=
es before even needing to look it up formally.</div><div><br></div><div>If =
named default arguments can be implemented entirely within the compile phas=
e and not touch the ABI, I think it could be a huge win.</div><div><br></di=
v><div>Another option is separating positional and named arguments as some =
have mentioned. We could again do the magic inline in the header, or use th=
e ABI by creating an anonymous struct with the named arguments and types. T=
hen the struct initialization syntax can be reused at the call site as well=
..</div><div><br></div><div><br>On Saturday, June 14, 2014 3:05:38 PM UTC-4,=
 Philipp Stephani wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">One pr=
oblem with this approach is that it requires ABI changes. Currently name ma=
ngling removes parameter names because they are not part of a function's si=
gnature. This approach requires that toolchains add support for mangling pa=
rameter names. It also means that no existing function can benefit from nam=
ed arguments.<br>
<br><div>On Sat Jun 14 2014 at 20:56:51, Andrew Tomazos &lt;<a href=3D"java=
script:" target=3D"_blank" gdf-obfuscated-mailto=3D"mMZr4z2vkicJ" onmousedo=
wn=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javas=
cript:';return true;">andrew...@gmail.com</a>&gt; wrote:</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">
<div dir=3D"ltr">Hi Botond,<div><br></div><div>This is interesting and some=
thing I was thinking about just the other day while looking at Objective-C =
and Swift.</div><div><br></div><div>I think the better approach would be to=
 nominate as part of a function declaration which arguments are positional =
and which are named. &nbsp;This characteristic of a function parameter, tha=
t is, whether it is named or positional, then becomes part of the function =
type. &nbsp;The names of named parameters also become part of the function =
type. &nbsp;Declaration matching between function declarations/definitions =
then proceeds as normal by matching the function type.</div>

<div><br></div><div>The syntax to declare a named parameter could be to ins=
ert a colon before the declarator-id:</div><div><br></div><div>&nbsp; &nbsp=
; void f(int positional, int: named); &nbsp; &nbsp; // 1</div><div>&nbsp; &=
nbsp; void f(int*: foo, char(*: bar)(double)); // 2</div>

<div><br></div><div>The calls are then as you suggest:</div><div><br></div>=
<div>&nbsp; &nbsp; f(x, named: y); // ok calls 1</div><div>&nbsp; &nbsp; f(=
named: y, x); // ok calls 1</div><div><div>&nbsp; &nbsp; f(foo: x, bar: y);=
 // ok calls 2</div></div>

<div><div>&nbsp; &nbsp; f(bar: y, foo: x); // ok calls 2</div></div><div><b=
r></div><div>Basically named parameters are unordered and do not take up a =
position that influences positional parameters. &nbsp;Positional and named =
parameters form two separate sets of parameters, and named arguments do not=
 have a position (they have names). &nbsp;Therefore:</div>

<div><br></div><div>&nbsp; &nbsp;void f(int: named, int othername); // rede=
clare 1, declaration matches</div><div><div>&nbsp; &nbsp;void f(char(*:bar)=
(double),&nbsp;int*: foo); // redeclare 2, declaration matches</div></div><=
div><br></div><div>Enjoy,</div>

<div>Andrew.</div><div><br></div><div><br></div><div>&nbsp;</div></div><div=
><br><br><div class=3D"gmail_quote">On Sat, Jun 14, 2014 at 8:21 PM,  <span=
 dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"mMZr4z2vkicJ" onmousedown=3D"this.href=3D'javascript:';return true=
;" onclick=3D"this.href=3D'javascript:';return true;">botond...@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">A colleague and I have been=
 working on a proposal to add named arguments to C++.<br><br>The proposal d=
raft can be found here: <a href=3D"http://ehsan.github.io/namedargs/namedar=
gs.html" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.co=
m/url?q\75http%3A%2F%2Fehsan.github.io%2Fnamedargs%2Fnamedargs.html\46sa\75=
D\46sntz\0751\46usg\75AFQjCNFl79uriDHY6hDhx4akmXCF4lTgcw';return true;" onc=
lick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fehsan.githu=
b.io%2Fnamedargs%2Fnamedargs.html\46sa\75D\46sntz\0751\46usg\75AFQjCNFl79ur=
iDHY6hDhx4akmXCF4lTgcw';return true;">http://ehsan.github.io/<wbr>namedargs=
/namedargs.html</a><br>

<br>Any feedback on it is appreciated!<br><br>Thanks,<br>Botond<span><font =
color=3D"#888888"><br></font></span></div><span><font color=3D"#888888">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
mMZr4z2vkicJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">std-proposal...@<wbr>isocpp.or=
g</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"mMZr4z2vkicJ" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">s=
td-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
mMZr4z2vkicJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">std-proposal...@<wbr>isocpp.or=
g</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"mMZr4z2vkicJ" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">s=
td-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</blockquote>
</blockquote></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_429_7799755.1402810213442--

.

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

On Sun, Jun 15, 2014 at 5:51 AM, Jeremy Maitin-Shepard <jeremy@jeremyms.com=
>
wrote:

> On Saturday, June 14, 2014 11:56:51 AM UTC-7, Andrew Tomazos wrote:
>>
>>
>> I think the better approach would be to nominate as part of a function
>> declaration which arguments are positional and which are named.  This
>> characteristic of a function parameter, that is, whether it is named or
>> positional, then becomes part of the function type.  The names of named
>> parameters also become part of the function type.  Declaration matching
>> between function declarations/definitions then proceeds as normal by
>> matching the function type.
>>
>> The syntax to declare a named parameter could be to insert a colon befor=
e
>> the declarator-id:
>>
>>     void f(int positional, int: named);     // 1
>>     void f(int*: foo, char(*: bar)(double)); // 2
>>
>> The calls are then as you suggest:
>>
>>     f(x, named: y); // ok calls 1
>>     f(named: y, x); // ok calls 1
>>     f(foo: x, bar: y); // ok calls 2
>>     f(bar: y, foo: x); // ok calls 2
>>
>> Basically named parameters are unordered and do not take up a position
>> that influences positional parameters.  Positional and named parameters
>> form two separate sets of parameters, and named arguments do not have a
>> position (they have names).  Therefore:
>>
>>    void f(int: named, int othername); // redeclare 1, declaration matche=
s
>>    void f(char(*:bar)(double), int*: foo); // redeclare 2, declaration
>> matches
>>
>
>
> Okay, seems pretty reasonable.  Positional parameters have to be specifie=
d
> by position, and named parameters have to be specified by name.
>
> Do we allow overloading based only on named parameter names, e.g.:
>
> void f(int: a); // 1
> void f(int: b); // 2
>
> f(a =3D 10); // calls 1
> f(b =3D 10); // calls 2
>
> It seems this could be useful and is a natural consequence of making the
> parameter names part of the type.
>

Yes, that is correct.  The two declarations do not match, so declare two
different functions.


> What about function pointers?  Can a pointer to a function with named
> parameters be converted to a pointer to a function with only positional
> parameters? (I would say the answer should be yes.)
>

Under the current spec the behavior would be:

int main()
{
    extern void f(int);
    auto p =3D &f;
    void (*q)(double) =3D p; // error: invalid conversion from =E2=80=98voi=
d
(*)(int)=E2=80=99 to =E2=80=98void (*)(double)=E2=80=99
    void (*r)(int: x) =3D p; // error: invalid conversion from =E2=80=98voi=
d
(*)(int)=E2=80=99 to =E2=80=98void (*)(int: x)=E2=80=99

    extern void g(int: x);
    auto s =3D &g;
    void (*t)(int: y) =3D s; // error: invalid conversion from =E2=80=98voi=
d (*)(int:
x)=E2=80=99 to =E2=80=98void (*)(int: y)=E2=80=99
}

I don't see a compelling reason to provide conversions, anymore so than for
example int(*)[1] should be convertible to struct { int x; }*, or struct {
int x; }* should be convertible to struct { int y; }*.

The big issue that hasn't been addressed is how this will interact with
> template metaprogramming/perfect forwarding/variadic arguments.  From my
> perspective, introducing named parameters without a way to handle them
> generically and forward them would be an uncceptable step backward.
>
> Any ideas how this can be supported?
>

I don't follow.  You can use them in function templates:

    template<class T>
    void f(T: x);

    f(x: 42); // ok calls f<int>
    f(x: 2.0); // ok calls f<double>

You can forward a named parameter:

    template<class T>
    void f(T&& x) { g(std::forward<T>(x)); }

Variadic arguments remain positional-only:

    template<class... T>
    void f(T... x); // ok

    template<class... T>
    void f(T... :x); // error

Unless you had something else in mind?


> We would similarly need this for named template arguments.
>

I think it can be done in the same way as shown previously.

--=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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Jun 15, 2014 at 5:51 AM, Jeremy Maitin-Shepard <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:jeremy@jeremyms.com" target=3D"_blank">jeremy@jeremyms.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"><div dir=3D"ltr"><div class=3D"">On Saturday, June 14, 201=
4 11:56:51 AM UTC-7, Andrew Tomazos wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:=
rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir=3D"ltr"><br><div>I think the better approach would be to nominate =
as part of a function declaration which arguments are positional and which =
are named. =C2=A0This characteristic of a function parameter, that is, whet=
her it is named or positional, then becomes part of the function type. =C2=
=A0The names of named parameters also become part of the function type. =C2=
=A0Declaration matching between function declarations/definitions then proc=
eeds as normal by matching the function type.</div>

<div><br></div><div>The syntax to declare a named parameter could be to ins=
ert a colon before the declarator-id:</div><div><br></div><div>=C2=A0 =C2=
=A0 void f(int positional, int: named); =C2=A0 =C2=A0 // 1</div><div>=C2=A0=
 =C2=A0 void f(int*: foo, char(*: bar)(double)); // 2</div>

<div><br></div><div>The calls are then as you suggest:</div><div><br></div>=
<div>=C2=A0 =C2=A0 f(x, named: y); // ok calls 1</div><div>=C2=A0 =C2=A0 f(=
named: y, x); // ok calls 1</div><div><div>=C2=A0 =C2=A0 f(foo: x, bar: y);=
 // ok calls 2</div></div>

<div><div>=C2=A0 =C2=A0 f(bar: y, foo: x); // ok calls 2</div></div><div><b=
r></div><div>Basically named parameters are unordered and do not take up a =
position that influences positional parameters. =C2=A0Positional and named =
parameters form two separate sets of parameters, and named arguments do not=
 have a position (they have names). =C2=A0Therefore:</div>

<div><br></div><div>=C2=A0 =C2=A0void f(int: named, int othername); // rede=
clare 1, declaration matches</div><div><div>=C2=A0 =C2=A0void f(char(*:bar)=
(double),=C2=A0int*: foo); // redeclare 2, declaration matches<br></div></d=
iv></div></blockquote>
</div><div><br><br>Okay, seems pretty reasonable.=C2=A0 Positional paramete=
rs have to be specified by position, and named parameters have to be specif=
ied by name.<br><br>Do we allow overloading based only on named parameter n=
ames, e.g.:<br>
<br>void f(int: a); // 1<br>void f(int: b); // 2<br><br>f(a =3D 10); // cal=
ls 1<br>f(b =3D 10); // calls 2<br><br>It seems this could be useful and is=
 a natural consequence of making the parameter names part of the type.<br><=
/div>
</div></blockquote><div><br></div><div>Yes, that is correct. =C2=A0The two =
declarations do not match, so declare two different functions.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex">
<div dir=3D"ltr"><div>What about function pointers?=C2=A0 Can a pointer to =
a function with named parameters be converted to a pointer to a function wi=
th only positional parameters? (I would say the answer should be yes.)<br><=
/div>
</div></blockquote><div><br></div><div>Under the current spec the behavior =
would be:</div><div><br></div><div><div>int main()</div><div>{</div><div>=
=C2=A0 =C2=A0 extern void f(int);</div><div>=C2=A0 =C2=A0 auto p =3D &amp;f=
;</div><div>=C2=A0 =C2=A0 void (*q)(double) =3D p; // error:=C2=A0invalid c=
onversion from =E2=80=98void (*)(int)=E2=80=99 to =E2=80=98void (*)(double)=
=E2=80=99</div>
</div><div>=C2=A0 =C2=A0 void (*r)(int: x) =3D p; // error: invalid convers=
ion from =E2=80=98void (*)(int)=E2=80=99 to =E2=80=98void (*)(int: x)=E2=80=
=99</div><div><br></div><div>=C2=A0 =C2=A0 extern void g(int: x);</div><div=
>=C2=A0 =C2=A0 auto s =3D &amp;g;</div><div>=C2=A0 =C2=A0 void (*t)(int: y)=
 =3D s; // error: invalid conversion from =E2=80=98void (*)(int: x)=E2=80=
=99 to =E2=80=98void (*)(int: y)=E2=80=99</div>
<div>}</div><div><br></div><div>I don&#39;t see a compelling reason to prov=
ide conversions, anymore so than for example int(*)[1] should be convertibl=
e to struct { int x; }*, or struct { int x; }* should be convertible to str=
uct { int y; }*.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>The big issue that ha=
sn&#39;t been addressed is how this will interact with template metaprogram=
ming/perfect forwarding/variadic arguments.=C2=A0 From my perspective, intr=
oducing named parameters without a way to handle them generically and forwa=
rd them would be an uncceptable step backward.<br>
<br>Any ideas how this can be supported?<br></div></div></blockquote><div><=
br></div><div>I don&#39;t follow. =C2=A0You can use them in function templa=
tes:</div><div><br></div><div>=C2=A0 =C2=A0 template&lt;class T&gt;</div><d=
iv>=C2=A0 =C2=A0 void f(T: x);</div>
<div><br></div><div>=C2=A0 =C2=A0 f(x: 42); // ok calls f&lt;int&gt;</div><=
div>=C2=A0 =C2=A0 f(x: 2.0); // ok calls f&lt;double&gt;</div><div><br></di=
v><div>You can forward a named parameter:</div><div><br></div><div>=C2=A0 =
=C2=A0 template&lt;class T&gt;</div>
<div>=C2=A0 =C2=A0 void f(T&amp;&amp; x) { g(std::forward&lt;T&gt;(x)); }</=
div><div><br></div><div>Variadic arguments remain positional-only:</div><di=
v><br></div><div><div>=C2=A0 =C2=A0 template&lt;class... T&gt;</div><div>=
=C2=A0 =C2=A0 void f(T... x); // ok</div>
</div><div><br></div><div>=C2=A0 =C2=A0 template&lt;class... T&gt;</div><di=
v>=C2=A0 =C2=A0 void f(T... :x); // error</div><div><br></div><div>Unless y=
ou had something else in mind?</div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-=
left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir=3D"ltr"><div>We would similarly need this for named template argum=
ents.<br></div></div></blockquote><div><br></div><div>I think it can be don=
e in the same way as shown previously.</div><div>=C2=A0</div></div></div></=
div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--001a1135e1dc79194d04fbd93a89--

.

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

On Sun, Jun 15, 2014 at 7:31 AM, Andrew Tomazos <andrewtomazos@gmail.com>
wrote:

> You can forward a named parameter:
>
>     template<class T>
>     void f(T&& x) { g(std::forward<T>(x)); }
>
> Oops... should read:

    template<class T>
    void f(T&&: x) { g(std::forward<T>(x)); }

of course.

--

---
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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Jun 15, 2014 at 7:31 AM, Andrew Tomazos <span dir=3D"ltr">&lt;<a href=
=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@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"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"=
gmail_quote">
<div class=3D"">You can forward a named parameter:<br></div><div><br></div>=
<div>=C2=A0 =C2=A0 template&lt;class T&gt;</div>
<div>=C2=A0 =C2=A0 void f(T&amp;&amp; x) { g(std::forward&lt;T&gt;(x)); }</=
div><div><br></div></div></div></div></blockquote><div>Oops... should read:=
</div><div><br></div><div><div>=C2=A0 =C2=A0 template&lt;class T&gt;</div><=
div>=C2=A0 =C2=A0 void f(T&amp;&amp;: x) { g(std::forward&lt;T&gt;(x)); }</=
div>
</div><div><br></div><div>of course.</div><div><br></div></div></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--047d7b343d5a3cef9504fbd94a32--

.

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

On Sat, Jun 14, 2014 at 10:31 PM, Andrew Tomazos <andrewtomazos@gmail.com>
wrote:

> On Sun, Jun 15, 2014 at 5:51 AM, Jeremy Maitin-Shepard <
> jeremy@jeremyms.com> wrote:
>
>> On Saturday, June 14, 2014 11:56:51 AM UTC-7, Andrew Tomazos wrote:
>>>
>>>
>>> Do we allow overloading based only on named parameter names, e.g.:
>>>
>>> void f(int: a); // 1
>>> void f(int: b); // 2
>>>
>>> f(a =3D 10); // calls 1
>>> f(b =3D 10); // calls 2
>>>
>>> It seems this could be useful and is a natural consequence of making th=
e
>>> parameter names part of the type.
>>>
>>
> Yes, that is correct.  The two declarations do not match, so declare two
> different functions.
>
>
>> What about function pointers?  Can a pointer to a function with named
>> parameters be converted to a pointer to a function with only positional
>> parameters? (I would say the answer should be yes.)
>>
>
> Under the current spec the behavior would be:
>
> int main()
> {
>     extern void f(int);
>     auto p =3D &f;
>     void (*q)(double) =3D p; // error: invalid conversion from =E2=80=98v=
oid
> (*)(int)=E2=80=99 to =E2=80=98void (*)(double)=E2=80=99
>     void (*r)(int: x) =3D p; // error: invalid conversion from =E2=80=98v=
oid
> (*)(int)=E2=80=99 to =E2=80=98void (*)(int: x)=E2=80=99
>
>     extern void g(int: x);
>     auto s =3D &g;
>     void (*t)(int: y) =3D s; // error: invalid conversion from =E2=80=98v=
oid
> (*)(int: x)=E2=80=99 to =E2=80=98void (*)(int: y)=E2=80=99
> }
>
> I don't see a compelling reason to provide conversions, anymore so than
> for example int(*)[1] should be convertible to struct { int x; }*, or
> struct { int x; }* should be convertible to struct { int y; }*.
>

You didn't include the critical case:

extern void g(int: x);
auto p =3D &g;
void (*q)(int) =3D p; // valid?

There is a lot of existing code that uses function pointers.  It would be
inconvenient for functions with named parameters to not be compatible with
normal function pointers.  I don't see any downside to allowing the
implicit conversion.


>
> The big issue that hasn't been addressed is how this will interact with
>> template metaprogramming/perfect forwarding/variadic arguments.  From my
>> perspective, introducing named parameters without a way to handle them
>> generically and forward them would be an uncceptable step backward.
>>
>> Any ideas how this can be supported?
>>
>
> Variadic arguments remain positional-only:
>
>     template<class... T>
>     void f(T... x); // ok
>
>     template<class... T>
>     void f(T... :x); // error
>
> Unless you had something else in mind?
>

Yes, it is the variadic arguments case that I am concerned about.  Consider
what is possible in Python with:

def foo(*args, **kwArgs):
  ...

We should be able to do much of the same things at compile time in C++.  At
the very least we should be able to do a perfect forwarding of keyword
arguments; you could pattern match against particular names in the same way
we can currently pick off the first argument of an argument pack.  In
general the parameter identifiers, types, and values should be exposed to
template metaprogramming in such a way that we can do pretty much anything
we want with them.  Ideally the names themselves could be manipulated as
compile-time strings, and we could construct an arbitrary named argument
list from compile-time strings.

--=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/.

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

<div dir=3D"ltr">On Sat, Jun 14, 2014 at 10:31 PM, Andrew Tomazos <span dir=
=3D"ltr">&lt;<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">a=
ndrewtomazos@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"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div class=3D"">On Sun, Jun 15, 2014 at 5:51 AM,=
 Jeremy Maitin-Shepard <span dir=3D"ltr">&lt;<a href=3D"mailto:jeremy@jerem=
yms.com" target=3D"_blank">jeremy@jeremyms.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"><div dir=3D"ltr"><div>On Saturday, June 14, 2014 11:56:51 =
AM UTC-7, Andrew Tomazos wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204=
,204);border-left-style:solid;padding-left:1ex">

<div dir=3D"ltr"><br><div>Do we allow overloading based only on named param=
eter names, e.g.:<br>
<br>void f(int: a); // 1<br>void f(int: b); // 2<br><br>f(a =3D 10); // cal=
ls 1<br>f(b =3D 10); // calls 2<br><br>It seems this could be useful and is=
 a natural consequence of making the parameter names part of the type.<br>
</div></div></blockquote></div>
</div></blockquote><div><br></div></div><div>Yes, that is correct. =C2=A0Th=
e two declarations do not match, so declare two different functions.</div><=
div class=3D""><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;padding-left:1ex">

<div dir=3D"ltr"><div>What about function pointers?=C2=A0 Can a pointer to =
a function with named parameters be converted to a pointer to a function wi=
th only positional parameters? (I would say the answer should be yes.)<br><=
/div>

</div></blockquote><div><br></div></div><div>Under the current spec the beh=
avior would be:</div><div><br></div><div><div>int main()</div><div>{</div><=
div>=C2=A0 =C2=A0 extern void f(int);</div><div>=C2=A0 =C2=A0 auto p =3D &a=
mp;f;</div><div>=C2=A0 =C2=A0 void (*q)(double) =3D p; // error:=C2=A0inval=
id conversion from =E2=80=98void (*)(int)=E2=80=99 to =E2=80=98void (*)(dou=
ble)=E2=80=99</div>

</div><div>=C2=A0 =C2=A0 void (*r)(int: x) =3D p; // error: invalid convers=
ion from =E2=80=98void (*)(int)=E2=80=99 to =E2=80=98void (*)(int: x)=E2=80=
=99</div><div><br></div><div>=C2=A0 =C2=A0 extern void g(int: x);</div><div=
>=C2=A0 =C2=A0 auto s =3D &amp;g;</div><div>=C2=A0 =C2=A0 void (*t)(int: y)=
 =3D s; // error: invalid conversion from =E2=80=98void (*)(int: x)=E2=80=
=99 to =E2=80=98void (*)(int: y)=E2=80=99</div>

<div>}</div><div><br></div><div>I don&#39;t see a compelling reason to prov=
ide conversions, anymore so than for example int(*)[1] should be convertibl=
e to struct { int x; }*, or struct { int x; }* should be convertible to str=
uct { int y; }*.</div>
</div></div></div></blockquote><div><br></div><div>You didn&#39;t include t=
he critical case:<br><br></div><div>extern void g(int: x);<br></div><div>au=
to p =3D &amp;g;<br></div><div>void (*q)(int) =3D p; // valid?<br></div><di=
v>
<br></div><div>There is a lot of existing code that uses function pointers.=
=C2=A0 It would be inconvenient for functions with named parameters to not =
be compatible with normal function pointers.=C2=A0 I don&#39;t see any down=
side to allowing the implicit conversion.<br>
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
 class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"">
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>The big issue that ha=
sn&#39;t been addressed is how this will interact with template metaprogram=
ming/perfect forwarding/variadic arguments.=C2=A0 From my perspective, intr=
oducing named parameters without a way to handle them generically and forwa=
rd them would be an uncceptable step backward.<br>

<br>Any ideas how this can be supported?<br></div></div></blockquote><div><=
br></div></div><div>Variadic arguments remain positional-only:</div><div><b=
r></div><div><div>=C2=A0 =C2=A0 template&lt;class... T&gt;</div><div>=C2=A0=
 =C2=A0 void f(T... x); // ok</div>

</div><div><br></div><div>=C2=A0 =C2=A0 template&lt;class... T&gt;</div><di=
v>=C2=A0 =C2=A0 void f(T... :x); // error</div><div><br></div><div>Unless y=
ou had something else in mind?<br></div></div></div></div></blockquote><div=
><br></div><div>
Yes, it is the variadic arguments case that I am concerned about.=C2=A0 Con=
sider what is possible in Python with:<br><br>def foo(*args, **kwArgs):<br>=
=C2=A0 ...<br><br></div><div>We should be able to do much of the same thing=
s at compile time in C++.=C2=A0 At the very least we should be able to do a=
 perfect forwarding of keyword arguments; you could pattern match against p=
articular names in the same way we can currently pick off the first argumen=
t of an argument pack.=C2=A0 In general the parameter identifiers, types, a=
nd values should be exposed to template metaprogramming in such a way that =
we can do pretty much anything we want with them.=C2=A0 Ideally the names t=
hemselves could be manipulated as compile-time strings, and we could constr=
uct an arbitrary named argument list from compile-time strings.<br>
</div></div></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--f46d0435c05275e19b04fbd9c3fc--

.

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

On Sun, Jun 15, 2014 at 8:10 AM, Jeremy Maitin-Shepard <jeremy@jeremyms.com=
>
wrote:

> You didn't include the critical case:
>
> extern void g(int: x);
> auto p =3D &g;
> void (*q)(int) =3D p; // valid?
>
>
No, invalid conversion from =E2=80=98void (*)(int: x)=E2=80=99 to =E2=80=98=
void (*)(int)=E2=80=99.  The
functions have different types.


> The big issue that hasn't been addressed is how this will interact with
>>> template metaprogramming/perfect forwarding/variadic arguments.  From m=
y
>>> perspective, introducing named parameters without a way to handle them
>>> generically and forward them would be an uncceptable step backward.
>>>
>>> Any ideas how this can be supported?
>>>
>>
>> Variadic arguments remain positional-only:
>>
>>     template<class... T>
>>     void f(T... x); // ok
>>
>>     template<class... T>
>>     void f(T... :x); // error
>>
>> Unless you had something else in mind?
>>
>
>  Yes, it is the variadic arguments case that I am concerned about.
> Consider what is possible in Python with:
>
> def foo(*args, **kwArgs):
>   ...
>
> We should be able to do much of the same things at compile time in C++.
> At the very least we should be able to do a perfect forwarding of keyword
> arguments; you could pattern match against particular names in the same w=
ay
> we can currently pick off the first argument of an argument pack.  In
> general the parameter identifiers, types, and values should be exposed to
> template metaprogramming in such a way that we can do pretty much anythin=
g
> we want with them.  Ideally the names themselves could be manipulated as
> compile-time strings, and we could construct an arbitrary named argument
> list from compile-time strings.
>

Yeah, I get it.  You want:

    struct Rect
    {
        Rect(int: width, int: height);
        ...
    };

    auto p =3D make_shared<Rect>(width: 100, height: 200);

I don't immediately see a good solution for this sorry.  My best thought so
far is that deducing T from T&& and then std::forward<T> magically captures
and forwards named parameters, perhaps by making the deduced T some opaque
special type when passed a named argument.

--=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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Jun 15, 2014 at 8:10 AM, Jeremy Maitin-Shepard <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:jeremy@jeremyms.com" target=3D"_blank">jeremy@jeremyms.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"><div dir=3D"ltr"><div>You didn&#39;t include the critical =
case:<br>
</div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><br></div>=
<div>extern void g(int: x);<br></div><div>auto p =3D &amp;g;<br></div><div>=
void (*q)(int) =3D p; // valid?<br></div>
<div>
<br></div></div></div></div></blockquote><div><br></div><div>No, invalid co=
nversion from =E2=80=98void (*)(int: x)=E2=80=99 to =E2=80=98void (*)(int)=
=E2=80=99. =C2=A0The functions have different types.</div><div>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote 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;paddi=
ng-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex">
<div dir=3D"ltr"><div>The big issue that hasn&#39;t been addressed is how t=
his will interact with template metaprogramming/perfect forwarding/variadic=
 arguments.=C2=A0 From my perspective, introducing named parameters without=
 a way to handle them generically and forward them would be an uncceptable =
step backward.<br>



<br>Any ideas how this can be supported?<br></div></div></blockquote><div><=
br></div></div></div><div><div>Variadic arguments remain positional-only:</=
div><div><br></div><div><div>=C2=A0 =C2=A0 template&lt;class... T&gt;</div>
<div>=C2=A0 =C2=A0 void f(T... x); // ok</div>

</div><div><br></div><div>=C2=A0 =C2=A0 template&lt;class... T&gt;</div><di=
v>=C2=A0 =C2=A0 void f(T... :x); // error</div><div><br></div><div>Unless y=
ou had something else in mind?<br></div></div></div></div></div></blockquot=
e><div><br></div>

<div>
Yes, it is the variadic arguments case that I am concerned about.=C2=A0 Con=
sider what is possible in Python with:<br><br>def foo(*args, **kwArgs):<br>=
=C2=A0 ...<br><br></div><div>We should be able to do much of the same thing=
s at compile time in C++.=C2=A0 At the very least we should be able to do a=
 perfect forwarding of keyword arguments; you could pattern match against p=
articular names in the same way we can currently pick off the first argumen=
t of an argument pack.=C2=A0 In general the parameter identifiers, types, a=
nd values should be exposed to template metaprogramming in such a way that =
we can do pretty much anything we want with them.=C2=A0 Ideally the names t=
hemselves could be manipulated as compile-time strings, and we could constr=
uct an arbitrary named argument list from compile-time strings.<br>


</div></div></div></div><div><div></div></div></blockquote><div><br></div><=
div>Yeah, I get it. =C2=A0You want:</div><div><br></div><div>=C2=A0 =C2=A0 =
struct Rect</div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 Rect(int: width, int: height);</div><div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...</div><div>=C2=A0 =C2=A0 };</div><div><br></=
div><div>=C2=A0 =C2=A0 auto p =3D make_shared&lt;Rect&gt;(width: 100, heigh=
t: 200);</div><div><br></div><div>I don&#39;t immediately see a good soluti=
on for this sorry. =C2=A0My best thought so far is that deducing T from T&a=
mp;&amp; and then std::forward&lt;T&gt; magically captures and forwards nam=
ed parameters, perhaps by making the deduced T some opaque special type whe=
n passed a named argument.</div>
<div><br></div></div></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--001a1135e1dc7c54d904fbda2c15--

.

--Apple-Mail=_EB2035B9-6EAD-40F8-A856-0DFE96021A7A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-06-15, at 2:39 PM, Andrew Tomazos <andrewtomazos@gmail.com> wrote:

> I don't immediately see a good solution for this sorry.  My best thought =
so far is that deducing T from T&& and then std::forward<T> magically captu=
res and forwards named parameters, perhaps by making the deduced T some opa=
que special type when passed a named argument.

This is analogous to the incompatibility of forwarding with aggregate initi=
alization and initializer lists in general. If a "reverse forwarding" syste=
m is designed, hopefully it will handle all these cases.

--=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=_EB2035B9-6EAD-40F8-A856-0DFE96021A7A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<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 2014&=
ndash;06&ndash;15, at 2:39 PM, Andrew Tomazos &lt;<a href=3D"mailto:andrewt=
omazos@gmail.com">andrewtomazos@gmail.com</a>&gt; wrote:</div><br class=3D"=
Apple-interchange-newline"><blockquote type=3D"cite"><div style=3D"font-fam=
ily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; orphans: =
auto; text-align: start; text-indent: 0px; text-transform: none; white-spac=
e: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;=
"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><d=
iv>I don't immediately see a good solution for this sorry. &nbsp;My best th=
ought so far is that deducing T from T&amp;&amp; and then std::forward&lt;T=
&gt; magically captures and forwards named parameters, perhaps by making th=
e deduced T some opaque special type when passed a named argument.</div></d=
iv></div></div></div></blockquote><br></div><div>This is analogous to the i=
ncompatibility of forwarding with aggregate initialization and initializer =
lists in general. If a &ldquo;reverse forwarding&rdquo; system is designed,=
 hopefully it will handle all these cases.</div><br></body></html>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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=_EB2035B9-6EAD-40F8-A856-0DFE96021A7A--

.

On 15 June 2014 09:39, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> On Sun, Jun 15, 2014 at 8:10 AM, Jeremy Maitin-Shepard <jeremy@jeremyms.c=
om>
> wrote:
>>
>> You didn't include the critical case:
>>
>> extern void g(int: x);
>> auto p =3D &g;
>> void (*q)(int) =3D p; // valid?
>>
>
> No, invalid conversion from =E2=80=98void (*)(int: x)=E2=80=99 to =E2=80=
=98void (*)(int)=E2=80=99.  The
> functions have different types.

Urgh, really? The most experience I have with named arguments (keyword
arguments)
is with Common Lisp, and there you can invoke a keyword-arg function 'norma=
lly'
if you want. I don't see the reason to prevent such a conversion, nor
do I see a reason
to treat a named-arg function as a different type. Yes, that means
that the named-argness
may be lost in some cases, but I don't think that's a significant problem.

--=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/.

.

On 14 June 2014 22:03, Philipp Maximilian Stephani
<p.stephani2@gmail.com> wrote:
> To give an example why named arguments are more than syntactic sugar in C++:
> // Translation unit C
> void f(int b, int a);
> int main() {
>   f(a: 1, b: 2);
> }
> All four translation units can be compiled separately. The object code for A
> can then be linked with one of B, C, D to produce an executable. Except for
> the named arguments all translation units are valid C++. C and D represent
> valid cases where your proposal would fail: C would result in a confusing
> situation (f is called with a = 2 and b = 1, in contrast to what the named
> arguments say)

I don't see how that follows. The translation unit has a declaration that names
the arguments, so why would a be 2 in that call?

--

---
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/.

.

On 14 June 2014 21:21,  <botond.ballo@gmail.com> wrote:
> A colleague and I have been working on a proposal to add named arguments to
> C++.
>
> The proposal draft can be found here:
> http://ehsan.github.io/namedargs/namedargs.html
>
> Any feedback on it is appreciated!

This part looks suspicious:
"For remaining candidate functions, we reorder the N named arguments
and if for some i < M + N, the i'th parameter of the function remains
unmatched, we match it with a synthetic argument using the parameter's
default value. Note that given the above conditions, such parameters
are guaranteed to have a default value."

If I read that correctly, it's saying that

void f(int a, int b, int c);

can be called with
f(a : 10);
and b and c would get default values. I don't think default arguments and named
arguments should be mixed that way. If a function designer says his parameter
has a default argument, fine - but if a function designer doesn't say
that, we shouldn't
go and provide such default arguments invisibly. A separate concern is
whether we then
would allow

void f(int a = 10, int b);

since this function now can be called even if the default arguments
are not defined
for all terminal-position parameters: you could call it with
f(b : 5);
and presumably a would get the value 10.

--

---
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/.

.

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

On Sun, Jun 15, 2014 at 9:00 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 15 June 2014 09:39, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> > On Sun, Jun 15, 2014 at 8:10 AM, Jeremy Maitin-Shepard <
> jeremy@jeremyms.com>
> > wrote:
> >>
> >> You didn't include the critical case:
> >>
> >> extern void g(int: x);
> >> auto p =3D &g;
> >> void (*q)(int) =3D p; // valid?
> >>
> >
> > No, invalid conversion from =E2=80=98void (*)(int: x)=E2=80=99 to =E2=
=80=98void (*)(int)=E2=80=99.  The
> > functions have different types.
>
> Urgh, really? The most experience I have with named arguments (keyword
> arguments)
> is with Common Lisp, and there you can invoke a keyword-arg function
> 'normally'
> if you want. I don't see the reason to prevent such a conversion, nor
> do I see a reason
> to treat a named-arg function as a different type. Yes, that means
> that the named-argness
> may be lost in some cases, but I don't think that's a significant problem=
..
>
>
You could argue similarly that `int(*)(long)` should be convertible to
`long(*)(int)` as the parameter is covariant and the return value is
contravariant - but this conversion is currently invalid.

Lisp is so alien to the C family it's difficult to draw on it as existing
practice.  I would say that the named parameter features of C# and
SmallTalk->ObjC->Swift are the two living mainstream lines closest to C++.

--=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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Jun 15, 2014 at 9:00 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@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 class=3D"">On 15 June 2014 09:39, Andre=
w Tomazos &lt;<a href=3D"mailto:andrewtomazos@gmail.com">andrewtomazos@gmai=
l.com</a>&gt; wrote:<br>

&gt; On Sun, Jun 15, 2014 at 8:10 AM, Jeremy Maitin-Shepard &lt;<a href=3D"=
mailto:jeremy@jeremyms.com">jeremy@jeremyms.com</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; You didn&#39;t include the critical case:<br>
&gt;&gt;<br>
&gt;&gt; extern void g(int: x);<br>
&gt;&gt; auto p =3D &amp;g;<br>
&gt;&gt; void (*q)(int) =3D p; // valid?<br>
&gt;&gt;<br>
&gt;<br>
&gt; No, invalid conversion from =E2=80=98void (*)(int: x)=E2=80=99 to =E2=
=80=98void (*)(int)=E2=80=99. =C2=A0The<br>
&gt; functions have different types.<br>
<br>
</div>Urgh, really? The most experience I have with named arguments (keywor=
d<br>
arguments)<br>
is with Common Lisp, and there you can invoke a keyword-arg function &#39;n=
ormally&#39;<br>
if you want. I don&#39;t see the reason to prevent such a conversion, nor<b=
r>
do I see a reason<br>
to treat a named-arg function as a different type. Yes, that means<br>
that the named-argness<br>
may be lost in some cases, but I don&#39;t think that&#39;s a significant p=
roblem.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><=
br></div><div>You could argue similarly that `int(*)(long)` should be conve=
rtible to `long(*)(int)` as the parameter is covariant and the return value=
 is contravariant - but this conversion is currently invalid.</div>
<div><br></div><div>Lisp is so alien to the C family it&#39;s difficult to =
draw on it as existing practice. =C2=A0I would say that the named parameter=
 features of C# and SmallTalk-&gt;ObjC-&gt;Swift are the two living mainstr=
eam lines closest to C++.</div>
<div><br></div></div></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--001a11c2d95057753004fbdb7972--

.

On 15 June 2014 11:12, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
>> > No, invalid conversion from =E2=80=98void (*)(int: x)=E2=80=99 to =E2=
=80=98void (*)(int)=E2=80=99.  The
>> > functions have different types.
>> Urgh, really? The most experience I have with named arguments (keyword
>> arguments)
>> is with Common Lisp, and there you can invoke a keyword-arg function
>> 'normally'
>> if you want. I don't see the reason to prevent such a conversion, nor
>> do I see a reason
>> to treat a named-arg function as a different type. Yes, that means
>> that the named-argness
>> may be lost in some cases, but I don't think that's a significant proble=
m.
> You could argue similarly that `int(*)(long)` should be convertible to
> `long(*)(int)` as the parameter is covariant and the return value is
> contravariant - but this conversion is currently invalid.

I don't see those conversions being similar at all.

> Lisp is so alien to the C family it's difficult to draw on it as existing
> practice.  I would say that the named parameter features of C# and
> SmallTalk->ObjC->Swift are the two living mainstream lines closest to C++=
..

I don't see why that's difficult, since lisp has had named arguments for
far longer than these other languages, and the design decisions there
seem quite reasonable.

Another matter (or three) that the aspiring proposal authors should
take into account
and cover in their proposal:

1) how is this proposal different from earlier ones?
2) does it have better solutions to the issues of the earlier ones?
3) if so, how/why?

--=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/.

.

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

On Sun, Jun 15, 2014 at 10:23 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 15 June 2014 11:12, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> >> > No, invalid conversion from =E2=80=98void (*)(int: x)=E2=80=99 to =
=E2=80=98void (*)(int)=E2=80=99.
>  The
> >> > functions have different types.
> >> Urgh, really? The most experience I have with named arguments (keyword
> >> arguments)
> >> is with Common Lisp, and there you can invoke a keyword-arg function
> >> 'normally'
> >> if you want. I don't see the reason to prevent such a conversion, nor
> >> do I see a reason
> >> to treat a named-arg function as a different type. Yes, that means
> >> that the named-argness
> >> may be lost in some cases, but I don't think that's a significant
> problem.
> > You could argue similarly that `int(*)(long)` should be convertible to
> > `long(*)(int)` as the parameter is covariant and the return value is
> > contravariant - but this conversion is currently invalid.
>
> I don't see those conversions being similar at all.


You're saying you want a function with one named parameter (x) of type int
to be convertible to a function with one positional parameter (1st) of type
int, as they are "compatible" in a natural way.  I see positional and named
parameters as similar but distinct things.  To me it's like saying you want
int[1], std::tuple<int> and struct { int x; } to be convertible because
they all have exactly one subobject of type int:

    struct { int x; } A;
    int B[1] =3D A; // sure :)
    std::tuple<int> C =3D B; // why not? :)

--=20

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Jun 15, 2014 at 10:23 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilain=
en@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On 15 June 2014 11:12, Andre=
w Tomazos &lt;<a href=3D"mailto:andrewtomazos@gmail.com">andrewtomazos@gmai=
l.com</a>&gt; wrote:<br>

&gt;&gt; &gt; No, invalid conversion from =E2=80=98void (*)(int: x)=E2=80=
=99 to =E2=80=98void (*)(int)=E2=80=99. =C2=A0The<br>
&gt;&gt; &gt; functions have different types.<br>
&gt;&gt; Urgh, really? The most experience I have with named arguments (key=
word<br>
&gt;&gt; arguments)<br>
&gt;&gt; is with Common Lisp, and there you can invoke a keyword-arg functi=
on<br>
&gt;&gt; &#39;normally&#39;<br>
&gt;&gt; if you want. I don&#39;t see the reason to prevent such a conversi=
on, nor<br>
&gt;&gt; do I see a reason<br>
&gt;&gt; to treat a named-arg function as a different type. Yes, that means=
<br>
&gt;&gt; that the named-argness<br>
&gt;&gt; may be lost in some cases, but I don&#39;t think that&#39;s a sign=
ificant problem.<br>
&gt; You could argue similarly that `int(*)(long)` should be convertible to=
<br>
&gt; `long(*)(int)` as the parameter is covariant and the return value is<b=
r>
&gt; contravariant - but this conversion is currently invalid.<br>
<br>
</div>I don&#39;t see those conversions being similar at all.</blockquote><=
div>=C2=A0</div><div>You&#39;re saying you want a function with one named p=
arameter (x) of type int to be convertible to a function with one positiona=
l parameter (1st) of type int, as they are &quot;compatible&quot; in a natu=
ral way. =C2=A0I see positional and named parameters as similar but distinc=
t things. =C2=A0To me it&#39;s like saying you want int[1], std::tuple&lt;i=
nt&gt; and struct { int x; } to be convertible because they all have exactl=
y one subobject of type int:</div>
<div><br></div><div>=C2=A0 =C2=A0 struct { int x; } A;</div><div>=C2=A0 =C2=
=A0 int B[1] =3D A; // sure :)</div><div>=C2=A0 =C2=A0 std::tuple&lt;int&gt=
; C =3D B; // why not? :)</div><div><br></div><div><br></div></div></div></=
div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--20cf303bf5687d401504fbdbdc81--

.

On 15 June 2014 11:40, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> You're saying you want a function with one named parameter (x) of type int
> to be convertible to a function with one positional parameter (1st) of type
> int, as they are "compatible" in a natural way.  I see positional and named

Correct. They can be called the same way with the exact same number of
conversions of arguments. The ability to be able to name an argument
in a call and reorder arguments that way is just sugar and has no impact
on the function type, as far as I can see.

> parameters as similar but distinct things.  To me it's like saying you want
> int[1], std::tuple<int> and struct { int x; } to be convertible because they
> all have exactly one subobject of type int:


You completely lost me there, I don't know what this attempt at an
analogy is supposed
to illustrate.

--

---
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/.

.

On Sun, Jun 15, 2014 at 10:23 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> Another matter (or three) that the aspiring proposal authors should
> take into account
> and cover in their proposal:
>
> 1) how is this proposal different from earlier ones?
> 2) does it have better solutions to the issues of the earlier ones?
> 3) if so, how/why?

Unfortunately, http://cplusplus.github.io/EWG/ewg-active.html doesn't
have an entry for "named parameters" that the authors of this paper
could use to easily find such previous papers. Could you add one?

Then I google-searched open-std.org to see if I could propose an
initial list of papers to include, but I couldn't find any. Are the
proposals for this just so old that everyone remembers to be scared,
but the issues aren't actually recorded anywhere accessible?

Jeffrey

--

---
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/.

.

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

On Sun, Jun 15, 2014 at 10:47 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 15 June 2014 11:40, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> > You're saying you want a function with one named parameter (x) of type
> int
> > to be convertible to a function with one positional parameter (1st) of
> type
> > int, as they are "compatible" in a natural way.  I see positional and
> named
>
> Correct. They can be called the same way with the exact same number of
> conversions of arguments. The ability to be able to name an argument
> in a call and reorder arguments that way is just sugar and has no impact
> on the function type, as far as I can see.



> > parameters as similar but distinct things.  To me it's like saying you
> want
> > int[1], std::tuple<int> and struct { int x; } to be convertible because
> they
> > all have exactly one subobject of type int:
>
>
You completely lost me there, I don't know what this attempt at an
> analogy is supposed
> to illustrate.


There are (at least) two ways to assign a relationship between a container
and its contents.

First you can describe a position.  The "first" in the egg tray.

Second you can give it a name.  The "roof" of the car.

Under my design we keep these two methods separate, and part of the
function.  Just like we keep the two methods separate between arrays/tuples
(positional) and structs (named).  The function designer chooses which
parameters of their function are to be denoted by position, and which are
to be denoted by name.

Under the OPs design and yours, the caller decides which parameters are
denoted by position and which parameters are denoted by name on a
call-by-call basis.  The problem I see with this design is that you are
retroactively giving existing function parameter names significance outside
of their current function prototype scope (for function declarations) or
function scope (for function definitions).  For example:

    int blah(int n, int x);
    int blah(int x, int y); // redeclaration

    int z = blah(x : 42, 43); // is this blah(42, 43) or blah(43, 42) ?

I think that will end up in a confusing mess.  I argue it's safer, cleaner
and more structured to leave this decision to the function designer, and to
leave all the existing code as having only positional parameters/arguments,
as was the case when the code was written.  Existing parameter names were
not designed to be significant outside their containing declarations.

--

---
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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Jun 15, 2014 at 10:47 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilain=
en@gmail.com</a>&gt;</span> wrote:<br>
</div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=
=3D"">On 15 June 2014 11:40, Andrew Tomazos &lt;<a href=3D"mailto:andrewtom=
azos@gmail.com">andrewtomazos@gmail.com</a>&gt; wrote:<br>

&gt; You&#39;re saying you want a function with one named parameter (x) of =
type int<br>
&gt; to be convertible to a function with one positional parameter (1st) of=
 type<br>
&gt; int, as they are &quot;compatible&quot; in a natural way. =C2=A0I see =
positional and named<br>
<br>
</div>Correct. They can be called the same way with the exact same number o=
f<br>
conversions of arguments. The ability to be able to name an argument<br>
in a call and reorder arguments that way is just sugar and has no impact<br=
>
on the function type, as far as I can see.</blockquote><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div class=3D"">
&gt; parameters as similar but distinct things. =C2=A0To me it&#39;s like s=
aying you want<br>
&gt; int[1], std::tuple&lt;int&gt; and struct { int x; } to be convertible =
because they<br>
&gt; all have exactly one subobject of type int:<br>=C2=A0=C2=A0</div></blo=
ckquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div class=3D"">You completely lost =
me there, I don&#39;t know what this attempt at an<br>
</div>
analogy is supposed<br>
to illustrate.</blockquote><div><br></div><div>There are (at least) two way=
s to assign a relationship between a container and its contents.</div><div>=
<br></div><div>First you can describe a position. =C2=A0The &quot;first&quo=
t; in the egg tray.</div>
<div><br></div><div>Second you can give it a name. =C2=A0The &quot;roof&quo=
t; of the car.</div><div><br></div><div>Under my design we keep these two m=
ethods separate, and part of the function. =C2=A0Just like we keep the two =
methods separate between arrays/tuples (positional) and structs (named). =
=C2=A0The function designer chooses which parameters of their function are =
to be denoted by position, and which are to be denoted by name.</div>
<div><br></div><div>Under the OPs design and yours, the caller decides whic=
h parameters are denoted by position and which parameters are denoted by na=
me on a call-by-call basis. =C2=A0The problem I see with this design is tha=
t you are retroactively giving existing function parameter names significan=
ce outside of their current function prototype scope (for function declarat=
ions) or function scope (for function definitions). =C2=A0For example:</div=
>
<div><br></div><div>=C2=A0 =C2=A0 int blah(int n, int x);</div><div>=C2=A0 =
=C2=A0 int blah(int x, int y); // redeclaration</div><div><br></div><div>=
=C2=A0 =C2=A0 int z =3D blah(x : 42, 43); // is this blah(42, 43) or blah(4=
3, 42) ?</div><div><br></div><div>
I think that will end up in a confusing mess. =C2=A0I argue it&#39;s safer,=
 cleaner and more structured to leave this decision to the function designe=
r, and to leave all the existing code as having only positional parameters/=
arguments, as was the case when the code was written. =C2=A0Existing parame=
ter names were not designed to be significant outside their containing decl=
arations.</div>
<div><br></div></div></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--089e011609f4a3b6e704fbdc9995--

.

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

Another plus is overloading on named parameters:

struct Rect
{
    Rect(int: left, int: top, int: right, int: bottom);
    Rect(int: left, int: top, int: width, int: height);
};

Rect r1(left: 100, top: 100, right: 200, bottom: 200);
Rect r2(left: 100, top: 100, width: 100, height: 100); // r1 == r2

Won't work with the per-call design.



On Sun, Jun 15, 2014 at 11:33 AM, Andrew Tomazos <andrewtomazos@gmail.com>
wrote:

> On Sun, Jun 15, 2014 at 10:47 AM, Ville Voutilainen <
> ville.voutilainen@gmail.com> wrote:
>
>> On 15 June 2014 11:40, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
>> > You're saying you want a function with one named parameter (x) of type
>> int
>> > to be convertible to a function with one positional parameter (1st) of
>> type
>> > int, as they are "compatible" in a natural way.  I see positional and
>> named
>>
>> Correct. They can be called the same way with the exact same number of
>> conversions of arguments. The ability to be able to name an argument
>> in a call and reorder arguments that way is just sugar and has no impact
>> on the function type, as far as I can see.
>
>
>
>> > parameters as similar but distinct things.  To me it's like saying you
>> want
>> > int[1], std::tuple<int> and struct { int x; } to be convertible because
>> they
>> > all have exactly one subobject of type int:
>>
>>
> You completely lost me there, I don't know what this attempt at an
>>  analogy is supposed
>> to illustrate.
>
>
> There are (at least) two ways to assign a relationship between a container
> and its contents.
>
> First you can describe a position.  The "first" in the egg tray.
>
> Second you can give it a name.  The "roof" of the car.
>
> Under my design we keep these two methods separate, and part of the
> function.  Just like we keep the two methods separate between arrays/tuples
> (positional) and structs (named).  The function designer chooses which
> parameters of their function are to be denoted by position, and which are
> to be denoted by name.
>
> Under the OPs design and yours, the caller decides which parameters are
> denoted by position and which parameters are denoted by name on a
> call-by-call basis.  The problem I see with this design is that you are
> retroactively giving existing function parameter names significance outside
> of their current function prototype scope (for function declarations) or
> function scope (for function definitions).  For example:
>
>     int blah(int n, int x);
>     int blah(int x, int y); // redeclaration
>
>     int z = blah(x : 42, 43); // is this blah(42, 43) or blah(43, 42) ?
>
> I think that will end up in a confusing mess.  I argue it's safer, cleaner
> and more structured to leave this decision to the function designer, and to
> leave all the existing code as having only positional parameters/arguments,
> as was the case when the code was written.  Existing parameter names were
> not designed to be significant outside their containing declarations.
>
>

--

---
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/.

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

<div dir=3D"ltr">Another plus is overloading on named parameters:<div><br><=
/div><div>struct Rect</div><div>{</div><div>=C2=A0 =C2=A0 Rect(int: left, i=
nt: top, int: right, int: bottom);</div><div>=C2=A0 =C2=A0 Rect(int: left, =
int: top, int: width, int: height);</div>
<div>};</div><div><br></div><div><div>Rect r1(left: 100, top: 100, right: 2=
00, bottom: 200);</div></div><div><div>Rect r2(left: 100, top: 100, width: =
100, height: 100); // r1 =3D=3D r2</div></div><div><br></div><div>Won&#39;t=
 work with the per-call design.</div>
<div><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Sun, Jun 15, 2014 at 11:33 AM, Andrew Tomazos <span dir=3D"ltr">=
&lt;<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtoma=
zos@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"><div class=3D"gmail_extra">=
<div class=3D""><div class=3D"gmail_quote">On Sun, Jun 15, 2014 at 10:47 AM=
, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilain=
en@gmail.com" target=3D"_blank">ville.voutilainen@gmail.com</a>&gt;</span> =
wrote:<br>

</div></div><div class=3D"gmail_quote"><div class=3D""><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div>On 15 June 2014 11:40, Andrew Tomazos &lt;<a href=3D"mailto=
:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@gmail.com</a>&gt;=
 wrote:<br>


&gt; You&#39;re saying you want a function with one named parameter (x) of =
type int<br>
&gt; to be convertible to a function with one positional parameter (1st) of=
 type<br>
&gt; int, as they are &quot;compatible&quot; in a natural way. =C2=A0I see =
positional and named<br>
<br>
</div>Correct. They can be called the same way with the exact same number o=
f<br>
conversions of arguments. The ability to be able to name an argument<br>
in a call and reorder arguments that way is just sugar and has no impact<br=
>
on the function type, as far as I can see.</blockquote><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div>
&gt; parameters as similar but distinct things. =C2=A0To me it&#39;s like s=
aying you want<br>
&gt; int[1], std::tuple&lt;int&gt; and struct { int x; } to be convertible =
because they<br>
&gt; all have exactly one subobject of type int:<br>=C2=A0=C2=A0</div></blo=
ckquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div>You completely lost me there, I=
 don&#39;t know what this attempt at an<br>

</div>
analogy is supposed<br>
to illustrate.</blockquote><div><br></div></div><div>There are (at least) t=
wo ways to assign a relationship between a container and its contents.</div=
><div><br></div><div>First you can describe a position. =C2=A0The &quot;fir=
st&quot; in the egg tray.</div>

<div><br></div><div>Second you can give it a name. =C2=A0The &quot;roof&quo=
t; of the car.</div><div><br></div><div>Under my design we keep these two m=
ethods separate, and part of the function. =C2=A0Just like we keep the two =
methods separate between arrays/tuples (positional) and structs (named). =
=C2=A0The function designer chooses which parameters of their function are =
to be denoted by position, and which are to be denoted by name.</div>

<div><br></div><div>Under the OPs design and yours, the caller decides whic=
h parameters are denoted by position and which parameters are denoted by na=
me on a call-by-call basis. =C2=A0The problem I see with this design is tha=
t you are retroactively giving existing function parameter names significan=
ce outside of their current function prototype scope (for function declarat=
ions) or function scope (for function definitions). =C2=A0For example:</div=
>

<div><br></div><div>=C2=A0 =C2=A0 int blah(int n, int x);</div><div>=C2=A0 =
=C2=A0 int blah(int x, int y); // redeclaration</div><div><br></div><div>=
=C2=A0 =C2=A0 int z =3D blah(x : 42, 43); // is this blah(42, 43) or blah(4=
3, 42) ?</div><div><br></div>
<div>
I think that will end up in a confusing mess. =C2=A0I argue it&#39;s safer,=
 cleaner and more structured to leave this decision to the function designe=
r, and to leave all the existing code as having only positional parameters/=
arguments, as was the case when the code was written. =C2=A0Existing parame=
ter names were not designed to be significant outside their containing decl=
arations.</div>

<div><br></div></div></div></div>
</blockquote></div><br></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--047d7bd6be0297856c04fbdd19b6--

.

>This part looks suspicious:
>"For remaining candidate functions, we reorder the N named arguments
>and if for some i < M + N, the i'th parameter of the function remains
>unmatched, we match it with a synthetic argument using the parameter's
>default value. Note that given the above conditions, such parameters
>are guaranteed to have a default value."
>
>If I read that correctly, it's saying that
>
>void f(int a, int b, int c);
>
>can be called with
>f(a : 10);
>and b and c would get default values. I don't think default arguments and =
named
>arguments should be mixed that way. If a function designer says his parame=
ter
>has a default argument, fine - but if a function designer doesn't say
>that, we shouldn't
>go and provide such default arguments invisibly.=A0

We are definitely not proposing this, and I agree that it would be
highly undesirable.

Our intention was to rule this out with this rule in our proposal:


"A given candidate is discarded if either of the following conditions holds=
:

=A0=A0=A0=A0 ...
=A0=A0 - A required parameter of the function remains unmatched after the a=
bove step."

I'll clarify the wording in the next draft.


>A separate concern is
>whether we then
>would allow
>
>void f(int a =3D 10, int b);
>
>since this function now can be called even if the default arguments
>are not defined
>for all terminal-position parameters: you could call it with
>f(b : 5);
>and presumably a would get the value 10.


We are currently not proposing any changes to the rules governing
function declarations, so this would still be ill-formed.

However, I agree that it might be a logical extension to allow
things like that.

Thanks,
Botond

--=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/.

.

> Another matter (or three) that the aspiring proposal authors should

> take into account
> and cover in their proposal:
>
> 1) how is this proposal different from earlier ones?
> 2) does it have better solutions to the issues of the earlier ones?
> 3) if so, how/why?

I looked through the papers at [1] but did not find any about
named arguments. If you're aware of previous proposals on
this subject, I would be very interested in looking at them.

Thanks,
Botond

[1] http://open-std.org/JTC1/SC22/WG21/docs/papers/

--

---
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/.

.

On 15 June 2014 12:33, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
>     int blah(int n, int x);
>     int blah(int x, int y); // redeclaration
>
>     int z = blah(x : 42, 43); // is this blah(42, 43) or blah(43, 42) ?

Based on the proposal, it's crystal clear: such calls are ill-formed. As they
are, I might add, in existing practice, like eg. Common Lisp.

> I think that will end up in a confusing mess.  I argue it's safer, cleaner

Unless we follow existing practice where it isn't a confusing mess.

--

---
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/.

.

On 15 June 2014 11:55, Jeffrey Yasskin <jyasskin@google.com> wrote:
> Unfortunately, http://cplusplus.github.io/EWG/ewg-active.html doesn't
> have an entry for "named parameters" that the authors of this paper
> could use to easily find such previous papers. Could you add one?

I will need to do some digging, but basically, yes.

> Then I google-searched open-std.org to see if I could propose an
> initial list of papers to include, but I couldn't find any. Are the
> proposals for this just so old that everyone remembers to be scared,
> but the issues aren't actually recorded anywhere accessible?


I think the answers are "yes" and "yes". Chances are that D&E has something
about it, I don't have it at hand to check.

--

---
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/.

.

On 15 June 2014 13:28, 'Botond Ballo' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:
>> Another matter (or three) that the aspiring proposal authors should
>
>> take into account
>> and cover in their proposal:
>>
>> 1) how is this proposal different from earlier ones?
>> 2) does it have better solutions to the issues of the earlier ones?
>> 3) if so, how/why?
>
> I looked through the papers at [1] but did not find any about
> named arguments. If you're aware of previous proposals on
> this subject, I would be very interested in looking at them.


It's possible that this information is more in old-timer brains than in
concrete proposals. I propose we corner some likely suspects
and apply mild third degree interrogation techniques on them
during the meeting. It's surprising what secrets people reveal
when presented with beer and meat.

--

---
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/.

.

On 15 June 2014 17:27, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> On 15 June 2014 13:28, 'Botond Ballo' via ISO C++ Standard - Future
> Proposals <std-proposals@isocpp.org> wrote:
>>> Another matter (or three) that the aspiring proposal authors should
>>
>>> take into account
>>> and cover in their proposal:
>>>
>>> 1) how is this proposal different from earlier ones?
>>> 2) does it have better solutions to the issues of the earlier ones?
>>> 3) if so, how/why?
>>
>> I looked through the papers at [1] but did not find any about
>> named arguments. If you're aware of previous proposals on
>> this subject, I would be very interested in looking at them.
>
>
> It's possible that this information is more in old-timer brains than in
> concrete proposals. I propose we corner some likely suspects
> and apply mild third degree interrogation techniques on them
> during the meeting. It's surprising what secrets people reveal
> when presented with beer and meat.

Well, quickly, this google search reveals some ancient scrolls to
me: "site:open-std.org keyword argument"

http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/1992/WG21%201992/X3J16_92-0010%20WG21_N0088.pdf
http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/1992/WG21%201992/X3J16_92-0054%20WG21_N0131.pdf
http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/1991/WG21%201991/X3J16_91-0127%20WG21_N0060.pdf

Note that these are indeed ancient scrolls, and weren't even on the site before
Bjarne uploaded his stash of old documents not-that-long-ago.

\begin{flippant}
And yes, you newbies, it's called a "keyword argument", not "named argument"
or "named parameter", because the existing practice in Common Lisp calls
it a "keyword argument". Now get off my lawn! :D
\end{flippant}

--

---
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/.

.

Em s=E1b 14 jun 2014, =E0s 20:51:26, Jeremy Maitin-Shepard escreveu:
> Do we allow overloading based only on named parameter names, e.g.:
>=20
> void f(int: a); // 1
> void f(int: b); // 2

IMHO, no, they are the same.

Named parameters are simply a way for the compiler to reorder the named=20
parameters into the positional order that the function expects. From that=
=20
point on, the call should proceed exactly as positional calls do.

--=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/.

.

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

I've had a look at the Named Argument feature of C#.  As far as I can tell
they have done it exactly the way the OP proposes, including the syntax and
even the proposal terminology matches the C# language specification.  In C#=
:

class NamedExample
{

    static int CalculateBMI(int weight, int height)
    {
        return (weight * 703) / (height * height);
    }

static void Main(string[] args)

    {
        // The method can be called in the normal way, by using
positional arguments.
        Console.WriteLine(CalculateBMI(123, 64));

        // Named arguments can be supplied for the parameters in either ord=
er.
        Console.WriteLine(CalculateBMI(weight: 123, height: 64));
        Console.WriteLine(CalculateBMI(height: 64, weight: 123));

        // Positional arguments cannot follow named arguments.
        // The following statement causes a compiler error.
        //Console.WriteLine(CalculateBMI(weight: 123, 64));

        // Named arguments can follow positional arguments.
        Console.WriteLine(CalculateBMI(123, height: 64));
    }

}

From the C# spec 7.5.1 Argument Lists:

> An argument-list consists of one or more arguments, separated by commas. =
Each argument consists of an optional  argument-name followed by an argumen=
t-value. An argument with an argument-name is referred to as a named argume=
nt, whereas an argument without an argument-name is a positional argument. =
*It is an error for a positional argument to appear after a named argument =
in an argument-list.*

Overload resolution then proceeds as you would expect from this constraint.

Although in C#, unlike C++, there is one canonical function
declaration/definition per function, which means forming canonical
parameter names easier, I agree it shows it is not as dangerous as I
first thought, and am swayed by the appeal to existing practice,
especially by C#.



On Sun, Jun 15, 2014 at 4:13 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 15 June 2014 12:33, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> >     int blah(int n, int x);
> >     int blah(int x, int y); // redeclaration
> >
> >     int z =3D blah(x : 42, 43); // is this blah(42, 43) or blah(43, 42)=
 ?
>
> Based on the proposal, it's crystal clear: such calls are ill-formed. As
> they
> are, I might add, in existing practice, like eg. Common Lisp.
>
> > I think that will end up in a confusing mess.  I argue it's safer,
> cleaner
>
> Unless we follow existing practice where it isn't a confusing mess.
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr">I&#39;ve had a look at the Named Argument feature of C#. =
=C2=A0As far as I can tell they have done it exactly the way the OP propose=
s, including the syntax and even the proposal terminology matches the C# la=
nguage specification. =C2=A0In C#:<div>
<div><br></div><div><pre style=3D"padding:5px;margin-top:0px;margin-bottom:=
0px;overflow:auto;word-wrap:normal;color:rgb(0,0,0);font-size:13px;line-hei=
ght:17.549999237060547px;font-family:Consolas,Courier,monospace!important">
<span style=3D"color:blue">class</span> NamedExample
{
<pre style=3D"padding:5px;margin-top:0px;margin-bottom:0px;overflow:auto;wo=
rd-wrap:normal;font-family:Consolas,Courier,monospace!important">    <span =
style=3D"color:blue">static</span>=C2=A0<span style=3D"color:blue">int</spa=
n> CalculateBMI(<span style=3D"color:blue">int</span> weight, <span style=
=3D"color:blue">int</span> height)
    {
        <span style=3D"color:blue">return</span> (weight * 703) / (height *=
 height);
    }
</pre><div>    <span style=3D"color:blue">static</span>=C2=A0<span style=3D=
"color:blue">void</span> Main(<span style=3D"color:blue">string</span>[] ar=
gs)<br></div></pre><pre style=3D"padding:5px;margin-top:0px;margin-bottom:0=
px;overflow:auto;word-wrap:normal;color:rgb(0,0,0);font-size:13px;line-heig=
ht:17.549999237060547px;font-family:Consolas,Courier,monospace!important">
    {
        <span style=3D"color:green">// The method can be called in the norm=
al way, by using positional arguments.</span>
        Console.WriteLine(CalculateBMI(123, 64));

        <span style=3D"color:green">// Named arguments can be supplied for =
the parameters in either order.</span>
        Console.WriteLine(CalculateBMI(weight: 123, height: 64));
        Console.WriteLine(CalculateBMI(height: 64, weight: 123));

        <span style=3D"color:green">// Positional arguments cannot follow n=
amed arguments.=C2=A0</span>
        <span style=3D"color:green">// The following statement causes a com=
piler error.=C2=A0</span>
        <span style=3D"color:green">//Console.WriteLine(CalculateBMI(weight=
: 123, 64));=C2=A0</span>

        <span style=3D"color:green">// Named arguments can follow positiona=
l arguments.</span>
        Console.WriteLine(CalculateBMI(123, height: 64));
    }

}</pre><pre style=3D"padding:5px;margin-top:0px;margin-bottom:0px;overflow:=
auto;word-wrap:normal;color:rgb(0,0,0);font-size:13px;line-height:17.549999=
237060547px;font-family:Consolas,Courier,monospace!important"><div style=3D=
"color:rgb(34,34,34);font-family:arial;font-size:small;line-height:normal;w=
hite-space:normal">
<div>From the C# spec 7.5.1 Argument Lists:</div><div><br></div><div>&gt; A=
n argument-list consists of one or more arguments, separated by commas. Eac=
h argument consists of an optional =C2=A0argument-name followed by an argum=
ent-value. An argument with an argument-name is referred to as a named argu=
ment, whereas an argument without an argument-name is a positional argument=
.. <b>It is an error for a positional argument to appear after a named argum=
ent in an argument-list.</b></div>
<div><br></div><div>Overload resolution then proceeds as you would expect f=
rom this constraint.</div><div><br></div><div>Although in C#, unlike C++, t=
here is one canonical function declaration/definition per function, which m=
eans forming canonical parameter names easier, I agree it shows it is not a=
s dangerous as I first thought, and am swayed by the appeal to existing pra=
ctice, especially by C#.</div>
<div><br></div></div></pre></div></div></div><div class=3D"gmail_extra"><br=
><br><div class=3D"gmail_quote">On Sun, Jun 15, 2014 at 4:13 PM, Ville Vout=
ilainen <span dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com=
" target=3D"_blank">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 class=3D"">On 15 June 2014 12:33, Andre=
w Tomazos &lt;<a href=3D"mailto:andrewtomazos@gmail.com">andrewtomazos@gmai=
l.com</a>&gt; wrote:<br>

&gt; =C2=A0 =C2=A0 int blah(int n, int x);<br>
&gt; =C2=A0 =C2=A0 int blah(int x, int y); // redeclaration<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 int z =3D blah(x : 42, 43); // is this blah(42, 43) or b=
lah(43, 42) ?<br>
<br>
</div>Based on the proposal, it&#39;s crystal clear: such calls are ill-for=
med. As they<br>
are, I might add, in existing practice, like eg. Common Lisp.<br>
<div class=3D""><br>
&gt; I think that will end up in a confusing mess. =C2=A0I argue it&#39;s s=
afer, cleaner<br>
<br>
</div>Unless we follow existing practice where it isn&#39;t a confusing mes=
s.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><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>
</div></div></blockquote></div><br></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--bcaec5299be35dfb6c04fbe17107--

.

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

On Sun, Jun 15, 2014 at 1:40 AM, Andrew Tomazos <andrewtomazos@gmail.com>
wrote:

> You're saying you want a function with one named parameter (x) of type int
> to be convertible to a function with one positional parameter (1st) of type
> int, as they are "compatible" in a natural way.  I see positional and named
> parameters as similar but distinct things.
>
The implicit conversion is likely to be useful and unlikely to do anything
unexpected or cause any harm.  However, if it required an explicit
conversion that would be okay.


> To me it's like saying you want int[1], std::tuple<int> and struct { int
> x; } to be convertible because they all have exactly one subobject of type
> int:
>
>     struct { int x; } A;
>     int B[1] = A; // sure :)
>     std::tuple<int> C = B; // why not? :)
>

Clearly we don't want them to be implicitly convertible, but in fact I
would say that they should be safely convertible using reinterpret_cast if
the types are all POD-like (I say POD-like because we should also relax
some of the POD requirements, but that is a separate matter).  std::tuple
should be required to have a layout identical to a struct with members in
the specified order.  Unfortunately some implementations accidentally? have
a reverse layout due to the recursive implementation used, but I think that
is worth prohibiting even if it breaks ABIs.  Would this prevent too many
optimization possibilities due to aliasing issues?  This is all a tangent,
though.

--

---
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/.

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

<div dir=3D"ltr">On Sun, Jun 15, 2014 at 1:40 AM, Andrew Tomazos <span dir=
=3D"ltr">&lt;<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">a=
ndrewtomazos@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"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div>You&#39;re saying you want a function with =
one named parameter (x) of type int to be convertible to a function with on=
e positional parameter (1st) of type int, as they are &quot;compatible&quot=
; in a natural way. =C2=A0I see positional and named parameters as similar =
but distinct things.</div>
</div></div></div></blockquote><div>The implicit conversion is likely to be=
 useful and unlikely to do anything unexpected or cause any harm.=C2=A0 How=
ever, if it required an explicit conversion that would be okay.<br></div><d=
iv>
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"g=
mail_extra"><div class=3D"gmail_quote"><div>To me it&#39;s like saying you =
want int[1], std::tuple&lt;int&gt; and struct { int x; } to be convertible =
because they all have exactly one subobject of type int:</div>

<div><br></div><div>=C2=A0 =C2=A0 struct { int x; } A;</div><div>=C2=A0 =C2=
=A0 int B[1] =3D A; // sure :)</div><div>=C2=A0 =C2=A0 std::tuple&lt;int&gt=
; C =3D B; // why not? :)</div></div></div></div></blockquote><div><br></di=
v><div>Clearly we don&#39;t want them to be implicitly convertible, but in =
fact I would say that they should be safely convertible using reinterpret_c=
ast if the types are all POD-like (I say POD-like because we should also re=
lax some of the POD requirements, but that is a separate matter).=C2=A0 std=
::tuple should be required to have a layout identical to a struct with memb=
ers in the specified order.=C2=A0 Unfortunately some implementations accide=
ntally? have a reverse layout due to the recursive implementation used, but=
 I think that is worth prohibiting even if it breaks ABIs.=C2=A0 Would this=
 prevent too many optimization possibilities due to aliasing issues?=C2=A0 =
This is all a tangent, though.<br>
</div></div><br></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--047d7b8743f6298b3404fbe22ec5--

.

On 2014-06-15, at 10:34 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

> Well, quickly, this google search reveals some ancient scrolls to
> me: "site:open-std.org keyword argument"

Thank you! Whodathunk that "keyword" would be the key word.

> http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/1992/WG21%201992/X3J16_92-0010%20WG21_N0088.pdf
> http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/1992/WG21%201992/X3J16_92-0054%20WG21_N0131.pdf

"As suggested above, designing classes to represent complex interfaces provides more functionality and is more readable."

"I recommend ... reject this proposal on the grounds that it makes minimal improvements at an unacceptable cost in complexity and compatibility."

Does nobody here support combining designated initializers with named arguments as a common facility? I'm seeing a lot of evidence of overlapping usage.

What is the latest status of designated initializers, taken alone? My recollection is that it's among a number of C features that hasn't been "ported" due to lack of interest.

--

---
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/.

.

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

On Sun, Jun 15, 2014 at 9:12 AM, Jeremy Maitin-Shepard <jeremy@jeremyms.com>
wrote:

> On Sun, Jun 15, 2014 at 1:40 AM, Andrew Tomazos <andrewtomazos@gmail.com>
> wrote:
>
>> You're saying you want a function with one named parameter (x) of type
>> int to be convertible to a function with one positional parameter (1st) of
>> type int, as they are "compatible" in a natural way.  I see positional and
>> named parameters as similar but distinct things.
>>
> The implicit conversion is likely to be useful and unlikely to do anything
> unexpected or cause any harm.  However, if it required an explicit
> conversion that would be okay.
>
>
>> To me it's like saying you want int[1], std::tuple<int> and struct { int
>> x; } to be convertible because they all have exactly one subobject of type
>> int:
>>
>>     struct { int x; } A;
>>     int B[1] = A; // sure :)
>>     std::tuple<int> C = B; // why not? :)
>>
>
> Clearly we don't want them to be implicitly convertible, but in fact I
> would say that they should be safely convertible using reinterpret_cast if
> the types are all POD-like (I say POD-like because we should also relax
> some of the POD requirements, but that is a separate matter).  std::tuple
> should be required to have a layout identical to a struct with members in
> the specified order.  Unfortunately some implementations accidentally? have
> a reverse layout due to the recursive implementation used, but I think that
> is worth prohibiting even if it breaks ABIs.  Would this prevent too many
> optimization possibilities due to aliasing issues?  This is all a tangent,
> though.
>
> I really should have said standard layout, and the relaxation I'm thinking
of is to allow base classes with non-static data members.

--

---
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/.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra">On Sun, Jun 15, 2014 at 9:1=
2 AM, Jeremy Maitin-Shepard <span dir=3D"ltr">&lt;<a href=3D"mailto:jeremy@=
jeremyms.com" target=3D"_blank">jeremy@jeremyms.com</a>&gt;</span> wrote:<b=
r><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"><div class=3D"">On Sun, Jun=
 15, 2014 at 1:40 AM, Andrew Tomazos <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@gmail.com</a>&gt=
;</span> wrote:<br>
</div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D""=
>
<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"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div>You&#39;re saying you want a function with =
one named parameter (x) of type int to be convertible to a function with on=
e positional parameter (1st) of type int, as they are &quot;compatible&quot=
; in a natural way. =C2=A0I see positional and named parameters as similar =
but distinct things.</div>

</div></div></div></blockquote></div><div>The implicit conversion is likely=
 to be useful and unlikely to do anything unexpected or cause any harm.=C2=
=A0 However, if it required an explicit conversion that would be okay.<br><=
/div>
<div class=3D""><div>
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"g=
mail_extra"><div class=3D"gmail_quote"><div>To me it&#39;s like saying you =
want int[1], std::tuple&lt;int&gt; and struct { int x; } to be convertible =
because they all have exactly one subobject of type int:</div>


<div><br></div><div>=C2=A0 =C2=A0 struct { int x; } A;</div><div>=C2=A0 =C2=
=A0 int B[1] =3D A; // sure :)</div><div>=C2=A0 =C2=A0 std::tuple&lt;int&gt=
; C =3D B; // why not? :)</div></div></div></div></blockquote><div><br></di=
v></div><div>Clearly we don&#39;t want them to be implicitly convertible, b=
ut in fact I would say that they should be safely convertible using reinter=
pret_cast if the types are all POD-like (I say POD-like because we should a=
lso relax some of the POD requirements, but that is a separate matter).=C2=
=A0 std::tuple should be required to have a layout identical to a struct wi=
th members in the specified order.=C2=A0 Unfortunately some implementations=
 accidentally? have a reverse layout due to the recursive implementation us=
ed, but I think that is worth prohibiting even if it breaks ABIs.=C2=A0 Wou=
ld this prevent too many optimization possibilities due to aliasing issues?=
=C2=A0 This is all a tangent, though.<br>

</div></div><br></div></div>
</blockquote></div>I really should have said standard layout, and the relax=
ation I&#39;m thinking of is to allow base classes with non-static data mem=
bers.<br></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--047d7b62494e6eb46304fbe2418c--

.

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

On Sun, Jun 15, 2014 at 6:17 PM, David Krauss <potswa@gmail.com> wrote:

> What is the latest status of designated initializers, taken alone? My
> recollection is that it's among a number of C features that hasn't been
> "ported" due to lack of interest.
>

Daryle Walker has a draft proposal posted here:

http://htmlpreview.github.io/?https://raw.github.com/CTMacUser/multiarray-iso-proposal/master/designation-proposal.html

Not sure if he put in into a mailing.

--

---
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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Jun 15, 2014 at 6:17 PM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"=
mailto:potswa@gmail.com" target=3D"_blank">potswa@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"><div class=3D"">What is the latest status of designated in=
itializers, taken alone? My recollection is that it&#39;s among a number of=
 C features that hasn&#39;t been &quot;ported&quot; due to lack of interest=
..<br>
</div>
<div class=3D""><div class=3D"h5"></div></div></blockquote></div><br></div>=
<div class=3D"gmail_extra">Daryle Walker has a draft proposal posted here:<=
/div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><a hre=
f=3D"http://htmlpreview.github.io/?https://raw.github.com/CTMacUser/multiar=
ray-iso-proposal/master/designation-proposal.html">http://htmlpreview.githu=
b.io/?https://raw.github.com/CTMacUser/multiarray-iso-proposal/master/desig=
nation-proposal.html</a><br>
</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Not s=
ure if he put in into a mailing.</div><div class=3D"gmail_extra"><br></div>=
</div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--20cf30363b4bb4463b04fbe25ec2--

.

On 15 June 2014 18:17, Thiago Macieira <thiago@macieira.org> wrote:
> Em s=C3=A1b 14 jun 2014, =C3=A0s 20:51:26, Jeremy Maitin-Shepard escreveu=
:
>> Do we allow overloading based only on named parameter names, e.g.:
>>
>> void f(int: a); // 1
>> void f(int: b); // 2
>
> IMHO, no, they are the same.
>
> Named parameters are simply a way for the compiler to reorder the named
> parameters into the positional order that the function expects. From that
> point on, the call should proceed exactly as positional calls do.


Strongly agreed. In fact, VERY strongly. Having overloading on parameter
names is not something I expect to support. I expect to do quite the opposi=
te,
if need be.

--=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/.

.

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

On Sun, Jun 15, 2014 at 10:02 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 15 June 2014 18:17, Thiago Macieira <thiago@macieira.org> wrote:
> > Em s=C3=A1b 14 jun 2014, =C3=A0s 20:51:26, Jeremy Maitin-Shepard escrev=
eu:
> >> Do we allow overloading based only on named parameter names, e.g.:
> >>
> >> void f(int: a); // 1
> >> void f(int: b); // 2
> >
> > IMHO, no, they are the same.
> >
> > Named parameters are simply a way for the compiler to reorder the named
> > parameters into the positional order that the function expects. From th=
at
> > point on, the call should proceed exactly as positional calls do.
>
>
> Strongly agreed. In fact, VERY strongly. Having overloading on parameter
> names is not something I expect to support. I expect to do quite the
> opposite,
> if need be.
>
> Certainly if the declaration syntax doesn't change, then it would be a
terrible idea.  If it does, then I don't see the harm.  You could still
allow specifying named arguments by position, but if there are multiple
matching functions it would simply be an ambiguity.

--=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/.

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

<div dir=3D"ltr">On Sun, Jun 15, 2014 at 10:02 AM, Ville Voutilainen <span =
dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_b=
lank">ville.voutilainen@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gm=
ail_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 class=3D"">O=
n 15 June 2014 18:17, Thiago Macieira &lt;<a href=3D"mailto:thiago@macieira=
..org">thiago@macieira.org</a>&gt; wrote:<br>

&gt; Em s=C3=A1b 14 jun 2014, =C3=A0s 20:51:26, Jeremy Maitin-Shepard escre=
veu:<br>
&gt;&gt; Do we allow overloading based only on named parameter names, e.g.:=
<br>
&gt;&gt;<br>
&gt;&gt; void f(int: a); // 1<br>
&gt;&gt; void f(int: b); // 2<br>
&gt;<br>
&gt; IMHO, no, they are the same.<br>
&gt;<br>
&gt; Named parameters are simply a way for the compiler to reorder the name=
d<br>
&gt; parameters into the positional order that the function expects. From t=
hat<br>
&gt; point on, the call should proceed exactly as positional calls do.<br>
<br>
<br>
</div>Strongly agreed. In fact, VERY strongly. Having overloading on parame=
ter<br>
names is not something I expect to support. I expect to do quite the opposi=
te,<br>
if need be.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote></div>=
Certainly if the declaration syntax doesn&#39;t change, then it would be a =
terrible idea.=C2=A0 If it does, then I don&#39;t see the harm.=C2=A0 You c=
ould still allow specifying named arguments by position, but if there are m=
ultiple matching functions it would simply be an ambiguity.<br>
</div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--047d7bd91754e6b28a04fbe35b48--

.

------=_Part_255_27438658.1402864449568
Content-Type: text/plain; charset=UTF-8

(I meant to send this reply earlier today but accidentally sent it to
another list.)

On Saturday, June 14, 2014 2:21:36 PM UTC-4, botond...@gmail.com wrote:
>
> A colleague and I have been working on a proposal to add named arguments
> to C++.
>
> The proposal draft can be found here:
> http://ehsan.github.io/namedargs/namedargs.html
>
> Any feedback on it is appreciated!
>

Wow, there have been a lot of responses to this in the time it took me to
get from Toronto to Rapperswil for the upcoming committee meeting :)

A lot of the responses talk about the necessity of changing the ABI and/or
the type system to accommodate named arguments.

Rather than responding to each one individually, let me just clarify that
our proposal does *not* involve changing either the ABI or the type system.
That would be a much bigger language change than we had in mind, and I
don't believe it's necessary, as we got named arguments to work without it,
by having the compiler look, for each call site, at the names used in the
(first) declaration of the function in that translation unit.

The problem of different declarations providing different names for
parameters is solved as follows:

If declarations in different translation units provide different names,
there is no problem. Call sites in each translation unit go by the names
used in the declaration in that translation unit. We do not propose making
this an ODR violation, as the behaviour can be well-defined.

If declarations in the same translation unit provide different names, then
call sites in that translation unit are not allowed to use named arguments.
The definition is excepted (and the parameter names used in it ignored),
unless it's also the first declaration.

(This is all explained in the proposal, by the way, with examples.)

I'll respond individually to some of the other points.

Thanks,
Botond

--

---
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_255_27438658.1402864449568
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">(I meant to send this reply earlier today but accidentally=
 sent it to another list.)<br><br>On Saturday, June 14, 2014 2:21:36 PM UTC=
-4, botond...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr">A colleague and I have been working on a proposal to add n=
amed arguments to C++.<br><br>The proposal draft can be found here: <a href=
=3D"http://ehsan.github.io/namedargs/namedargs.html" target=3D"_blank" onmo=
usedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fehsan.gi=
thub.io%2Fnamedargs%2Fnamedargs.html\46sa\75D\46sntz\0751\46usg\75AFQjCNFl7=
9uriDHY6hDhx4akmXCF4lTgcw';return true;" onclick=3D"this.href=3D'http://www=
..google.com/url?q\75http%3A%2F%2Fehsan.github.io%2Fnamedargs%2Fnamedargs.ht=
ml\46sa\75D\46sntz\0751\46usg\75AFQjCNFl79uriDHY6hDhx4akmXCF4lTgcw';return =
true;">http://ehsan.github.io/<wbr>namedargs/namedargs.html</a><br><br>Any =
feedback on it is appreciated!<br></div></blockquote><div><br><div id=3D"yi=
v2261253940yui_3_16_0_8_1402823648114_4"><span id=3D"yiv2261253940yui_3_16_=
0_8_1402823648114_12">Wow,
 there have been a lot of responses to this in the time it took me to=20
get from Toronto to Rapperswil for the upcoming committee meeting :)</span>=
</div><div id=3D"yiv2261253940yui_3_16_0_8_1402823648114_14" style=3D"color=
:rgb(0, 0, 0);font-size:16px;font-family:HelveticaNeue, Helvetica Neue, Hel=
vetica, Arial, Lucida Grande, sans-serif;background-color:transparent;font-=
style:normal;"><br clear=3D"none"><span id=3D"yiv2261253940yui_3_16_0_8_140=
2823648114_12"></span></div><div id=3D"yiv2261253940yui_3_16_0_8_1402823648=
114_17" style=3D"color:rgb(0, 0, 0);font-size:16px;font-family:HelveticaNeu=
e, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;background-c=
olor:transparent;font-style:normal;"><span id=3D"yiv2261253940yui_3_16_0_8_=
1402823648114_12">A lot of the responses talk
 about the necessity of changing the ABI and/or the type system to accommod=
ate named arguments. <br id=3D"yiv2261253940yui_3_16_0_8_1402823648114_33" =
clear=3D"none"></span></div><div id=3D"yiv2261253940yui_3_16_0_8_1402823648=
114_29" style=3D"color:rgb(0, 0, 0);font-size:16px;font-family:HelveticaNeu=
e, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;background-c=
olor:transparent;font-style:normal;"><span id=3D"yiv2261253940yui_3_16_0_8_=
1402823648114_12"><br id=3D"yiv2261253940yui_3_16_0_8_1402823648114_38" cle=
ar=3D"none"></span></div><div id=3D"yiv2261253940yui_3_16_0_8_1402823648114=
_34" style=3D"color:rgb(0, 0, 0);font-size:16px;font-family:HelveticaNeue, =
Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;background-colo=
r:transparent;font-style:normal;"><span id=3D"yiv2261253940yui_3_16_0_8_140=
2823648114_12">Rather
 than responding to each one individually, let me just clarify that our=20
proposal does *not* involve changing either the ABI or the type system.
 That would be a much bigger language change than we had in mind, and I=20
don't believe it's
 necessary, as we got named arguments to work without it, by having the=20
compiler look, for each call site, at the names used in the (first)=20
declaration of the function in that translation unit.</span></div><div id=
=3D"yiv2261253940yui_3_16_0_8_1402823648114_46" style=3D"color:rgb(0, 0, 0)=
;font-size:16px;font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial=
, Lucida Grande, sans-serif;background-color:transparent;font-style:normal;=
"><br clear=3D"none"><span id=3D"yiv2261253940yui_3_16_0_8_1402823648114_12=
"></span></div><div id=3D"yiv2261253940yui_3_16_0_8_1402823648114_49" style=
=3D"color:rgb(0, 0, 0);font-size:16px;font-family:HelveticaNeue, Helvetica =
Neue, Helvetica, Arial, Lucida Grande, sans-serif;background-color:transpar=
ent;font-style:normal;"><span id=3D"yiv2261253940yui_3_16_0_8_1402823648114=
_12">The problem of different declarations providing different names for pa=
rameters is solved as follows:</span></div><div id=3D"yiv2261253940yui_3_16=
_0_8_1402823648114_53" style=3D"color:rgb(0, 0, 0);font-size:16px;font-fami=
ly:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-ser=
if;background-color:transparent;font-style:normal;"><br clear=3D"none"><spa=
n id=3D"yiv2261253940yui_3_16_0_8_1402823648114_12"></span></div><span id=
=3D"yiv2261253940yui_3_16_0_8_1402823648114_12">If declarations in differen=
t </span>translation
 units provide different names, there is no problem. Call sites in each=20
translation unit go by the names used in the declaration in that=20
translation unit. We do not propose making this an ODR violation, as the
 behaviour can be well-defined.<br clear=3D"none"><br clear=3D"none">If=20
declarations in the same translation unit provide different names, then=20
call sites in that translation unit are not allowed to use named=20
arguments. The definition is excepted (and the parameter names used in=20
it
 ignored), unless it's also the first declaration.<br clear=3D"none"><br cl=
ear=3D"none">(This is all explained in the proposal, by the way, with examp=
les.)<br clear=3D"none"><br clear=3D"none">I'll respond individually to som=
e of the other points.<br clear=3D"none"><br clear=3D"none">Thanks,<br clea=
r=3D"none">Botond <br></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_255_27438658.1402864449568--

.

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

Hi, I might be too late but one thing I was wondering when reading the
document and this discussion is:
does the rules you propose implicitely suggests a specific behaviour in the
case of having overloads with _unnamed_ arguments?
If I take this example:

void foo(int a, char b, std::string c); void foo(int a, char b, std::string
x); void bar(int a, char b); void bar(int x, char b); void test() { foo(1,
'c', "s"); // valid foo(1, 'c', c: "s"); // invalid -- different names for
an argument in multiple declarations foo(1, 'c', x: "s"); // invalid --
different names for an argument in multiple declarations bar(1, b: 'c'); //
invalid -- different names for an argument in multiple declarations }

It is not 100% clear to me what is supposed to happen in this variant:

void foo(int a, char b, std::string c); void foo(int , char , std::string
); void bar(int a, char b); void bar(int , char ); void test() { foo(1,
'c', "s"); // valid foo(1, 'c', c: "s"); // invalid? foo(1, 'c', x: "s");
// invalid -- different names for an argument in multiple declarations
bar(1, b: 'c'); // invalid? }

In any way I think it would be a big win for clarity at call site if such
feature was provided.
I'm surprised that only C# and List have been mentionned so far (but I
might have skipped some info), Python seems to me
to be the language with the most versatile (and complex) function argument
features so it might be
a good idea to look at issues with it too, even if C# is certainly the best
reference for such a change.






On Sun, Jun 15, 2014 at 10:34 PM, <botond.ballo@gmail.com> wrote:

> (I meant to send this reply earlier today but accidentally sent it to
> another list.)
>
>
> On Saturday, June 14, 2014 2:21:36 PM UTC-4, botond...@gmail.com wrote:
>>
>> A colleague and I have been working on a proposal to add named arguments
>> to C++.
>>
>> The proposal draft can be found here: http://ehsan.github.io/
>> namedargs/namedargs.html
>>
>> Any feedback on it is appreciated!
>>
>
> Wow, there have been a lot of responses to this in the time it took me to
> get from Toronto to Rapperswil for the upcoming committee meeting :)
>
> A lot of the responses talk about the necessity of changing the ABI and/or
> the type system to accommodate named arguments.
>
> Rather than responding to each one individually, let me just clarify that
> our proposal does *not* involve changing either the ABI or the type system.
> That would be a much bigger language change than we had in mind, and I
> don't believe it's necessary, as we got named arguments to work without it,
> by having the compiler look, for each call site, at the names used in the
> (first) declaration of the function in that translation unit.
>
> The problem of different declarations providing different names for
> parameters is solved as follows:
>
> If declarations in different translation units provide different names,
> there is no problem. Call sites in each translation unit go by the names
> used in the declaration in that translation unit. We do not propose making
> this an ODR violation, as the behaviour can be well-defined.
>
> If declarations in the same translation unit provide different names, then
> call sites in that translation unit are not allowed to use named arguments.
> The definition is excepted (and the parameter names used in it ignored),
> unless it's also the first declaration.
>
> (This is all explained in the proposal, by the way, with examples.)
>
> I'll respond individually to some of the other points.
>
> Thanks,
> Botond
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr">Hi, I might be too late but one thing I was wondering when=
 reading the document and this discussion is:<div>does the rules you propos=
e implicitely suggests a specific behaviour in the case of having overloads=
 with _unnamed_ arguments?</div>
<div>If I take this example:</div><div><br></div><div><span style=3D"color:=
rgb(0,0,0);font-family:monospace;font-size:medium;white-space:pre">   void =
foo(int a, char b, std::string c);
      void foo(int a, char b, std::string x);
      void bar(int a, char b);
      void bar(int x, char b);
      void test() {
          foo(1, &#39;c&#39;, &quot;s&quot;);     // valid
          foo(1, &#39;c&#39;, c: &quot;s&quot;);  // invalid -- different n=
ames for an argument in multiple declarations
          foo(1, &#39;c&#39;, x: &quot;s&quot;);  // invalid -- different n=
ames for an argument in multiple declarations
          bar(1, b: &#39;c&#39;);       // invalid -- different names for a=
n argument in multiple declarations
      }</span><br></div><div><span style=3D"color:rgb(0,0,0);font-family:mo=
nospace;font-size:medium;white-space:pre"><br></span></div>It is not 100% c=
lear to me what is supposed to happen in this variant:<div><br></div><div>
<div><span style=3D"color:rgb(0,0,0);font-family:monospace;font-size:medium=
;white-space:pre">   void foo(int a, char b, std::string c);
      void foo(int , char , std::string );
      void bar(int a, char b);
      void bar(int , char );
      void test() {
          foo(1, &#39;c&#39;, &quot;s&quot;);     // valid
          foo(1, &#39;c&#39;, c: &quot;s&quot;);  // invalid?=20
          foo(1, &#39;c&#39;, x: &quot;s&quot;);  // invalid -- different n=
ames for an argument in multiple declarations
          bar(1, b: &#39;c&#39;);       // invalid?
      }</span><br></div><div><span style=3D"color:rgb(0,0,0);font-family:mo=
nospace;font-size:medium;white-space:pre"><br></span></div>In any way I thi=
nk it would be a big win for clarity at call site if such feature was provi=
ded.</div>
<div>I&#39;m surprised that only C# and List have been mentionned so far (b=
ut I might have skipped some info), Python seems to me</div><div>to be the =
language with the most versatile (and complex) function argument features s=
o it might be=C2=A0</div>
<div>a good idea to look at issues with it too, even if C# is certainly the=
 best reference for such a change.</div><div><br></div><div><br></div><div>=
<div><br></div><div><br></div></div></div><div class=3D"gmail_extra"><br>
<br><div class=3D"gmail_quote">On Sun, Jun 15, 2014 at 10:34 PM,  <span dir=
=3D"ltr">&lt;<a href=3D"mailto:botond.ballo@gmail.com" target=3D"_blank">bo=
tond.ballo@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
<div dir=3D"ltr">(I meant to send this reply earlier today but accidentally=
 sent it to another list.)<div class=3D""><br><br>On Saturday, June 14, 201=
4 2:21:36 PM UTC-4, <a href=3D"mailto:botond...@gmail.com" target=3D"_blank=
">botond...@gmail.com</a> 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">A colleague and I have been working on a proposal to add n=
amed arguments to C++.<br><br>The proposal draft can be found here: <a href=
=3D"http://ehsan.github.io/namedargs/namedargs.html" target=3D"_blank">http=
://ehsan.github.io/<u></u>namedargs/namedargs.html</a><br>
<br>Any feedback on it is appreciated!<br></div></blockquote></div><div><br=
><div><span>Wow,
 there have been a lot of responses to this in the time it took me to=20
get from Toronto to Rapperswil for the upcoming committee meeting :)</span>=
</div><div style=3D"color:rgb(0,0,0);font-size:16px;font-family:HelveticaNe=
ue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;background-color=
:transparent;font-style:normal">
<br clear=3D"none"><span></span></div><div style=3D"color:rgb(0,0,0);font-s=
ize:16px;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Gr=
ande,sans-serif;background-color:transparent;font-style:normal"><span>A lot=
 of the responses talk
 about the necessity of changing the ABI and/or the type system to accommod=
ate named arguments. <br clear=3D"none"></span></div><div style=3D"color:rg=
b(0,0,0);font-size:16px;font-family:HelveticaNeue,Helvetica Neue,Helvetica,=
Arial,Lucida Grande,sans-serif;background-color:transparent;font-style:norm=
al">
<span><br clear=3D"none"></span></div><div style=3D"color:rgb(0,0,0);font-s=
ize:16px;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Gr=
ande,sans-serif;background-color:transparent;font-style:normal"><span>Rathe=
r
 than responding to each one individually, let me just clarify that our=20
proposal does *not* involve changing either the ABI or the type system.
 That would be a much bigger language change than we had in mind, and I=20
don&#39;t believe it&#39;s
 necessary, as we got named arguments to work without it, by having the=20
compiler look, for each call site, at the names used in the (first)=20
declaration of the function in that translation unit.</span></div><div styl=
e=3D"color:rgb(0,0,0);font-size:16px;font-family:HelveticaNeue,Helvetica Ne=
ue,Helvetica,Arial,Lucida Grande,sans-serif;background-color:transparent;fo=
nt-style:normal">
<br clear=3D"none"><span></span></div><div style=3D"color:rgb(0,0,0);font-s=
ize:16px;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Gr=
ande,sans-serif;background-color:transparent;font-style:normal"><span>The p=
roblem of different declarations providing different names for parameters i=
s solved as follows:</span></div>
<div style=3D"color:rgb(0,0,0);font-size:16px;font-family:HelveticaNeue,Hel=
vetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;background-color:trans=
parent;font-style:normal"><br clear=3D"none"><span></span></div><span>If de=
clarations in different </span>translation
 units provide different names, there is no problem. Call sites in each=20
translation unit go by the names used in the declaration in that=20
translation unit. We do not propose making this an ODR violation, as the
 behaviour can be well-defined.<br clear=3D"none"><br clear=3D"none">If=20
declarations in the same translation unit provide different names, then=20
call sites in that translation unit are not allowed to use named=20
arguments. The definition is excepted (and the parameter names used in=20
it
 ignored), unless it&#39;s also the first declaration.<br clear=3D"none"><b=
r clear=3D"none">(This is all explained in the proposal, by the way, with e=
xamples.)<br clear=3D"none"><br clear=3D"none">I&#39;ll respond individuall=
y to some of the other points.<br clear=3D"none">
<br clear=3D"none">Thanks,<br clear=3D"none">Botond <br></div></div><div cl=
ass=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <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+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
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 />
<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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--089e013cba44cdd36104fbf7b299--

.

> It is not 100% clear to me what is supposed to happen in this variant:

>
>
> void foo(int a, char b, std::string c);=20

> void foo(int , char , std::string );=20

> void bar(int a, char b);=20

> void bar(int , char );=20

> void test() {=20

>=A0=A0 foo(1, 'c', "s");=A0=A0=A0=A0 // valid=20

>=A0=A0 foo(1, 'c', c: "s");=A0=A0// invalid?=A0=20

>=A0=A0 foo(1, 'c', x: "s");=A0=A0// invalid -- different names for an argu=
ment in multiple declarations=20

>=A0=A0 bar(1, b: 'c');=A0=A0=A0=A0=A0=A0 // invalid?=20

> }


They would be invalid in our proposal by the rule that says
"assuming that parameter N is the last to not have a name=20

(nor a default argument), all well-formed calls to that=20

function must provide at least N positional arguments".

However, it might make sense to make an exception for
declarations where *all* the arguments are unnamed, and
just ignore those declarations (assuming another
declaration that provides names is present).

Thanks,
Botond

--=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/.

.

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

On Mon, Jun 16, 2014 at 8:07 PM, 'Botond Ballo' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> They would be invalid in our proposal by the rule that says
> "assuming that parameter N is the last to not have a name
>
> (nor a default argument), all well-formed calls to that
>
> function must provide at least N positional arguments".
>
> However, it might make sense to make an exception for
> declarations where *all* the arguments are unnamed, and
> just ignore those declarations (assuming another
> declaration that provides names is present).
>

I don't know if adding that would help but at least a clarifying example
for this specific case might be good for the proposal (even if it's indeed
apparently covered by the rules).

--

---
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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Mon, Jun 16, 2014 at 8:07 PM, &#39;Botond Ballo&#39; via ISO C++ Standar=
d - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@=
isocpp.org" target=3D"_blank">std-proposals@isocpp.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 id=3D":35h" class=3D"a3s" style=3D"over=
flow:hidden">They would be invalid in our proposal by the rule that says<br=
>
&quot;assuming that parameter N is the last to not have a name<br>
<br>
(nor a default argument), all well-formed calls to that<br>
<br>
function must provide at least N positional arguments&quot;.<br>
<br>
However, it might make sense to make an exception for<br>
declarations where *all* the arguments are unnamed, and<br>
just ignore those declarations (assuming another<br>
declaration that provides names is present).</div></blockquote></div><br>I =
don&#39;t know if adding that would help but at least a clarifying example =
for this specific case might be good for the proposal (even if it&#39;s ind=
eed apparently covered by the rules).</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><=
/div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--001a11c1d9aa0a93b704fbf7f25c--

.