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

I'm working on a paper to write this up more formally, but before I do
that, I wanted to share my research and work and generate some discussion.

Currently, it is possible to pass parameters by position, but not by name.
To work around this limitation, there are a multitude of solutions. A few
are listed here:

   - The "Named Parameters Idiom," sometimes called the Builder Pattern.
   - Boost Parameters
   <https://www.boost.org/doc/libs/1_68_0/libs/parameter/doc/html/index.html>.
   Overloads operator= to make it look like a named parameter.
   - Boost Graph's named parameters. Parameter values are passed via member
   functions.
   - Strong types. This suffers from the limitation that parameters cannot
   be reordered, and sometimes you'd have to create types that otherwise have
   no meaning.
   - Designated Initializers. There are those who hope that designated
   initializers will work as named parameters, but they don't work that well.

Each of these have disadvantages. Here's a small list:

   - Hard to maintain.
   - Have to prefix every argument with the library's namespace, or else
   use a lot of using declarations or even a using directive.
   - Each argument has to be passed in order (Strong types), otherwise it's
   a ton of overloads for the library author to work out.
   - Possibly worse code-gen

I claim we should standardize a way of passing named arguments in C++.



Use cases for Named Parameters (aka Named Arguments, aka Keyword Arguments):

   - Named-or-positional parameters.
   - Name-only parameters
   - Either of the above combined with default arguments



Syntax: there are two possible syntaxes I've seen that work for named
parameters in C++:

foo(.name = value)
foo(name: value)

I honestly don't care which we go for, but for consistency with designated
initializers (which may be a bad thing if the behavior is significantly
different), I'm going to choose the foo(.name = value) syntax for the time
being.

For declaring a function with named parameters, it is imperative that it is
opt-in, otherwise, functions parameter names become part of the public API
of the function, which is undesirable:

int foo(int .x);

It might be tempting to separate the name of the parameter from the name
used in named parameters, but I claim this overly repetitive. As long as
named parameters are opt-in, having to give an alternative name is
completely redundant. (I believe Swift does this)

There should be some way to specify that the parameter is name-only. For
example, altering Python's implementation
<https://www.python.org/dev/peps/pep-3102/>:

// anything after the . is name-only
int foo(., int .x);

Default arguments should be able to work as they are now.



Semantics:
It's a pretty standard rule that all named arguments must come after all
positional arguments. It is also pretty standard that named arguments can
be in a different order than in the function declaration. I don't see a
compelling reason to break from this, even though there are exceptions in
languages today (e.g. C# and Swift)

There are some options on how the named parameters should work. It could work
like C# and just reorder the arguments
<https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/named-and-optional-arguments#overload-resolution>.
However, I believe that the name should be part of the function type and
should be mangled into the name for the function. It should not be allowed
for the following two declarations to coexist:

int foo(int .x, int .y);
int foo(int .a, int .b);

If the name of the parameters are not part of the function, then if those
declarations are in separate translation units, there's little way to
enforce that this should fail to compile / link.

This does bring in the issue that it becomes harder to change existing APIs
to accept named parameters in an ABI compatible manner. For this, maybe the
compiler could emit two symbols for the named-positional argument case?
Otherwise, I think there should be some way to either cause the compiler to
emit two symbols or otherwise maintain ABI compatibility.

Now for templates. In order to have higher-order functions which work on
named parameters, I believe it is necessary to have a new kind of template
parameter, something like this:

// I separated the name completely from the type.
// This would severely complicate generic code, however, so maybe there's
// a way to keep both together
template <typename F, .typename Name, typename Arg>
void call(F fn, Arg&& .Name arg) {
    // Some syntax to expand the name is needed. I'm not sure what
    // a reasonable choice is. There should also probably be a way
    // to generate a name from a compile time string.
    fn(.(Name) = std::forward<Arg>(arg));
}

// Or maybe something combining the name and type would be better:
template <typename F, .typename Kwarg>
void call(F fn, Kwarg&& arg) {
    fn(.(nameof(Kwarg)) = std::forward<Kwarg>(arg));
}

// Valid ways to call it:
call(sqrt, .x = 9);
call(sqrt, 9); // We didn't enforce name-only in the declaration of call

Reflection could possibly allow us to inspect the actual name supplied
(useful for libraries such as fmt: fmt::format("({x}, {y})", .x = 10, .y =
20); ), and it would probably be useful to be able to generate a name from
a compile-time string.

How lookup is performed: it's certainly possible to have overloaded
functions along with named parameters. I haven't spent the time yet to
flesh out all the details, but the named parameters can be each in their
own dimension, as compared to the positional dimension.



Further ideas: I don't want to propose this yet, but I would also like to
see named parameters in template parameters. For example, it would be nice
to be easily able to specify the allocator of an unordered_map:
std::unordered_map<Key,
Value, .allocator = MyAllocator> . I believe this would break ABI
compatibility, though.



Implementation:
It sounds crazy to add a new kind of template parameter and include the
name of the parameters as part of the function type, but I believe this
would be implementable with some kind of __name<"parameter_name"> type with
some connection to the regular template type, as well as some rules on
reordering (consider something like sorting all name-only parameters
lexicographically and re-mapping named-positional parameters to their
position). I won't know for sure until I attempt an implementation, but I
believe it should work.



References - some things I've found about named parameter design, which I
may have referred to in my writeup above. Most of these I didn't link to
inline:

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

https://internals.rust-lang.org/t/pre-rfc-named-arguments/3831

https://internals.rust-lang.org/t/pre-rfc-named-arguments/3831/196

https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/named-and-optional-arguments#overload-resolution

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4172.htm

http://jamboree.github.io/designator-draft.html

https://www.reddit.com/r/cpp/comments/5mdes5/what_happened_to_the_named_parameter_proposal/

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

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

<div dir=3D"ltr"><div>I&#39;m working on a paper to write this up more form=
ally, but before I do that, I wanted to share my research and work and gene=
rate some discussion.</div><div><br></div><div>Currently, it is possible to=
 pass parameters by position, but not by name. To work around this limitati=
on, there are a multitude of solutions. A few are listed here:</div><div><u=
l><li>The &quot;Named Parameters Idiom,&quot; sometimes called the Builder =
Pattern.</li><li><a href=3D"https://www.boost.org/doc/libs/1_68_0/libs/para=
meter/doc/html/index.html" target=3D"_blank">Boost Parameters</a>. Overload=
s <font face=3D"monospace, monospace">operator=3D</font> to make it look li=
ke a named parameter.</li><li>Boost Graph&#39;s named parameters. Parameter=
 values are passed via member functions.</li><li>Strong types. This suffers=
 from the limitation that parameters cannot be reordered, and sometimes you=
&#39;d have to create types that otherwise have no meaning.</li><li>Designa=
ted Initializers. There are those who hope that designated initializers wil=
l work as named parameters, but they don&#39;t work that well.</li></ul><di=
v>Each of these have disadvantages. Here&#39;s a small list:</div></div><di=
v><ul><li>Hard to maintain.</li><li>Have to prefix every argument with the =
library&#39;s namespace, or else use a lot of using declarations or even a =
using directive.</li><li>Each argument has to be passed in order (Strong ty=
pes), otherwise it&#39;s a ton of overloads for the library author to work =
out.</li><li>Possibly worse code-gen</li></ul></div><div>I claim we should =
standardize a way of passing named arguments in C++.</div><div><br></div><d=
iv><br></div><div><br></div><div>Use cases for Named Parameters (aka Named =
Arguments, aka Keyword Arguments):</div><div><ul><li>Named-or-positional pa=
rameters.</li><li>Name-only parameters</li><li>Either of the above combined=
 with default arguments</li></ul><div><br></div><div><br></div><div>Syntax:=
 there are two possible syntaxes I&#39;ve seen that work for named paramete=
rs in C++:</div></div><div><br></div><div><font face=3D"monospace, monospac=
e">foo(.name =3D value)</font></div><div><font face=3D"monospace, monospace=
">foo(name: value)</font></div><div><br></div><div>I honestly don&#39;t car=
e which we go for, but for consistency with designated initializers (which =
may be a bad thing if the behavior is significantly different), I&#39;m goi=
ng to choose the <font face=3D"monospace, monospace">foo(.name =3D value)</=
font> syntax for the time being.</div><div><br></div><div>For declaring a f=
unction with named parameters, it is imperative that it is opt-in, otherwis=
e, functions parameter names become part of the public API of the function,=
 which is undesirable:</div><div><br></div><div><font face=3D"monospace, mo=
nospace">int foo(int .x);</font></div><div><br></div><div>It might be tempt=
ing to separate the name of the parameter from the name used in named param=
eters, but I claim this overly repetitive. As long as named parameters are =
opt-in, having to give an alternative name is completely redundant. (I beli=
eve Swift does this)</div><div><br></div><div>There should be some way to s=
pecify that the parameter is name-only. For example, altering <a href=3D"ht=
tps://www.python.org/dev/peps/pep-3102/" target=3D"_blank">Python&#39;s imp=
lementation</a>:</div><div><br></div><div><font face=3D"monospace, monospac=
e">// anything after the . is name-only</font></div><div><font face=3D"mono=
space, monospace">int foo(., int .x);</font></div><div><br></div><div>Defau=
lt arguments should be able to work as they are now.</div><div><br></div><d=
iv><br></div><div><br></div><div>Semantics:</div><div>It&#39;s a pretty sta=
ndard rule that all named arguments must come after all positional argument=
s. It is also pretty standard that named arguments can be in a different or=
der than in the function declaration. I don&#39;t see a compelling reason t=
o break from this, even though there are exceptions in languages today (e.g=
.. C# and Swift)</div><div><br></div><div>There are some options on how the =
named parameters should work. It could <a href=3D"https://docs.microsoft.co=
m/en-us/dotnet/csharp/programming-guide/classes-and-structs/named-and-optio=
nal-arguments#overload-resolution" target=3D"_blank">work like C# and just =
reorder the arguments</a>. However, I believe that the name should be part =
of the function type and should be mangled into the name for the function. =
It should not be allowed for the following two declarations to coexist:</di=
v><div><br></div><div><font face=3D"monospace, monospace">int foo(int .x, i=
nt .y);</font></div><div><font face=3D"monospace, monospace">int foo(int .a=
, int .b);</font></div><div><br></div><div>If the name of the parameters ar=
e not part of the function, then if those declarations are in separate tran=
slation units, there&#39;s little way to enforce that this should fail to c=
ompile / link.</div><div><br></div><div>This does bring in the issue that i=
t becomes harder to change existing APIs to accept named parameters in an A=
BI compatible manner. For this, maybe the compiler could emit two symbols f=
or the named-positional argument case? Otherwise, I think there should be s=
ome way to either cause the compiler to emit two symbols or otherwise maint=
ain ABI compatibility.</div><div><br></div><div>Now for templates. In order=
 to have higher-order functions which work on named parameters, I believe i=
t is necessary to have a new kind of template parameter, something like thi=
s:</div><div><br></div><div><font face=3D"monospace, monospace">// I separa=
ted the name completely from the type.</font></div><div><font face=3D"monos=
pace, monospace">// This would severely complicate generic code, however, s=
o maybe there&#39;s</font></div><div><font face=3D"monospace, monospace">//=
 a way to keep both together</font></div><div><font face=3D"monospace, mono=
space">template &lt;typename F, .typename Name, typename Arg&gt;</font></di=
v><div><font face=3D"monospace, monospace">void call(F fn, Arg&amp;&amp; .N=
ame arg) {</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=
=A0=C2=A0</font><span style=3D"font-family:monospace,monospace">// Some syn=
tax to expand the name is needed. I&#39;m not sure what</span></div><div><s=
pan style=3D"font-family:monospace,monospace">=C2=A0 =C2=A0 // a reasonable=
 choice is. There should also probably be a way</span></div><div><span styl=
e=3D"font-family:monospace,monospace">=C2=A0 =C2=A0 // to generate a name f=
rom a compile time string.</span></div><div><font face=3D"monospace, monosp=
ace">=C2=A0 =C2=A0 fn(.(Name) =3D std::forward&lt;Arg&gt;(arg));</font></di=
v><div><font face=3D"monospace, monospace">}</font></div><div><font face=3D=
"monospace, monospace"><br></font></div><div><font face=3D"monospace, monos=
pace">// Or maybe something combining the name and type would be better:</f=
ont></div><div><font face=3D"monospace, monospace">template &lt;typename F,=
 .typename Kwarg&gt;</font></div><div><font face=3D"monospace, monospace">v=
oid call(F fn, Kwarg&amp;&amp; arg) {</font></div><div><font face=3D"monosp=
ace, monospace">=C2=A0 =C2=A0 fn(.(nameof(Kwarg)) =3D std::forward&lt;Kwarg=
&gt;(arg));</font></div><div><font face=3D"monospace, monospace">}</font></=
div><div><font face=3D"monospace, monospace"><br></font></div><div><font fa=
ce=3D"monospace, monospace">// Valid ways to call it:</font></div><div><fon=
t face=3D"monospace, monospace">call(sqrt, .x =3D 9);</font></div><div><fon=
t face=3D"monospace, monospace">call(sqrt, 9); // We didn&#39;t enforce nam=
e-only in the declaration of call</font></div><div><br></div><div>Reflectio=
n could possibly allow us to inspect the actual name supplied (useful for l=
ibraries such as fmt: <font face=3D"monospace, monospace">fmt::format(&quot=
;({x}, {y})&quot;, .x =3D 10, .y =3D 20);</font> ), and it would probably b=
e useful to be able to generate a name from a compile-time string.</div><di=
v><br></div><div>How lookup is performed: it&#39;s certainly possible to ha=
ve overloaded functions along with named parameters. I haven&#39;t spent th=
e time yet to flesh out all the details, but the named parameters can be ea=
ch in their own dimension, as compared to the positional dimension.</div><d=
iv><br></div><div><br></div><div><br></div><div>Further ideas: I don&#39;t =
want to propose this yet, but I would also like to see named parameters in =
template parameters. For example, it would be nice to be easily able to spe=
cify the allocator of an unordered_map: <font face=3D"monospace, monospace"=
>std::unordered_map&lt;Key, Value, .allocator =3D MyAllocator&gt;</font><fo=
nt face=3D"arial, helvetica, sans-serif">=C2=A0. I believe this would break=
 ABI compatibility, though.</font></div><div><br></div><div><br></div><div>=
<br></div><div>Implementation:</div><div>It sounds crazy to add a new kind =
of template parameter and include the name of the parameters as part of the=
 function type, but I believe this would be implementable with some kind of=
 <font face=3D"monospace, monospace">__name&lt;&quot;parameter_name&quot;&g=
t;</font> type with some connection to the regular template type, as well a=
s some rules on reordering (consider something like sorting all name-only p=
arameters lexicographically and re-mapping named-positional parameters to t=
heir position). I won&#39;t know for sure until I attempt an implementation=
, but I believe it should work.</div><div><br></div><div><br></div><div><br=
></div>References - some things I&#39;ve found about named parameter design=
, which I may have referred to in my writeup above. Most of these I didn&#3=
9;t link to inline:<div><br></div><div><a href=3D"https://www.python.org/de=
v/peps/pep-3102/" target=3D"_blank">https://www.python.org/dev/peps/pep-310=
2/</a><br></div><div><br></div><div><a href=3D"https://internals.rust-lang.=
org/t/pre-rfc-named-arguments/3831" target=3D"_blank">https://internals.rus=
t-lang.org/t/pre-rfc-named-arguments/3831</a><br></div><div><br></div><div>=
<a href=3D"https://internals.rust-lang.org/t/pre-rfc-named-arguments/3831/1=
96" target=3D"_blank">https://internals.rust-lang.org/t/pre-rfc-named-argum=
ents/3831/196</a><br></div><div><br></div><div><a href=3D"https://docs.micr=
osoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/named-a=
nd-optional-arguments#overload-resolution" target=3D"_blank">https://docs.m=
icrosoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/name=
d-and-optional-arguments#overload-resolution</a><br></div><div><br></div><d=
iv><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4172=
..htm" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/=
2014/n4172.htm</a><br></div><div><br></div><div><a href=3D"http://jamboree.=
github.io/designator-draft.html" target=3D"_blank">http://jamboree.github.i=
o/designator-draft.html</a><br></div><div><br></div><div><a href=3D"https:/=
/www.reddit.com/r/cpp/comments/5mdes5/what_happened_to_the_named_parameter_=
proposal/" target=3D"_blank">https://www.reddit.com/r/cpp/comments/5mdes5/w=
hat_happened_to_the_named_parameter_proposal/</a><br></div></div>

<p></p>

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

--0000000000007a3c360573867702--

.

--0000000000000b6b8a0573871766
Content-Type: text/plain; charset="UTF-8"

>
> For declaring a function with named parameters, it is imperative that it
> is opt-in, otherwise, functions parameter names become part of the public
> API of the function, which is undesirable


Pardon my ignorance, but why exactly is this undesirable? Designated
initializer lists are also not opt-in. I don't really see a problem with
this. I can't imagine function parameters to change once they're the
function is part of the API.

There should be some way to specify that the parameter is name-only. For
> example, altering Python's implementation
> <https://www.python.org/dev/peps/pep-3102/>:
>
> // anything after the . is name-only
> int foo(., int .x);
>
> Default arguments should be able to work as they are now.
>

I disagree with your proposed solution. Name-only parameters naturally
appear when they are after a varadic ("catch-all") parameter, just like in
Python's implementation.

template <typename ...T>
void f(T ..., int name);

f(.name = 1); // name-only argument

Now you have a small problem: C's variadic parameters are specified in the
grammar itself to come last, which can be changed but would require some
restructuring. But I don't think it's worth supporting them.

However, I believe that the name should be part of the function type and
> should be mangled into the name for the function. It should not be allowed
> for the following two declarations to coexist:
>
> int foo(int .x, int .y);
> int foo(int .a, int .b);
>
> If the name of the parameters are not part of the function, then if those
> declarations are in separate translation units, there's little way to
> enforce that this should fail to compile / link.
>

Any reasons to disallow this? I mean, this is already possible:

void foo(int = 1);

void f() {
  void foo(int = 2);
  foo();
}

I'm not saying that this is good code, but the truth is that indeed there
is no way to enforce this requirement over multiple TUs for every single
case. There is the possibility of making this IF;NDR, but really, I don't
see why I shouldn't be able to rename parameters (coding/style guidelines?).


> Now for templates. In order to have higher-order functions which work on
> named parameters, I believe it is necessary to have a new kind of template
> parameter, something like this:
>

Oh I don't like this; it's too different if you know what I mean. What do
you think of saying that the named parameter is implicitly part of the
expansion if the expansion happens in a function parameter list?

template <typename ...Ts>
auto f(Ts ...Args) {                             // No change here.
  g(Args...);                                         // Same.
  return {Args...}[0];                          // Same.
}

f(1, 2); // ok: calls g(1, 2); returns 1
f(.Lhs = 1, .Rhs = 2); // ok; calls g(.Lhs = 1, .Rhs = 2); returns 1

For example, it would be nice to be easily able to specify the allocator of
> an unordered_map: std::unordered_map<Key, Value, .allocator = MyAllocator> .
> I believe this would break ABI compatibility, though.


How would this break ABI compatibility? The name of the function arguments
need to to be mangled (which is a non-issue for templates in any case).

On Wed, Aug 15, 2018 at 10:10 PM Justin Bassett <jbassett271@gmail.com>
wrote:

> I'm working on a paper to write this up more formally, but before I do
> that, I wanted to share my research and work and generate some discussion.
>
> Currently, it is possible to pass parameters by position, but not by name.
> To work around this limitation, there are a multitude of solutions. A few
> are listed here:
>
>    - The "Named Parameters Idiom," sometimes called the Builder Pattern.
>    - Boost Parameters
>    <https://www.boost.org/doc/libs/1_68_0/libs/parameter/doc/html/index.html>.
>    Overloads operator= to make it look like a named parameter.
>    - Boost Graph's named parameters. Parameter values are passed via
>    member functions.
>    - Strong types. This suffers from the limitation that parameters
>    cannot be reordered, and sometimes you'd have to create types that
>    otherwise have no meaning.
>    - Designated Initializers. There are those who hope that designated
>    initializers will work as named parameters, but they don't work that well.
>
> Each of these have disadvantages. Here's a small list:
>
>    - Hard to maintain.
>    - Have to prefix every argument with the library's namespace, or else
>    use a lot of using declarations or even a using directive.
>    - Each argument has to be passed in order (Strong types), otherwise
>    it's a ton of overloads for the library author to work out.
>    - Possibly worse code-gen
>
> I claim we should standardize a way of passing named arguments in C++.
>
>
>
> Use cases for Named Parameters (aka Named Arguments, aka Keyword
> Arguments):
>
>    - Named-or-positional parameters.
>    - Name-only parameters
>    - Either of the above combined with default arguments
>
>
>
> Syntax: there are two possible syntaxes I've seen that work for named
> parameters in C++:
>
> foo(.name = value)
> foo(name: value)
>
> I honestly don't care which we go for, but for consistency with designated
> initializers (which may be a bad thing if the behavior is significantly
> different), I'm going to choose the foo(.name = value) syntax for the
> time being.
>
> For declaring a function with named parameters, it is imperative that it
> is opt-in, otherwise, functions parameter names become part of the public
> API of the function, which is undesirable:
>
> int foo(int .x);
>
> It might be tempting to separate the name of the parameter from the name
> used in named parameters, but I claim this overly repetitive. As long as
> named parameters are opt-in, having to give an alternative name is
> completely redundant. (I believe Swift does this)
>
> There should be some way to specify that the parameter is name-only. For
> example, altering Python's implementation
> <https://www.python.org/dev/peps/pep-3102/>:
>
> // anything after the . is name-only
> int foo(., int .x);
>
> Default arguments should be able to work as they are now.
>
>
>
> Semantics:
> It's a pretty standard rule that all named arguments must come after all
> positional arguments. It is also pretty standard that named arguments can
> be in a different order than in the function declaration. I don't see a
> compelling reason to break from this, even though there are exceptions in
> languages today (e.g. C# and Swift)
>
> There are some options on how the named parameters should work. It could work
> like C# and just reorder the arguments
> <https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/named-and-optional-arguments#overload-resolution>.
> However, I believe that the name should be part of the function type and
> should be mangled into the name for the function. It should not be allowed
> for the following two declarations to coexist:
>
> int foo(int .x, int .y);
> int foo(int .a, int .b);
>
> If the name of the parameters are not part of the function, then if those
> declarations are in separate translation units, there's little way to
> enforce that this should fail to compile / link.
>
> This does bring in the issue that it becomes harder to change existing
> APIs to accept named parameters in an ABI compatible manner. For this,
> maybe the compiler could emit two symbols for the named-positional argument
> case? Otherwise, I think there should be some way to either cause the
> compiler to emit two symbols or otherwise maintain ABI compatibility.
>
> Now for templates. In order to have higher-order functions which work on
> named parameters, I believe it is necessary to have a new kind of template
> parameter, something like this:
>
> // I separated the name completely from the type.
> // This would severely complicate generic code, however, so maybe there's
> // a way to keep both together
> template <typename F, .typename Name, typename Arg>
> void call(F fn, Arg&& .Name arg) {
>     // Some syntax to expand the name is needed. I'm not sure what
>     // a reasonable choice is. There should also probably be a way
>     // to generate a name from a compile time string.
>     fn(.(Name) = std::forward<Arg>(arg));
> }
>
> // Or maybe something combining the name and type would be better:
> template <typename F, .typename Kwarg>
> void call(F fn, Kwarg&& arg) {
>     fn(.(nameof(Kwarg)) = std::forward<Kwarg>(arg));
> }
>
> // Valid ways to call it:
> call(sqrt, .x = 9);
> call(sqrt, 9); // We didn't enforce name-only in the declaration of call
>
> Reflection could possibly allow us to inspect the actual name supplied
> (useful for libraries such as fmt: fmt::format("({x}, {y})", .x = 10, .y
> = 20); ), and it would probably be useful to be able to generate a name
> from a compile-time string.
>
> How lookup is performed: it's certainly possible to have overloaded
> functions along with named parameters. I haven't spent the time yet to
> flesh out all the details, but the named parameters can be each in their
> own dimension, as compared to the positional dimension.
>
>
>
> Further ideas: I don't want to propose this yet, but I would also like to
> see named parameters in template parameters. For example, it would be nice
> to be easily able to specify the allocator of an unordered_map: std::unordered_map<Key,
> Value, .allocator = MyAllocator> . I believe this would break ABI
> compatibility, though.
>
>
>
> Implementation:
> It sounds crazy to add a new kind of template parameter and include the
> name of the parameters as part of the function type, but I believe this
> would be implementable with some kind of __name<"parameter_name"> type
> with some connection to the regular template type, as well as some rules on
> reordering (consider something like sorting all name-only parameters
> lexicographically and re-mapping named-positional parameters to their
> position). I won't know for sure until I attempt an implementation, but I
> believe it should work.
>
>
>
> References - some things I've found about named parameter design, which I
> may have referred to in my writeup above. Most of these I didn't link to
> inline:
>
> https://www.python.org/dev/peps/pep-3102/
>
> https://internals.rust-lang.org/t/pre-rfc-named-arguments/3831
>
> https://internals.rust-lang.org/t/pre-rfc-named-arguments/3831/196
>
>
> https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/named-and-optional-arguments#overload-resolution
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4172.htm
>
> http://jamboree.github.io/designator-draft.html
>
>
> https://www.reddit.com/r/cpp/comments/5mdes5/what_happened_to_the_named_parameter_proposal/
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPuuy5eBx1ybcPjS6dNsk7n1_c2uhdRBS19qr%3Dq5cj3cTURnLQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPuuy5eBx1ybcPjS6dNsk7n1_c2uhdRBS19qr%3Dq5cj3cTURnLQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

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

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">For decl=
aring a function with named parameters, it is imperative that it is opt-in,=
 otherwise, functions parameter names become part of the public API of the =
function, which is undesirable</blockquote><div dir=3D"auto" style=3D"font-=
family:sans-serif"><br>Pardon my ignorance, but why exactly is this undesir=
able? Designated initializer lists are also not opt-in. I don&#39;t really =
see a problem with this. I can&#39;t imagine function parameters to change =
once they&#39;re the function is part of the API.</div><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div>There should be some way =
to specify that the parameter is name-only. For example, altering=C2=A0<a h=
ref=3D"https://www.python.org/dev/peps/pep-3102/" target=3D"_blank">Python&=
#39;s implementation</a>:</div><div><br></div><div><font face=3D"monospace,=
 monospace">// anything after the . is name-only</font></div><div><font fac=
e=3D"monospace, monospace">int foo(., int .x);</font></div><div><br></div><=
div>Default arguments should be able to work as they are now.</div></blockq=
uote><div><br></div><div>I disagree with your proposed solution. Name-only =
parameters naturally appear when they are after a varadic (&quot;catch-all&=
quot;) parameter, just like in Python&#39;s implementation.=C2=A0</div><div=
><br></div><div>template &lt;typename ...T&gt;</div><div>void f(T ..., int =
name);</div><div><br></div><div>f(.name =3D 1); // name-only argument</div>=
<div><br></div><div>Now you have a small problem: C&#39;s variadic paramete=
rs are specified in the grammar itself to come last, which can be changed b=
ut would require some restructuring. But I don&#39;t think it&#39;s worth s=
upporting them.=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><div>However, I believe that the name should be part of th=
e function type and should be mangled into the name for the function. It sh=
ould not be allowed for the following two declarations to coexist:</div><di=
v><br></div><div><font face=3D"monospace, monospace">int foo(int .x, int .y=
);</font></div><div><font face=3D"monospace, monospace">int foo(int .a, int=
 .b);</font></div><div><br></div><div>If the name of the parameters are not=
 part of the function, then if those declarations are in separate translati=
on units, there&#39;s little way to enforce that this should fail to compil=
e / link.</div></blockquote><div><br></div><div>Any reasons to disallow thi=
s? I mean, this is already possible:</div><div><br></div><div>void foo(int =
=3D 1);</div><div><br></div><div>void f() {<br>=C2=A0 void foo(int =3D 2);<=
/div><div>=C2=A0 foo();</div><div>}</div><div><br></div><div>I&#39;m not sa=
ying that this is good code, but the truth is that indeed there is no way t=
o enforce this requirement over multiple TUs for every single case. There i=
s the possibility of making this IF;NDR, but really, I don&#39;t see why I =
shouldn&#39;t be able to rename parameters (coding/style guidelines?).</div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Now for=
 templates. In order to have higher-order functions which work on named par=
ameters, I believe it is necessary to have a new kind of template parameter=
, something like this:<br></blockquote><div><br></div><div>Oh I don&#39;t l=
ike this; it&#39;s too different if you know what I mean. What do you think=
 of saying that the named parameter is implicitly part of the expansion if =
the expansion happens in a function parameter list?</div><div><br></div><di=
v>template &lt;typename ...Ts&gt;</div><div>auto f(Ts ...Args) {=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0// No change here.</div><div>=C2=A0 g(Args...);=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Same.<=
/div><div>=C2=A0 return {Args...}[0];=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // Same.</div><div>}</=
div><div><br></div><div>f(1, 2); // ok: calls g(1, 2); returns 1</div><div>=
f(.Lhs =3D 1, .Rhs =3D 2); // ok; calls g(.Lhs =3D 1, .Rhs =3D 2); returns =
1</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">For=
 example, it would be nice to be easily able to specify the allocator of an=
 unordered_map:=C2=A0<font face=3D"monospace, monospace">std::unordered_map=
&lt;Key, Value, .allocator =3D MyAllocator&gt;</font><font face=3D"arial, h=
elvetica, sans-serif">=C2=A0. I believe this would break ABI compatibility,=
 though.</font></blockquote><div><br></div><div>How would this break ABI co=
mpatibility? The name of the function arguments need to to be mangled (whic=
h is a non-issue for templates in any case).=C2=A0=C2=A0</div><div>=C2=A0</=
div><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Aug 15, 2018 at 10:=
10 PM Justin Bassett &lt;<a href=3D"mailto:jbassett271@gmail.com">jbassett2=
71@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div>I&#39;m working on a paper to write this up more formally, b=
ut before I do that, I wanted to share my research and work and generate so=
me discussion.</div><div><br></div><div>Currently, it is possible to pass p=
arameters by position, but not by name. To work around this limitation, the=
re are a multitude of solutions. A few are listed here:</div><div><ul><li>T=
he &quot;Named Parameters Idiom,&quot; sometimes called the Builder Pattern=
..</li><li><a href=3D"https://www.boost.org/doc/libs/1_68_0/libs/parameter/d=
oc/html/index.html" target=3D"_blank">Boost Parameters</a>. Overloads <font=
 face=3D"monospace, monospace">operator=3D</font> to make it look like a na=
med parameter.</li><li>Boost Graph&#39;s named parameters. Parameter values=
 are passed via member functions.</li><li>Strong types. This suffers from t=
he limitation that parameters cannot be reordered, and sometimes you&#39;d =
have to create types that otherwise have no meaning.</li><li>Designated Ini=
tializers. There are those who hope that designated initializers will work =
as named parameters, but they don&#39;t work that well.</li></ul><div>Each =
of these have disadvantages. Here&#39;s a small list:</div></div><div><ul><=
li>Hard to maintain.</li><li>Have to prefix every argument with the library=
&#39;s namespace, or else use a lot of using declarations or even a using d=
irective.</li><li>Each argument has to be passed in order (Strong types), o=
therwise it&#39;s a ton of overloads for the library author to work out.</l=
i><li>Possibly worse code-gen</li></ul></div><div>I claim we should standar=
dize a way of passing named arguments in C++.</div><div><br></div><div><br>=
</div><div><br></div><div>Use cases for Named Parameters (aka Named Argumen=
ts, aka Keyword Arguments):</div><div><ul><li>Named-or-positional parameter=
s.</li><li>Name-only parameters</li><li>Either of the above combined with d=
efault arguments</li></ul><div><br></div><div><br></div><div>Syntax: there =
are two possible syntaxes I&#39;ve seen that work for named parameters in C=
++:</div></div><div><br></div><div><font face=3D"monospace, monospace">foo(=
..name =3D value)</font></div><div><font face=3D"monospace, monospace">foo(n=
ame: value)</font></div><div><br></div><div>I honestly don&#39;t care which=
 we go for, but for consistency with designated initializers (which may be =
a bad thing if the behavior is significantly different), I&#39;m going to c=
hoose the <font face=3D"monospace, monospace">foo(.name =3D value)</font> s=
yntax for the time being.</div><div><br></div><div>For declaring a function=
 with named parameters, it is imperative that it is opt-in, otherwise, func=
tions parameter names become part of the public API of the function, which =
is undesirable:</div><div><br></div><div><font face=3D"monospace, monospace=
">int foo(int .x);</font></div><div><br></div><div>It might be tempting to =
separate the name of the parameter from the name used in named parameters, =
but I claim this overly repetitive. As long as named parameters are opt-in,=
 having to give an alternative name is completely redundant. (I believe Swi=
ft does this)</div><div><br></div><div>There should be some way to specify =
that the parameter is name-only. For example, altering <a href=3D"https://w=
ww.python.org/dev/peps/pep-3102/" target=3D"_blank">Python&#39;s implementa=
tion</a>:</div><div><br></div><div><font face=3D"monospace, monospace">// a=
nything after the . is name-only</font></div><div><font face=3D"monospace, =
monospace">int foo(., int .x);</font></div><div><br></div><div>Default argu=
ments should be able to work as they are now.</div><div><br></div><div><br>=
</div><div><br></div><div>Semantics:</div><div>It&#39;s a pretty standard r=
ule that all named arguments must come after all positional arguments. It i=
s also pretty standard that named arguments can be in a different order tha=
n in the function declaration. I don&#39;t see a compelling reason to break=
 from this, even though there are exceptions in languages today (e.g. C# an=
d Swift)</div><div><br></div><div>There are some options on how the named p=
arameters should work. It could <a href=3D"https://docs.microsoft.com/en-us=
/dotnet/csharp/programming-guide/classes-and-structs/named-and-optional-arg=
uments#overload-resolution" target=3D"_blank">work like C# and just reorder=
 the arguments</a>. However, I believe that the name should be part of the =
function type and should be mangled into the name for the function. It shou=
ld not be allowed for the following two declarations to coexist:</div><div>=
<br></div><div><font face=3D"monospace, monospace">int foo(int .x, int .y);=
</font></div><div><font face=3D"monospace, monospace">int foo(int .a, int .=
b);</font></div><div><br></div><div>If the name of the parameters are not p=
art of the function, then if those declarations are in separate translation=
 units, there&#39;s little way to enforce that this should fail to compile =
/ link.</div><div><br></div><div>This does bring in the issue that it becom=
es harder to change existing APIs to accept named parameters in an ABI comp=
atible manner. For this, maybe the compiler could emit two symbols for the =
named-positional argument case? Otherwise, I think there should be some way=
 to either cause the compiler to emit two symbols or otherwise maintain ABI=
 compatibility.</div><div><br></div><div>Now for templates. In order to hav=
e higher-order functions which work on named parameters, I believe it is ne=
cessary to have a new kind of template parameter, something like this:</div=
><div><br></div><div><font face=3D"monospace, monospace">// I separated the=
 name completely from the type.</font></div><div><font face=3D"monospace, m=
onospace">// This would severely complicate generic code, however, so maybe=
 there&#39;s</font></div><div><font face=3D"monospace, monospace">// a way =
to keep both together</font></div><div><font face=3D"monospace, monospace">=
template &lt;typename F, .typename Name, typename Arg&gt;</font></div><div>=
<font face=3D"monospace, monospace">void call(F fn, Arg&amp;&amp; .Name arg=
) {</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0=C2=
=A0</font><span style=3D"font-family:monospace,monospace">// Some syntax to=
 expand the name is needed. I&#39;m not sure what</span></div><div><span st=
yle=3D"font-family:monospace,monospace">=C2=A0 =C2=A0 // a reasonable choic=
e is. There should also probably be a way</span></div><div><span style=3D"f=
ont-family:monospace,monospace">=C2=A0 =C2=A0 // to generate a name from a =
compile time string.</span></div><div><font face=3D"monospace, monospace">=
=C2=A0 =C2=A0 fn(.(Name) =3D std::forward&lt;Arg&gt;(arg));</font></div><di=
v><font face=3D"monospace, monospace">}</font></div><div><font face=3D"mono=
space, monospace"><br></font></div><div><font face=3D"monospace, monospace"=
>// Or maybe something combining the name and type would be better:</font><=
/div><div><font face=3D"monospace, monospace">template &lt;typename F, .typ=
ename Kwarg&gt;</font></div><div><font face=3D"monospace, monospace">void c=
all(F fn, Kwarg&amp;&amp; arg) {</font></div><div><font face=3D"monospace, =
monospace">=C2=A0 =C2=A0 fn(.(nameof(Kwarg)) =3D std::forward&lt;Kwarg&gt;(=
arg));</font></div><div><font face=3D"monospace, monospace">}</font></div><=
div><font face=3D"monospace, monospace"><br></font></div><div><font face=3D=
"monospace, monospace">// Valid ways to call it:</font></div><div><font fac=
e=3D"monospace, monospace">call(sqrt, .x =3D 9);</font></div><div><font fac=
e=3D"monospace, monospace">call(sqrt, 9); // We didn&#39;t enforce name-onl=
y in the declaration of call</font></div><div><br></div><div>Reflection cou=
ld possibly allow us to inspect the actual name supplied (useful for librar=
ies such as fmt: <font face=3D"monospace, monospace">fmt::format(&quot;({x}=
, {y})&quot;, .x =3D 10, .y =3D 20);</font> ), and it would probably be use=
ful to be able to generate a name from a compile-time string.</div><div><br=
></div><div>How lookup is performed: it&#39;s certainly possible to have ov=
erloaded functions along with named parameters. I haven&#39;t spent the tim=
e yet to flesh out all the details, but the named parameters can be each in=
 their own dimension, as compared to the positional dimension.</div><div><b=
r></div><div><br></div><div><br></div><div>Further ideas: I don&#39;t want =
to propose this yet, but I would also like to see named parameters in templ=
ate parameters. For example, it would be nice to be easily able to specify =
the allocator of an unordered_map: <font face=3D"monospace, monospace">std:=
:unordered_map&lt;Key, Value, .allocator =3D MyAllocator&gt;</font><font fa=
ce=3D"arial, helvetica, sans-serif">=C2=A0. I believe this would break ABI =
compatibility, though.</font></div><div><br></div><div><br></div><div><br><=
/div><div>Implementation:</div><div>It sounds crazy to add a new kind of te=
mplate parameter and include the name of the parameters as part of the func=
tion type, but I believe this would be implementable with some kind of <fon=
t face=3D"monospace, monospace">__name&lt;&quot;parameter_name&quot;&gt;</f=
ont> type with some connection to the regular template type, as well as som=
e rules on reordering (consider something like sorting all name-only parame=
ters lexicographically and re-mapping named-positional parameters to their =
position). I won&#39;t know for sure until I attempt an implementation, but=
 I believe it should work.</div><div><br></div><div><br></div><div><br></di=
v>References - some things I&#39;ve found about named parameter design, whi=
ch I may have referred to in my writeup above. Most of these I didn&#39;t l=
ink to inline:<div><br></div><div><a href=3D"https://www.python.org/dev/pep=
s/pep-3102/" target=3D"_blank">https://www.python.org/dev/peps/pep-3102/</a=
><br></div><div><br></div><div><a href=3D"https://internals.rust-lang.org/t=
/pre-rfc-named-arguments/3831" target=3D"_blank">https://internals.rust-lan=
g.org/t/pre-rfc-named-arguments/3831</a><br></div><div><br></div><div><a hr=
ef=3D"https://internals.rust-lang.org/t/pre-rfc-named-arguments/3831/196" t=
arget=3D"_blank">https://internals.rust-lang.org/t/pre-rfc-named-arguments/=
3831/196</a><br></div><div><br></div><div><a href=3D"https://docs.microsoft=
..com/en-us/dotnet/csharp/programming-guide/classes-and-structs/named-and-op=
tional-arguments#overload-resolution" target=3D"_blank">https://docs.micros=
oft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/named-and=
-optional-arguments#overload-resolution</a><br></div><div><br></div><div><a=
 href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4172.htm"=
 target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/=
n4172.htm</a><br></div><div><br></div><div><a href=3D"http://jamboree.githu=
b.io/designator-draft.html" target=3D"_blank">http://jamboree.github.io/des=
ignator-draft.html</a><br></div><div><br></div><div><a href=3D"https://www.=
reddit.com/r/cpp/comments/5mdes5/what_happened_to_the_named_parameter_propo=
sal/" target=3D"_blank">https://www.reddit.com/r/cpp/comments/5mdes5/what_h=
appened_to_the_named_parameter_proposal/</a><br></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPuuy5eBx1ybcPjS6dNsk7n1_c2uhdRBS19q=
r%3Dq5cj3cTURnLQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAPuuy5eBx1ybcPjS6dNsk7n1_c2uhdRBS19qr%3Dq5cj3cTURnLQ%40mail.gmail.c=
om</a>.<br>
</blockquote></div></div>

<p></p>

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

--0000000000000b6b8a0573871766--

.

--00000000000049578b057387a1b7
Content-Type: text/plain; charset="UTF-8"

On Wed, Aug 15, 2018 at 10:55 PM Nicolas Lesser <blitzrakete@gmail.com>
wrote:

> For declaring a function with named parameters, it is imperative that it
>> is opt-in, otherwise, functions parameter names become part of the public
>> API of the function, which is undesirable
>
>
> Pardon my ignorance, but why exactly is this undesirable? Designated
> initializer lists are also not opt-in. I don't really see a problem with
> this. I can't imagine function parameters to change once they're the
> function is part of the API.
>

Consider all the standard library functions. Suddenly all the parameter
names become public. Here's an example from this reddit thread (
https://www.reddit.com/r/cpp/comments/5mdes5/what_happened_to_the_named_parameter_proposal/
):

std::max(._Left = 1, ._Right = 2)

Those names are not intended to be public. They are named strangely like
this to avoid problems with user defined macros. We *could *standardize
names for every function in the standard, but I believe that is a lot of
work.

Also, that would make parameter names part of the API by default. I believe
library authors would like the opt-in design, as it makes it much easier to
make API compatible changes. Names used as function parameters are not
generally expected to be part of the API. Especially considering that there
is a lot of code already written which assumes that the parameter names are
not part of the API. If we suddenly change it to be part of the API, the
library authors had no say in whether those names should be part of the API.


> There should be some way to specify that the parameter is name-only. For
>> example, altering Python's implementation
>> <https://www.python.org/dev/peps/pep-3102/>:
>>
>> // anything after the . is name-only
>> int foo(., int .x);
>>
>> Default arguments should be able to work as they are now.
>>
>
> I disagree with your proposed solution. Name-only parameters naturally
> appear when they are after a varadic ("catch-all") parameter, just like in
> Python's implementation.
>

Good point. I don't disagree with this, but I didn't like having to specify
the types for the variadic template pack. Note that PEP 3102, which I
linked to, allows Python to leave off the name for the variadic parameter.
I was imagining something like that


> template <typename ...T>
> void f(T ..., int name);
>
> f(.name = 1); // name-only argument
>
> Now you have a small problem: C's variadic parameters are specified in the
> grammar itself to come last, which can be changed but would require some
> restructuring. But I don't think it's worth supporting them.
>

I agree here. If supporting C's varargs is difficult in this case, I don't
consider it a big drawback to disallow them when a function has named
parameters.


> However, I believe that the name should be part of the function type and
>> should be mangled into the name for the function. It should not be allowed
>> for the following two declarations to coexist:
>>
>> int foo(int .x, int .y);
>> int foo(int .a, int .b);
>>
>> If the name of the parameters are not part of the function, then if those
>> declarations are in separate translation units, there's little way to
>> enforce that this should fail to compile / link.
>>
>
> Any reasons to disallow this? I mean, this is already possible:
>

My first reason for doing so was to directly address concerns in a reddit
thread asking about a previous named parameters proposal
<https://www.reddit.com/r/cpp/comments/5mdes5/what_happened_to_the_named_parameter_proposal/>.
I also believe it is wrong for names which are part of the API to be easily
changeable like that. Additionally, consider name-only parameters. If they
could be renamed, that would be dependent on the order in which they are
declared, which I consider to be an implementation detail. I'm okay if it
is allowed, but I strongly prefer it to be disallowed.


> void foo(int = 1);
>
> void f() {
>   void foo(int = 2);
>   foo();
> }
>

Named parameters are very different from default parameters. I dislike that
we can even do this for default arguments. I'd rather be more restrictive
and find we should loosen the restriction later than be less restrictive
and find we should have tightened the restrictions.

I'm not saying that this is good code, but the truth is that indeed there
> is no way to enforce this requirement over multiple TUs for every single
> case. There is the possibility of making this IF;NDR, but really, I don't
> see why I shouldn't be able to rename parameters (coding/style guidelines?).
>

I believe it is possible to enforce this over multiple TUs in some basic
cases, but thinking about it, I guess it is true that it doesn't work for
some of the more complex cases. If we mangle the names of every named
parameter into the symbol, though, that would catch many cases, I believe,
albeit with a not-very-descriptive diagnostic. IF;NDR is my preference
otherwise.


> Now for templates. In order to have higher-order functions which work on
>> named parameters, I believe it is necessary to have a new kind of template
>> parameter, something like this:
>>
>
> Oh I don't like this; it's too different if you know what I mean. What do
> you think of saying that the named parameter is implicitly part of the
> expansion if the expansion happens in a function parameter list?
>

I thought about this. My primary concern is that functions which were never
designed with named parameters in mind suddenly can be called with named
parameters. I believe it is best to give library authors the chance to
think about this new aspect of the API before opening it up to all named
parameters.

Other things:

   - This would be similar to if Python's varargs accepted kwargs as well.
   I don't like this.
   - How would the library author restrict a function to only named
   parameters, or only positional parameters?
   - There would be quite a bit of work figuring out all the cases where a
   name should be generated and where a name should not be generated. It might
   not even be possible.



> template <typename ...Ts>
> auto f(Ts ...Args) {                             // No change here.
>   g(Args...);                                         // Same.
>   return {Args...}[0];                          // Same.
> }
>
> f(1, 2); // ok: calls g(1, 2); returns 1
> f(.Lhs = 1, .Rhs = 2); // ok; calls g(.Lhs = 1, .Rhs = 2); returns 1
>


> For example, it would be nice to be easily able to specify the allocator
>> of an unordered_map: std::unordered_map<Key, Value, .allocator =
>> MyAllocator> . I believe this would break ABI compatibility, though.
>
>
> How would this break ABI compatibility? The name of the function arguments
> need to to be mangled (which is a non-issue for templates in any case).
>

It depends on how it is implemented. True, it only has to be a reordering,
in which case it would be fully ABI compatible. For some reason, I was
imagining the names being mangled into the type.

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

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

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed=
, Aug 15, 2018 at 10:55 PM Nicolas Lesser &lt;<a href=3D"mailto:blitzrakete=
@gmail.com">blitzrakete@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">For declaring a function with named parameters, it=
 is imperative that it is opt-in, otherwise, functions parameter names beco=
me part of the public API of the function, which is undesirable</blockquote=
><div dir=3D"auto" style=3D"font-family:sans-serif"><br>Pardon my ignorance=
, but why exactly is this undesirable? Designated initializer lists are als=
o not opt-in. I don&#39;t really see a problem with this. I can&#39;t imagi=
ne function parameters to change once they&#39;re the function is part of t=
he API.</div></div></blockquote><div><br></div><div>Consider all the standa=
rd library functions. Suddenly all the parameter names become public. Here&=
#39;s an example from this reddit thread (<a href=3D"https://www.reddit.com=
/r/cpp/comments/5mdes5/what_happened_to_the_named_parameter_proposal/">http=
s://www.reddit.com/r/cpp/comments/5mdes5/what_happened_to_the_named_paramet=
er_proposal/</a>):</div><div><br></div><div><font face=3D"monospace, monosp=
ace">std::max(._Left =3D 1, ._Right =3D 2)</font></div><div><br></div><div>=
Those names are not intended to be public. They are named strangely like th=
is to avoid problems with user defined macros. We <i>could </i>standardize =
names for every function in the standard, but I believe that is a lot of wo=
rk.</div><div><br></div><div>Also, that would make parameter names part of =
the API by default. I believe library authors would like the opt-in design,=
 as it makes it much easier to make API compatible changes. Names used as f=
unction parameters are not generally expected to be part of the API. Especi=
ally considering that there is a lot of code already written which assumes =
that the parameter names are not part of the API. If we suddenly change it =
to be part of the API, the library authors had no say in whether those name=
s should be part of the API.</div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr"><div></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div>There should be some way to specify that =
the parameter is name-only. For example, altering=C2=A0<a href=3D"https://w=
ww.python.org/dev/peps/pep-3102/" target=3D"_blank">Python&#39;s implementa=
tion</a>:</div><div><br></div><div><font face=3D"monospace, monospace">// a=
nything after the . is name-only</font></div><div><font face=3D"monospace, =
monospace">int foo(., int .x);</font></div><div><br></div><div>Default argu=
ments should be able to work as they are now.</div></blockquote><div><br></=
div><div>I disagree with your proposed solution. Name-only parameters natur=
ally appear when they are after a varadic (&quot;catch-all&quot;) parameter=
, just like in Python&#39;s implementation.=C2=A0</div></div></blockquote><=
div><br></div><div>Good point. I don&#39;t disagree with this, but I didn&#=
39;t like having to specify the types for the variadic template pack. Note =
that PEP 3102, which=C2=A0I linked to, allows Python to leave off the name =
for the variadic parameter. I was imagining something like that</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div></div><div>template &lt;typename ...T&gt;</div><div>void f(T ..., =
int name);</div><div><br></div><div>f(.name =3D 1); // name-only argument</=
div><div><br></div><div>Now you have a small problem: C&#39;s variadic para=
meters are specified in the grammar itself to come last, which can be chang=
ed but would require some restructuring. But I don&#39;t think it&#39;s wor=
th supporting them.=C2=A0</div></div></blockquote><div><br></div><div>I agr=
ee here. If supporting C&#39;s varargs is difficult in this case, I don&#39=
;t consider it a big drawback to disallow them when a function has named pa=
rameters.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex"><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div>However, I believe that the name should be part of the func=
tion type and should be mangled into the name for the function. It should n=
ot be allowed for the following two declarations to coexist:</div><div><br>=
</div><div><font face=3D"monospace, monospace">int foo(int .x, int .y);</fo=
nt></div><div><font face=3D"monospace, monospace">int foo(int .a, int .b);<=
/font></div><div><br></div><div>If the name of the parameters are not part =
of the function, then if those declarations are in separate translation uni=
ts, there&#39;s little way to enforce that this should fail to compile / li=
nk.</div></blockquote><div><br></div><div>Any reasons to disallow this? I m=
ean, this is already possible:</div></div></blockquote><div><br></div><div>=
My first reason for doing so was to directly address concerns in <a href=3D=
"https://www.reddit.com/r/cpp/comments/5mdes5/what_happened_to_the_named_pa=
rameter_proposal/">a reddit thread asking about a previous named parameters=
 proposal</a>. I also believe it is wrong for names which are part of the A=
PI to be easily changeable like that. Additionally, consider name-only para=
meters. If they could be renamed, that would be dependent on the order in w=
hich they are declared, which I consider to be an implementation detail. I&=
#39;m okay if it is allowed, but I strongly prefer it to be disallowed.</di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"ltr"><div></div><div>void foo(int =3D 1);</div><div><br></div><div>vo=
id f() {<br>=C2=A0 void foo(int =3D 2);</div><div>=C2=A0 foo();</div><div>}=
</div></div></blockquote><div><br></div><div>Named parameters are very diff=
erent from default parameters. I dislike that we can even do this for defau=
lt arguments. I&#39;d rather be more restrictive and find we should loosen =
the restriction later than be less restrictive and find we should have tigh=
tened the restrictions.</div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr"><div></div><div>I&#39;m not saying that=
 this is good code, but the truth is that indeed there is no way to enforce=
 this requirement over multiple TUs for every single case. There is the pos=
sibility of making this IF;NDR, but really, I don&#39;t see why I shouldn&#=
39;t be able to rename parameters (coding/style guidelines?).</div></div></=
blockquote><div><br></div><div>I believe it is possible to enforce this ove=
r multiple TUs in some basic cases, but thinking about it, I guess it is tr=
ue that it doesn&#39;t work for some of the more complex cases. If we mangl=
e the names of every named parameter into the symbol, though, that would ca=
tch many cases, I believe, albeit with a not-very-descriptive diagnostic. I=
F;NDR is my preference otherwise.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">Now for templates. In order to have higher-order f=
unctions which work on named parameters, I believe it is necessary to have =
a new kind of template parameter, something like this:<br></blockquote><div=
><br></div><div>Oh I don&#39;t like this; it&#39;s too different if you kno=
w what I mean. What do you think of saying that the named parameter is impl=
icitly part of the expansion if the expansion happens in a function paramet=
er list?</div></div></blockquote><div><br></div><div>I thought about this. =
My primary concern is that functions which were never designed with named p=
arameters in mind suddenly can be called with named parameters. I believe i=
t is best to give library authors the chance to think about this new aspect=
 of the API before opening it up to all named parameters.</div><div><br></d=
iv><div>Other things:</div><div><ul><li>This would be similar to if Python&=
#39;s varargs accepted kwargs as well. I don&#39;t like this.</li><li>How w=
ould the library author restrict a function to only named parameters, or on=
ly positional parameters?</li><li>There would be quite a bit of work figuri=
ng out all the cases where a name should be generated and where a name shou=
ld not be generated. It might not even be possible.</li></ul></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
><div></div><div>template &lt;typename ...Ts&gt;</div><div>auto f(Ts ...Arg=
s) {=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// No change here.</div><div>=C2=A0 g(Arg=
s...);=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0// Same.</div><div>=C2=A0 return {Args...}[0];=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // Same.=
</div><div>}</div><div><br></div><div>f(1, 2); // ok: calls g(1, 2); return=
s 1</div><div>f(.Lhs =3D 1, .Rhs =3D 2); // ok; calls g(.Lhs =3D 1, .Rhs =
=3D 2); returns 1</div></div></blockquote><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">For example, it would be nice to be easily able t=
o specify the allocator of an unordered_map:=C2=A0<font face=3D"monospace, =
monospace">std::unordered_map&lt;Key, Value, .allocator =3D MyAllocator&gt;=
</font><font face=3D"arial, helvetica, sans-serif">=C2=A0. I believe this w=
ould break ABI compatibility, though.</font></blockquote><div><br></div><di=
v>How would this break ABI compatibility? The name of the function argument=
s need to to be mangled (which is a non-issue for templates in any case).=
=C2=A0=C2=A0</div></div></blockquote><div><br></div><div>It depends on how =
it is implemented. True, it only has to be a reordering, in which case it w=
ould be fully ABI compatible. For some reason, I was imagining the names be=
ing mangled into the type.</div><div><br></div></div></div>

<p></p>

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

--00000000000049578b057387a1b7--

.

------=_Part_189_488993600.1534402493251
Content-Type: multipart/alternative;
 boundary="----=_Part_190_332488714.1534402493252"

------=_Part_190_332488714.1534402493252
Content-Type: text/plain; charset="UTF-8"

Yeah, I see you linked to my early draft
<http://jamboree.github.io/designator-draft.html>, and it's actually been
extended further to support perfect forwarding of designators.
Well, I didn't write a new version of the draft, however, some idea can be
found in this thread
<https://www.reddit.com/r/cpp/comments/61r0qf/rfc_template_declname_parameter_and/>
..

The "crazy new kind of template parameter" you mentioned is implemented in
my prototype and it's called "template declname parameter".
It's not restricted to named parameters. See the above thread if you're
interested.

I didn't make designator part of the function type, but things got
complicated after the introduction of designating-type (i.e a combination
of type and designator, e.g. "int.a").
The designating-type is a pseudo type, you can't use it to declare a
variable, it's only purpose is for template to decompose it.
Now a function has 2 types - one without designators and one with
designators

Consider the following:

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

template<class F>
void call1(F f);

template<class R, class... A, declname... N>
void call2(R(*f)(A.N...));

call1(f); // call1 is void(void(*)(int, int))
call2(f); // call2 is void(void(*)(int.a, int.b))

The designated version is only used if you ask for explicitly, so call1
gets the plain-old-function-type, while call2 gets designated-function-type.

There's also an idea I didn't explored but probably nice to have - allowing
the parameters to have 2 names (interface & impl), e.g.

template<class T>
void copy(T.from a, T&.to b) {
    b = a;
}

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

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

<div dir=3D"ltr"><div>Yeah, I see you linked to my early=C2=A0<a href=3D"ht=
tp://jamboree.github.io/designator-draft.html">draft</a>, and it&#39;s actu=
ally been extended further to support perfect forwarding of designators.</d=
iv><div>Well, I didn&#39;t write a new version of the draft, however, some =
idea can be found in this=C2=A0<a href=3D"https://www.reddit.com/r/cpp/comm=
ents/61r0qf/rfc_template_declname_parameter_and/">thread</a>.</div><div><br=
></div>The &quot;<span style=3D"font-size: small;">crazy new kind of templa=
te parameter&quot; you mentioned is implemented in my prototype and it&#39;=
s called &quot;template declname parameter&quot;.</span><div><font size=3D"=
2">It&#39;s not restri</font>cted to named parameters. See the above thread=
 if you&#39;re interested.</div><div><br></div><div>I didn&#39;t make desig=
nator part of the function type, but things got complicated after the intro=
duction of designating-type (i.e a combination of type and designator, e.g.=
 &quot;int.a&quot;).</div><div>The designating-type is a pseudo type, you c=
an&#39;t use it to declare a variable, it&#39;s only purpose is for templat=
e to decompose it.</div><div>Now a function=C2=A0has 2 types - one without =
designators and one with designators<br></div><div><br></div><div>Consider =
the following:</div><div><br></div><div class=3D"prettyprint" style=3D"back=
ground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-=
style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pre=
ttyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>int</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">a</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">b</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">te=
mplate</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">class</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> F</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> call1</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">F f</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">template</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">c=
lass</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> R</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">class</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">...</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> A</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> declname</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> N</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> call2</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">R</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">(*</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">f</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">)(</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">A</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
..</span><span style=3D"color: #000;" class=3D"styled-by-prettify">N</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">...));</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>call1</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">f</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D=
"styled-by-prettify">// call1 is void(void(*)(int, int))</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>call2</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">f</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-b=
y-prettify">// call2 is void(void(*)(int.a, int.b))</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><div=
><br></div><div>The designated version is only used if you ask for explicit=
ly, so call1 gets the plain-old-function-type, while call2 gets designated-=
function-type.</div><div><br></div><div>There&#39;s also an idea I didn&#39=
;t explored but probably nice to have - allowing the parameters to have 2 n=
ames (interface &amp; impl), e.g.</div><div><br></div><div class=3D"prettyp=
rint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187,=
 187, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"=
><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">template</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">void</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> copy</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">from</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> a</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&amp;.</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">to b</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 b <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> a</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">}</span></div></code></div><div><br></div=
></div>

<p></p>

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

------=_Part_190_332488714.1534402493252--

------=_Part_189_488993600.1534402493251--

.

------=_Part_222_284781185.1534404529963
Content-Type: multipart/alternative;
 boundary="----=_Part_223_1316472730.1534404529964"

------=_Part_223_1316472730.1534404529964
Content-Type: text/plain; charset="UTF-8"

Note that, because of Python and C# popularity, this has been suggested
multiple times in one for or another. Never passed.

Also you missed some
proposals http://jamboree.github.io/designator-draft.html
and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0671r0.html

The latter did not pass and is turned into the
poor-mans http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0671r2.html

In other words, you should state what is different.

I am personally *pro* named arguments, but the chances are (extremely) low.
I have written a post here, just 10 days ago, on a (more or less)
alternative solution
- https://groups.google.com/a/isocpp.org/d/msg/std-proposals/wz0a7NrwnGQ/iBpN8pYMFQAJ

In any case
- C#-like and Python-like solutions have failed already.
- Solutions that modify the signature and/or the typesystem are doomed for
multiple reasons.
Also there are people that find named arguments *completely* unneeded and
such people might as well be in the committee.






--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1510edaf-324a-403c-95bd-0f3fb42ba118%40isocpp.org.

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

<div dir=3D"ltr">Note that, because of Python and C# popularity, this has b=
een suggested multiple times in one for or another. Never passed.=C2=A0<div=
><br><div>Also you missed some proposals=C2=A0http://jamboree.github.io/des=
ignator-draft.html=C2=A0</div><div>and=C2=A0http://www.open-std.org/jtc1/sc=
22/wg21/docs/papers/2017/p0671r0.html</div><div><br></div><div>The latter d=
id not pass and is turned into the poor-mans=C2=A0http://www.open-std.org/J=
TC1/SC22/WG21/docs/papers/2018/p0671r2.html</div><div><br></div><div>In oth=
er words, you should state what is different.</div><div><br></div><div>I am=
 personally <i>pro</i> named arguments, but the chances are (extremely) low=
..=C2=A0</div><div>I have written a post here, just 10 days ago, on a (more =
or less) alternative solution -=C2=A0https://groups.google.com/a/isocpp.org=
/d/msg/std-proposals/wz0a7NrwnGQ/iBpN8pYMFQAJ</div><div><br></div><div>In a=
ny case=C2=A0</div><div>- C#-like and Python-like solutions have failed alr=
eady.=C2=A0</div><div>- Solutions that modify the signature and/or the type=
system are doomed for multiple reasons. =C2=A0</div><div>Also there are peo=
ple that find named arguments <i>completely</i> unneeded and such people mi=
ght as well be in the committee.=C2=A0</div><div><br></div><div><br></div><=
div><br></div><div><br></div><div><br></div><div><br></div></div></div>

<p></p>

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

------=_Part_223_1316472730.1534404529964--

------=_Part_222_284781185.1534404529963--

.

On 16/08/18 07:10, Justin Bassett wrote:
> I'm working on a paper to write this up more formally, but before I do
> that, I wanted to share my research and work and generate some discussion.

I am at a loss to why people key wanting to make this such a complicated
issue.

Let's simplify things, and look at the requirements:

1. We want to be able to use named parameters.  It leads to clearer code
and fewer errors - especially for functions with several parameters.

2. The primary use is to check that parameters are given in the right
order, with the ability to re-order parameters at the call site as a
secondary concern.

3. It should not require changes to existing code, new ABIs, new object
file formats, or anything more than minimal changes to the compiler
front-end.

We do /not/ want this to be part of a function's signature - there is no
benefit to it, and vast complications involved.  In most well-written
code a function (if exported) is declared once in a header somewhere,
and this declaration is available when the function's definition is
seen.  So checking for matching parameter names can be done then - just
as checking is done for matching numbers and types.  Compilers can warn
on mismatches.  And if the declaration and definition are independent,
then it's the programmer's responsibility to make sure they work
together - just as for other aspects of functions.

(I appreciate that there are advantages in allowing names to be part of
the signature - it would let you distinguish "complex(double r, double
i)" and "complex(double r, double theta)".  But the added complexity and
implementation effort needed would not be worth it - such costly ideas
hinder the adoption of the main feature.  And there would be nothing to
stop this being added in some way at a later date.)


Named parameters are only relevant to function /calls/ - not to function
definitions.  The names to use come from a function's declaration - the
argument names in a function's definition are irrelevant (though a
compiler warning to check they match would be a useful implementation
feature).  They are very similar, therefore, to default arguments.

 int foo(int a, int b, int c = 3, int d = 4);

All these mean the same thing:

 foo(1, 2, 3, 4);
 foo(1, 2, 3);
 foo(.a = 1, .b = 2, .c = 3, .d = 4);
 foo(.b = 2, .a = 1, 3);
 foo(.d = 4, .b = 2, .a = 1);


These are errors (for obvious reasons):

 foo(.ab = 1, 2);
 foo(.c = 3, 2, 3);


Within the call parameters, the compiler will take the list of calling
parameters and match it up with a list of parameters in the function
declaration.  First, any named parameters are put in the right spot
according to name.  Then any unnamed parameters are put in the same spot
number as they had in the call.  Any empty spots are filled with the
default values.  If any spot has no value, or more than one value, it's
an error.


If a function is declared with some unnamed parameters, and re-declared
with names for some of these parameters, that's fine - the current set
of names is the union of these.  If a function is redeclared giving the
same name to parameters, that's fine too.  If a function is redeclared
and there is a conflict in a parameter name, or if a parameter is never
given a name, then that parameter can't be used as a named parameter.
An exception would be that parameter names with reserved identifiers are
considered anonymous - you can't match on such a name.

An alternative resolution here would be simply to say that the last seen
declaration is the one that counts in regard to parameter names.
(Again, compiler warnings for conflicts, excluding reserved identifiers,
would be encouraged.)



That is /all/ that is needed.  It could be implemented simply (well,
relatively simply!) in any C++ compiler front-end.  It does not conflict
with existing syntax, it will not change the meaning of any existing
code.  New headers can be written to take advantage of the feature, but
such functions can still be used with positional parameters.

The same feature can also be used for 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/pl3ogk%24csr%241%40blaine.gmane.org.

.

------=_Part_345_1607312661.1534424903176
Content-Type: multipart/alternative;
 boundary="----=_Part_346_1832926499.1534424903176"

------=_Part_346_1832926499.1534424903176
Content-Type: text/plain; charset="UTF-8"

There are tree major problems with such simple approaches

First - you make something, that has been private for 30+ years, public.
Second - warnings are not good enough. There is no situation where wrong
argument is ignorable and not an error. If you make named arguments that
weak, one can just use comments.
Third - perfect forwarding must work.

On Thursday, August 16, 2018 at 2:54:14 PM UTC+3, David Brown wrote:
>
> On 16/08/18 07:10, Justin Bassett wrote:
> > I'm working on a paper to write this up more formally, but before I do
> > that, I wanted to share my research and work and generate some
> discussion.
>
> I am at a loss to why people key wanting to make this such a complicated
> issue.
>
> Let's simplify things, and look at the requirements:
>
> 1. We want to be able to use named parameters.  It leads to clearer code
> and fewer errors - especially for functions with several parameters.
>
> 2. The primary use is to check that parameters are given in the right
> order, with the ability to re-order parameters at the call site as a
> secondary concern.
>
> 3. It should not require changes to existing code, new ABIs, new object
> file formats, or anything more than minimal changes to the compiler
> front-end.
>
> We do /not/ want this to be part of a function's signature - there is no
> benefit to it, and vast complications involved.  In most well-written
> code a function (if exported) is declared once in a header somewhere,
> and this declaration is available when the function's definition is
> seen.  So checking for matching parameter names can be done then - just
> as checking is done for matching numbers and types.  Compilers can warn
> on mismatches.  And if the declaration and definition are independent,
> then it's the programmer's responsibility to make sure they work
> together - just as for other aspects of functions.
>
> (I appreciate that there are advantages in allowing names to be part of
> the signature - it would let you distinguish "complex(double r, double
> i)" and "complex(double r, double theta)".  But the added complexity and
> implementation effort needed would not be worth it - such costly ideas
> hinder the adoption of the main feature.  And there would be nothing to
> stop this being added in some way at a later date.)
>
>
> Named parameters are only relevant to function /calls/ - not to function
> definitions.  The names to use come from a function's declaration - the
> argument names in a function's definition are irrelevant (though a
> compiler warning to check they match would be a useful implementation
> feature).  They are very similar, therefore, to default arguments.
>
>         int foo(int a, int b, int c = 3, int d = 4);
>
> All these mean the same thing:
>
>         foo(1, 2, 3, 4);
>         foo(1, 2, 3);
>         foo(.a = 1, .b = 2, .c = 3, .d = 4);
>         foo(.b = 2, .a = 1, 3);
>         foo(.d = 4, .b = 2, .a = 1);
>
>
> These are errors (for obvious reasons):
>
>         foo(.ab = 1, 2);
>         foo(.c = 3, 2, 3);
>
>
> Within the call parameters, the compiler will take the list of calling
> parameters and match it up with a list of parameters in the function
> declaration.  First, any named parameters are put in the right spot
> according to name.  Then any unnamed parameters are put in the same spot
> number as they had in the call.  Any empty spots are filled with the
> default values.  If any spot has no value, or more than one value, it's
> an error.
>
>
> If a function is declared with some unnamed parameters, and re-declared
> with names for some of these parameters, that's fine - the current set
> of names is the union of these.  If a function is redeclared giving the
> same name to parameters, that's fine too.  If a function is redeclared
> and there is a conflict in a parameter name, or if a parameter is never
> given a name, then that parameter can't be used as a named parameter.
> An exception would be that parameter names with reserved identifiers are
> considered anonymous - you can't match on such a name.
>
> An alternative resolution here would be simply to say that the last seen
> declaration is the one that counts in regard to parameter names.
> (Again, compiler warnings for conflicts, excluding reserved identifiers,
> would be encouraged.)
>
>
>
> That is /all/ that is needed.  It could be implemented simply (well,
> relatively simply!) in any C++ compiler front-end.  It does not conflict
> with existing syntax, it will not change the meaning of any existing
> code.  New headers can be written to take advantage of the feature, but
> such functions can still be used with positional parameters.
>
> The same feature can also be used for 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f3af9e48-f865-476e-8724-4af19ce23369%40isocpp.org.

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

<div dir=3D"ltr">There are tree major problems with such simple approaches=
=C2=A0<div><br></div><div>First - you make something, that has been private=
 for 30+ years, public.</div><div>Second - warnings are not good enough. Th=
ere is no situation where wrong argument is ignorable and not an error. If =
you make named arguments that weak, one can just use comments.</div><div>Th=
ird - perfect forwarding must work.=C2=A0<br><br>On Thursday, August 16, 20=
18 at 2:54:14 PM UTC+3, David Brown wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;">On 16/08/18 07:10, Justin Bassett wrote:
<br>&gt; I&#39;m working on a paper to write this up more formally, but bef=
ore I do
<br>&gt; that, I wanted to share my research and work and generate some dis=
cussion.
<br>
<br>I am at a loss to why people key wanting to make this such a complicate=
d
<br>issue.
<br>
<br>Let&#39;s simplify things, and look at the requirements:
<br>
<br>1. We want to be able to use named parameters. =C2=A0It leads to cleare=
r code
<br>and fewer errors - especially for functions with several parameters.
<br>
<br>2. The primary use is to check that parameters are given in the right
<br>order, with the ability to re-order parameters at the call site as a
<br>secondary concern.
<br>
<br>3. It should not require changes to existing code, new ABIs, new object
<br>file formats, or anything more than minimal changes to the compiler
<br>front-end.
<br>
<br>We do /not/ want this to be part of a function&#39;s signature - there =
is no
<br>benefit to it, and vast complications involved. =C2=A0In most well-writ=
ten
<br>code a function (if exported) is declared once in a header somewhere,
<br>and this declaration is available when the function&#39;s definition is
<br>seen. =C2=A0So checking for matching parameter names can be done then -=
 just
<br>as checking is done for matching numbers and types. =C2=A0Compilers can=
 warn
<br>on mismatches. =C2=A0And if the declaration and definition are independ=
ent,
<br>then it&#39;s the programmer&#39;s responsibility to make sure they wor=
k
<br>together - just as for other aspects of functions.
<br>
<br>(I appreciate that there are advantages in allowing names to be part of
<br>the signature - it would let you distinguish &quot;complex(double r, do=
uble
<br>i)&quot; and &quot;complex(double r, double theta)&quot;. =C2=A0But the=
 added complexity and
<br>implementation effort needed would not be worth it - such costly ideas
<br>hinder the adoption of the main feature. =C2=A0And there would be nothi=
ng to
<br>stop this being added in some way at a later date.)
<br>
<br>
<br>Named parameters are only relevant to function /calls/ - not to functio=
n
<br>definitions. =C2=A0The names to use come from a function&#39;s declarat=
ion - the
<br>argument names in a function&#39;s definition are irrelevant (though a
<br>compiler warning to check they match would be a useful implementation
<br>feature). =C2=A0They are very similar, therefore, to default arguments.
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0int foo(int a, int b, i=
nt c =3D 3, int d =3D 4);
<br>
<br>All these mean the same thing:
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0foo(1, 2, 3, 4);
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0foo(1, 2, 3);
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0foo(.a =3D 1, .b =3D 2,=
 .c =3D 3, .d =3D 4);
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0foo(.b =3D 2, .a =3D 1,=
 3);
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0foo(.d =3D 4, .b =3D 2,=
 .a =3D 1);
<br>
<br>
<br>These are errors (for obvious reasons):
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0foo(.ab =3D 1, 2);
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0foo(.c =3D 3, 2, 3);
<br>
<br>
<br>Within the call parameters, the compiler will take the list of calling
<br>parameters and match it up with a list of parameters in the function
<br>declaration. =C2=A0First, any named parameters are put in the right spo=
t
<br>according to name. =C2=A0Then any unnamed parameters are put in the sam=
e spot
<br>number as they had in the call. =C2=A0Any empty spots are filled with t=
he
<br>default values. =C2=A0If any spot has no value, or more than one value,=
 it&#39;s
<br>an error.
<br>
<br>
<br>If a function is declared with some unnamed parameters, and re-declared
<br>with names for some of these parameters, that&#39;s fine - the current =
set
<br>of names is the union of these. =C2=A0If a function is redeclared givin=
g the
<br>same name to parameters, that&#39;s fine too. =C2=A0If a function is re=
declared
<br>and there is a conflict in a parameter name, or if a parameter is never
<br>given a name, then that parameter can&#39;t be used as a named paramete=
r.
<br>An exception would be that parameter names with reserved identifiers ar=
e
<br>considered anonymous - you can&#39;t match on such a name.
<br>
<br>An alternative resolution here would be simply to say that the last see=
n
<br>declaration is the one that counts in regard to parameter names.
<br>(Again, compiler warnings for conflicts, excluding reserved identifiers=
,
<br>would be encouraged.)
<br>
<br>
<br>
<br>That is /all/ that is needed. =C2=A0It could be implemented simply (wel=
l,
<br>relatively simply!) in any C++ compiler front-end. =C2=A0It does not co=
nflict
<br>with existing syntax, it will not change the meaning of any existing
<br>code. =C2=A0New headers can be written to take advantage of the feature=
, but
<br>such functions can still be used with positional parameters.
<br>
<br>The same feature can also be used for template arguments.
<br>
<br>
<br>
<br>
<br>
<br></blockquote></div></div>

<p></p>

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

------=_Part_346_1832926499.1534424903176--

------=_Part_345_1607312661.1534424903176--

.

On 2018-08-16 07:53, David Brown wrote:
> I am at a loss to why people key wanting to make this such a complicated
> issue.
> [...]
> 2. The primary use is to check that parameters are given in the right
> order, with the ability to re-order parameters at the call site as a
> secondary concern.

....probably because plenty of people disagree with this point. AFAIAC,
any proposal that does NOT allow these:

  void foo(int, int :a = 1, int :b = 2, int :c = 12);
  foo(3, b: 5); // foo(3, 1, 5, 12)

  void bar(int :a);
  void bar(int :x); // distinct overload

....is pointless. Checking argument order is, IMHO, not only *not* "the
primary use", but *optional*.

> 3. It should not require changes to existing code, new ABIs, new object
> file formats, or anything more than minimal changes to the compiler
> front-end.

While I agree we'd like to obtain this, I don't think it's realistic...
which probably has a lot to do with why no proposal has (yet) been accepted.

> We do /not/ want this to be part of a function's signature - there is no
> benefit to it,

Wrong: overloading.

Python doesn't have this problem because a) there is no such thing as
separate declarations and definitions in Python, and b) Python has no
overloading, period.

These aren't the case in C++, and trying to ignore the ramifications of
these points as they apply to named arguments is IMO a recipe for failure.

Also, forwarding needs to work somehow. I don't see how this can be done
without making names part of the type system.

> (But the added complexity and implementation effort needed would not
> be worth it - such costly ideas hinder the adoption of the main
> feature. And there would be nothing to stop this being added in some
> way at a later date.)

I disagree; if you make named arguments *not* part of the ABI, I think
it will be very hard to go back and change that decision.

>  foo(.b = 2, .a = 1, 3);

This is confusing, and IMO should be prohibited. Just like it is in Python.

--
Matthew

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

.

On 16/08/18 16:34, Matthew Woehlke wrote:
> On 2018-08-16 07:53, David Brown wrote:
>> I am at a loss to why people key wanting to make this such a complicated
>> issue.
>> [...]
>> 2. The primary use is to check that parameters are given in the right
>> order, with the ability to re-order parameters at the call site as a
>> secondary concern.
>
> ...probably because plenty of people disagree with this point. AFAIAC,
> any proposal that does NOT allow these:
>
>   void foo(int, int :a = 1, int :b = 2, int :c = 12);
>   foo(3, b: 5); // foo(3, 1, 5, 12)

My proposal allows that.  It just doesn't need any change to the
declaration to make it work:

   void foo(int, int a = 1, int b = 2, int c = 12);
   foo(3, b: 5); // foo(3, 1, 5, 12)

(I suggested the syntax "foo(3, .b = 5)" - but I would be perfectly
happy with alternatives like "foo(3, b: 5)".)


>
>   void bar(int :a);
>   void bar(int :x); // distinct overload

> ...is pointless.

I disagree.  Distinct overloads like this would be nice, but (as I
wrote) extremely costly in terms of changes to implementations and
existing software.  I would rather see that as a later enhancement once
we have the simple named parameters in place - my proposal does not
conflict with having this as a later feature.

>
> Checking argument order is, IMHO, not only *not* "the
> primary use", but *optional*.

Checking argument order is absolutely the key point in terms of helping
people write correct code by spotting errors at compile time.  It is
also key to making code clearer by documenting parameters better without
ugly "/* parameter_name */" comments.

Those would be two /huge/ benefits to today's language, and can be
implemented easily and cheaply.

Allowing a re-arrangement of the order of parameters would be another
big benefit for not much higher cost, and is also something I would want.

The cost-benefit relation for name-based overload is very different.
While I would also like it, I would hate to see simple, useful named
parameters blocked or delayed while people fight over this feature.

>
>> 3. It should not require changes to existing code, new ABIs, new object
>> file formats, or anything more than minimal changes to the compiler
>> front-end.
>
> While I agree we'd like to obtain this, I don't think it's realistic...
> which probably has a lot to do with why no proposal has (yet) been accepted.

My proposal would not require any changes to these things.  The reason
no proposal has been accepted is because people demand too much - such
as name-based overloads - that block the simple features.

>
>> We do /not/ want this to be part of a function's signature - there is no
>> benefit to it,
>
> Wrong: overloading.

Yes, you are right - you need the names to be part of the signature for
name-based overloading.  That is a key reason why name-based overloading
should not be part of a first step for named parameters - it avoids this
massive change.

>
> Python doesn't have this problem because a) there is no such thing as
> separate declarations and definitions in Python, and b) Python has no
> overloading, period.
>
> These aren't the case in C++, and trying to ignore the ramifications of
> these points as they apply to named arguments is IMO a recipe for failure.
>
> Also, forwarding needs to work somehow. I don't see how this can be done
> without making names part of the type system.
>

It is very simple - as long as you drop name-based overloading.  Named
parameters can be based purely and completely on function declarations -
nothing else.  If you want to forward to different function, use the
names declared for that function.  If you want to use a function
pointer, use the names given in the declaration for that function
pointer.  If there are no names given, you can't use named parameters.

>> (But the added complexity and implementation effort needed would not
>> be worth it - such costly ideas hinder the adoption of the main
>> feature. And there would be nothing to stop this being added in some
>> way at a later date.)
>
> I disagree; if you make named arguments *not* part of the ABI, I think
> it will be very hard to go back and change that decision.
>

I think it is important to consider how they might be added later, and
what effect that would have - and if possible leave the door open for
name-based overloads in future versions.

But if the choice came down to named parameters without name-based
overloads implemented now, or waiting for an all-singing all-dancing
version some time in the future, I have not the slightest doubt which I
would pick.


>>  foo(.b = 2, .a = 1, 3);
>
> This is confusing, and IMO should be prohibited. Just like it is in Python.
>

I would not object to it being prohibited.


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

.

------=_Part_426_1656525480.1534434121700
Content-Type: multipart/alternative;
 boundary="----=_Part_427_1333116341.1534434121700"

------=_Part_427_1333116341.1534434121700
Content-Type: text/plain; charset="UTF-8"

Designated initializers effectively gives you most of these features. That
is, if you declare your function as taking a single aggregate of
parameters, you can get about 90% of what you want.

A function with named parameters would have that set of named parameters as
part of its ABI:

struct FoosParams {int x; int y;};
void foo(FoosParams params);

You would have the ability to call it with or without names, but you can't
mix-and-match:

foo({.x = 5, .y = 12});
foo({5, 12});
foo({.x = 5, 12}); //ill-formed

You can have default parameters without positional order:

struct FoosParams {int x = 5; int y;}
void foo(FoosParams params);
foo({.y = 12});

It even allows meaningful overloading on "names" alone:

struct complex_ri {double r, double i};
struct complex_rt {double r, double theta_rad};

//Constructors

complex(complex_ri ri);
complex(complex_rt rt);

//usage
complex a({.r = 5.0d, .i = 3.0d});
complex b({.r = 4.2d, .theta_rad = 2});
complex c({5.0d, 3.0d}); //ill-formed, due to call ambiguity.

I believe that works with designated initializes in C++20, but I admittedly
have not studied the proposal that closely. So it may not work.

This even works through forwarding, but it does require you to explicitly
name the `FoosParams` type at the call site:

std::function<void(FoosParams)> foofunctor = &foo;
foofunctor(FoosParams{.x = 5, .y = 12});

Now of course, this way of handling named parameters causes a bunch of
warts. Anytime you want to create such a function, you have to explicitly
create a type for it. Forwarding, or any usage of the signature, requires
using that typename. And while you can forward them, the forwarding
function only sees it as a single struct, not a set of values. This makes
doing things like transforming parameters impossible (well, without
reflection, and even then, your code would have to assume that the single
struct is a set of "parameters" to be transformed). And so forth.

But overall, it gets the job done without language changes. It's not clean,
so it won't be used universally or anything, but it works well enough that
it can be used in places where the ambiguity of a call is worse than having
to pass a struct.

The way I see it, the only reason to promote named parameters to a language
feature is to make usage of them more widespread. That is, rather than
restricting them to cases of significant ambiguity where the cost of a
struct is better than without it, you would be able to use them in cases
where you don't really have to.

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

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

<div dir=3D"ltr"><div>Designated initializers effectively gives you most of=
 these features. That is, if you declare your function as taking a single a=
ggregate of parameters, you can get about 90% of what you want.</div><div><=
br></div><div>A function with named parameters would have that set of named=
 parameters as part of its ABI:</div><div><br></div>struct FoosParams {int =
x; int y;};<br>void foo(FoosParams params);<div></div><div><br>You would ha=
ve the ability to call it with or without names, but you can&#39;t mix-and-=
match:</div><div><br></div><div>foo({.x =3D 5, .y =3D 12});<br>foo({5, 12})=
;<br>foo({.x =3D 5, 12}); //ill-formed<br></div><br><div>You can have defau=
lt parameters without positional order:</div><div><br></div><div>struct Foo=
sParams {int x =3D 5; int y;}<br>void foo(FoosParams params);<br>foo({.y =
=3D 12});<br></div><br><div>It even allows meaningful overloading on &quot;=
names&quot; alone:</div><div><br></div>struct complex_ri {double r, double =
i};<br>struct complex_rt {double r, double theta_rad};<br><br>//Constructor=
s<br><br>complex(complex_ri ri);<br>complex(complex_rt rt);<br><br>//usage<=
br>complex a({.r =3D 5.0d, .i =3D 3.0d});<br>complex b({.r =3D 4.2d, .theta=
_rad =3D 2});<br>complex c({5.0d, 3.0d}); //ill-formed, due to call ambigui=
ty.<div><br></div><div>I believe that works with designated initializes in =
C++20, but I admittedly have not studied the proposal that closely. So it m=
ay not work.<br></div><div><br></div><div>This even works through forwardin=
g, but it does require you to explicitly name the `FoosParams` type at the =
call site:</div><div><br></div>std::function&lt;void(FoosParams)&gt; foofun=
ctor =3D &amp;foo;<br>foofunctor(FoosParams{.x =3D 5, .y =3D 12});<br><div>=
<br></div><div>Now of course, this way of handling named parameters causes =
a bunch of warts. Anytime you want to create such a function, you have to e=
xplicitly create a type for it. Forwarding, or any usage of the signature, =
requires using that typename. And while you can forward them, the forwardin=
g function only sees it as a single struct, not a set of values. This makes=
 doing things like transforming parameters impossible (well, without reflec=
tion, and even then, your code would have to assume that the single struct =
is a set of &quot;parameters&quot; to be transformed). And so forth.</div><=
div><br></div><div>But overall, it gets the job done without language chang=
es. It&#39;s not clean, so it won&#39;t be used universally or anything, bu=
t it works well enough that it can be used in places where the ambiguity of=
 a call is worse than having to pass a struct.</div><div><br></div><div>The=
 way I see it, the only reason to promote named parameters to a language fe=
ature is to make usage of them more widespread. That is, rather than restri=
cting them to cases of significant ambiguity where the cost of a struct is =
better than without it, you would be able to use them in cases where you do=
n&#39;t really have to.<br></div></div>

<p></p>

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

------=_Part_427_1333116341.1534434121700--

------=_Part_426_1656525480.1534434121700--

.

------=_Part_422_1977040671.1534434302593
Content-Type: multipart/alternative;
 boundary="----=_Part_423_893001457.1534434302593"

------=_Part_423_893001457.1534434302593
Content-Type: text/plain; charset="UTF-8"



On Thursday, August 16, 2018 at 5:34:58 PM UTC+3, Matthew Woehlke wrote:
>
> On 2018-08-16 07:53, David Brown wrote:
> > I am at a loss to why people key wanting to make this such a complicated
> > issue.
> > [...]
> > 2. The primary use is to check that parameters are given in the right
> > order, with the ability to re-order parameters at the call site as a
> > secondary concern.
>
> ...probably because plenty of people disagree with this point. AFAIAC,
> any proposal that does NOT allow these:
>
>   void foo(int, int :a = 1, int :b = 2, int :c = 12);
>   foo(3, b: 5); // foo(3, 1, 5, 12)
>
>   void bar(int :a);
>   void bar(int :x); // distinct overload
>
> ...is pointless. Checking argument order is, IMHO, not only *not* "the
> primary use", but *optional*.
>

Names part of the signature makes them mandatory. There are plenty of ways
to do that today - types, tags, function names.
And all work with forwarding.

I might disagree on a lot of points with the OP, but the primary goal is to
confirm parameters are semantically correct when that meaning is hard,
incorrect or clumsy to express as a separate type.
Bonus is defaulted-params-in-the-middle which will enable foo(3, a:, b: 5);
and *eventually* a bonus rearrange.


>
> > 3. It should not require changes to existing code, new ABIs, new object
> > file formats, or anything more than minimal changes to the compiler
> > front-end.
>
> While I agree we'd like to obtain this, I don't think it's realistic...
> which probably has a lot to do with why no proposal has (yet) been
> accepted.
>
> > We do /not/ want this to be part of a function's signature - there is no
> > benefit to it,
>
> Wrong: overloading.
>
> Python doesn't have this problem because a) there is no such thing as
> separate declarations and definitions in Python, and b) Python has no
> overloading, period.
>
> These aren't the case in C++, and trying to ignore the ramifications of
> these points as they apply to named arguments is IMO a recipe for failure.
>
> Also, forwarding needs to work somehow. I don't see how this can be done
> without making names part of the type system.
>
> > (But the added complexity and implementation effort needed would not
> > be worth it - such costly ideas hinder the adoption of the main
> > feature. And there would be nothing to stop this being added in some
> > way at a later date.)
>
> I disagree; if you make named arguments *not* part of the ABI, I think
> it will be very hard to go back and change that decision.
>
> >         foo(.b = 2, .a = 1, 3);
>
> This is confusing, and IMO should be prohibited. Just like it is in
> Python.
>
> --
> Matthew
>

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

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

<div dir=3D"ltr"><br><br>On Thursday, August 16, 2018 at 5:34:58 PM UTC+3, =
Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2018-=
08-16 07:53, David Brown wrote:
<br>&gt; I am at a loss to why people key wanting to make this such a compl=
icated
<br>&gt; issue.
<br>&gt; [...]
<br>&gt; 2. The primary use is to check that parameters are given in the ri=
ght
<br>&gt; order, with the ability to re-order parameters at the call site as=
 a
<br>&gt; secondary concern.
<br>
<br>...probably because plenty of people disagree with this point. AFAIAC,
<br>any proposal that does NOT allow these:
<br>
<br>=C2=A0 void foo(int, int :a =3D 1, int :b =3D 2, int :c =3D 12);
<br>=C2=A0 foo(3, b: 5); // foo(3, 1, 5, 12)
<br>
<br>=C2=A0 void bar(int :a);
<br>=C2=A0 void bar(int :x); // distinct overload
<br>
<br>...is pointless. Checking argument order is, IMHO, not only *not* &quot=
;the
<br>primary use&quot;, but *optional*.
<br></blockquote><div><br></div><div>Names part of the signature makes them=
 mandatory. There are plenty of ways to do that today - types, tags, functi=
on names.</div><div>And all work with forwarding.=C2=A0</div><div><br></div=
><div>I might disagree on a lot of points with the OP, but the primary goal=
 is to confirm parameters are semantically correct when that meaning is har=
d, incorrect or clumsy to express as a separate type.</div><div>Bonus is de=
faulted-params-in-the-middle which will enable=C2=A0<font face=3D"courier n=
ew, monospace">foo(3, a:, b: 5);=C2=A0</font>and=C2=A0<i>eventually</i>=C2=
=A0a bonus rearrange.=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;">
<br>&gt; 3. It should not require changes to existing code, new ABIs, new o=
bject
<br>&gt; file formats, or anything more than minimal changes to the compile=
r
<br>&gt; front-end.
<br>
<br>While I agree we&#39;d like to obtain this, I don&#39;t think it&#39;s =
realistic...
<br>which probably has a lot to do with why no proposal has (yet) been acce=
pted.
<br>
<br>&gt; We do /not/ want this to be part of a function&#39;s signature - t=
here is no
<br>&gt; benefit to it,
<br>
<br>Wrong: overloading.
<br>
<br>Python doesn&#39;t have this problem because a) there is no such thing =
as
<br>separate declarations and definitions in Python, and b) Python has no
<br>overloading, period.
<br>
<br>These aren&#39;t the case in C++, and trying to ignore the ramification=
s of
<br>these points as they apply to named arguments is IMO a recipe for failu=
re.
<br>
<br>Also, forwarding needs to work somehow. I don&#39;t see how this can be=
 done
<br>without making names part of the type system.
<br>
<br>&gt; (But the added complexity and implementation effort needed would n=
ot
<br>&gt; be worth it - such costly ideas hinder the adoption of the main
<br>&gt; feature. And there would be nothing to stop this being added in so=
me
<br>&gt; way at a later date.)
<br>
<br>I disagree; if you make named arguments *not* part of the ABI, I think
<br>it will be very hard to go back and change that decision.
<br>
<br>&gt; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0foo(.b =3D 2, .a =
=3D 1, 3);
<br>
<br>This is confusing, and IMO should be prohibited. Just like it is in Pyt=
hon.
<br>
<br>--=20
<br>Matthew
<br></blockquote></div>

<p></p>

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

------=_Part_423_893001457.1534434302593--

------=_Part_422_1977040671.1534434302593--

.

------=_Part_411_856894243.1534435329854
Content-Type: multipart/alternative;
 boundary="----=_Part_412_1200471754.1534435329855"

------=_Part_412_1200471754.1534435329855
Content-Type: text/plain; charset="UTF-8"



On Thursday, August 16, 2018 at 6:42:01 PM UTC+3, Nicol Bolas wrote:
>
> Designated initializers effectively gives you most of these features. That
> is, if you declare your function as taking a single aggregate of
> parameters, you can get about 90% of what you want.
>
> A function with named parameters would have that set of named parameters
> as part of its ABI:
>
> struct FoosParams {int x; int y;};
> void foo(FoosParams params);
>
> You would have the ability to call it with or without names, but you can't
> mix-and-match:
>
> foo({.x = 5, .y = 12});
> foo({5, 12});
> foo({.x = 5, 12}); //ill-formed
>
> You can have default parameters without positional order:
>
> struct FoosParams {int x = 5; int y;}
> void foo(FoosParams params);
> foo({.y = 12});
>
> It even allows meaningful overloading on "names" alone:
>
> struct complex_ri {double r, double i};
> struct complex_rt {double r, double theta_rad};
>
> //Constructors
>
> complex(complex_ri ri);
> complex(complex_rt rt);
>
> //usage
> complex a({.r = 5.0d, .i = 3.0d});
> complex b({.r = 4.2d, .theta_rad = 2});
> complex c({5.0d, 3.0d}); //ill-formed, due to call ambiguity.
>
> I believe that works with designated initializes in C++20, but I
> admittedly have not studied the proposal that closely. So it may not work.
>
> This even works through forwarding, but it does require you to explicitly
> name the `FoosParams` type at the call site:
>
> std::function<void(FoosParams)> foofunctor = &foo;
> foofunctor(FoosParams{.x = 5, .y = 12});
>
> Now of course, this way of handling named parameters causes a bunch of
> warts. Anytime you want to create such a function, you have to explicitly
> create a type for it. Forwarding, or any usage of the signature, requires
> using that typename. And while you can forward them, the forwarding
> function only sees it as a single struct, not a set of values. This makes
> doing things like transforming parameters impossible (well, without
> reflection, and even then, your code would have to assume that the single
> struct is a set of "parameters" to be transformed). And so forth.
>

Add to all this,
 - no IntelliSense will ever help you ,
 - the implementation is severely affected (structured bindings to the
rescue I guess...)
 - overloading is surreal


>
> But overall, it gets the job done without language changes. It's not
> clean, so it won't be used universally or anything, but it works well
> enough that it can be used in places where the ambiguity of a call is worse
> than having to pass a struct.
>
> The way I see it, the only reason to promote named parameters to a
> language feature is to make usage of them more widespread. That is, rather
> than restricting them to cases of significant ambiguity where the cost of a
> struct is better than without it, you would be able to use them in cases
> where you don't really have to.
>

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

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

<div dir=3D"ltr"><br><br>On Thursday, August 16, 2018 at 6:42:01 PM UTC+3, =
Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div>Designated initializers effectively gives you most of these featu=
res. That is, if you declare your function as taking a single aggregate of =
parameters, you can get about 90% of what you want.</div><div><br></div><di=
v>A function with named parameters would have that set of named parameters =
as part of its ABI:</div><div><br></div>struct FoosParams {int x; int y;};<=
br>void foo(FoosParams params);<div></div><div><br>You would have the abili=
ty to call it with or without names, but you can&#39;t mix-and-match:</div>=
<div><br></div><div>foo({.x =3D 5, .y =3D 12});<br>foo({5, 12});<br>foo({.x=
 =3D 5, 12}); //ill-formed<br></div><br><div>You can have default parameter=
s without positional order:</div><div><br></div><div>struct FoosParams {int=
 x =3D 5; int y;}<br>void foo(FoosParams params);<br>foo({.y =3D 12});<br><=
/div><br><div>It even allows meaningful overloading on &quot;names&quot; al=
one:</div><div><br></div>struct complex_ri {double r, double i};<br>struct =
complex_rt {double r, double theta_rad};<br><br>//Constructors<br><br>compl=
ex(complex_ri ri);<br>complex(complex_rt rt);<br><br>//usage<br>complex a({=
..r =3D 5.0d, .i =3D 3.0d});<br>complex b({.r =3D 4.2d, .theta_rad =3D 2});<=
br>complex c({5.0d, 3.0d}); //ill-formed, due to call ambiguity.<div><br></=
div><div>I believe that works with designated initializes in C++20, but I a=
dmittedly have not studied the proposal that closely. So it may not work.<b=
r></div><div><br></div><div>This even works through forwarding, but it does=
 require you to explicitly name the `FoosParams` type at the call site:</di=
v><div><br></div>std::function&lt;void(FoosParams)<wbr>&gt; foofunctor =3D =
&amp;foo;<br>foofunctor(FoosParams{.x =3D 5, .y =3D 12});<br><div><br></div=
><div>Now of course, this way of handling named parameters causes a bunch o=
f warts. Anytime you want to create such a function, you have to explicitly=
 create a type for it. Forwarding, or any usage of the signature, requires =
using that typename. And while you can forward them, the forwarding functio=
n only sees it as a single struct, not a set of values. This makes doing th=
ings like transforming parameters impossible (well, without reflection, and=
 even then, your code would have to assume that the single struct is a set =
of &quot;parameters&quot; to be transformed). And so forth.</div></div></bl=
ockquote><div><br></div><div>Add to all this,=C2=A0</div><div>=C2=A0- no In=
telliSense will ever help you ,=C2=A0</div><div>=C2=A0- the implementation =
is severely affected (structured bindings to the rescue I guess...)</div><d=
iv>=C2=A0- overloading is surreal=C2=A0</div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><div>But ov=
erall, it gets the job done without language changes. It&#39;s not clean, s=
o it won&#39;t be used universally or anything, but it works well enough th=
at it can be used in places where the ambiguity of a call is worse than hav=
ing to pass a struct.</div><div><br></div><div>The way I see it, the only r=
eason to promote named parameters to a language feature is to make usage of=
 them more widespread. That is, rather than restricting them to cases of si=
gnificant ambiguity where the cost of a struct is better than without it, y=
ou would be able to use them in cases where you don&#39;t really have to.<b=
r></div></div></blockquote></div>

<p></p>

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

------=_Part_412_1200471754.1534435329855--

------=_Part_411_856894243.1534435329854--

.

On 2018-08-16 10:53, David Brown wrote:
> On 16/08/18 16:34, Matthew Woehlke wrote:
>> Checking argument order is, IMHO, not only *not* "the
>> primary use", but *optional*.
>
> Checking argument order is absolutely the key point in terms of helping
> people write correct code by spotting errors at compile time.  It is
> also key to making code clearer by documenting parameters better without
> ugly "/* parameter_name */" comments.
>
> Those would be two /huge/ benefits to today's language, and can be
> implemented easily and cheaply.

While I don't disagree with that, exactly, I also don't see it as a
compelling benefit. For me, named arguments are *primarily* about fixing
the problem of needing extremely flexible functions (read: large number
of parameters and/or large number of overloads) of which any *one* user
is only going to care about a small slice of the total surface area. I
only care about argument order to the extent it is useful in solving
that problem. Thus, for me, *the* killer features are being able to
specify one parameter in the middle of a list of defaulted parameters,
and/or to overload on parameter names.

If I don't get those, I'd rather not muddy the feature space with
anything else.

> Yes, you are right - you need the names to be part of the signature for
> name-based overloading.  That is a key reason why name-based overloading
> should not be part of a first step for named parameters - it avoids this
> massive change.
> [...]
> [Forwarding] is very simple - as long as you drop name-based overloading.
> [...]
> I think it is important to consider how they might be added later, and
> what effect that would have - and if possible leave the door open for
> name-based overloads in future versions.

Right, so... here's an experiment. Explain how we could *later* add
name-based overloading on top of your proposal.

If you can't do that, then accepting your proposal means we can *never*
have name-based overloading. Which means everyone that wants that is
going to be opposed to your proposal.

If you *can* do that, I think it would make your proposal much more
compelling.

--
Matthew

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

.

------=_Part_416_1568735611.1534436939644
Content-Type: multipart/alternative;
 boundary="----=_Part_417_816888617.1534436939644"

------=_Part_417_816888617.1534436939644
Content-Type: text/plain; charset="UTF-8"



On Thursday, August 16, 2018 at 12:02:09 PM UTC-4, mihailn...@gmail.com
wrote:
>
>
>
> On Thursday, August 16, 2018 at 6:42:01 PM UTC+3, Nicol Bolas wrote:
>>
>> Designated initializers effectively gives you most of these features.
>> That is, if you declare your function as taking a single aggregate of
>> parameters, you can get about 90% of what you want.
>>
>> A function with named parameters would have that set of named parameters
>> as part of its ABI:
>>
>> struct FoosParams {int x; int y;};
>> void foo(FoosParams params);
>>
>> You would have the ability to call it with or without names, but you
>> can't mix-and-match:
>>
>> foo({.x = 5, .y = 12});
>> foo({5, 12});
>> foo({.x = 5, 12}); //ill-formed
>>
>> You can have default parameters without positional order:
>>
>> struct FoosParams {int x = 5; int y;}
>> void foo(FoosParams params);
>> foo({.y = 12});
>>
>> It even allows meaningful overloading on "names" alone:
>>
>> struct complex_ri {double r, double i};
>> struct complex_rt {double r, double theta_rad};
>>
>> //Constructors
>>
>> complex(complex_ri ri);
>> complex(complex_rt rt);
>>
>> //usage
>> complex a({.r = 5.0d, .i = 3.0d});
>> complex b({.r = 4.2d, .theta_rad = 2});
>> complex c({5.0d, 3.0d}); //ill-formed, due to call ambiguity.
>>
>> I believe that works with designated initializes in C++20, but I
>> admittedly have not studied the proposal that closely. So it may not work.
>>
>> This even works through forwarding, but it does require you to explicitly
>> name the `FoosParams` type at the call site:
>>
>> std::function<void(FoosParams)> foofunctor = &foo;
>> foofunctor(FoosParams{.x = 5, .y = 12});
>>
>> Now of course, this way of handling named parameters causes a bunch of
>> warts. Anytime you want to create such a function, you have to explicitly
>> create a type for it. Forwarding, or any usage of the signature, requires
>> using that typename. And while you can forward them, the forwarding
>> function only sees it as a single struct, not a set of values. This makes
>> doing things like transforming parameters impossible (well, without
>> reflection, and even then, your code would have to assume that the single
>> struct is a set of "parameters" to be transformed). And so forth.
>>
>
> Add to all this,
>

"And so forth" means that the list is not comprehensive. But that being
said:


>  - no IntelliSense will ever help you ,
>

In what way will it not ever help you? Can't intellisense work with
aggregate initialization or list initialization in general? It should be
easy enough for it to figure out the possible overloads and, when you open
the first brace, list possibilities for designated or positional list
arguments.

Maybe such tools aren't not smart enough to do that at present, but I see
no reason why it would be impossible for them to provide help.

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

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

<div dir=3D"ltr"><br><br>On Thursday, August 16, 2018 at 12:02:09 PM UTC-4,=
 mihailn...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><br><br>On Thursday, August 16, 2018 at 6:42:01 PM UTC+3, Ni=
col Bolas 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"><d=
iv>Designated initializers effectively gives you most of these features. Th=
at is, if you declare your function as taking a single aggregate of paramet=
ers, you can get about 90% of what you want.</div><div><br></div><div>A fun=
ction with named parameters would have that set of named parameters as part=
 of its ABI:</div><div><br></div>struct FoosParams {int x; int y;};<br>void=
 foo(FoosParams params);<div></div><div><br>You would have the ability to c=
all it with or without names, but you can&#39;t mix-and-match:</div><div><b=
r></div><div>foo({.x =3D 5, .y =3D 12});<br>foo({5, 12});<br>foo({.x =3D 5,=
 12}); //ill-formed<br></div><br><div>You can have default parameters witho=
ut positional order:</div><div><br></div><div>struct FoosParams {int x =3D =
5; int y;}<br>void foo(FoosParams params);<br>foo({.y =3D 12});<br></div><b=
r><div>It even allows meaningful overloading on &quot;names&quot; alone:</d=
iv><div><br></div>struct complex_ri {double r, double i};<br>struct complex=
_rt {double r, double theta_rad};<br><br>//Constructors<br><br>complex(comp=
lex_ri ri);<br>complex(complex_rt rt);<br><br>//usage<br>complex a({.r =3D =
5.0d, .i =3D 3.0d});<br>complex b({.r =3D 4.2d, .theta_rad =3D 2});<br>comp=
lex c({5.0d, 3.0d}); //ill-formed, due to call ambiguity.<div><br></div><di=
v>I believe that works with designated initializes in C++20, but I admitted=
ly have not studied the proposal that closely. So it may not work.<br></div=
><div><br></div><div>This even works through forwarding, but it does requir=
e you to explicitly name the `FoosParams` type at the call site:</div><div>=
<br></div>std::function&lt;void(FoosParams)<wbr>&gt; foofunctor =3D &amp;fo=
o;<br>foofunctor(FoosParams{.x =3D 5, .y =3D 12});<br><div><br></div><div>N=
ow of course, this way of handling named parameters causes a bunch of warts=
.. Anytime you want to create such a function, you have to explicitly create=
 a type for it. Forwarding, or any usage of the signature, requires using t=
hat typename. And while you can forward them, the forwarding function only =
sees it as a single struct, not a set of values. This makes doing things li=
ke transforming parameters impossible (well, without reflection, and even t=
hen, your code would have to assume that the single struct is a set of &quo=
t;parameters&quot; to be transformed). And so forth.</div></div></blockquot=
e><div><br></div><div>Add to all this,=C2=A0</div></div></blockquote><div><=
br></div><div>&quot;And so forth&quot; means that the list is not comprehen=
sive. But that being said:<br></div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"><div>=C2=A0- no IntelliSense will e=
ver help you ,=C2=A0</div></div></blockquote><div><br></div><div>In what wa=
y will it not ever help you? Can&#39;t intellisense work with aggregate ini=
tialization or list initialization in general? It should be easy enough for=
 it to figure out the possible overloads and, when you open the first brace=
, list possibilities for designated or positional list arguments.</div><div=
><br></div><div>Maybe such tools aren&#39;t not smart enough to do that at =
present, but I see no reason why it would be impossible for them to provide=
 help.</div><br></div>

<p></p>

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

------=_Part_417_816888617.1534436939644--

------=_Part_416_1568735611.1534436939644--

.

> From: Nicol Bolas <jmckesson@gmail.com>
> Sent: Thursday, August 16, 2018 10:42 AM
>
> You would have the ability to call it with or without names, but you can't mix-and-match:
>
> foo({.x = 5, .y = 12});
> foo({5, 12});
> foo({.x = 5, 12}); //ill-formed

This may be extended to at least allow
an _initializer-list_ as a prefix.

> It even allows meaningful overloading on "names" alone:
>
> complex a({.r = 5.0d, .i = 3.0d});
> complex b({.r = 4.2d, .theta_rad = 2});

This is deliberately not allowed.

> And while you can forward them, the forwarding function only sees it as a single struct, not a set of values.

Some authors believe that if we get some form of
named parameters in the future, its semantics
should be equivalent to decomposing such a struct
with a compiler synthesized structured binding.

--
You received this message because you are 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 mailto:std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to mailto:std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5d064165-5a58-4810-90f7-aa3732be92db%40isocpp.org?utm_medium=email&utm_source=footer.


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

.

------=_Part_467_227900228.1534439444304
Content-Type: multipart/alternative;
 boundary="----=_Part_468_1830355490.1534439444305"

------=_Part_468_1830355490.1534439444305
Content-Type: text/plain; charset="UTF-8"



On Thursday, August 16, 2018 at 7:25:22 PM UTC+3, Matthew Woehlke wrote:
>
> On 2018-08-16 10:53, David Brown wrote:
> > On 16/08/18 16:34, Matthew Woehlke wrote:
> >> Checking argument order is, IMHO, not only *not* "the
> >> primary use", but *optional*.
> >
> > Checking argument order is absolutely the key point in terms of helping
> > people write correct code by spotting errors at compile time.  It is
> > also key to making code clearer by documenting parameters better without
> > ugly "/* parameter_name */" comments.
> >
> > Those would be two /huge/ benefits to today's language, and can be
> > implemented easily and cheaply.
>
> While I don't disagree with that, exactly, I also don't see it as a
> compelling benefit. For me, named arguments are *primarily* about fixing
> the problem of needing extremely flexible functions (read: large number
> of parameters and/or large number of overloads) of which any *one* user
> is only going to care about a small slice of the total surface area. I
> only care about argument order to the extent it is useful in solving
> that problem. Thus, for me, *the* killer features are being able to
> specify one parameter in the middle of a list of defaulted parameters,
> and/or to overload on parameter names.
>

Why overloading is so important to you? Because the first request is doable
(default-by-mention or full rearrange), but the last is a *nightmare* to
define *and* is doable today via workarounds.

Can you please define names change the signature? Is this some sort of
name-type pair? Is it a tag? Is this pure compiler help or part of the type
system?

And again, why is a killer?


>
> If I don't get those, I'd rather not muddy the feature space with
> anything else.
>
> > Yes, you are right - you need the names to be part of the signature for
> > name-based overloading.  That is a key reason why name-based overloading
> > should not be part of a first step for named parameters - it avoids this
> > massive change.
> > [...]
> > [Forwarding] is very simple - as long as you drop name-based
> overloading.
> > [...]
> > I think it is important to consider how they might be added later, and
> > what effect that would have - and if possible leave the door open for
> > name-based overloads in future versions.
>
> Right, so... here's an experiment. Explain how we could *later* add
> name-based overloading on top of your proposal.
>
> If you can't do that, then accepting your proposal means we can *never*
> have name-based overloading. Which means everyone that wants that is
> going to be opposed to your proposal.
>
> If you *can* do that, I think it would make your proposal much more
> compelling.
>
> --
> Matthew
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/77719fdf-0f81-4c24-ad56-91826ef73032%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Thursday, August 16, 2018 at 7:25:22 PM UTC+3, =
Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2018-=
08-16 10:53, David Brown wrote:
<br>&gt; On 16/08/18 16:34, Matthew Woehlke wrote:
<br>&gt;&gt; Checking argument order is, IMHO, not only *not* &quot;the
<br>&gt;&gt; primary use&quot;, but *optional*.
<br>&gt;=20
<br>&gt; Checking argument order is absolutely the key point in terms of he=
lping
<br>&gt; people write correct code by spotting errors at compile time. =C2=
=A0It is
<br>&gt; also key to making code clearer by documenting parameters better w=
ithout
<br>&gt; ugly &quot;/* parameter_name */&quot; comments.
<br>&gt;=20
<br>&gt; Those would be two /huge/ benefits to today&#39;s language, and ca=
n be
<br>&gt; implemented easily and cheaply.
<br>
<br>While I don&#39;t disagree with that, exactly, I also don&#39;t see it =
as a
<br>compelling benefit. For me, named arguments are *primarily* about fixin=
g
<br>the problem of needing extremely flexible functions (read: large number
<br>of parameters and/or large number of overloads) of which any *one* user
<br>is only going to care about a small slice of the total surface area. I
<br>only care about argument order to the extent it is useful in solving
<br>that problem. Thus, for me, *the* killer features are being able to
<br>specify one parameter in the middle of a list of defaulted parameters,
<br>and/or to overload on parameter names.
<br></blockquote><div><br></div><div>Why overloading is so important to you=
? Because the first request is doable (default-by-mention or full rearrange=
), but the last is a <i>nightmare</i> to define <i>and</i> is doable today =
via workarounds.=C2=A0</div><div><br></div><div>Can you please define names=
 change the signature? Is this some sort of name-type pair? Is it a tag? Is=
 this pure compiler help or part of the type system?=C2=A0</div><div><br></=
div><div>And again, why is a killer?</div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;">
<br>If I don&#39;t get those, I&#39;d rather not muddy the feature space wi=
th
<br>anything else.
<br>
<br>&gt; Yes, you are right - you need the names to be part of the signatur=
e for
<br>&gt; name-based overloading. =C2=A0That is a key reason why name-based =
overloading
<br>&gt; should not be part of a first step for named parameters - it avoid=
s this
<br>&gt; massive change.
<br>&gt; [...]
<br>&gt; [Forwarding] is very simple - as long as you drop name-based overl=
oading.
<br>&gt; [...]
<br>&gt; I think it is important to consider how they might be added later,=
 and
<br>&gt; what effect that would have - and if possible leave the door open =
for
<br>&gt; name-based overloads in future versions.
<br>
<br>Right, so... here&#39;s an experiment. Explain how we could *later* add
<br>name-based overloading on top of your proposal.
<br>
<br>If you can&#39;t do that, then accepting your proposal means we can *ne=
ver*
<br>have name-based overloading. Which means everyone that wants that is
<br>going to be opposed to your proposal.
<br>
<br>If you *can* do that, I think it would make your proposal much more
<br>compelling.
<br>
<br>--=20
<br>Matthew
<br></blockquote></div>

<p></p>

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

------=_Part_468_1830355490.1534439444305--

------=_Part_467_227900228.1534439444304--

.

On 2018-08-16 13:10, mihailnajdenov@gmail.com wrote:
> Why overloading is so important to you? Because the first request is doable
> (default-by-mention or full rearrange), but the last is a *nightmare* to
> define *and* is doable today via workarounds.

  vector<int> x{values: 1};
  vector<int> x{reserve: 1};

  complex{imag: 1};
  complex{r: 1, t: 90};

Is it *killer*? Maybe, maybe not. But that's not the point. IMHO, the
burden of proof should be on the one(s) arguing for an implementation
that seems to preclude *ever* getting name overload to either show a)
why we will *never* need/want this feature, or b) how it could still be
implemented, later.

I'd rather have no feature than a half-baked feature that can't ever be
made better.

--
Matthew

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

.

------=_Part_495_700288707.1534444803754
Content-Type: multipart/alternative;
 boundary="----=_Part_496_94024937.1534444803755"

------=_Part_496_94024937.1534444803755
Content-Type: text/plain; charset="UTF-8"



On Thursday, August 16, 2018 at 8:29:33 PM UTC+3, Matthew Woehlke wrote:
>
> On 2018-08-16 13:10, mihailn...@gmail.com <javascript:> wrote:
> > Why overloading is so important to you? Because the first request is
> doable
> > (default-by-mention or full rearrange), but the last is a *nightmare* to
> > define *and* is doable today via workarounds.
>
>   vector<int> x{values: 1};
>   vector<int> x{reserve: 1};
>
>   complex{imag: 1};
>   complex{r: 1, t: 90};
>
> Is it *killer*? Maybe, maybe not. But that's not the point. IMHO, the
> burden of proof should be on the one(s) arguing for an implementation
> that seems to preclude *ever* getting name overload to either show a)
> why we will *never* need/want this feature, or b) how it could still be
> implemented, later.
>
> I'd rather have no feature than a half-baked feature that can't ever be
> made better.
>

The point was to define how it would work.

  vector<int> x{values: 1};
  vector<int> x{reserve: 1};

This is doable with tags. And we can improve them
<https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2GXb0/4OjT5Z4pBQAJ>

  complex{imag: 1};
  complex{r: 1, t: 90};

This is already overloaded, no need for strong names.


BTW, I am not against *any* use case you would come up with, as I said I am
pro named arguments,
not only that, *I believe we need both that change the signature and the
ones that don't!*

However, the ones that *do* change the signature are, in practice, *both
less common and easier to work around*!
And, the ones that do *not* need overload are more common and often very
clumsy to work around.

As for future proofing -  *there is no problem if we support both*

rect(Point topLeft: pos, Point bottomRight: br); //< weak argument names,
not mandatory

// later in some future

rect(center: Point pos, Point bottomRight: br) //< strong argument name,
adds an overload, not ignorable


All the old code will work, but now center: is mandatory and *will*
overload.

How would this work? Well, the easiest is to be a tag, as already explored.
But it could be a modifier to Point or some automagic shortcut to std::pair<"center",
Point>

And again, weak named argument are somewhat easier and not less useful
(unless they are just warnings)
and not mutually exclusive to strong ones!



> --
> Matthew
>

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

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

<div dir=3D"ltr"><br><br>On Thursday, August 16, 2018 at 8:29:33 PM UTC+3, =
Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2018-=
08-16 13:10, <a onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"java=
script:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"r7hI5p=
kVDAAJ">mihailn...@gmail.com</a> wrote:
<br>&gt; Why overloading is so important to you? Because the first request =
is doable=20
<br>&gt; (default-by-mention or full rearrange), but the last is a *nightma=
re* to=20
<br>&gt; define *and* is doable today via workarounds.=20
<br>
<br>=C2=A0 vector&lt;int&gt; x{values: 1};
<br>=C2=A0 vector&lt;int&gt; x{reserve: 1};
<br>
<br>=C2=A0 complex{imag: 1};
<br>=C2=A0 complex{r: 1, t: 90};
<br>
<br>Is it *killer*? Maybe, maybe not. But that&#39;s not the point. IMHO, t=
he
<br>burden of proof should be on the one(s) arguing for an implementation
<br>that seems to preclude *ever* getting name overload to either show a)
<br>why we will *never* need/want this feature, or b) how it could still be
<br>implemented, later.
<br>
<br>I&#39;d rather have no feature than a half-baked feature that can&#39;t=
 ever be
<br>made better.=C2=A0<br></blockquote><div><br></div><div>The point was to=
 define how it would work.</div><div><br style=3D"background-attachment: sc=
roll; background-clip: border-box; background-color: transparent; backgroun=
d-image: none; background-origin: padding-box; background-position-x: 0%; b=
ackground-position-y: 0%; background-repeat: repeat; background-size: auto;=
 border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bo=
ttom-width: 0px; border-image-outset: 0; border-image-repeat: stretch; bord=
er-image-slice: 100%; border-image-source: none; border-image-width: 1; bor=
der-left-color: rgb(34, 34, 34); border-left-style: none; border-left-width=
: 0px; border-right-color: rgb(34, 34, 34); border-right-style: none; borde=
r-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: no=
ne; border-top-width: 0px; color: rgb(34, 34, 34); font-family: &amp;quot;A=
rial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; f=
ont-style: normal; font-variant: normal; font-weight: 400; height: auto; le=
tter-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0=
px; margin-top: 0px; min-width: 0px; orphans: 2; overflow: visible; overflo=
w-x: visible; overflow-y: visible; padding-bottom: 0px; padding-left: 0px; =
padding-right: 0px; padding-top: 0px; text-align: left; text-decoration: no=
ne; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px;=
 white-space: normal; word-spacing: 0px;"></div><div><span style=3D"display=
: inline !important; float: none; background-color: transparent; color: rgb=
(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-ser=
if; font-size: 13px; font-style: normal; font-variant: normal; font-weight:=
 400; letter-spacing: normal; orphans: 2; text-align: left; text-decoration=
: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: =
0px; white-space: normal; word-spacing: 0px;">=C2=A0 vector&lt;int&gt; x{va=
lues: 1};
</span><br style=3D"background-attachment: scroll; background-clip: border-=
box; background-color: transparent; background-image: none; background-orig=
in: padding-box; background-position-x: 0%; background-position-y: 0%; back=
ground-repeat: repeat; background-size: auto; border-bottom-color: rgb(34, =
34, 34); border-bottom-style: none; border-bottom-width: 0px; border-image-=
outset: 0; border-image-repeat: stretch; border-image-slice: 100%; border-i=
mage-source: none; border-image-width: 1; border-left-color: rgb(34, 34, 34=
); border-left-style: none; border-left-width: 0px; border-right-color: rgb=
(34, 34, 34); border-right-style: none; border-right-width: 0px; border-top=
-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; col=
or: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helve=
tica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-varian=
t: normal; font-weight: 400; height: auto; letter-spacing: normal; margin-b=
ottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; min-width=
: 0px; orphans: 2; overflow: visible; overflow-x: visible; overflow-y: visi=
ble; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-to=
p: 0px; text-align: left; text-decoration: none; text-indent: 0px; text-tra=
nsform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spa=
cing: 0px;"><span style=3D"display: inline !important; float: none; backgro=
und-color: transparent; color: rgb(34, 34, 34); font-family: &quot;Arial&qu=
ot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: normal; =
font-variant: normal; font-weight: 400; letter-spacing: normal; orphans: 2;=
 text-align: left; text-decoration: none; text-indent: 0px; text-transform:=
 none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0=
px;">=C2=A0 vector&lt;int&gt; x{reserve: 1};=C2=A0</span></div><div><b></b>=
<i></i><u></u><sub></sub><sup></sup><strike></strike><br></div><div>This is=
 doable with tags. <a href=3D"https://groups.google.com/a/isocpp.org/d/msg/=
std-proposals/tPtdQE2GXb0/4OjT5Z4pBQAJ">And we can improve them</a></div><d=
iv>=C2=A0</div><div><span style=3D"display: inline !important; float: none;=
 background-color: transparent; color: rgb(34, 34, 34); font-family: &quot;=
Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: =
normal; font-variant: normal; font-weight: 400; letter-spacing: normal; orp=
hans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-tr=
ansform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-sp=
acing: 0px;">=C2=A0 complex{imag: 1};
</span><br style=3D"background-attachment: scroll; background-clip: border-=
box; background-color: transparent; background-image: none; background-orig=
in: padding-box; background-position-x: 0%; background-position-y: 0%; back=
ground-repeat: repeat; background-size: auto; border-bottom-color: rgb(34, =
34, 34); border-bottom-style: none; border-bottom-width: 0px; border-image-=
outset: 0; border-image-repeat: stretch; border-image-slice: 100%; border-i=
mage-source: none; border-image-width: 1; border-left-color: rgb(34, 34, 34=
); border-left-style: none; border-left-width: 0px; border-right-color: rgb=
(34, 34, 34); border-right-style: none; border-right-width: 0px; border-top=
-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; col=
or: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helve=
tica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-varian=
t: normal; font-weight: 400; height: auto; letter-spacing: normal; margin-b=
ottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; min-width=
: 0px; orphans: 2; overflow: visible; overflow-x: visible; overflow-y: visi=
ble; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-to=
p: 0px; text-align: left; text-decoration: none; text-indent: 0px; text-tra=
nsform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spa=
cing: 0px;"><span style=3D"display: inline !important; float: none; backgro=
und-color: transparent; color: rgb(34, 34, 34); font-family: &quot;Arial&qu=
ot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: normal; =
font-variant: normal; font-weight: 400; letter-spacing: normal; orphans: 2;=
 text-align: left; text-decoration: none; text-indent: 0px; text-transform:=
 none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0=
px;">=C2=A0 complex{r: 1, t: 90};=C2=A0</span></div><div><b></b><i></i><u><=
/u><sub></sub><sup></sup><strike></strike><br></div><div>This is already ov=
erloaded, no need for strong names.</div><div><br></div><div><br></div><div=
>BTW, I am not against <i>any</i> use case you would come up with, as I sai=
d I am pro named arguments,=C2=A0<br></div><div>not only that, <i>I believe=
 we need both that change the signature and the ones that don&#39;t!</i></d=
iv><div><i></i><br></div><div>However, the ones that <i>do</i> change the s=
ignature are, in practice, <i>both less common and easier to work around</i=
>!=C2=A0<br></div><div>And, the ones that do <i>not</i> need overload are m=
ore common and often very clumsy to work around.</div><div><br></div><div>A=
s for future proofing -=C2=A0 <i>there is no problem if we support both</i>=
</div><div><i></i><br></div><div><font face=3D"Consolas">rect(Point topLeft=
: pos, Point bottomRight: br); //&lt; weak argument names, not mandatory=C2=
=A0</font></div><div><font face=3D"Consolas"><br></font></div><div><font fa=
ce=3D"Consolas">// later in some future</font></div><div><font face=3D"Cons=
olas">=C2=A0</font></div><div><font face=3D"Consolas"><font face=3D"arial,h=
elvetica,sans-serif" style=3D"text-align: left; color: rgb(34, 34, 34); tex=
t-transform: none; line-height: 19.99px; text-indent: 0px; letter-spacing: =
normal; overflow: visible; font-family: arial,helvetica,sans-serif; font-si=
ze: 13.33px; font-variant: normal; word-spacing: 0px; white-space: normal; =
orphans: 2; font-size-adjust: none; font-stretch: 100%; -webkit-text-stroke=
-width: 0px; background-color: transparent;"></font>rect(center: Point pos,=
 Point bottomRight: br) //&lt;=C2=A0<span style=3D"display: inline !importa=
nt; float: none; background-color: transparent; color: rgb(34, 34, 34); fon=
t-family: Consolas; font-size: 13px; font-style: normal; font-variant: norm=
al; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left;=
 text-decoration: none; text-indent: 0px; text-transform: none; -webkit-tex=
t-stroke-width: 0px; white-space: normal; word-spacing: 0px;">strong argume=
nt name, adds an overload, not ignorable </span><font face=3D"arial,helveti=
ca,sans-serif" style=3D"text-align: left; color: rgb(34, 34, 34); text-tran=
sform: none; line-height: 19.99px; text-indent: 0px; letter-spacing: normal=
; overflow: visible; font-family: arial,helvetica,sans-serif; font-size: 13=
..33px; font-variant: normal; word-spacing: 0px; white-space: normal; orphan=
s: 2; font-size-adjust: none; font-stretch: 100%; -webkit-text-stroke-width=
: 0px; background-color: transparent;"></font><b></b><i></i><u></u><sub></s=
ub><sup></sup><strike></strike><br></font><font face=3D"arial,helvetica,san=
s-serif" style=3D"text-align: left; color: rgb(34, 34, 34); text-transform:=
 none; line-height: 19.99px; text-indent: 0px; letter-spacing: normal; over=
flow: visible; font-family: arial,helvetica,sans-serif; font-size: 13.33px;=
 font-variant: normal; word-spacing: 0px; white-space: normal; orphans: 2; =
font-size-adjust: none; font-stretch: 100%; -webkit-text-stroke-width: 0px;=
 background-color: transparent;"></font></div><div><b></b><i></i><u></u><su=
b></sub><sup></sup><strike></strike><b></b><i></i><u></u><sub></sub><sup></=
sup><strike></strike><b></b><i></i><u></u><sub></sub><sup></sup><strike></s=
trike><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><br></div=
><div><br></div><div>All the old code will work, but now <span style=3D"dis=
play: inline !important; float: none; background-color: transparent; color:=
 rgb(34, 34, 34); font-family: Consolas; font-size: 13px; font-style: norma=
l; font-variant: normal; font-weight: 400; letter-spacing: normal; orphans:=
 2; text-align: left; text-decoration: none; text-indent: 0px; text-transfo=
rm: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing=
: 0px;"><span style=3D"display: inline !important; float: none; background-=
color: transparent; color: rgb(34, 34, 34); font-family: Consolas; font-siz=
e: 13px; font-style: normal; font-variant: normal; font-weight: 400; letter=
-spacing: normal; orphans: 2; text-align: left; text-decoration: none; text=
-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-s=
pace: normal; word-spacing: 0px;">center: <font face=3D"arial,sans-serif">i=
s mandatory and <i>will</i> overload.=C2=A0</font></span></span></div><div>=
<span style=3D"display: inline !important; float: none; background-color: t=
ransparent; color: rgb(34, 34, 34); font-family: Consolas; font-size: 13px;=
 font-style: normal; font-variant: normal; font-weight: 400; letter-spacing=
: normal; orphans: 2; text-align: left; text-decoration: none; text-indent:=
 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: no=
rmal; word-spacing: 0px;"><span style=3D"display: inline !important; float:=
 none; background-color: transparent; color: rgb(34, 34, 34); font-family: =
Consolas; font-size: 13px; font-style: normal; font-variant: normal; font-w=
eight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-deco=
ration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-w=
idth: 0px; white-space: normal; word-spacing: 0px;"><font face=3D"arial,san=
s-serif"><br></font></span></span></div><div><span style=3D"display: inline=
 !important; float: none; background-color: transparent; color: rgb(34, 34,=
 34); font-family: Consolas; font-size: 13px; font-style: normal; font-vari=
ant: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-ali=
gn: left; text-decoration: none; text-indent: 0px; text-transform: none; -w=
ebkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"><spa=
n style=3D"display: inline !important; float: none; background-color: trans=
parent; color: rgb(34, 34, 34); font-family: Consolas; font-size: 13px; fon=
t-style: normal; font-variant: normal; font-weight: 400; letter-spacing: no=
rmal; orphans: 2; text-align: left; text-decoration: none; text-indent: 0px=
; text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal=
; word-spacing: 0px;"><font face=3D"arial,sans-serif">How would this work? =
Well, the easiest is to be a tag, as already explored.=C2=A0</font></span><=
/span></div><div><span style=3D"display: inline !important; float: none; ba=
ckground-color: transparent; color: rgb(34, 34, 34); font-family: Consolas;=
 font-size: 13px; font-style: normal; font-variant: normal; font-weight: 40=
0; letter-spacing: normal; orphans: 2; text-align: left; text-decoration: n=
one; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px=
; white-space: normal; word-spacing: 0px;"><span style=3D"display: inline !=
important; float: none; background-color: transparent; color: rgb(34, 34, 3=
4); font-family: Consolas; font-size: 13px; font-style: normal; font-varian=
t: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align=
: left; text-decoration: none; text-indent: 0px; text-transform: none; -web=
kit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"><font =
face=3D"arial,sans-serif">But it could be a modifier to Point or some autom=
agic shortcut to <font face=3D"courier new,monospace">std::pair&lt;&quot;ce=
nter&quot;, Point&gt;</font>=C2=A0</font></span></span></div><div><b></b><i=
></i><u></u><sub></sub><sup></sup><strike></strike><b></b><i></i><u></u><su=
b></sub><sup></sup><strike></strike><font face=3D"arial,sans-serif"></font>=
<font face=3D"arial,sans-serif"></font><br></div><div>And again, weak named=
 argument are somewhat easier and not less useful (unless they are just war=
nings)=C2=A0</div><div>and not mutually exclusive to strong ones!</div><div=
><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>--=20
<br>Matthew
<br></blockquote></div>

<p></p>

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

------=_Part_496_94024937.1534444803755--

------=_Part_495_700288707.1534444803754--

.

On 2018-08-16 14:40, mihailnajdenov@gmail.com wrote:
> This is already overloaded, no need for strong names.

Eh? Both of those functions, without names have / would have the
signature (double, double). Without strong names, that would be ambiguous.

> As for future proofing -  *there is no problem if we support both*
>
> rect(Point topLeft: pos, Point bottomRight: br); //< weak argument names,
> not mandatory
>
> // later in some future
>
> rect(center: Point pos, Point bottomRight: br) //< strong argument name,
> adds an overload, not ignorable

How would... oh, wait, you're proposing to differentiate strong vs. weak
names *based on position*? That's confusing as all else. I can't imagine
that would *ever* be approved.

--
Matthew

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

.

On Thursday, 16 August 2018 07:53:47 PDT David Brown wrote:
> > void bar(int :a);
> > void bar(int :x); // distinct overload
> >
> > ...is pointless.
>
> I disagree.  Distinct overloads like this would be nice, but (as I
> wrote) extremely costly in terms of changes to implementations and
> existing software.  I would rather see that as a later enhancement once
> we have the simple named parameters in place - my proposal does not
> conflict with having this as a later feature.

I don't think you can have this as a later feature. It needs to be designed in
from the first version.

The mangling of "void bar(int)" is
 _Z3bari
 ?bar@@YAXH@Z

If this is used for "void bar(int :a)", then you CANNOT later overload with
"void bar(int :x)". In other words, for named arguments to be overloadable at
any point in the future, they must have been overloadable at all points in the
past too.

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



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

.

------=_Part_113_153098909.1534449246749
Content-Type: multipart/alternative;
 boundary="----=_Part_114_1361245875.1534449246750"

------=_Part_114_1361245875.1534449246750
Content-Type: text/plain; charset="UTF-8"



On Thursday, August 16, 2018 at 9:49:30 PM UTC+3, Matthew Woehlke wrote:
>
> On 2018-08-16 14:40, mihailn...@gmail.com <javascript:> wrote:
> > This is already overloaded, no need for strong names.
>
> Eh? Both of those functions, without names have / would have the
> signature (double, double). Without strong names, that would be ambiguous.
>

Ok I skimmed a bit too fast.

As I said, I will not deny any use case, but the workarounds are not hard
and some would argue more correct in this case, like making angle a
different type.


>
> > As for future proofing -  *there is no problem if we support both*
> >
> > rect(Point topLeft: pos, Point bottomRight: br); //< weak argument
> names,
> > not mandatory
> >
> > // later in some future
> >
> > rect(center: Point pos, Point bottomRight: br) //< strong argument name,
> > adds an overload, not ignorable
>
>

> How would... oh, wait, you're proposing to differentiate strong vs. weak
> names *based on position*? That's confusing as all else. I can't imagine
> that would *ever* be approved.
>

Yet, it is learnable and does not require extra syntax.

That was not the point, the point is - we need both - one can't just say
"named arguments are like this" and stick to only one type.

*Both* are useful, but for different things
 - weak as semantic disambiguation (for the reader) and conformation (from
the compiler), where using type is incorrect/impractical/maintenance
toll/code size toll,
   and, eventually for some sort of typing shortcut
 - strong as "named constructors", almost exclusively.

Note that strong can't be used for the purpose of weak, because this will
be extremely annoying (*chough* Objective C)




> --
> Matthew
>

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

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

<div dir=3D"ltr"><br><br>On Thursday, August 16, 2018 at 9:49:30 PM UTC+3, =
Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2018-=
08-16 14:40, <a onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"java=
script:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"BweztP=
YZDAAJ">mihailn...@gmail.com</a> wrote:
<br>&gt; This is already overloaded, no need for strong names.
<br>
<br>Eh? Both of those functions, without names have / would have the
<br>signature (double, double). Without strong names, that would be ambiguo=
us.
<br></blockquote><div><br></div><div>Ok I skimmed a bit too fast.</div><div=
><br></div><div>As I said, I will not deny any use case, but the workaround=
s are not hard and some would argue more correct in this case, like making =
angle a different type.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;">
<br>&gt; As for future proofing - =C2=A0*there is no problem if we support =
both*
<br>&gt;=20
<br>&gt; rect(Point topLeft: pos, Point bottomRight: br); //&lt; weak argum=
ent names,=20
<br>&gt; not mandatory=20
<br>&gt;=20
<br>&gt; // later in some future
<br>&gt; =C2=A0
<br>&gt; rect(center: Point pos, Point bottomRight: br) //&lt; strong argum=
ent name,=20
<br>&gt; adds an overload, not ignorable=20
<br>
<br></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">How would... oh, wait, you&#39;re proposing to differentiate strong v=
s. weak
<br>names *based on position*? That&#39;s confusing as all else. I can&#39;=
t imagine
<br>that would *ever* be approved.
<br></blockquote><div><br></div><div>Yet, it is learnable and does not requ=
ire extra syntax.</div><div><br></div><div>That was not the point, the poin=
t is - we need both - one can&#39;t just say &quot;named arguments are like=
 this&quot; and stick to only one type.=C2=A0</div><div><br></div><div><i>B=
oth</i> are useful, but for different things=C2=A0</div><div>=C2=A0- weak a=
s semantic disambiguation (for the reader) and conformation (from the compi=
ler), where using type is incorrect/impractical/maintenance toll/code size =
toll,=C2=A0</div><div>=C2=A0=C2=A0 and, eventually for some sort of typing =
shortcut</div><div>=C2=A0- strong as &quot;named constructors&quot;, almost=
 exclusively.<br></div><div><br></div><div>Note that strong can&#39;t be us=
ed for the purpose of weak, because this will be extremely annoying (*choug=
h* Objective C) =C2=A0</div><div><br></div><div><br></div><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">
<br>--=20
<br>Matthew
<br></blockquote></div>

<p></p>

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

------=_Part_114_1361245875.1534449246750--

------=_Part_113_153098909.1534449246749--

.

------=_Part_449_613378931.1534449947763
Content-Type: multipart/alternative;
 boundary="----=_Part_450_227583293.1534449947763"

------=_Part_450_227583293.1534449947763
Content-Type: text/plain; charset="UTF-8"



On Thursday, August 16, 2018 at 3:54:06 PM UTC-4, mihailn...@gmail.com
wrote:
>
>
>
> On Thursday, August 16, 2018 at 9:49:30 PM UTC+3, Matthew Woehlke wrote:
>>
>> On 2018-08-16 14:40, mihailn...@gmail.com wrote:
>> > This is already overloaded, no need for strong names.
>>
>> Eh? Both of those functions, without names have / would have the
>> signature (double, double). Without strong names, that would be
>> ambiguous.
>>
>
> Ok I skimmed a bit too fast.
>
> As I said, I will not deny any use case, but the workarounds are not hard
> and some would argue more correct in this case, like making angle a
> different type.
>
>
>>
>> > As for future proofing -  *there is no problem if we support both*
>> >
>> > rect(Point topLeft: pos, Point bottomRight: br); //< weak argument
>> names,
>> > not mandatory
>> >
>> > // later in some future
>> >
>> > rect(center: Point pos, Point bottomRight: br) //< strong argument
>> name,
>> > adds an overload, not ignorable
>>
>>
>
>> How would... oh, wait, you're proposing to differentiate strong vs. weak
>> names *based on position*? That's confusing as all else. I can't imagine
>> that would *ever* be approved.
>>
>
> Yet, it is learnable and does not require extra syntax.
>

There are a lot of things in C++ that are "learnable". SFINAE is
"learnable". "Uniform" initialization is "learnable". The "Most Vexing
Parse" is "learnable".

But I think we can make a distinction between things whose behavior is
fairly obvious and things whose behavior requires significant learning
before it can be understood. What you're talking about seems more like the
latter.

That was not the point, the point is - we need both - one can't just say
> "named arguments are like this" and stick to only one type.
>
> *Both* are useful, but for different things
>  - weak as semantic disambiguation (for the reader) and conformation (from
> the compiler), where using type is incorrect/impractical/maintenance
> toll/code size toll,
>    and, eventually for some sort of typing shortcut
>  - strong as "named constructors", almost exclusively.
>
> Note that strong can't be used for the purpose of weak, because this will
> be extremely annoying (*chough* Objective C)
>

The question therefore is whether we need "weak semantic disambiguation and
confirmation" as a language feature at all.

Strong named parameters actually *do something*; they allow us to express
things that either couldn't be done before or were very inconvenient to do.

Weak named parameters by contrast are mere notation. So why is it important
that we have a language feature for that?

Equally importantly, there are costs to having both. Two separate syntaxes
for something that most languages handle with one. Two separate syntaxes
that have to fight for space in the same area (function parameters). Will
they be reasonably distinct from one another? Is not having two syntaxes
that do subtly different things not inherently confusing?

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

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

<div dir=3D"ltr"><br><br>On Thursday, August 16, 2018 at 3:54:06 PM UTC-4, =
mihailn...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><br><br>On Thursday, August 16, 2018 at 9:49:30 PM UTC+3, Mat=
thew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 2018-08-16 14=
:40, <a rel=3D"nofollow">mihailn...@gmail.com</a> wrote:
<br>&gt; This is already overloaded, no need for strong names.
<br>
<br>Eh? Both of those functions, without names have / would have the
<br>signature (double, double). Without strong names, that would be ambiguo=
us.
<br></blockquote><div><br></div><div>Ok I skimmed a bit too fast.</div><div=
><br></div><div>As I said, I will not deny any use case, but the workaround=
s are not hard and some would argue more correct in this case, like making =
angle a different type.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex">
<br>&gt; As for future proofing - =C2=A0*there is no problem if we support =
both*
<br>&gt;=20
<br>&gt; rect(Point topLeft: pos, Point bottomRight: br); //&lt; weak argum=
ent names,=20
<br>&gt; not mandatory=20
<br>&gt;=20
<br>&gt; // later in some future
<br>&gt; =C2=A0
<br>&gt; rect(center: Point pos, Point bottomRight: br) //&lt; strong argum=
ent name,=20
<br>&gt; adds an overload, not ignorable=20
<br>
<br></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>How would... oh, wait, you&#39;re proposing to differentiate strong vs. we=
ak
<br>names *based on position*? That&#39;s confusing as all else. I can&#39;=
t imagine
<br>that would *ever* be approved.
<br></blockquote><div><br></div><div>Yet, it is learnable and does not requ=
ire extra syntax.</div></div></blockquote><div><br></div><div>There are a l=
ot of things in C++ that are &quot;learnable&quot;. SFINAE is &quot;learnab=
le&quot;. &quot;Uniform&quot; initialization is &quot;learnable&quot;. The =
&quot;Most Vexing Parse&quot; is &quot;learnable&quot;.<br></div><div><br><=
/div><div>But I think we can make a distinction between things whose behavi=
or is fairly obvious and things whose behavior requires significant learnin=
g before it can be understood. What you&#39;re talking about seems more lik=
e the latter.<br></div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><div></div><div>That was not the point, the point =
is - we need both - one can&#39;t just say &quot;named arguments are like t=
his&quot; and stick to only one type.=C2=A0</div><div><br></div><div><i>Bot=
h</i> are useful, but for different things=C2=A0</div><div>=C2=A0- weak as =
semantic disambiguation (for the reader) and conformation (from the compile=
r), where using type is incorrect/impractical/<wbr>maintenance toll/code si=
ze toll,=C2=A0</div><div>=C2=A0=C2=A0 and, eventually for some sort of typi=
ng shortcut</div><div>=C2=A0- strong as &quot;named constructors&quot;, alm=
ost exclusively.<br></div><div><br></div><div>Note that strong can&#39;t be=
 used for the purpose of weak, because this will be extremely annoying (*ch=
ough* Objective C)<br></div></div></blockquote><div><br></div><div>The ques=
tion therefore is whether we need &quot;weak semantic disambiguation and co=
nfirmation&quot; as a language feature at all.</div><div><br></div><div>Str=
ong named parameters actually <i>do something</i>; they allow us to express=
 things that either couldn&#39;t be done before or were very inconvenient t=
o do.</div><div><br></div><div>Weak named parameters by contrast are mere n=
otation. So why is it important that we have a language feature for that?</=
div><div><br></div><div>Equally importantly, there are costs to having both=
.. Two separate syntaxes for something that most languages handle with one. =
Two separate syntaxes that have to fight for space in the same area (functi=
on parameters). Will they be reasonably distinct from one another? Is not h=
aving two syntaxes that do subtly different things not inherently confusing=
?<br></div></div>

<p></p>

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

------=_Part_450_227583293.1534449947763--

------=_Part_449_613378931.1534449947763--

.

------=_Part_630_796107928.1534455529406
Content-Type: multipart/alternative;
 boundary="----=_Part_631_1527018004.1534455529406"

------=_Part_631_1527018004.1534455529406
Content-Type: text/plain; charset="UTF-8"



On Thursday, August 16, 2018 at 11:05:47 PM UTC+3, Nicol Bolas wrote:
>
>
>
> On Thursday, August 16, 2018 at 3:54:06 PM UTC-4, mihailn...@gmail.com
> wrote:
>>
>>
>>
>> On Thursday, August 16, 2018 at 9:49:30 PM UTC+3, Matthew Woehlke wrote:
>>>
>>> On 2018-08-16 14:40, mihailn...@gmail.com wrote:
>>> > This is already overloaded, no need for strong names.
>>>
>>> Eh? Both of those functions, without names have / would have the
>>> signature (double, double). Without strong names, that would be
>>> ambiguous.
>>>
>>
>> Ok I skimmed a bit too fast.
>>
>> As I said, I will not deny any use case, but the workarounds are not hard
>> and some would argue more correct in this case, like making angle a
>> different type.
>>
>>
>>>
>>> > As for future proofing -  *there is no problem if we support both*
>>> >
>>> > rect(Point topLeft: pos, Point bottomRight: br); //< weak argument
>>> names,
>>> > not mandatory
>>> >
>>> > // later in some future
>>> >
>>> > rect(center: Point pos, Point bottomRight: br) //< strong argument
>>> name,
>>> > adds an overload, not ignorable
>>>
>>>
>>
>>> How would... oh, wait, you're proposing to differentiate strong vs. weak
>>> names *based on position*? That's confusing as all else. I can't imagine
>>> that would *ever* be approved.
>>>
>>
>> Yet, it is learnable and does not require extra syntax.
>>
>
> There are a lot of things in C++ that are "learnable". SFINAE is
> "learnable". "Uniform" initialization is "learnable". The "Most Vexing
> Parse" is "learnable".
>
> But I think we can make a distinction between things whose behavior is
> fairly obvious and things whose behavior requires significant learning
> before it can be understood. What you're talking about seems more like the
> latter.
>
> That was not the point, the point is - we need both - one can't just say
>> "named arguments are like this" and stick to only one type.
>>
>> *Both* are useful, but for different things
>>  - weak as semantic disambiguation (for the reader) and conformation
>> (from the compiler), where using type is incorrect/impractical/maintenance
>> toll/code size toll,
>>    and, eventually for some sort of typing shortcut
>>  - strong as "named constructors", almost exclusively.
>>
>> Note that strong can't be used for the purpose of weak, because this will
>> be extremely annoying (*chough* Objective C)
>>
>
> The question therefore is whether we need "weak semantic disambiguation
> and confirmation" as a language feature at all.
>
> Strong named parameters actually *do something*; they allow us to express
> things that either couldn't be done before or were very inconvenient to do.
>

> Weak named parameters by contrast are mere notation. So why is it
> important that we have a language feature for that?
>

They fix the last semantic hole that neither Types nor Contracts can fix.
Types bound what the item is, contracts bound what value the item has,
names bound what the meaning of the item is.

Often meaning is inferred form type but often this is not possible (math,
physics) or simply incorrect semantically - MotherName is wrong kind of
type.
And often meaning is inferred from the variables themselves, but that is
not enforceable.

Yet, passing an argument, meaning something different is, for all intend
and proposes, a breach of contract, no matter if this is a form on paper to
fill with a pen or a function call.

Can this be solved by types - only if workaround is solving
Can this be solved by strong names - well, yeah, at the price of thinking
the users are idiots having them to repeat like monkeys every name that "we
think it is important".


> Equally importantly, there are costs to having both.
>
Two separate syntaxes for something that most languages handle with one.
>
Two separate syntaxes that have to fight for space in the same area
> (function parameters). Will they be reasonably distinct from one another?
> Is not having two syntaxes that do subtly different things not inherently
> confusing?
>

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

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

<div dir=3D"ltr"><br><br>On Thursday, August 16, 2018 at 11:05:47 PM UTC+3,=
 Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><br><br>On Thursday, August 16, 2018 at 3:54:06 PM UTC-4, <a>mihailn.=
...@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"><br><br>On Thursday, August 16, 2018 at 9:49:30 PM UTC+3, Matthew Woeh=
lke wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex">On 2018-08-16 14:40, <a r=
el=3D"nofollow">mihailn...@gmail.com</a> wrote:
<br>&gt; This is already overloaded, no need for strong names.
<br>
<br>Eh? Both of those functions, without names have / would have the
<br>signature (double, double). Without strong names, that would be ambiguo=
us.
<br></blockquote><div><br></div><div>Ok I skimmed a bit too fast.</div><div=
><br></div><div>As I said, I will not deny any use case, but the workaround=
s are not hard and some would argue more correct in this case, like making =
angle a different type.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex">
<br>&gt; As for future proofing - =C2=A0*there is no problem if we support =
both*
<br>&gt;=20
<br>&gt; rect(Point topLeft: pos, Point bottomRight: br); //&lt; weak argum=
ent names,=20
<br>&gt; not mandatory=20
<br>&gt;=20
<br>&gt; // later in some future
<br>&gt; =C2=A0
<br>&gt; rect(center: Point pos, Point bottomRight: br) //&lt; strong argum=
ent name,=20
<br>&gt; adds an overload, not ignorable=20
<br>
<br></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>How would... oh, wait, you&#39;re proposing to differentiate strong vs. we=
ak
<br>names *based on position*? That&#39;s confusing as all else. I can&#39;=
t imagine
<br>that would *ever* be approved.
<br></blockquote><div><br></div><div>Yet, it is learnable and does not requ=
ire extra syntax.</div></div></blockquote><div><br></div><div>There are a l=
ot of things in C++ that are &quot;learnable&quot;. SFINAE is &quot;learnab=
le&quot;. &quot;Uniform&quot; initialization is &quot;learnable&quot;. The =
&quot;Most Vexing Parse&quot; is &quot;learnable&quot;.<br></div><div><br><=
/div><div>But I think we can make a distinction between things whose behavi=
or is fairly obvious and things whose behavior requires significant learnin=
g before it can be understood. What you&#39;re talking about seems more lik=
e the latter.<br></div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div></div><div>That was not the point, the point is - =
we need both - one can&#39;t just say &quot;named arguments are like this&q=
uot; and stick to only one type.=C2=A0</div><div><br></div><div><i>Both</i>=
 are useful, but for different things=C2=A0</div><div>=C2=A0- weak as seman=
tic disambiguation (for the reader) and conformation (from the compiler), w=
here using type is incorrect/impractical/<wbr>maintenance toll/code size to=
ll,=C2=A0</div><div>=C2=A0=C2=A0 and, eventually for some sort of typing sh=
ortcut</div><div>=C2=A0- strong as &quot;named constructors&quot;, almost e=
xclusively.<br></div><div><br></div><div>Note that strong can&#39;t be used=
 for the purpose of weak, because this will be extremely annoying (*chough*=
 Objective C)<br></div></div></blockquote><div><br></div><div>The question =
therefore is whether we need &quot;weak semantic disambiguation and confirm=
ation&quot; as a language feature at all.</div><div><br></div><div>Strong n=
amed parameters actually <i>do something</i>; they allow us to express thin=
gs that either couldn&#39;t be done before or were very inconvenient to do.=
=C2=A0</div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div><br></div><div>Weak named parameters by contrast are=
 mere notation. So why is it important that we have a language feature for =
that?</div></div></blockquote><div><br></div><div>They fix the last semanti=
c hole that neither Types nor Contracts can fix.=C2=A0</div><div>Types boun=
d what the item is, contracts bound what value the item has, names bound wh=
at the meaning of the item is.</div><div><br></div><div>Often meaning is in=
ferred form type but often this is not possible (math, physics) or simply i=
ncorrect semantically - MotherName is wrong kind of type.<br></div><div>And=
 often meaning is inferred from the variables themselves, but that is not e=
nforceable.</div><div><br></div><div>Yet, passing an argument, meaning some=
thing different is, for all intend and proposes, a breach of contract, no m=
atter if this is a form on paper to fill with a pen or a function call. =C2=
=A0</div><div><br></div><div>Can this be solved by types - only if workarou=
nd is solving=C2=A0</div><div>Can this be solved by strong names - well, ye=
ah, at the price of thinking the users are idiots having them to repeat lik=
e monkeys every name that &quot;we think it is important&quot;.=C2=A0</div>=
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div><br></div><div>Equally importantly, there are costs to having both.=
=C2=A0<br></div></div></blockquote><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div>Two separate syntaxes for something that most l=
anguages handle with one.=C2=A0<br></div></div></blockquote><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Two separate syntaxes t=
hat have to fight for space in the same area (function parameters). Will th=
ey be reasonably distinct from one another? Is not having two syntaxes that=
 do subtly different things not inherently confusing?<br></div></div></bloc=
kquote></div>

<p></p>

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

------=_Part_631_1527018004.1534455529406--

------=_Part_630_796107928.1534455529406--

.

------=_Part_521_127235167.1534457325571
Content-Type: multipart/alternative;
 boundary="----=_Part_522_778960251.1534457325571"

------=_Part_522_778960251.1534457325571
Content-Type: text/plain; charset="UTF-8"

On Thursday, August 16, 2018 at 5:38:49 PM UTC-4, mihailn...@gmail.com
wrote:
>
> On Thursday, August 16, 2018 at 11:05:47 PM UTC+3, Nicol Bolas wrote:
>>
>> On Thursday, August 16, 2018 at 3:54:06 PM UTC-4, mihailn...@gmail.com
>> wrote:
>>>
>>> On Thursday, August 16, 2018 at 9:49:30 PM UTC+3, Matthew Woehlke wrote:
>>>>
>>>> On 2018-08-16 14:40, mihailn...@gmail.com wrote:
>>>> > This is already overloaded, no need for strong names.
>>>>
>>>> Eh? Both of those functions, without names have / would have the
>>>> signature (double, double). Without strong names, that would be
>>>> ambiguous.
>>>>
>>>
>>> Ok I skimmed a bit too fast.
>>>
>>> As I said, I will not deny any use case, but the workarounds are not
>>> hard and some would argue more correct in this case, like making angle a
>>> different type.
>>>
>>>
>>>>
>>>> > As for future proofing -  *there is no problem if we support both*
>>>> >
>>>> > rect(Point topLeft: pos, Point bottomRight: br); //< weak argument
>>>> names,
>>>> > not mandatory
>>>> >
>>>> > // later in some future
>>>> >
>>>> > rect(center: Point pos, Point bottomRight: br) //< strong argument
>>>> name,
>>>> > adds an overload, not ignorable
>>>>
>>>>
>>>
>>>> How would... oh, wait, you're proposing to differentiate strong vs.
>>>> weak
>>>> names *based on position*? That's confusing as all else. I can't
>>>> imagine
>>>> that would *ever* be approved.
>>>>
>>>
>>> Yet, it is learnable and does not require extra syntax.
>>>
>>
>> There are a lot of things in C++ that are "learnable". SFINAE is
>> "learnable". "Uniform" initialization is "learnable". The "Most Vexing
>> Parse" is "learnable".
>>
>> But I think we can make a distinction between things whose behavior is
>> fairly obvious and things whose behavior requires significant learning
>> before it can be understood. What you're talking about seems more like the
>> latter.
>>
>> That was not the point, the point is - we need both - one can't just say
>>> "named arguments are like this" and stick to only one type.
>>>
>>> *Both* are useful, but for different things
>>>  - weak as semantic disambiguation (for the reader) and conformation
>>> (from the compiler), where using type is incorrect/impractical/maintenance
>>> toll/code size toll,
>>>    and, eventually for some sort of typing shortcut
>>>  - strong as "named constructors", almost exclusively.
>>>
>>> Note that strong can't be used for the purpose of weak, because this
>>> will be extremely annoying (*chough* Objective C)
>>>
>>
>> The question therefore is whether we need "weak semantic disambiguation
>> and confirmation" as a language feature at all.
>>
>> Strong named parameters actually *do something*; they allow us to
>> express things that either couldn't be done before or were very
>> inconvenient to do.
>>
>
>> Weak named parameters by contrast are mere notation. So why is it
>> important that we have a language feature for that?
>>
>
> They fix the last semantic hole that neither Types nor Contracts can fix.
> Types bound what the item is, contracts bound what value the item has,
> names bound what the meaning of the item is.
>
> Often meaning is inferred form type but often this is not possible (math,
> physics) or simply incorrect semantically - MotherName is wrong kind of
> type.
> And often meaning is inferred from the variables themselves, but that is
> not enforceable.
>
> Yet, passing an argument, meaning something different is, for all intend
> and proposes, a breach of contract, no matter if this is a form on paper to
> fill with a pen or a function call.
>

Your argument makes more sense for strong names than weak ones. After all,
if "meaning something different" is truly a "breach of contract" (and
therefore an error), then that contract is important enough to be stated
whenever the function is used. If I've written a function that needs to
test this "contract", then I want everyone who calls it to actually provide
the correct information.

And if the contract is not important enough to be stated explicitly, then
why does it need to be said at all. How can a contract be *optional*? And I
don't mean in the Contracts proposal way, where compiler options/`axiom`
can turn them on or off. I mean in that each individual use has the ability
to pick and choose whether to provide this "meaning" or not.

Or to put it another way, the only reason "override" is optional is that it
would be a huge compatibility break to make it mandatory. That feature is
very similar to here: both cases are stating the meaning of something
explicitly.

Why is this meaning important enough to be said and verified sometimes and
not other-times?

Lastly, a big problem I have with your conception of weak names is that
you're trying to make them a full-fledged piece of information connected
with a value (in order to make forwarding work)... but you're not using any
existing C++ mechanism to provide this channel of information. Names aren't
types. They aren't values. They're associated with parameter names, but
they have to be able to pass through `std::forward` somehow. And users have
to be able to pass them to non-named functions (like loggers) as well as
named ones.

The various strong naming proposals make these names actual parts of the
C++ language. Some make them into values passed into the function. Others
make the function take an unnamed struct. And so forth.

Weak names can't work through normal C++ channels of information.

Can this be solved by types - only if workaround is solving
> Can this be solved by strong names - well, yeah, at the price of thinking
> the users are idiots having them to repeat like monkeys every name that "we
> think it is important".
>

To the degree that I think named parameters are important enough to have in
the language, I will happily pay the price of the latter if it means not
having to pay the price of having *two syntaxes* for things that are
essentially the same thing.

It's bad enough that we're creating two separate names for a parameter at
all (the in-function name and the out-of-function name). Let's not compound
this folly by having two ways to set the out-of-function name that have
slightly different meanings.

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

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

<div dir=3D"ltr">On Thursday, August 16, 2018 at 5:38:49 PM UTC-4, mihailn.=
...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">On Thursday, August 16, 2018 at 11:05:47 PM UTC+3, Nicol Bolas wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thursday, Augus=
t 16, 2018 at 3:54:06 PM UTC-4, <a>mihailn...@gmail.com</a> wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thursday, August 16, 201=
8 at 9:49:30 PM UTC+3, Matthew Woehlke wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex">On 2018-08-16 14:40, <a rel=3D"nofollow">mihailn...@gmail.com</a>=
 wrote:
<br>&gt; This is already overloaded, no need for strong names.
<br>
<br>Eh? Both of those functions, without names have / would have the
<br>signature (double, double). Without strong names, that would be ambiguo=
us.
<br></blockquote><div><br></div><div>Ok I skimmed a bit too fast.</div><div=
><br></div><div>As I said, I will not deny any use case, but the workaround=
s are not hard and some would argue more correct in this case, like making =
angle a different type.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex">
<br>&gt; As for future proofing - =C2=A0*there is no problem if we support =
both*
<br>&gt;=20
<br>&gt; rect(Point topLeft: pos, Point bottomRight: br); //&lt; weak argum=
ent names,=20
<br>&gt; not mandatory=20
<br>&gt;=20
<br>&gt; // later in some future
<br>&gt; =C2=A0
<br>&gt; rect(center: Point pos, Point bottomRight: br) //&lt; strong argum=
ent name,=20
<br>&gt; adds an overload, not ignorable=20
<br>
<br></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>How would... oh, wait, you&#39;re proposing to differentiate strong vs. we=
ak
<br>names *based on position*? That&#39;s confusing as all else. I can&#39;=
t imagine
<br>that would *ever* be approved.
<br></blockquote><div><br></div><div>Yet, it is learnable and does not requ=
ire extra syntax.</div></div></blockquote><div><br></div><div>There are a l=
ot of things in C++ that are &quot;learnable&quot;. SFINAE is &quot;learnab=
le&quot;. &quot;Uniform&quot; initialization is &quot;learnable&quot;. The =
&quot;Most Vexing Parse&quot; is &quot;learnable&quot;.<br></div><div><br><=
/div><div>But I think we can make a distinction between things whose behavi=
or is fairly obvious and things whose behavior requires significant learnin=
g before it can be understood. What you&#39;re talking about seems more lik=
e the latter.<br></div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div></div><div>That was not the point, the point is - =
we need both - one can&#39;t just say &quot;named arguments are like this&q=
uot; and stick to only one type.=C2=A0</div><div><br></div><div><i>Both</i>=
 are useful, but for different things=C2=A0</div><div>=C2=A0- weak as seman=
tic disambiguation (for the reader) and conformation (from the compiler), w=
here using type is incorrect/impractical/<wbr>maintenance toll/code size to=
ll,=C2=A0</div><div>=C2=A0=C2=A0 and, eventually for some sort of typing sh=
ortcut</div><div>=C2=A0- strong as &quot;named constructors&quot;, almost e=
xclusively.<br></div><div><br></div><div>Note that strong can&#39;t be used=
 for the purpose of weak, because this will be extremely annoying (*chough*=
 Objective C)<br></div></div></blockquote><div><br></div><div>The question =
therefore is whether we need &quot;weak semantic disambiguation and confirm=
ation&quot; as a language feature at all.</div><div><br></div><div>Strong n=
amed parameters actually <i>do something</i>; they allow us to express thin=
gs that either couldn&#39;t be done before or were very inconvenient to do.=
=C2=A0</div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div><br></div><div>Weak named parameters by contrast are mere=
 notation. So why is it important that we have a language feature for that?=
</div></div></blockquote><div><br></div><div>They fix the last semantic hol=
e that neither Types nor Contracts can fix.=C2=A0</div><div>Types bound wha=
t the item is, contracts bound what value the item has, names bound what th=
e meaning of the item is.</div><div><br></div><div>Often meaning is inferre=
d form type but often this is not possible (math, physics) or simply incorr=
ect semantically - MotherName is wrong kind of type.<br></div><div>And ofte=
n meaning is inferred from the variables themselves, but that is not enforc=
eable.</div><div><br></div><div>Yet, passing an argument, meaning something=
 different is, for all intend and proposes, a breach of contract, no matter=
 if this is a form on paper to fill with a pen or a function call.<br></div=
></div></blockquote><div><br></div><div>Your argument makes more sense for =
strong names than weak ones. After all, if &quot;meaning something differen=
t&quot; is truly a &quot;breach of contract&quot; (and therefore an error),=
 then that contract is important enough to be stated whenever the function =
is used. If I&#39;ve written a function that needs to test this &quot;contr=
act&quot;, then I want everyone who calls it to actually provide the correc=
t information.<br></div><div><br></div><div>And if the contract is not impo=
rtant enough to be stated explicitly, then why does it need to be said at a=
ll. How can a contract be <i>optional</i>? And I don&#39;t mean in the Cont=
racts proposal way, where compiler options/`axiom` can turn them on or off.=
 I mean in that each individual use has the ability to pick and choose whet=
her to provide this &quot;meaning&quot; or not.<br></div><div><br></div><di=
v>Or to put it another way, the only reason &quot;override&quot; is optiona=
l is that it would be a huge compatibility break to make it mandatory. That=
 feature is very similar to here: both cases are stating the meaning of som=
ething explicitly.</div><div><br></div><div>Why is this meaning important e=
nough to be said and verified sometimes and not other-times?</div><div><br>=
</div><div>Lastly, a big problem I have with your conception of weak names =
is that you&#39;re trying to make them a full-fledged piece of information =
connected with a value (in order to make forwarding work)... but you&#39;re=
 not using any existing C++ mechanism to provide this channel of informatio=
n. Names aren&#39;t types. They aren&#39;t values. They&#39;re associated w=
ith parameter names, but they have to be able to pass through `std::forward=
` somehow. And users have to be able to pass them to non-named functions (l=
ike loggers) as well as named ones.</div><div><br></div><div>The various st=
rong naming proposals make these names actual parts of the C++ language. So=
me make them into values passed into the function. Others make the function=
 take an unnamed struct. And so forth.</div><div><br></div><div>Weak names =
can&#39;t work through normal C++ channels of information.<br></div><div><b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>=
</div><div></div><div>Can this be solved by types - only if workaround is s=
olving=C2=A0</div><div>Can this be solved by strong names - well, yeah, at =
the price of thinking the users are idiots having them to repeat like monke=
ys every name that &quot;we think it is important&quot;.</div></div></block=
quote><div><br></div><div>To the degree that I think named parameters are i=
mportant enough to have in the language, I will happily pay the price of th=
e latter if it means not having to pay the price of having <i>two syntaxes<=
/i> for things that are essentially the same thing.</div><div><br></div><di=
v>It&#39;s bad enough that we&#39;re creating two separate names for a para=
meter at all (the in-function name and the out-of-function name). Let&#39;s=
 not compound this folly by having two ways to set the out-of-function name=
 that have slightly different meanings.</div><br></div>

<p></p>

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

------=_Part_522_778960251.1534457325571--

------=_Part_521_127235167.1534457325571--

.

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

On Thu, Aug 16, 2018 at 12:28 AM <mihailnajdenov@gmail.com> wrote:

> Note that, because of Python and C# popularity, this has been suggested
> multiple times in one for or another. Never passed.
>
> Also you missed some proposals
> http://jamboree.github.io/designator-draft.html
> and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0671r0.html
>
> The latter did not pass and is turned into the poor-mans
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0671r2.html
>
> In other words, you should state what is different.
>

I wasn't aware of P0671. My proposal is similar to R0, but more different
from R2. Ignoring syntax differences, P0671r0 makes named parameters opt-in
and only supports name-only parameters. P0671r2 goes in a completely
different direction and makes parameters named by default and
named-positional, with a possible attribute for name-only. P0671 talks
about ellipses, which I haven't investigated yet, but I don't believe I
would stray too far from that. P0671r2 looks like nothing more than
parameter reordering, which I believe to be an inferior form of named
parameters. I didn't see any mention of template functions, but I believe
P0671 only supports named parameters on the outermost layer. My proposal
works to integrate named parameters into the language as a core language
feature rather than as simple syntactic sugar on top.

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

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

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu=
, Aug 16, 2018 at 12:28 AM &lt;<a href=3D"mailto:mihailnajdenov@gmail.com">=
mihailnajdenov@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr">Note that, because of Python and C# popularity, this =
has been suggested multiple times in one for or another. Never passed.=C2=
=A0<div><br><div>Also you missed some proposals=C2=A0<a href=3D"http://jamb=
oree.github.io/designator-draft.html" target=3D"_blank">http://jamboree.git=
hub.io/designator-draft.html</a>=C2=A0</div><div>and=C2=A0<a href=3D"http:/=
/www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0671r0.html" target=3D"_=
blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0671r0.html=
</a></div><div><br></div><div>The latter did not pass and is turned into th=
e poor-mans=C2=A0<a href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/pap=
ers/2018/p0671r2.html" target=3D"_blank">http://www.open-std.org/JTC1/SC22/=
WG21/docs/papers/2018/p0671r2.html</a></div><div><br></div><div>In other wo=
rds, you should state what is different.</div></div></div></blockquote><div=
><br></div><div>I wasn&#39;t aware of P0671. My proposal is similar to R0, =
but more different from R2. Ignoring syntax differences, P0671r0 makes name=
d parameters opt-in and only supports name-only parameters. P0671r2 goes in=
 a completely different direction and makes parameters named by default and=
 named-positional, with a possible attribute for name-only. P0671 talks abo=
ut ellipses, which I haven&#39;t investigated yet, but I don&#39;t believe =
I would stray too far from that. P0671r2 looks like nothing more than param=
eter reordering, which I believe to be an inferior form of named parameters=
.. I didn&#39;t see any mention of template functions, but I believe P0671 o=
nly supports named parameters on the outermost layer. My proposal works to =
integrate named parameters into the language as a core language feature rat=
her than as simple syntactic sugar on top.=C2=A0</div><div>=C2=A0<br></div>=
</div></div>

<p></p>

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

--0000000000005e3ca4057399a73b--

.

--00000000000005b5e4057399a9dc
Content-Type: text/plain; charset="UTF-8"

On Thu, Aug 16, 2018 at 7:34 AM Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2018-08-16 07:53, David Brown wrote:
> > I am at a loss to why people key wanting to make this such a complicated
> > issue.
> > [...]
> > 2. The primary use is to check that parameters are given in the right
> > order, with the ability to re-order parameters at the call site as a
> > secondary concern.
>
> ...probably because plenty of people disagree with this point. AFAIAC,
> any proposal that does NOT allow these:
>
>   void foo(int, int :a = 1, int :b = 2, int :c = 12);
>   foo(3, b: 5); // foo(3, 1, 5, 12)
>
>   void bar(int :a);
>   void bar(int :x); // distinct overload
>
> ...is pointless. Checking argument order is, IMHO, not only *not* "the
> primary use", but *optional*.
>

I agree for the most part, but I disagree that this should be a valid
overload set, unless parameters are name-only:

void bar(int :a);
void bar(int :x);

The problem is that bar(4) is ambiguous. It would be better to catch this
at the declaration rather than at the first ambiguous point of use.
Overloading on name-only parameters is just fine.

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Au=
g 16, 2018 at 7:34 AM Matthew Woehlke &lt;<a href=3D"mailto:mwoehlke.floss@=
gmail.com">mwoehlke.floss@gmail.com</a>&gt; wrote:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">On 2018-08-16 07:53, David Brown wrote:<br>
&gt; I am at a loss to why people key wanting to make this such a complicat=
ed<br>
&gt; issue.<br>
&gt; [...]<br>
&gt; 2. The primary use is to check that parameters are given in the right<=
br>
&gt; order, with the ability to re-order parameters at the call site as a<b=
r>
&gt; secondary concern.<br>
<br>
....probably because plenty of people disagree with this point. AFAIAC,<br>
any proposal that does NOT allow these:<br>
<br>
=C2=A0 void foo(int, int :a =3D 1, int :b =3D 2, int :c =3D 12);<br>
=C2=A0 foo(3, b: 5); // foo(3, 1, 5, 12)<br>
<br>
=C2=A0 void bar(int :a);<br>
=C2=A0 void bar(int :x); // distinct overload<br>
<br>
....is pointless. Checking argument order is, IMHO, not only *not* &quot;the=
<br>
primary use&quot;, but *optional*.<br></blockquote><div><br></div><div>I ag=
ree for the most part, but I disagree that this should be a valid overload =
set, unless parameters are name-only:</div><div><br></div><div><font face=
=3D"monospace, monospace">void bar(int :a);</font></div><div><font face=3D"=
monospace, monospace">void bar(int :x);</font></div><div><br></div><div>The=
 problem is that <font face=3D"monospace, monospace">bar(4)</font> is ambig=
uous. It would be better to catch this at the declaration rather than at th=
e first ambiguous point of use. Overloading on name-only parameters is just=
 fine.</div><div>=C2=A0<br></div></div></div>

<p></p>

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

--00000000000005b5e4057399a9dc--

.

On 16/08/18 15:08, mihailnajdenov@gmail.com wrote:
> There are tree major problems with such simple approaches
>
> First - you make something, that has been private for 30+ years, public.

No, it is not.  The names for parameters are in function declarations,
in headers - these are public.  My proposal does not use names from the
definitions (which may be private).

Some functions are declared without parameter names - you can't use them
for named parameters, without a re-declaration.  Some functions are
declared with "private" reserved names as parameter names (especially in
standard library implementations, to avoid conflict with any macros the
user may have defined).  By my proposal, you can't use them either as
parameter names.

> Second - warnings are not good enough. There is no situation where wrong
> argument is ignorable and not an error. If you make named arguments that
> weak, one can just use comments.

I'd have no problem with errors rather than warnings.

But I would want to be able to call existing functions using named
arguments, and I would want to call new functions with positional
arguments.  I am sceptical to the idea of being able to force the use of
named arguments at any point (in fact, that would, I think, cause more
problems for perfect forwarding), and the whole idea would be useless if
special syntax were needed to declare that a function uses named parameters.

> Third - perfect forwarding must work.
>

Perfect forwarding would work fine, as far as I can see.  However, I
don't claim to be particularly familiar with perfect forwarding, and I
would appreciate corrections if it looks like I've got things wrong
here.  I agree that perfect forwarding /should/ work - I'm less
convinced that it /must/ work.  Again, I am frustrated that a simple
feature that could be extremely useful in many cases is missing merely
because it can't be used in some other cases.


Here is an example:

template<typename T, typename... Args>
unique_ptr<T> make_unique(Args&&... args)
{
    return unique_ptr<T>(new T(std::forward<Args>(args)...));
}

And let's make a class:

class Point {
public:
 Point(int x, int y, int z);
 ...
}

This means you can have:

 int a = 1;
 const int b = 2;

 auto p1 = make_unique<Point>(a, b, 3);

When the compiler sees this "make_unique" call, it also has the
declaration of Point's constructor available.  So if you write this:

 auto p2 = make_unique<Point>(.y = b, .z = 3, .x = a);

the compiler knows the names of the parameters in the constructor, and
can re-arrange them to give exactly the same call as the positional
arguments.

Is this what you were looking for, or did you mean something else?



> On Thursday, August 16, 2018 at 2:54:14 PM UTC+3, David Brown wrote:
>
>     On 16/08/18 07:10, Justin Bassett wrote:
>     > I'm working on a paper to write this up more formally, but before
>     I do
>     > that, I wanted to share my research and work and generate some
>     discussion.
>
>     I am at a loss to why people key wanting to make this such a
>     complicated
>     issue.
>
>     Let's simplify things, and look at the requirements:
>
>     1. We want to be able to use named parameters.  It leads to clearer
>     code
>     and fewer errors - especially for functions with several parameters.
>
>     2. The primary use is to check that parameters are given in the right
>     order, with the ability to re-order parameters at the call site as a
>     secondary concern.
>
>     3. It should not require changes to existing code, new ABIs, new object
>     file formats, or anything more than minimal changes to the compiler
>     front-end.
>
>     We do /not/ want this to be part of a function's signature - there
>     is no
>     benefit to it, and vast complications involved.  In most well-written
>     code a function (if exported) is declared once in a header somewhere,
>     and this declaration is available when the function's definition is
>     seen.  So checking for matching parameter names can be done then - just
>     as checking is done for matching numbers and types.  Compilers can warn
>     on mismatches.  And if the declaration and definition are independent,
>     then it's the programmer's responsibility to make sure they work
>     together - just as for other aspects of functions.
>
>     (I appreciate that there are advantages in allowing names to be part of
>     the signature - it would let you distinguish "complex(double r, double
>     i)" and "complex(double r, double theta)".  But the added complexity
>     and
>     implementation effort needed would not be worth it - such costly ideas
>     hinder the adoption of the main feature.  And there would be nothing to
>     stop this being added in some way at a later date.)
>
>
>     Named parameters are only relevant to function /calls/ - not to
>     function
>     definitions.  The names to use come from a function's declaration - the
>     argument names in a function's definition are irrelevant (though a
>     compiler warning to check they match would be a useful implementation
>     feature).  They are very similar, therefore, to default arguments.
>
>             int foo(int a, int b, int c = 3, int d = 4);
>
>     All these mean the same thing:
>
>             foo(1, 2, 3, 4);
>             foo(1, 2, 3);
>             foo(.a = 1, .b = 2, .c = 3, .d = 4);
>             foo(.b = 2, .a = 1, 3);
>             foo(.d = 4, .b = 2, .a = 1);
>
>
>     These are errors (for obvious reasons):
>
>             foo(.ab = 1, 2);
>             foo(.c = 3, 2, 3);
>
>
>     Within the call parameters, the compiler will take the list of calling
>     parameters and match it up with a list of parameters in the function
>     declaration.  First, any named parameters are put in the right spot
>     according to name.  Then any unnamed parameters are put in the same
>     spot
>     number as they had in the call.  Any empty spots are filled with the
>     default values.  If any spot has no value, or more than one value, it's
>     an error.
>
>
>     If a function is declared with some unnamed parameters, and re-declared
>     with names for some of these parameters, that's fine - the current set
>     of names is the union of these.  If a function is redeclared giving the
>     same name to parameters, that's fine too.  If a function is redeclared
>     and there is a conflict in a parameter name, or if a parameter is never
>     given a name, then that parameter can't be used as a named parameter.
>     An exception would be that parameter names with reserved identifiers
>     are
>     considered anonymous - you can't match on such a name.
>
>     An alternative resolution here would be simply to say that the last
>     seen
>     declaration is the one that counts in regard to parameter names.
>     (Again, compiler warnings for conflicts, excluding reserved
>     identifiers,
>     would be encouraged.)
>
>
>
>     That is /all/ that is needed.  It could be implemented simply (well,
>     relatively simply!) in any C++ compiler front-end.  It does not
>     conflict
>     with existing syntax, it will not change the meaning of any existing
>     code.  New headers can be written to take advantage of the feature, but
>     such functions can still be used with positional parameters.
>
>     The same feature can also be used for 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/pl671k%24gsb%241%40blaine.gmane.org.

.

On 16/08/18 21:50, Thiago Macieira wrote:
> On Thursday, 16 August 2018 07:53:47 PDT David Brown wrote:
>>> void bar(int :a);
>>> void bar(int :x); // distinct overload
>>>
>>> ...is pointless.
>>
>> I disagree.  Distinct overloads like this would be nice, but (as I
>> wrote) extremely costly in terms of changes to implementations and
>> existing software.  I would rather see that as a later enhancement once
>> we have the simple named parameters in place - my proposal does not
>> conflict with having this as a later feature.
>
> I don't think you can have this as a later feature. It needs to be designed in
> from the first version.
>
> The mangling of "void bar(int)" is
>  _Z3bari
>  ?bar@@YAXH@Z
>
> If this is used for "void bar(int :a)", then you CANNOT later overload with
> "void bar(int :x)". In other words, for named arguments to be overloadable at
> any point in the future, they must have been overloadable at all points in the
> past too.
>

Of course.  And that is /fine/.

If you want to have two functions that are overloaded on the basis of
their parameter names, then you want that to be part of the definition
and declaration of /both/ functions.  You don't want to have one
"normal" function and one "overloaded" function - that opens the door to
ambiguity, confusion, and getting the wrong function by mistake.

Suppose we start with named parameters in the way I described.  Then you
have:

 // declaration
 void foo(int a, int b);

 // definition can use any names, but matching names recommended
 void foo(int a, int param_b) { ... }

 // call
 foo(1, 2);
 foo(.a = 1, .b = 2);


Let's add a syntax for /required/ named parameters.  Unlike someone
else's suggestion, I would want this to be clearly distinguished - not
just based on a minor change in positions.  At this stage, I really
don't know what syntax would be nice here, so I'm simply going to invent
one to discuss the point - it is not a suggestion for a final choice of
syntax.

 // declarations
 void foo(int @a, int @b);
 void foo(int @x, int @y);

 // definitions must use identical names
 void foo(int @a, int@b) { ... }
 void foo(int @x, int@y) { ... }

 // call
 foo(.a = 1, .b = 2);
 foo(.y = 10, .x = 20);

 foo(1, 2) // Syntax error!

As far as the caller is concerned, the syntax for non-optional named
parameters is the same as that of choosing to use optional named parameters.

If the mangled name of "void foo(int, int)" is "foo_v_i_i", then the
declarations and definitions above would mangle to "foo_v_i_i__a_b" and
"foo_v_i_i__x_y", or something on those lines.  The compiler can
distinguish the declarations, it can distinguish the definitions, it can
distinguish the mangled names used for linkage.  No information needs to
be added to the ABI, the object formats, or anything else other than
some extra mangling.  No changes are needed on the linker, or most of
the compiler - just a straightforward change to the compiler front-end
(and debuggers trying to interpret the mangled symbols).


Thus you need a change to the mangled name of a function only if you
want to use parameter name based overload.  Other uses of parameter
names are unaffected.




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

.

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

On Fri, 17 Aug 2018, 12:10 David Brown, <david@westcontrol.com> wrote:

> Let's add a syntax for /required/ named parameters.


The named parameter topic always starts with a suggestion that named
parameters make things easier for a user to read a function call site.
That's something I'm willing to go along with for the sake of argument.

What I'm uncomfortable about is when it forcably changes how a user writes
a function call. It doesn't make things much easier to write because
memorising the parameter names is barely different to memorising the
parameter orders. For me it's purely about reading the call site. I'm all
for people using it for their ease, but I want the choice of not using it
for mine. I know I'm not going to be creating them for a long time simply
because it isn't compatible with compilers and, being a language change,
there's no way of spoofing the behaviour.

I also don't like the notion of implicitly elevating a name to a type,
which is what I see here. Perhaps it's the physicist in me, but for me a
function operates on some types Ts..., which it is able to label purely for
its own purposes. I'm comfortable with the idea that if two calls do two
different things with the same types, either it isnt the same function or
they aren't the same semantic types. In most cases the latter should be the
case.

At least python handles the overloading issue - by not supporting
overloading. But that also comes with its own problems - it encourages
ridiculous interfaces. See pandas.to_csv as a good example - credit to them
for making such an incredible library, but their many-optional-parameter
interfaces combined with their inconsistent parameter naming styles results
in a usability nightmare, and we're opening ourselves up to that mentality
with the very mention of named parameters.

Anyway, rant over.

While I disagree with the reason for wanting forcably named parameters, one
thing it does provide is an implementation via strong types. One that can
be implemented at a higher level without changing the mangling, and without
runtime overhead. If a function has a forced named parameter, such as
my_func(@T x), that @T can be internally represented as a struct my_func_x
{ T value; }. When you call my_func(x: 3), it puts 3 into a struct
my_func_x, passes that to my_func, which then automatically
reinterpret_casts the my_func_x as a T* and dereferences into x. As
my_func_y cant implicitly cast to my_func_x, there's no ambiguity.

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

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

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, =
17 Aug 2018, 12:10 David Brown, &lt;<a href=3D"mailto:david@westcontrol.com=
" rel=3D"noreferrer noreferrer" target=3D"_blank">david@westcontrol.com</a>=
&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Let&#39;s add a syntax =
for /required/ named parameters.</blockquote></div></div><div dir=3D"auto">=
<br></div><div dir=3D"auto">The named parameter topic always starts with a =
suggestion that named parameters make things easier for a user to read a fu=
nction call site. That&#39;s something I&#39;m willing to go along with for=
 the sake of argument.</div><div dir=3D"auto"><br></div><div dir=3D"auto">W=
hat I&#39;m uncomfortable about is when it forcably changes how a user writ=
es a function call. It doesn&#39;t make things much easier to write because=
 memorising the parameter names is barely different to memorising the param=
eter orders. For me it&#39;s purely about reading the call site. I&#39;m al=
l for people using it for their ease, but I want the choice of not using it=
 for mine. I know I&#39;m not going to be creating them for a long time sim=
ply because it isn&#39;t compatible with compilers and, being a language ch=
ange, there&#39;s no way of spoofing the behaviour.</div><div dir=3D"auto">=
<br></div><div dir=3D"auto">I also don&#39;t like the notion of implicitly =
elevating a name to a type, which is what I see here. Perhaps it&#39;s the =
physicist in me, but for me a function operates on some types Ts..., which =
it is able to label purely for its own purposes. I&#39;m comfortable with t=
he idea that if two calls do two different things with the same types, eith=
er it isnt the same function or they aren&#39;t the same semantic types. In=
 most cases the latter should be the case.</div><div dir=3D"auto"><br></div=
><div dir=3D"auto">At least python handles the overloading issue - by not s=
upporting overloading. But that also comes with its own problems - it encou=
rages ridiculous interfaces. See pandas.to_csv as a good example - credit t=
o them for making such an incredible library, but their many-optional-param=
eter interfaces combined with their inconsistent parameter naming styles re=
sults in a usability nightmare, and we&#39;re opening ourselves up to that =
mentality with the very mention of named parameters.</div><div dir=3D"auto"=
><br></div><div dir=3D"auto">Anyway, rant over.</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">While I disagree with the reason for wanting forcab=
ly named parameters, one thing it does provide is an implementation via str=
ong types. One that can be implemented at a higher level without changing t=
he mangling, and without runtime overhead. If a function has a forced named=
 parameter, such as my_func(@T x), that @T can be internally represented as=
 a struct my_func_x { T value; }. When you call my_func(x: 3), it puts 3 in=
to a struct my_func_x, passes that to my_func, which then automatically rei=
nterpret_casts the my_func_x as a T* and dereferences into x. As my_func_y =
cant implicitly cast to my_func_x, there&#39;s no ambiguity.</div><div dir=
=3D"auto"></div></div>

<p></p>

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

--0000000000002cbaf20573a0cfe4--

.

On 17/08/18 14:36, Jake Arkinstall wrote:
> On Fri, 17 Aug 2018, 12:10 David Brown, <david@westcontrol.com
> <mailto:david@westcontrol.com>> wrote:
>
>     Let's add a syntax for /required/ named parameters.
>
>
> The named parameter topic always starts with a suggestion that named
> parameters make things easier for a user to read a function call site.
> That's something I'm willing to go along with for the sake of argument.
>

No one (I hope) suggests that named parameters always make it easier to
read or write function calls correctly - merely that they are a tool
that can improve readability and help get correct code in some cases.

> What I'm uncomfortable about is when it forcably changes how a user
> writes a function call.

I agree.  I want it to be optional.  I can only see it be /required/ if
parameter name based overloading is used.  (Overloading by parameter
name is not something I see as a big issue, or a big use case, but some
people are keen on it.)

> It doesn't make things much easier to write
> because memorising the parameter names is barely different to memorising
> the parameter orders.

IDE's will help with this, but otherwise I agree.

> For me it's purely about reading the call site.
> I'm all for people using it for their ease, but I want the choice of not
> using it for mine. I know I'm not going to be creating them for a long
> time simply because it isn't compatible with compilers and, being a
> language change, there's no way of spoofing the behaviour.

Agreed.  I would be entirely against a syntax that required changes to
the definitions or declarations of functions that made them incompatible
with existing compilers - except where it supports a new feature that
was not available previously.  (This would be parameter name based
overloading.)

>
> I also don't like the notion of implicitly elevating a name to a type,
> which is what I see here. Perhaps it's the physicist in me, but for me a
> function operates on some types Ts..., which it is able to label purely
> for its own purposes. I'm comfortable with the idea that if two calls do
> two different things with the same types, either it isnt the same
> function or they aren't the same semantic types. In most cases the
> latter should be the case.
>
> At least python handles the overloading issue - by not supporting
> overloading. But that also comes with its own problems - it encourages
> ridiculous interfaces. See pandas.to_csv as a good example - credit to
> them for making such an incredible library, but their
> many-optional-parameter interfaces combined with their inconsistent
> parameter naming styles results in a usability nightmare, and we're
> opening ourselves up to that mentality with the very mention of named
> parameters.
>
> Anyway, rant over.
>
> While I disagree with the reason for wanting forcably named parameters,
> one thing it does provide is an implementation via strong types. One
> that can be implemented at a higher level without changing the mangling,
> and without runtime overhead. If a function has a forced named
> parameter, such as my_func(@T x), that @T can be internally represented
> as a struct my_func_x { T value; }. When you call my_func(x: 3), it puts
> 3 into a struct my_func_x, passes that to my_func, which then
> automatically reinterpret_casts the my_func_x as a T* and dereferences
> into x. As my_func_y cant implicitly cast to my_func_x, there's no
> ambiguity.
>

What you are suggesting here, I think, is that forced named parameters -
as required for parameter name based overloading - could be handled as
syntactic sugar for generating new types on the fly.  That does not
sound unreasonable, and could be a way to implement it using a minimum
of changes to existing tools.


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

.

This is a multi-part message in MIME format.
--------------1644943E0458EE6E153C8AB8
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 16/08/2018 =C3=A0 21:50, Thiago Macieira a =C3=A9crit=C2=A0:
> On Thursday, 16 August 2018 07:53:47 PDT David Brown wrote:
>>> void bar(int :a);
>>> void bar(int :x); // distinct overload
>>>
>>> ...is pointless.
>> I disagree.  Distinct overloads like this would be nice, but (as I
>> wrote) extremely costly in terms of changes to implementations and
>> existing software.  I would rather see that as a later enhancement once
>> we have the simple named parameters in place - my proposal does not
>> conflict with having this as a later feature.
> I don't think you can have this as a later feature. It needs to be design=
ed in
> from the first version.
>
> The mangling of "void bar(int)" is
>  _Z3bari
>  ?bar@@YAXH@Z
>
> If this is used for "void bar(int :a)", then you CANNOT later overload wi=
th
> "void bar(int :x)". In other words, for named arguments to be overloadabl=
e at
> any point in the future, they must have been overloadable at all points i=
n the
> past too.
>

I think that these are orthogonal features and should be defined=20
independently.

For me named parameters are just syntactic sugar and shouldn't change=20
neither the signature of the function nor the mangling.

For me, having two declarations of the same function with different=20
parameters, should just allow to use those parameters as named parameters.

So having

 =C2=A0=C2=A0=C2=A0 void f(int a, int b);

 =C2=A0=C2=A0=C2=A0 void f(int x, int y);

would allow to use the named parameters and b and x and y respectively.

The question is why allowing that?

The idea is that we want to avoid a successful TU to be modified because=20
we add an additional declaration on one of the header files.


As this would request to compiler to store somewhere all the=20
declarations of a specific function, I believe that in order to don't=20
pay for what we don't use, we would need to opt in for the feature is=20
some specific way, that I don't worry about. E.g.

 =C2=A0=C2=A0=C2=A0 void f(a:int, b:int);

 =C2=A0=C2=A0=C2=A0 void f(x:int x, y:int);

Only in this case the named parameters should be allowed.

I could live also having the naming by default, but I believe that the=20
name used for something that today is not in the public interface would=20
very often be not the most appropriated hence the need to opt in.

We should note that if opt in is not retained, this doesn't mean that=20
from the standard library point of view we shouldn't opt in to have a=20
public parameter name, as it shall be part of the wording, so bikesheing=20
will not be avoided.


The other alternatives for me are

* names are part of the signature and we can overload on them. This is=20
something else for me (this would be syntactic sugar for tag=20
dispatching). I'm not saying we don't need something like that, just=20
that I don't want to name this or mix with=C2=A0 name parameters as it is=
=20
naming an overload not a parameter.

 =C2=A0=C2=A0=C2=A0 The syntax for this kind of additional named function/c=
onstructor=20
overload could be different as the implications are different and maybe=20
the needs are also different.

 =C2=A0=C2=A0=C2=A0 If we need something else to be able to oveload it shou=
ld be=20
something that is on the domain of types and so syntactic sugar for tag=20
types. This will change the signature and of course the mangling of the=20
function.


* only one set of names is possible for all the TU (this need the kind=20
of mangling you are suggesting). I can live without this. IIRC this was=20
the approach that was rejected by the committee.

* only one set of names is possible for a TU. This is easy to check but=20
I it is not stable. Adding an additional header file would add=20
additional forward declaration that could break the code.


Vicente




--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/60fba045-252b-486e-92e0-03c08b6d5a35%40wanadoo.f=
r.

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

<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 16/08/2018 =C3=A0 21:50, Thiago Macie=
ira
      a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite" cite=3D"mid:1708615.QdClGnisbJ@tjmaciei-mobl1=
">
      <pre wrap=3D"">On Thursday, 16 August 2018 07:53:47 PDT David Brown w=
rote:
</pre>
      <blockquote type=3D"cite">
        <blockquote type=3D"cite">
          <pre wrap=3D"">void bar(int :a);
void bar(int :x); // distinct overload

....is pointless.
</pre>
        </blockquote>
        <pre wrap=3D"">
I disagree.  Distinct overloads like this would be nice, but (as I
wrote) extremely costly in terms of changes to implementations and
existing software.  I would rather see that as a later enhancement once
we have the simple named parameters in place - my proposal does not
conflict with having this as a later feature.
</pre>
      </blockquote>
      <pre wrap=3D"">
I don't think you can have this as a later feature. It needs to be designed=
 in=20
from the first version.

The mangling of "void bar(int)" is
 _Z3bari
 ?bar@@YAXH@Z

If this is used for "void bar(int :a)", then you CANNOT later overload with=
=20
"void bar(int :x)". In other words, for named arguments to be overloadable =
at=20
any point in the future, they must have been overloadable at all points in =
the=20
past too.

</pre>
    </blockquote>
    <p><font size=3D"+1"><br>
      </font></p>
    <p><font size=3D"+1">I think that these are orthogonal features and
        should be defined independently.<br>
      </font></p>
    <p><font size=3D"+1">For me named parameters are just syntactic sugar
        and shouldn't change neither the signature of the function nor
        the mangling. <br>
      </font></p>
    <p><font size=3D"+1">For me, having two declarations of the same
        function with different parameters, should just allow to use
        those parameters as named parameters.</font></p>
    <p><font size=3D"+1">So having</font></p>
    <p><font size=3D"+1">=C2=A0=C2=A0=C2=A0 void f(int a, int b);<br>
      </font></p>
    <p><font size=3D"+1"><font size=3D"+1">=C2=A0=C2=A0=C2=A0 void f(int x,=
 int y);</font></font></p>
    <p><font size=3D"+1"><font size=3D"+1">would allow to use the named
          parameters and b and x and y respectively.<br>
        </font></font></p>
    <p><font size=3D"+1"><font size=3D"+1">The question is why allowing
          that? <br>
        </font></font></p>
    <p><font size=3D"+1"><font size=3D"+1">The idea is that we want to avoi=
d
          a successful TU to be modified because we add an additional
          declaration on one of the header files.<br>
        </font></font></p>
    <p><font size=3D"+1"><font size=3D"+1"><br>
        </font></font></p>
    <p><font size=3D"+1"><font size=3D"+1">As this would request to compile=
r
          to store somewhere all the declarations of a specific
          function, I believe that in order to don't pay for what we
          don't use, we would need to opt in for the feature is some
          specific way, that I don't worry about. E.g.</font></font></p>
    <p><font size=3D"+1">=C2=A0=C2=A0=C2=A0 void f(a:int, b:int);<br>
      </font></p>
    <p><font size=3D"+1"><font size=3D"+1">=C2=A0=C2=A0=C2=A0 void f(x:int =
x, y:int);</font></font></p>
    <p><font size=3D"+1"><font size=3D"+1">Only in this case the named
          parameters should be allowed.<br>
        </font></font></p>
    <p>I could live also having the naming by default, but I believe
      that the name used for something that today is not in the public
      interface would very often be not the most appropriated hence the
      need to opt in.</p>
    <p>We should note that if opt in is not retained, this doesn't mean
      that from the standard library point of view we shouldn't opt in
      to have a public parameter name, as it shall be part of the
      wording, so bikesheing will not be avoided.<br>
    </p>
    <p><br>
    </p>
    <p><font size=3D"+1">The other alternatives for me are<br>
      </font></p>
    <p><font size=3D"+1">* names are part of the signature and we can
        overload on them. This is something else for me (this would be
        syntactic sugar for tag dispatching). I'm not saying we don't
        need something like that, just that I don't want to name this or
        mix with=C2=A0 name parameters as it is naming an overload not a
        parameter.</font></p>
    <p><font size=3D"+1">=C2=A0=C2=A0=C2=A0 The syntax for this kind of add=
itional named
        function/constructor overload could be different as the
        implications are different and maybe the needs are also
        different.<br>
      </font></p>
    <p><font size=3D"+1">=C2=A0=C2=A0=C2=A0 If we need something else to be=
 able to
        oveload it should be something that is on the domain of types
        and so syntactic sugar for tag types. This will change the
        signature and of course the mangling of the function.</font></p>
    <p><font size=3D"+1"><br>
      </font></p>
    <p><font size=3D"+1">* only one set of names is possible for all the
        TU (this need the kind of mangling you are suggesting). I can
        live without this. IIRC this was the approach that was rejected
        by the committee.<br>
      </font></p>
    <p><font size=3D"+1"><font size=3D"+1">* </font></font><font size=3D"+1=
"><font
          size=3D"+1"><font size=3D"+1">only one set of names</font> is
          possible for a TU. This is easy to check but I it is not
          stable. Adding an additional header file would add additional
          forward declaration that could break the code.<br>
        </font></font></p>
    <p><font size=3D"+1"><font size=3D"+1"><br>
        </font></font></p>
    <p><font size=3D"+1"><font size=3D"+1">Vicente<br>
        </font></font></p>
    <br>
    <p><font size=3D"+1"><br>
      </font></p>
    <p><font size=3D"+1"></font><br>
    </p>
  </body>
</html>

<p></p>

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

--------------1644943E0458EE6E153C8AB8--

.

On Friday, 17 August 2018 07:46:42 PDT Vicente J. Botet Escriba wrote:
> As this would request to compiler to store somewhere all the
> declarations of a specific function, I believe that in order to don't
> pay for what we don't use, we would need to opt in for the feature is
> some specific way, that I don't worry about. E.g.
>
>      void f(a:int, b:int);
>
>      void f(x:int x, y:int);
>
> Only in this case the named parameters should be allowed.

Agreed. To me, parameter names need to be opt-in. Anything else is simply not
workable as the names have not and will continue not to be stable, so they
aren't usable by users in the first place.

But my question to you is: are those two function declarations the same
function? If they are, how do you propose we declare them so that they are
*not* the same function?

>      The syntax for this kind of additional named function/constructor
> overload could be different as the implications are different and maybe
> the needs are also different.

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



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

.

On 2018-08-17 06:14, David Brown wrote:
> On 16/08/18 15:08, mihailnajdenov@gmail.com wrote:
>> There are tree major problems with such simple approaches
>>
>> First - you make something, that has been private for 30+ years, public.
>
> No, it is not.  The names for parameters are in function declarations,
> in headers - these are public.

No, they aren't. Or, more correctly, while they are "public" in the
sense that a user can see them by reading the header, they aren't a
(normative) part of the API, any more than comments are. To *the
compiler*, they may as well not exist.

You are proposing to change that. That is a *serious* change.

> But I would want to be able to call existing functions using named
> arguments, and I would want to call new functions with positional
> arguments.  I am sceptical to the idea of being able to force the use of
> named arguments at any point

I don't think anyone has proposed that, with one exception:

  foo(int :a, int :b = 3, int :c = 12);
  foo(1, c: 6); // name *must* be used here because 'b' is omitted

At least, I don't know any reason why we would need to require names to
be used, other than the above example.

> and the whole idea would be useless if
> special syntax were needed to declare that a function uses named parameters.

I don't think you can *avoid* that, since there is very strong
opposition (see above) to turning all existing functions into functions
that have named parameters. Also, everyone that *is* proposing to have
named parameters with syntax apparently don't share this opinion.

--
Matthew

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

.

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

On Fri, Aug 17, 2018, 7:46 AM Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:

> * only one set of names is possible for all the TU (this need the kind of
> mangling you are suggesting). I can live without this. IIRC this was the
> approach that was rejected by the committee.
>

Is there a way I can see the comments the committee has made on a proposal?
My impression from my research was counter to this: I thought the committee
didn't like that names could vary across translation units. I would like to
read the comments on proposals, rather than just guess what the committee's
concerns are

>

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

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

<div dir=3D"auto"><br><br><div class=3D"gmail_quote" dir=3D"auto"><div dir=
=3D"ltr">On Fri, Aug 17, 2018, 7:46 AM Vicente J. Botet Escriba &lt;<a href=
=3D"mailto:vicente.botet@wanadoo.fr">vicente.botet@wanadoo.fr</a>&gt; wrote=
:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"m_-1925368017976257733moz-cite-prefix">* only one set of =
names is possible for all the
        TU (this need the kind of mangling you are suggesting). I can
        live without this. IIRC this was the approach that was rejected
        by the committee.</div></div></blockquote></div><div dir=3D"auto"><=
br></div><div dir=3D"auto">Is there a way I can see the comments the commit=
tee has made on a proposal? My impression from my research was counter to t=
his: I thought the committee didn&#39;t like that names could vary across t=
ranslation units. I would like to read the comments on proposals, rather th=
an just guess what the committee&#39;s concerns are</div><div class=3D"gmai=
l_quote" dir=3D"auto"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div>

<p></p>

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

--000000000000c7cdb80573a30fe9--

.

On 2018-08-17 08:36, Jake Arkinstall wrote:
> At least python handles the overloading issue - by not supporting
> overloading. But that also comes with its own problems - it encourages
> ridiculous interfaces. See pandas.to_csv as a good example - credit to them
> for making such an incredible library, but their many-optional-parameter
> interfaces combined with their inconsistent parameter naming styles results
> in a usability nightmare, and we're opening ourselves up to that mentality
> with the very mention of named parameters.

A Python developer would say, "thank God we don't have those awful C++
interfaces with their dozens of confusing and redundant overloads". And
there is truth to that. I've written such interfaces, and there are
absolutely times I would *much* rather have a Pythonic interface with a
great big bag of *named* parameters.

Happiness, I think, lies somewhere between the two extremes, and/or in
being able to choose the most appropriate approach for any given problem
(i.e. having both tools in our toolbox).

--
Matthew

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

.

--0000000000009ceb970573a3e7d3
Content-Type: text/plain; charset="UTF-8"

On Fri, 17 Aug 2018, 16:16 Matthew Woehlke, <mwoehlke.floss@gmail.com>
wrote:

>
>   foo(int :a, int :b = 3, int :c = 12);
>   foo(1, c: 6); // name *must* be used here because 'b' is omitted
>

Ah. That does demolish my idea about using strong types as named wrappers
for the underlying type. Well, it makes it insufficient, at least - in
order to make it work we'd need to change the language to keep trying
parameter ordering until the types fit.

Unlike an approach that changes mangling directly, this does mean that the
following non-named code would become valid:

foo(const int& a=1, const std::string& b="hello");
foo("world"); //yuck

Which, innocent enough in this example, is going to be a source of bugs
when an implicit conversion exists - unless that ordering search matches
act as explicit, which is going to cause its own problems in terms of
usability.

>

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

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

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
On Fri, 17 Aug 2018, 16:16 Matthew Woehlke, &lt;<a href=3D"mailto:mwoehlke.=
floss@gmail.com" target=3D"_blank" rel=3D"noreferrer">mwoehlke.floss@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">
<br>
=C2=A0 foo(int :a, int :b =3D 3, int :c =3D 12);<br>
=C2=A0 foo(1, c: 6); // name *must* be used here because &#39;b&#39; is omi=
tted<br></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"au=
to">Ah. That does demolish my idea about using strong types as named wrappe=
rs for the underlying type. Well, it makes it insufficient, at least - in o=
rder to make it work we&#39;d need to change the language to keep trying pa=
rameter ordering until the types fit.</div><div dir=3D"auto"><br></div><div=
 dir=3D"auto">Unlike an approach that changes mangling directly, this does =
mean that the following non-named code would become valid:</div><div dir=3D=
"auto"><br></div><div dir=3D"auto">foo(const int&amp; a=3D1, const std::str=
ing&amp; b=3D&quot;hello&quot;);</div><div dir=3D"auto">foo(&quot;world&quo=
t;); //yuck</div><div dir=3D"auto"><br></div><div dir=3D"auto">Which, innoc=
ent enough in this example, is going to be a source of bugs when an implici=
t conversion exists - unless that ordering search matches act as explicit, =
which is going to cause its own problems in terms of usability.</div><div d=
ir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>

<p></p>

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

--0000000000009ceb970573a3e7d3--

.

On 2018-08-17 00:04, Justin Bassett wrote:
> I agree for the most part, but I disagree that this should be a valid
> overload set, unless parameters are name-only:
>
> void bar(int :a);
> void bar(int :x);
>
> The problem is that bar(4) is ambiguous.

So what?

  void foo(int, double=1.);
  void foo(int, int=2);

  foo(1); // error: ambiguous

  void bar(int :a); // #1
  void bar(int :x); // #2

  bar(1);    // error: ambiguous
  bar(.z=1); // error: no matching declaration
  bar(.a=1); // okay, calls #1

I don't see a problem here.

> Overloading on name-only parameters is just fine.

What is a "name only" parameter?

--
Matthew

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

.

On 2018-08-17 12:17, Jake Arkinstall wrote:
> On Fri, 17 Aug 2018, 16:16 Matthew Woehlke wrote:
>>   foo(int :a, int :b = 3, int :c = 12);
>>   foo(1, c: 6); // name *must* be used here because 'b' is omitted
>
> Ah. That does demolish my idea about using strong types as named wrappers
> for the underlying type.

Well... yes and no. "Strong types as named wrappers for the underlying
type" sounds suspiciously like where my own thoughts on this matter have
been going. However, while I would envision a library/type component, we
do *need* language-level support... not just for syntactic sugar, but
for this, specifically. (And since this is my #1 "killer feature" for
named arguments... don't get me wrong, tagged dispatch / named overload
is #2, but skipping arguments is #1 :-).)

> Well, it makes it insufficient, at least - in order to make it work
> we'd need to change the language to keep trying parameter ordering
> until the types fit.
>
> Unlike an approach that changes mangling directly, this does mean that the
> following non-named code would become valid:
>
> foo(const int& a=1, const std::string& b="hello");
> foo("world"); //yuck
>
> Which, innocent enough in this example, is going to be a source of bugs
> when an implicit conversion exists - unless that ordering search matches
> act as explicit, which is going to cause its own problems in terms of
> usability.

I would not allow skipping for unnamed parameters.

--
Matthew

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

.

On 17/08/18 17:16, Matthew Woehlke wrote:
> On 2018-08-17 06:14, David Brown wrote:
>> On 16/08/18 15:08, mihailnajdenov@gmail.com wrote:
>>> There are tree major problems with such simple approaches
>>>
>>> First - you make something, that has been private for 30+ years, public.
>>
>> No, it is not.  The names for parameters are in function declarations,
>> in headers - these are public.
>
> No, they aren't. Or, more correctly, while they are "public" in the
> sense that a user can see them by reading the header, they aren't a
> (normative) part of the API, any more than comments are. To *the
> compiler*, they may as well not exist.
>
> You are proposing to change that. That is a *serious* change.
>

Nah, you are overreacting.  At most, it is a /tiny/ issue compared to
the huge amount of implementation stuff in typical C++ headers that
really is supposed to be private implementation details.  (Hint: lots of
it is labelled "private:".)

It is very common to give sensible names to parameters in headers - just
as it is common to write sensible comments in headers.  Yes, the
compiler ignores them - but humans reading the headers do not, and lots
of other tools do /not/ ignore either parameter names or even comments.
 IDE's regularly show parameter names in some sort of tooltip or hint
when you are typing a function call, or will show them as a sort of
function summary - possibly along with nearby comments.  Documentation
tools like doxygen use them.

If you want to make it hard for people to use functions by obscuring the
point of the parameters, leave them unnamed.  Don't put a name in the
header and pretend it's a secret.

>> But I would want to be able to call existing functions using named
>> arguments, and I would want to call new functions with positional
>> arguments.  I am sceptical to the idea of being able to force the use of
>> named arguments at any point
>
> I don't think anyone has proposed that, with one exception:
>
>   foo(int :a, int :b = 3, int :c = 12);
>   foo(1, c: 6); // name *must* be used here because 'b' is omitted
>
> At least, I don't know any reason why we would need to require names to
> be used, other than the above example.

Some people have suggested a syntax for function declarations (or
definitions) that indicated that one or more of the parameters /must/ be
used as named parameters.  I can see that being useful if they are to be
used for overloads, but not otherwise.


>
>> and the whole idea would be useless if
>> special syntax were needed to declare that a function uses named parameters.
>
> I don't think you can *avoid* that, since there is very strong
> opposition (see above) to turning all existing functions into functions
> that have named parameters. Also, everyone that *is* proposing to have
> named parameters with syntax apparently don't share this opinion.
>

I don't think your argument against allowing people to use named
parameters for existing functions is at all convincing.  I am happy to
accept that /you/ have strong opinions against it - and therefore that
there is /some/ opposition to it.  Whether a lot of people share your
opinion here or not, I don't know.  All we can be sure about for now is
that some people strongly approve of it, some people strongly oppose it.
 I guess that's why we have a C++ standards committee, and not a C++
standards dictatorship.



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

.

------=_Part_900_1279948063.1534526380271
Content-Type: multipart/alternative;
 boundary="----=_Part_901_1406851582.1534526380271"

------=_Part_901_1406851582.1534526380271
Content-Type: text/plain; charset="UTF-8"



On Friday, August 17, 2018 at 1:08:45 AM UTC+3, Nicol Bolas wrote:
>
> On Thursday, August 16, 2018 at 5:38:49 PM UTC-4, mihailn...@gmail.com
> wrote:
>>
>> On Thursday, August 16, 2018 at 11:05:47 PM UTC+3, Nicol Bolas wrote:
>>>
>>> On Thursday, August 16, 2018 at 3:54:06 PM UTC-4, mihailn...@gmail.com
>>> wrote:
>>>>
>>>> On Thursday, August 16, 2018 at 9:49:30 PM UTC+3, Matthew Woehlke wrote:
>>>>>
>>>>> On 2018-08-16 14:40, mihailn...@gmail.com wrote:
>>>>> > This is already overloaded, no need for strong names.
>>>>>
>>>>> Eh? Both of those functions, without names have / would have the
>>>>> signature (double, double). Without strong names, that would be
>>>>> ambiguous.
>>>>>
>>>>
>>>> Ok I skimmed a bit too fast.
>>>>
>>>> As I said, I will not deny any use case, but the workarounds are not
>>>> hard and some would argue more correct in this case, like making angle a
>>>> different type.
>>>>
>>>>
>>>>>
>>>>> > As for future proofing -  *there is no problem if we support both*
>>>>> >
>>>>> > rect(Point topLeft: pos, Point bottomRight: br); //< weak argument
>>>>> names,
>>>>> > not mandatory
>>>>> >
>>>>> > // later in some future
>>>>> >
>>>>> > rect(center: Point pos, Point bottomRight: br) //< strong argument
>>>>> name,
>>>>> > adds an overload, not ignorable
>>>>>
>>>>>
>>>>
>>>>> How would... oh, wait, you're proposing to differentiate strong vs.
>>>>> weak
>>>>> names *based on position*? That's confusing as all else. I can't
>>>>> imagine
>>>>> that would *ever* be approved.
>>>>>
>>>>
>>>> Yet, it is learnable and does not require extra syntax.
>>>>
>>>
>>> There are a lot of things in C++ that are "learnable". SFINAE is
>>> "learnable". "Uniform" initialization is "learnable". The "Most Vexing
>>> Parse" is "learnable".
>>>
>>> But I think we can make a distinction between things whose behavior is
>>> fairly obvious and things whose behavior requires significant learning
>>> before it can be understood. What you're talking about seems more like the
>>> latter.
>>>
>>> That was not the point, the point is - we need both - one can't just say
>>>> "named arguments are like this" and stick to only one type.
>>>>
>>>> *Both* are useful, but for different things
>>>>  - weak as semantic disambiguation (for the reader) and conformation
>>>> (from the compiler), where using type is incorrect/impractical/maintenance
>>>> toll/code size toll,
>>>>    and, eventually for some sort of typing shortcut
>>>>  - strong as "named constructors", almost exclusively.
>>>>
>>>> Note that strong can't be used for the purpose of weak, because this
>>>> will be extremely annoying (*chough* Objective C)
>>>>
>>>
>>> The question therefore is whether we need "weak semantic disambiguation
>>> and confirmation" as a language feature at all.
>>>
>>> Strong named parameters actually *do something*; they allow us to
>>> express things that either couldn't be done before or were very
>>> inconvenient to do.
>>>
>>
>>> Weak named parameters by contrast are mere notation. So why is it
>>> important that we have a language feature for that?
>>>
>>
>> They fix the last semantic hole that neither Types nor Contracts can fix.
>> Types bound what the item is, contracts bound what value the item has,
>> names bound what the meaning of the item is.
>>
>> Often meaning is inferred form type but often this is not possible (math,
>> physics) or simply incorrect semantically - MotherName is wrong kind of
>> type.
>> And often meaning is inferred from the variables themselves, but that is
>> not enforceable.
>>
>> Yet, passing an argument, meaning something different is, for all intend
>> and proposes, a breach of contract, no matter if this is a form on paper to
>> fill with a pen or a function call.
>>
>
> Your argument makes more sense for strong names than weak ones. After all,
> if "meaning something different" is truly a "breach of contract" (and
> therefore an error), then that contract is important enough to be stated
> whenever the function is used. If I've written a function that needs to
> test this "contract", then I want everyone who calls it to actually provide
> the correct information.
>
> And if the contract is not important enough to be stated explicitly, then
> why does it need to be said at all. How can a contract be *optional*? And
> I don't mean in the Contracts proposal way, where compiler options/`axiom`
> can turn them on or off. I mean in that each individual use has the ability
> to pick and choose whether to provide this "meaning" or not.
>

It is not optional, but the help writing them is.
So ok, weak names are helpers writing correctly the contract, not the
contract itself. They are like a clerk - you can ask him for help, you can
ask him to verify OR you can do it yourself if you know what you are doing.



>
> Or to put it another way, the only reason "override" is optional is that
> it would be a huge compatibility break to make it mandatory. That feature
> is very similar to here: both cases are stating the meaning of something
> explicitly.
>
> Why is this meaning important enough to be said and verified sometimes and
> not other-times?
>
> Lastly, a big problem I have with your conception of weak names is that
> you're trying to make them a full-fledged piece of information connected
> with a value (in order to make forwarding work)... but you're not using any
> existing C++ mechanism to provide this channel of information. Names aren't
> types. They aren't values. They're associated with parameter names, but
> they have to be able to pass through `std::forward` somehow. And users have
> to be able to pass them to non-named functions (like loggers) as well as
> named ones.
>
>
Agreed, for better or worse names are outside the language as defined use
today. Probably the closest are attributes. Super pretty attributes. We
just need a way to mark (or hardcode) std::forward as forwarding them

And BTW, it is not some my conception - C# uses weak names for 10 years
now, pure compiler syntax, outside of types or function signature.

Also, it should be noted it is the weak ones that were proposed for C++ for
26 years now. People just seem to need some extra level of (trivial to get)
protection and explicitness.



> The various strong naming proposals make these names actual parts of the
> C++ language. Some make them into values passed into the function. Others
> make the function take an unnamed struct. And so forth.
>
> Weak names can't work through normal C++ channels of information.
>
> Can this be solved by types - only if workaround is solving
>> Can this be solved by strong names - well, yeah, at the price of thinking
>> the users are idiots having them to repeat like monkeys every name that "we
>> think it is important".
>>
>
> To the degree that I think named parameters are important enough to have
> in the language, I will happily pay the price of the latter if it means not
> having to pay the price of having *two syntaxes* for things that are
> essentially the same thing.
>

They are not the same, and languages that have only one syntax pick one or
another - C# weak, Objective C- strong.

I am not proposing something concretely, just saying both are valuable, and
theoretically we could have both.

As said, the only reason I would prefer to get weak first, is because the
others are easier to workaround.

And I do believe having mandatory only names will be very annoying - after
all you would need at most one or two strongs to disambiguate and all the
others will be a pain.
Or, we would need extra syntax to make some names optional (ala Swift), but
then, well, we have both strong and weak syntaxes, don't we?

rect(center c: Point, _ br: Point) //< Swift "two syntaxes" mandatory and
optional


> It's bad enough that we're creating two separate names for a parameter at
> all (the in-function name and the out-of-function name). Let's not compound
> this folly by having two ways to set the out-of-function name that have
> slightly different meanings.
>
>

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

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

<div dir=3D"ltr"><br><br>On Friday, August 17, 2018 at 1:08:45 AM UTC+3, Ni=
col Bolas 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"lt=
r">On Thursday, August 16, 2018 at 5:38:49 PM UTC-4, <a>mihailn...@gmail.co=
m</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">On Thu=
rsday, August 16, 2018 at 11:05:47 PM UTC+3, Nicol Bolas 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">On Thursday, August 16, 2018 a=
t 3:54:06 PM UTC-4, <a>mihailn...@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">On Thursday, August 16, 2018 at 9:49:30=
 PM UTC+3, Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On=
 2018-08-16 14:40, <a rel=3D"nofollow">mihailn...@gmail.com</a> wrote:
<br>&gt; This is already overloaded, no need for strong names.
<br>
<br>Eh? Both of those functions, without names have / would have the
<br>signature (double, double). Without strong names, that would be ambiguo=
us.
<br></blockquote><div><br></div><div>Ok I skimmed a bit too fast.</div><div=
><br></div><div>As I said, I will not deny any use case, but the workaround=
s are not hard and some would argue more correct in this case, like making =
angle a different type.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex">
<br>&gt; As for future proofing - =C2=A0*there is no problem if we support =
both*
<br>&gt;=20
<br>&gt; rect(Point topLeft: pos, Point bottomRight: br); //&lt; weak argum=
ent names,=20
<br>&gt; not mandatory=20
<br>&gt;=20
<br>&gt; // later in some future
<br>&gt; =C2=A0
<br>&gt; rect(center: Point pos, Point bottomRight: br) //&lt; strong argum=
ent name,=20
<br>&gt; adds an overload, not ignorable=20
<br>
<br></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>How would... oh, wait, you&#39;re proposing to differentiate strong vs. we=
ak
<br>names *based on position*? That&#39;s confusing as all else. I can&#39;=
t imagine
<br>that would *ever* be approved.
<br></blockquote><div><br></div><div>Yet, it is learnable and does not requ=
ire extra syntax.</div></div></blockquote><div><br></div><div>There are a l=
ot of things in C++ that are &quot;learnable&quot;. SFINAE is &quot;learnab=
le&quot;. &quot;Uniform&quot; initialization is &quot;learnable&quot;. The =
&quot;Most Vexing Parse&quot; is &quot;learnable&quot;.<br></div><div><br><=
/div><div>But I think we can make a distinction between things whose behavi=
or is fairly obvious and things whose behavior requires significant learnin=
g before it can be understood. What you&#39;re talking about seems more lik=
e the latter.<br></div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div></div><div>That was not the point, the point is - =
we need both - one can&#39;t just say &quot;named arguments are like this&q=
uot; and stick to only one type.=C2=A0</div><div><br></div><div><i>Both</i>=
 are useful, but for different things=C2=A0</div><div>=C2=A0- weak as seman=
tic disambiguation (for the reader) and conformation (from the compiler), w=
here using type is incorrect/impractical/<wbr>maintenance toll/code size to=
ll,=C2=A0</div><div>=C2=A0=C2=A0 and, eventually for some sort of typing sh=
ortcut</div><div>=C2=A0- strong as &quot;named constructors&quot;, almost e=
xclusively.<br></div><div><br></div><div>Note that strong can&#39;t be used=
 for the purpose of weak, because this will be extremely annoying (*chough*=
 Objective C)<br></div></div></blockquote><div><br></div><div>The question =
therefore is whether we need &quot;weak semantic disambiguation and confirm=
ation&quot; as a language feature at all.</div><div><br></div><div>Strong n=
amed parameters actually <i>do something</i>; they allow us to express thin=
gs that either couldn&#39;t be done before or were very inconvenient to do.=
=C2=A0</div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div><br></div><div>Weak named parameters by contrast are mere=
 notation. So why is it important that we have a language feature for that?=
</div></div></blockquote><div><br></div><div>They fix the last semantic hol=
e that neither Types nor Contracts can fix.=C2=A0</div><div>Types bound wha=
t the item is, contracts bound what value the item has, names bound what th=
e meaning of the item is.</div><div><br></div><div>Often meaning is inferre=
d form type but often this is not possible (math, physics) or simply incorr=
ect semantically - MotherName is wrong kind of type.<br></div><div>And ofte=
n meaning is inferred from the variables themselves, but that is not enforc=
eable.</div><div><br></div><div>Yet, passing an argument, meaning something=
 different is, for all intend and proposes, a breach of contract, no matter=
 if this is a form on paper to fill with a pen or a function call.<br></div=
></div></blockquote><div><br></div><div>Your argument makes more sense for =
strong names than weak ones. After all, if &quot;meaning something differen=
t&quot; is truly a &quot;breach of contract&quot; (and therefore an error),=
 then that contract is important enough to be stated whenever the function =
is used. If I&#39;ve written a function that needs to test this &quot;contr=
act&quot;, then I want everyone who calls it to actually provide the correc=
t information.<br></div><div><br></div><div>And if the contract is not impo=
rtant enough to be stated explicitly, then why does it need to be said at a=
ll. How can a contract be <i>optional</i>? And I don&#39;t mean in the Cont=
racts proposal way, where compiler options/`axiom` can turn them on or off.=
 I mean in that each individual use has the ability to pick and choose whet=
her to provide this &quot;meaning&quot; or not.<br></div></div></blockquote=
><div><br></div><div>It is not optional, but the help writing them is.<br>S=
o ok, weak names are helpers writing correctly the contract, not the contra=
ct itself. They are like a clerk - you can ask him for help, you can ask hi=
m to verify OR you can do it yourself if you know what you are doing.=C2=A0=
</div><div><br>=C2=A0=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"ltr"><div></div><div><br></div><div>Or to put it another way=
, the only reason &quot;override&quot; is optional is that it would be a hu=
ge compatibility break to make it mandatory. That feature is very similar t=
o here: both cases are stating the meaning of something explicitly.</div><d=
iv><br></div><div>Why is this meaning important enough to be said and verif=
ied sometimes and not other-times?</div><div><br></div><div>Lastly, a big p=
roblem I have with your conception of weak names is that you&#39;re trying =
to make them a full-fledged piece of information connected with a value (in=
 order to make forwarding work)... but you&#39;re not using any existing C+=
+ mechanism to provide this channel of information. Names aren&#39;t types.=
 They aren&#39;t values. They&#39;re associated with parameter names, but t=
hey have to be able to pass through `std::forward` somehow. And users have =
to be able to pass them to non-named functions (like loggers) as well as na=
med ones.</div><div><br></div></div></blockquote><div><br></div><div>Agreed=
, for better or worse names are outside the language as defined use today. =
Probably the closest are attributes. Super pretty attributes. We just need =
a way to mark (or hardcode) std::forward as forwarding them</div><div><br><=
/div><div>And BTW, it is not some my conception - C# uses weak names for 10=
 years now, pure compiler syntax, outside of types or function signature.</=
div><div><br></div><div>Also, it should be noted it is the weak ones that w=
ere proposed for C++ for 26 years now. People just seem to need some extra =
level of (trivial to get) protection and explicitness.=C2=A0</div><div><br>=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><div></div><div>The various strong naming proposals make these na=
mes actual parts of the C++ language. Some make them into values passed int=
o the function. Others make the function take an unnamed struct. And so for=
th.</div><div><br></div><div>Weak names can&#39;t work through normal C++ c=
hannels of information.<br></div><div><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div></div><div></div><div>Can this be solved=
 by types - only if workaround is solving=C2=A0</div><div>Can this be solve=
d by strong names - well, yeah, at the price of thinking the users are idio=
ts having them to repeat like monkeys every name that &quot;we think it is =
important&quot;.</div></div></blockquote><div><br></div><div>To the degree =
that I think named parameters are important enough to have in the language,=
 I will happily pay the price of the latter if it means not having to pay t=
he price of having <i>two syntaxes</i> for things that are essentially the =
same thing.</div></div></blockquote><div><br></div><div>They are not the sa=
me, and languages that have only one syntax pick one or another - C# weak, =
Objective C- strong.</div><div><br></div><div>I am not proposing something =
concretely, just saying both are valuable, and theoretically we could have =
both.</div><div><br></div><div>As said, the only reason I would prefer to g=
et weak first, is because the others are easier to workaround.</div><div><b=
r></div><div>And I do believe having mandatory only names will be very anno=
ying - after all you would need at most one or two strongs to disambiguate =
and all the others will be a pain. <br>Or, we would need extra syntax to ma=
ke some names optional (ala Swift), but then, well, we have both strong and=
 weak syntaxes, don&#39;t we?</div><div><br></div><div><font face=3D"courie=
r new,monospace">rect(center c: Point, _ br: Point) //&lt; Swift &quot;two =
syntaxes&quot; mandatory and optional</font><font face=3D"courier new,monos=
pace"><br></font></div><div><font face=3D"courier new,monospace"><b></b><i>=
</i><u></u><sub></sub><sup></sup><strike></strike><br></font></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><b></b><i></i><u=
></u><sub></sub><sup></sup><strike></strike><font face=3D"courier new,monos=
pace"></font><br></div><div>It&#39;s bad enough that we&#39;re creating two=
 separate names for a parameter at all (the in-function name and the out-of=
-function name). Let&#39;s not compound this folly by having two ways to se=
t the out-of-function name that have slightly different meanings.</div><br>=
</div></blockquote></div>

<p></p>

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

------=_Part_901_1406851582.1534526380271--

------=_Part_900_1279948063.1534526380271--

.

------=_Part_979_980756520.1534527046877
Content-Type: multipart/alternative;
 boundary="----=_Part_980_111926103.1534527046877"

------=_Part_980_111926103.1534527046877
Content-Type: text/plain; charset="UTF-8"



On Friday, August 17, 2018 at 1:12:20 PM UTC-4, David Brown wrote:
>
> On 17/08/18 17:16, Matthew Woehlke wrote:
> > On 2018-08-17 06:14, David Brown wrote:
> >> On 16/08/18 15:08, mihailn...@gmail.com <javascript:> wrote:
> >>> There are tree major problems with such simple approaches
> >>>
> >>> First - you make something, that has been private for 30+ years,
> public.
> >>
> >> No, it is not.  The names for parameters are in function declarations,
> >> in headers - these are public.
> >
> > No, they aren't. Or, more correctly, while they are "public" in the
> > sense that a user can see them by reading the header, they aren't a
> > (normative) part of the API, any more than comments are. To *the
> > compiler*, they may as well not exist.
> >
> > You are proposing to change that. That is a *serious* change.
> >
>
> Nah, you are overreacting.  At most, it is a /tiny/ issue compared to
> the huge amount of implementation stuff in typical C++ headers that
> really is supposed to be private implementation details.  (Hint: lots of
> it is labelled "private:".)
>

"Overreacting"? Show me a standard library implementation that actually
uses the parameter names that the standard library defines. What's more,
standard libraries *cannot* use those parameter names. Why?

Macro defensiveness.

Users can define macros with almost any names. And standard library headers
are *required* to not be affected by such macros. As such, standard library
implementations are required to use the set of names that macros cannot
touch: names that are restricted for the implementation.

So if you can't even rely on the standard library's parameter names, you
would be unable to write cross-platform code that uses those names. And if
you can't even rely on the *standard* library... what *can* you rely on?

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

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

<div dir=3D"ltr"><br><br>On Friday, August 17, 2018 at 1:12:20 PM UTC-4, Da=
vid Brown wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 17/08/18 17=
:16, Matthew Woehlke wrote:
<br>&gt; On 2018-08-17 06:14, David Brown wrote:
<br>&gt;&gt; On 16/08/18 15:08, <a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"g0x5AT5jDAAJ" rel=3D"nofollow" onmousedown=3D"this.=
href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;java=
script:&#39;;return true;">mihailn...@gmail.com</a> wrote:
<br>&gt;&gt;&gt; There are tree major problems with such simple approaches=
=20
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; First - you make something, that has been private for 30+ =
years, public.
<br>&gt;&gt;
<br>&gt;&gt; No, it is not. =C2=A0The names for parameters are in function =
declarations,
<br>&gt;&gt; in headers - these are public.
<br>&gt;=20
<br>&gt; No, they aren&#39;t. Or, more correctly, while they are &quot;publ=
ic&quot; in the
<br>&gt; sense that a user can see them by reading the header, they aren&#3=
9;t a
<br>&gt; (normative) part of the API, any more than comments are. To *the
<br>&gt; compiler*, they may as well not exist.
<br>&gt;=20
<br>&gt; You are proposing to change that. That is a *serious* change.
<br>&gt;=20
<br>
<br>Nah, you are overreacting. =C2=A0At most, it is a /tiny/ issue compared=
 to
<br>the huge amount of implementation stuff in typical C++ headers that
<br>really is supposed to be private implementation details. =C2=A0(Hint: l=
ots of
<br>it is labelled &quot;private:&quot;.)<br></blockquote><div><br></div><d=
iv>&quot;Overreacting&quot;? Show me a standard library implementation that=
 actually uses the parameter names that the standard library defines. What&=
#39;s more, standard libraries <i>cannot</i> use those parameter names. Why=
?</div><div><br></div><div>Macro defensiveness.</div><div><br></div><div>Us=
ers can define macros with almost any names. And standard library headers a=
re <i>required</i> to not be affected by such macros. As such, standard lib=
rary implementations are required to use the set of names that macros canno=
t touch: names that are restricted for the implementation.</div><div><br></=
div><div>So if you can&#39;t even rely on the standard library&#39;s parame=
ter names, you would be unable to write cross-platform code that uses those=
 names. And if you can&#39;t even rely on the <i>standard</i> library... wh=
at <i>can</i> you rely on?</div><br></div>

<p></p>

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

------=_Part_980_111926103.1534527046877--

------=_Part_979_980756520.1534527046877--

.

On 17 August 2018 at 20:30, Nicol Bolas <jmckesson@gmail.com> wrote:
> "Overreacting"? Show me a standard library implementation that actually uses
> the parameter names that the standard library defines. What's more, standard
> libraries cannot use those parameter names. Why?
>
> Macro defensiveness.
>
> Users can define macros with almost any names. And standard library headers
> are required to not be affected by such macros. As such, standard library
> implementations are required to use the set of names that macros cannot
> touch: names that are restricted for the implementation.
>
> So if you can't even rely on the standard library's parameter names, you
> would be unable to write cross-platform code that uses those names. And if
> you can't even rely on the standard library... what can you rely on?

This problem ceases to be a problem once modules land.

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

.

------=_Part_909_769073811.1534527454280
Content-Type: multipart/alternative;
 boundary="----=_Part_910_1675027922.1534527454280"

------=_Part_910_1675027922.1534527454280
Content-Type: text/plain; charset="UTF-8"

On Friday, August 17, 2018 at 1:31:45 PM UTC-4, Ville Voutilainen wrote:
>
> On 17 August 2018 at 20:30, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> > "Overreacting"? Show me a standard library implementation that actually
> uses
> > the parameter names that the standard library defines. What's more,
> standard
> > libraries cannot use those parameter names. Why?
> >
> > Macro defensiveness.
> >
> > Users can define macros with almost any names. And standard library
> headers
> > are required to not be affected by such macros. As such, standard
> library
> > implementations are required to use the set of names that macros cannot
> > touch: names that are restricted for the implementation.
> >
> > So if you can't even rely on the standard library's parameter names, you
> > would be unable to write cross-platform code that uses those names. And
> if
> > you can't even rely on the standard library... what can you rely on?
>
> This problem ceases to be a problem once modules land.
>

And of course, `#include`s of C++ standard library headers are not required
to actually "include" text files (which is why they don't end in `.h`).
They can just be `import` directives under the hood. Or they can include
text files that themselves just import a module.

That bears thinking about. But at the same time, if we go this route, we
effectively enforce standard libraries to use those names for its
parameters. Names become a de-facto part of their interfaces. That will
make it difficult for standard library implementations to compile on both
C++17 and C++20/whatever-has-modules.

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

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

<div dir=3D"ltr">On Friday, August 17, 2018 at 1:31:45 PM UTC-4, Ville Vout=
ilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 17 August 201=
8 at 20:30, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"LMgZQ01kDAAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; &quot;Overreacting&quot;? Show me a standard library implementatio=
n that actually uses
<br>&gt; the parameter names that the standard library defines. What&#39;s =
more, standard
<br>&gt; libraries cannot use those parameter names. Why?
<br>&gt;
<br>&gt; Macro defensiveness.
<br>&gt;
<br>&gt; Users can define macros with almost any names. And standard librar=
y headers
<br>&gt; are required to not be affected by such macros. As such, standard =
library
<br>&gt; implementations are required to use the set of names that macros c=
annot
<br>&gt; touch: names that are restricted for the implementation.
<br>&gt;
<br>&gt; So if you can&#39;t even rely on the standard library&#39;s parame=
ter names, you
<br>&gt; would be unable to write cross-platform code that uses those names=
.. And if
<br>&gt; you can&#39;t even rely on the standard library... what can you re=
ly on?
<br>
<br>This problem ceases to be a problem once modules land.
<br></blockquote><div><br></div><div>And of course, `#include`s of C++ stan=
dard library headers are not required to actually &quot;include&quot; text =
files (which is why they don&#39;t end in `.h`). They can just be `import` =
directives under the hood. Or they can include text files that themselves j=
ust import a module.</div><div><br></div><div>That bears thinking about. Bu=
t at the same time, if we go this route, we effectively enforce standard li=
braries to use those names for its parameters. Names become a de-facto part=
 of their interfaces. That will make it difficult for standard library impl=
ementations to compile on both C++17 and C++20/whatever-has-modules.<br></d=
iv></div>

<p></p>

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

------=_Part_910_1675027922.1534527454280--

------=_Part_909_769073811.1534527454280--

.

On 17 August 2018 at 20:37, Nicol Bolas <jmckesson@gmail.com> wrote:
>> > So if you can't even rely on the standard library's parameter names, you
>> > would be unable to write cross-platform code that uses those names. And
>> > if
>> > you can't even rely on the standard library... what can you rely on?
>>
>> This problem ceases to be a problem once modules land.
>
>
> And of course, `#include`s of C++ standard library headers are not required
> to actually "include" text files (which is why they don't end in `.h`). They
> can just be `import` directives under the hood. Or they can include text
> files that themselves just import a module.
>
> That bears thinking about. But at the same time, if we go this route, we
> effectively enforce standard libraries to use those names for its
> parameters. Names become a de-facto part of their interfaces. That will make
> it difficult for standard library implementations to compile on both C++17
> and C++20/whatever-has-modules.

It's worth noting that some languages like Common Lisp do standardize
the names of some
parameters of the standard library functions. So it's not
unfathomable; prior to modules,
the problem was that we _couldn't_ standardize the names, it was just
not possible.

What I have established, having had discussions about named arguments
on multiple occasions,
is that the following pain points are important:

1) it needs to be an opt-in for the author of a library, so no
automagic naming. Some library
authors do not want users relying on names that the library author
didn't expect them to rely
on, in order to avoid breakage that wasn't considered beforehand.

2) The standard library part is the other major one; it's a bit
embarrassing if the facility can't work
with any standard library functions, and prior to modules, it indeed can't.

There have been various suggestions to make names part of the ABI and
part of the function type,
so that the function can't be called without named arguments, in the
traditional ordered-unnamed
arguments.
That makes wrapping such functions in binds and lambdas and whatnot
horrible. Lisp, for example,
still allows ordered-unnamed calls even if some parameters are
declared &key. Making it part
of the ABI is likewise nice for some things (changing the names breaks
ABI, silent change of
meaning doesn't happen for users), but it's unfortunate from other
perspectives, like having
to invent new manglings and again running into problems with
ordered-unnamed calls.

I do expect further discussion and proposals for named arguments. Some
committee members
are trying fairly hard to get named arguments in.

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

.

On 2018-08-17 13:12, David Brown wrote:
> On 17/08/18 17:16, Matthew Woehlke wrote:
>> On 2018-08-17 06:14, David Brown wrote:
>>> On 16/08/18 15:08, mihailnajdenov@gmail.com wrote:
>>>> First - you make something, that has been private for 30+ years, public.
>>>
>>> No, it is not.  The names for parameters are in function declarations,
>>> in headers - these are public.
>>
>> No, they aren't. Or, more correctly, while they are "public" in the
>> sense that a user can see them by reading the header, they aren't a
>> (normative) part of the API, any more than comments are. To *the
>> compiler*, they may as well not exist.
>>
>> You are proposing to change that. That is a *serious* change.
>
> Nah, you are overreacting.

You are certainly entitled to believe that. I happen to disagree, but
more importantly, AFAICT quite a few others also disagree. The point is,
you are facing an uphill battle to convince the committee on this matter.

Right now, changing the names of function parameters is SC+BC. IIUC, you
are proposing to make it at least SIC, if not also BIC. I honestly can't
see how you're going to convince the committee that that's okay.

> At most, it is a /tiny/ issue compared to
> the huge amount of implementation stuff in typical C++ headers that
> really is supposed to be private implementation details.  (Hint: lots of
> it is labelled "private:".)

You mean like this?

  class foo
  {
    ...interface...
  private:
    FooPrivate* d;
  };

No so much "leaked" there...

> Some people have suggested a syntax for function declarations (or
> definitions) that indicated that one or more of the parameters /must/ be
> used as named parameters.  I can see that being useful if they are to be
> used for overloads, but not otherwise.

Well, I don't believe I've ever been one of them. I currently don't see
any reason why such a feature would be desirable.

There *are* instances (overload resolution, skipping parameters) when a
*call* needs to use a name, but I don't see the value in having a
declaration that says you *must always* use the name.

>>> and the whole idea would be useless if
>>> special syntax were needed to declare that a function uses named parameters.
>>
>> I don't think you can *avoid* that, since there is very strong
>> opposition (see above) to turning all existing functions into functions
>> that have named parameters. Also, everyone that *is* proposing to have
>> named parameters with syntax apparently don't share this opinion.
>
> I don't think your argument against allowing people to use named
> parameters for existing functions is at all convincing.

Who's arguing that?

I would make this perfectly legal:

  void foo(int x); // note: not a named parameter
  foo(.x=5); // okay, but maybe warn in pedantic mode
  foo(.a=5); // okay, but probably warn

--
Matthew

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

.

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

On Fri, Aug 17, 2018 at 5:54 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2018-08-17 00:04, Justin Bassett wrote:
> > I agree for the most part, but I disagree that this should be a valid
> > overload set, unless parameters are name-only:
> >
> > void bar(int :a);
> > void bar(int :x);
> >
> > The problem is that bar(4) is ambiguous.
>
> So what?
>
>   void foo(int, double=1.);
>   void foo(int, int=2);
>
>   foo(1); // error: ambiguous
>

TRWTF is the fact that the second function definition is even allowed in
the first place - IMO it should be (and have always been) a 'redefinition'
error. But I do see your point.

> Overloading on name-only parameters is just fine.
>
> What is a "name only" parameter?
>

I imagine it's a parameter that you can *only* provide by specifying the
name.


On Fri, Aug 17, 2018 at 6:00 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2018-08-17 12:17, Jake Arkinstall wrote:
> > On Fri, 17 Aug 2018, 16:16 Matthew Woehlke wrote:
> >>   foo(int :a, int :b = 3, int :c = 12);
> >>   foo(1, c: 6); // name *must* be used here because 'b' is omitted
> >
> > Ah. That does demolish my idea about using strong types as named wrappers
> > for the underlying type.
>
> Well... yes and no. "Strong types as named wrappers for the underlying
> type" sounds suspiciously like where my own thoughts on this matter have
> been going. However, while I would envision a library/type component, we
> do *need* language-level support... not just for syntactic sugar, but
> for this, specifically. (And since this is my #1 "killer feature" for
> named arguments... don't get me wrong, tagged dispatch / named overload
> is #2, but skipping arguments is #1 :-).)


That's where we differ. Only because skipping arguments tends to lead to
sloppy interfaces (but I believe we agree to disagree on this - it is a
matter of personal preference).


> > Well, it makes it insufficient, at least - in order to make it work
> > we'd need to change the language to keep trying parameter ordering
> > until the types fit.
> >
> > Unlike an approach that changes mangling directly, this does mean that
> the
> > following non-named code would become valid:
> >
> > foo(const int& a=1, const std::string& b="hello");
> > foo("world"); //yuck
> >
> > Which, innocent enough in this example, is going to be a source of bugs
> > when an implicit conversion exists - unless that ordering search matches
> > act as explicit, which is going to cause its own problems in terms of
> > usability.
>
> I would not allow skipping for unnamed parameters.
>

That's the catch, though.

I suggested using a strong type mechanism for named parameters as a
high-level solution. It just requires generating a struct from the named
parameter at the declaration site, and reinterpreting the input as that
struct when named through the call site (reinterpreting it as the expected
type before entering the function itself). This can be done relatively
early in translation (or even by running code through a few lines of perl
before compilation). As such, it doesn't require changing that much in the
language (in particular, mangling and selecting the right call at the call
site - that's handled indirectly just by introducing the types).

But this high-level solution doesn't suffice if we also want to have a
special case (parameter skipping) - it would be more consistent to just
make it apply to all function calls (which makes me nervous). The only way
I can imagine it COULD work using this approach, but allowing skipping only
for these calls, is if we generate the 2^N possible function calls (N:
number of arguments with defaults) as unique symbols.

If we want to make the parameters rearrangeable too (which would make sense
if we really want to get pythonic bag-functions), all (sum_{k=0}^{N} N!/k!)
possible combinations. That's... horrifying. At least if we enable the
parameter skipping for ordinary functions too, we can get away with N!
symbols (scary, albeit less so than (sum_{k=0}^{N} N!/k!)).

If we allow skipping AND reordering of function arguments for normal
(un-named) calls, such that:

f(S=a, T b=0, U c=0);
f(U{},S{}) // okay

Then we'd be back to the status quo with a single symbol. But obviously,
that would make the language completely unstable.


So unless I'm missing something (which is likely, this stuff isn't my
forte), allowing skipping (and/or reordering) just for these will require a
language change at a later translation phase. And in a later translation
phase, the strong type approach seems rather pointless - it could just be
done directly by the compiler, however the compiler wants to do it.

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Aug 17, 2018 at 5:54 PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><span class=3D"gmail-">On 2018-08-17 00:04, Justin Bassett wrote:<br>
&gt; I agree for the most part, but I disagree that this should be a valid<=
br>
&gt; overload set, unless parameters are name-only:<br>
&gt; <br>
&gt; void bar(int :a);<br>
&gt; void bar(int :x);<br>
&gt; <br>
&gt; The problem is that bar(4) is ambiguous.<br>
<br>
</span>So what?<br>
<br>
=C2=A0 void foo(int, double=3D1.);<br>
=C2=A0 void foo(int, int=3D2);<br>
<br>
=C2=A0 foo(1); // error: ambiguous<br></blockquote><div><br></div><div>TRWT=
F=20
is the fact that the second function definition is even allowed in the=20
first place - IMO it should be (and have always been) a &#39;redefinition&#=
39;=20
error. But I do see your point.<br></div><span class=3D"gmail-"></span><br>=
<span class=3D"gmail-"></span><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><span class=3D"gmail-">
&gt; Overloading on name-only parameters is just fine.<br>
<br>
</span>What is a &quot;name only&quot; parameter?<br></blockquote><div><br>=
</div><div>I imagine it&#39;s a parameter that you can *only* provide by sp=
ecifying the name.<br></div></div></div><br><div class=3D"gmail_extra"><br>=
<div class=3D"gmail_quote">On Fri, Aug 17, 2018 at 6:00 PM, Matthew Woehlke=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:mwoehlke.floss@gmail.com" target=
=3D"_blank">mwoehlke.floss@gmail.com</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">On 2018-08-17 12:17, Jake Arkinstall w=
rote:<br>
<span class=3D"gmail-">&gt; On Fri, 17 Aug 2018, 16:16 Matthew Woehlke wrot=
e:<br>
&gt;&gt;=C2=A0 =C2=A0foo(int :a, int :b =3D 3, int :c =3D 12);<br>
&gt;&gt;=C2=A0 =C2=A0foo(1, c: 6); // name *must* be used here because &#39=
;b&#39; is omitted<br>
&gt; <br>
&gt; Ah. That does demolish my idea about using strong types as named wrapp=
ers<br>
&gt; for the underlying type.<br>
<br>
</span>Well... yes and no. &quot;Strong types as named wrappers for the und=
erlying<br>
type&quot; sounds suspiciously like where my own thoughts on this matter ha=
ve<br>
been going. However, while I would envision a library/type component, we<br=
>
do *need* language-level support... not just for syntactic sugar, but<br>
for this, specifically. (And since this is my #1 &quot;killer feature&quot;=
 for<br>
named arguments... don&#39;t get me wrong, tagged dispatch / named overload=
<br>
is #2, but skipping arguments is #1 :-).)</blockquote><div><br></div><div>T=
hat&#39;s
 where we differ. Only because skipping arguments tends to lead to=20
sloppy interfaces (but I believe we agree to disagree on this - it is a=20
matter of personal preference).<br><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><span class=3D"gmail-"><br>
&gt; Well, it makes it insufficient, at least - in order to make it work<br=
>
&gt; we&#39;d need to change the language to keep trying parameter ordering=
<br>
&gt; until the types fit.<br>
&gt; <br>
&gt; Unlike an approach that changes mangling directly, this does mean that=
 the<br>
&gt; following non-named code would become valid:<br>
&gt; <br>
&gt; foo(const int&amp; a=3D1, const std::string&amp; b=3D&quot;hello&quot;=
);<br>
&gt; foo(&quot;world&quot;); //yuck<br>
&gt; <br>
&gt; Which, innocent enough in this example, is going to be a source of bug=
s<br>
&gt; when an implicit conversion exists - unless that ordering search match=
es<br>
&gt; act as explicit, which is going to cause its own problems in terms of<=
br>
&gt; usability.<br>
<br>
</span>I would not allow skipping for unnamed parameters.<br></blockquote><=
div><br></div><div>That&#39;s
 the catch, though.<br><br>I suggested using a strong type mechanism for na=
med=20
parameters as a high-level solution. It just=20
requires generating a struct from the named parameter at the
 declaration site, and reinterpreting the input as that struct when=20
named through the call site (reinterpreting it as the expected type=20
before entering the function itself). This can be done relatively early in =
translation (or even by running code through a few lines of perl before com=
pilation). As such, it doesn&#39;t require changing that much in the langua=
ge (in particular, mangling and selecting the=20
right call at the call site - that&#39;s handled indirectly just by introdu=
cing the types).<br></div><div><br></div><div>But this high-level solution =
doesn&#39;t suffice if we also want to have a special=20
case (parameter skipping) - it would be more consistent
to just make it apply to all function calls (which makes me nervous). The=
=20
only way I can imagine it COULD work using this approach, but allowing skip=
ping only for these calls, is if we generate the 2^N possible function call=
s (N: number of arguments with=20
defaults) as unique symbols.<br><br>If we want to make the parameters rearr=
angeable too (which would make sense if we really want to get pythonic bag-=
functions), all (sum_{k=3D0}^{N} N!/k!) possible combinations. That&#39;s..=
.. horrifying. At least if we enable the parameter skipping for ordinary fun=
ctions too, we can get away with N! symbols (scary, albeit less so than (su=
m_{k=3D0}^{N} N!/k!)).<br><br>If we allow skipping AND reordering of functi=
on arguments for normal (un-named) calls, such that:</div><div><br></div><d=
iv>f(S=3Da, T b=3D0, U c=3D0);</div><div>f(U{},S{}) // okay<br><br></div><d=
iv>Then we&#39;d be back to the status quo with a single symbol. But obviou=
sly, that would make the language completely unstable.<br><br></div><div><b=
r></div><div>So unless I&#39;m missing something (which is likely, this stu=
ff isn&#39;t my forte), allowing skipping (and/or reordering) just for thes=
e will require a language change at a later translation phase. And in a lat=
er translation phase, the strong type approach seems rather pointless - it =
could just be done directly by the compiler, however the compiler wants to =
do it.<br></div></div></div></div>

<p></p>

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

--000000000000d2875d0573a57328--

.

------=_Part_492_2018458905.1534531270268
Content-Type: multipart/alternative;
 boundary="----=_Part_493_590757894.1534531270269"

------=_Part_493_590757894.1534531270269
Content-Type: text/plain; charset="UTF-8"



On Friday, August 17, 2018 at 8:49:19 PM UTC+3, Ville Voutilainen wrote:
>
> On 17 August 2018 at 20:37, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> >> > So if you can't even rely on the standard library's parameter names,
> you
> >> > would be unable to write cross-platform code that uses those names.
> And
> >> > if
> >> > you can't even rely on the standard library... what can you rely on?
> >>
> >> This problem ceases to be a problem once modules land.
> >
> >
> > And of course, `#include`s of C++ standard library headers are not
> required
> > to actually "include" text files (which is why they don't end in `.h`).
> They
> > can just be `import` directives under the hood. Or they can include text
> > files that themselves just import a module.
> >
> > That bears thinking about. But at the same time, if we go this route, we
> > effectively enforce standard libraries to use those names for its
> > parameters. Names become a de-facto part of their interfaces. That will
> make
> > it difficult for standard library implementations to compile on both
> C++17
> > and C++20/whatever-has-modules.
>
> It's worth noting that some languages like Common Lisp do standardize
> the names of some
> parameters of the standard library functions. So it's not
> unfathomable; prior to modules,
> the problem was that we _couldn't_ standardize the names, it was just
> not possible.
>
> What I have established, having had discussions about named arguments
> on multiple occasions,
> is that the following pain points are important:
>
> 1) it needs to be an opt-in for the author of a library, so no
> automagic naming. Some library
> authors do not want users relying on names that the library author
> didn't expect them to rely
> on, in order to avoid breakage that wasn't considered beforehand.
>
> 2) The standard library part is the other major one; it's a bit
> embarrassing if the facility can't work
> with any standard library functions, and prior to modules, it indeed
> can't.
>


Wouldn't the interface to a template still be its header? Aren't modules
only for compiled code?

How is the relation b/w modules and templates envisioned to be?



>
> There have been various suggestions to make names part of the ABI and
> part of the function type,
> so that the function can't be called without named arguments, in the
> traditional ordered-unnamed
> arguments.
> That makes wrapping such functions in binds and lambdas and whatnot
> horrible. Lisp, for example,
> still allows ordered-unnamed calls even if some parameters are
> declared &key. Making it part
> of the ABI is likewise nice for some things (changing the names breaks
> ABI, silent change of
> meaning doesn't happen for users), but it's unfortunate from other
> perspectives, like having
> to invent new manglings and again running into problems with
> ordered-unnamed calls.
>
> I do expect further discussion and proposals for named arguments. Some
> committee members
> are trying fairly hard to get named arguments in.
>

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

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

<div dir=3D"ltr"><br><br>On Friday, August 17, 2018 at 8:49:19 PM UTC+3, Vi=
lle Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 17 Au=
gust 2018 at 20:37, Nicol Bolas &lt;<a onmousedown=3D"this.href=3D&#39;java=
script:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;ret=
urn true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfu=
scated-mailto=3D"MdVFi0JlDAAJ">jmck...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; &gt; So if you can&#39;t even rely on the standard library&#39=
;s parameter names, you
<br>&gt;&gt; &gt; would be unable to write cross-platform code that uses th=
ose names. And
<br>&gt;&gt; &gt; if
<br>&gt;&gt; &gt; you can&#39;t even rely on the standard library... what c=
an you rely on?
<br>&gt;&gt;
<br>&gt;&gt; This problem ceases to be a problem once modules land.
<br>&gt;
<br>&gt;
<br>&gt; And of course, `#include`s of C++ standard library headers are not=
 required
<br>&gt; to actually &quot;include&quot; text files (which is why they don&=
#39;t end in `.h`). They
<br>&gt; can just be `import` directives under the hood. Or they can includ=
e text
<br>&gt; files that themselves just import a module.
<br>&gt;
<br>&gt; That bears thinking about. But at the same time, if we go this rou=
te, we
<br>&gt; effectively enforce standard libraries to use those names for its
<br>&gt; parameters. Names become a de-facto part of their interfaces. That=
 will make
<br>&gt; it difficult for standard library implementations to compile on bo=
th C++17
<br>&gt; and C++20/whatever-has-modules.
<br>
<br>It&#39;s worth noting that some languages like Common Lisp do standardi=
ze
<br>the names of some
<br>parameters of the standard library functions. So it&#39;s not
<br>unfathomable; prior to modules,
<br>the problem was that we _couldn&#39;t_ standardize the names, it was ju=
st
<br>not possible.
<br>
<br>What I have established, having had discussions about named arguments
<br>on multiple occasions,
<br>is that the following pain points are important:
<br>
<br>1) it needs to be an opt-in for the author of a library, so no
<br>automagic naming. Some library
<br>authors do not want users relying on names that the library author
<br>didn&#39;t expect them to rely
<br>on, in order to avoid breakage that wasn&#39;t considered beforehand.
<br>
<br>2) The standard library part is the other major one; it&#39;s a bit
<br>embarrassing if the facility can&#39;t work
<br>with any standard library functions, and prior to modules, it indeed ca=
n&#39;t.
<br></blockquote><div><br></div><div><br></div><div>Wouldn&#39;t the interf=
ace to a template still be its header? Aren&#39;t modules only for compiled=
 code?=C2=A0</div><div><br></div><div><span style=3D"display: inline !impor=
tant; float: none; background-color: transparent; color: rgb(34, 34, 34); f=
ont-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: =
13px; font-style: normal; font-variant: normal; font-weight: 400; letter-sp=
acing: normal; orphans: 2; text-align: left; text-decoration: none; text-in=
dent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-spac=
e: normal; word-spacing: 0px;">How is the relation b/w modules and template=
s envisioned to be?=C2=A0</span><b></b><i></i><u></u><sub></sub><sup></sup>=
<strike></strike><br></div><div><b></b><i></i><u></u><sub></sub><sup></sup>=
<strike></strike><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;">
<br>There have been various suggestions to make names part of the ABI and
<br>part of the function type,
<br>so that the function can&#39;t be called without named arguments, in th=
e
<br>traditional ordered-unnamed
<br>arguments.
<br>That makes wrapping such functions in binds and lambdas and whatnot
<br>horrible. Lisp, for example,
<br>still allows ordered-unnamed calls even if some parameters are
<br>declared &amp;key. Making it part
<br>of the ABI is likewise nice for some things (changing the names breaks
<br>ABI, silent change of
<br>meaning doesn&#39;t happen for users), but it&#39;s unfortunate from ot=
her
<br>perspectives, like having
<br>to invent new manglings and again running into problems with
<br>ordered-unnamed calls.
<br>
<br>I do expect further discussion and proposals for named arguments. Some
<br>committee members
<br>are trying fairly hard to get named arguments in.
<br></blockquote></div>

<p></p>

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

------=_Part_493_590757894.1534531270269--

------=_Part_492_2018458905.1534531270268--

.

On 17/08/18 19:53, Matthew Woehlke wrote:
> On 2018-08-17 13:12, David Brown wrote:
>> On 17/08/18 17:16, Matthew Woehlke wrote:
>>> On 2018-08-17 06:14, David Brown wrote:
>>>> On 16/08/18 15:08, mihailnajdenov@gmail.com wrote:
>>>>> First - you make something, that has been private for 30+ years, public.
>>>>
>>>> No, it is not.  The names for parameters are in function declarations,
>>>> in headers - these are public.
>>>
>>> No, they aren't. Or, more correctly, while they are "public" in the
>>> sense that a user can see them by reading the header, they aren't a
>>> (normative) part of the API, any more than comments are. To *the
>>> compiler*, they may as well not exist.
>>>
>>> You are proposing to change that. That is a *serious* change.
>>
>> Nah, you are overreacting.
>
> You are certainly entitled to believe that. I happen to disagree, but
> more importantly, AFAICT quite a few others also disagree. The point is,
> you are facing an uphill battle to convince the committee on this matter.

Fair enough.  As I say, I feel differently - but final decisions here
will be up to the committee.  I doubt if anything I might say here is
new to the committee - if they didn't like it before, they won't like it
now and I will not be able to convince them.  I see C++ from my little
corner of the world, looking at what makes sense to me - they look at a
far, far wider view.  They might not make the decision that I think is
best for /me/, but I'm sure they will make a considered judgement on
what they think is best overall.

And certainly if the choice is between named parameters for functions
declared specifically to allow named parameters, or no named parameters
at all, my vote would be with them.  A second-best solution would be
better than no solution.  (But see my final comment in this post - it
could be that I have been misunderstanding your point.)

>
> Right now, changing the names of function parameters is SC+BC. IIUC, you
> are proposing to make it at least SIC, if not also BIC. I honestly can't
> see how you're going to convince the committee that that's okay.

I'm sorry, I don't recognise the abbreviations SC, BC, SIC and BIC.

>
>> At most, it is a /tiny/ issue compared to
>> the huge amount of implementation stuff in typical C++ headers that
>> really is supposed to be private implementation details.  (Hint: lots of
>> it is labelled "private:".)
>
> You mean like this?
>
>    class foo
>    {
>      ...interface...
>    private:
>      FooPrivate* d;
>    };
>
> No so much "leaked" there...
>

Well, no, not in a case like this.  But when the private section holds
members and possibly inline implementations, it is leaked.  This is
especially true of template libraries.

>> Some people have suggested a syntax for function declarations (or
>> definitions) that indicated that one or more of the parameters /must/ be
>> used as named parameters.  I can see that being useful if they are to be
>> used for overloads, but not otherwise.
>
> Well, I don't believe I've ever been one of them. I currently don't see
> any reason why such a feature would be desirable.
>
> There *are* instances (overload resolution, skipping parameters) when a
> *call* needs to use a name, but I don't see the value in having a
> declaration that says you *must always* use the name.
>

Agreed.

>>>> and the whole idea would be useless if
>>>> special syntax were needed to declare that a function uses named parameters.
>>>
>>> I don't think you can *avoid* that, since there is very strong
>>> opposition (see above) to turning all existing functions into functions
>>> that have named parameters. Also, everyone that *is* proposing to have
>>> named parameters with syntax apparently don't share this opinion.
>>
>> I don't think your argument against allowing people to use named
>> parameters for existing functions is at all convincing.
>
> Who's arguing that?
>
> I would make this perfectly legal:
>
>    void foo(int x); // note: not a named parameter
>    foo(.x=5); // okay, but maybe warn in pedantic mode
>    foo(.a=5); // okay, but probably warn
>

Do you mean you would be happy to allow the parameter name in an
existing declaration to be used in function calls as a check?  But you
would presumably not allow such names to be used for overloads - that
would require a specific extra syntax in the declaration.  Is that correct?

I would be entirely happy with such a situation - my main objective is
to aid in writing correct and readable code, and my compiler (given
appropriate flags) would accept "foo(.x = 5)" without complaint while
warning about "foo(.a = 5)", I'd be very satisfied.

I'd been even happier if it accepted this:

 void foo(int x, int y);
 foo(.y = 1, .x = 2); // Same as foo(2, 1)

But if that's a problem, I'd be fine without it.

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

.

On 2018-08-17 14:08, Jake Arkinstall wrote:
> On Fri, Aug 17, 2018 at 5:54 PM, Matthew Woehlke wrote:
>> What is a "name only" parameter?
>
> I imagine it's a parameter that you can *only* provide by specifying the
> name.

I assume so also. I don't think we need those as such; not at the
declaration level, certainly.

There will be cases where *calling* a function will need a name, either
due to skipping params or to disambiguate overloads that differ only by
explicit parameter names. But I don't think we need a mechanism that
says 'we will not let you call this function unless you explicitly give
the name' (overload ambiguities aside).

> On Fri, Aug 17, 2018 at 6:00 PM, Matthew Woehlke wrote:
>> [...] skipping arguments is #1 :-).
>
> That's where we differ. Only because skipping arguments tends to lead to
> sloppy interfaces (but I believe we agree to disagree on this - it is a
> matter of personal preference).

They aren't ideal, but I've run into plenty of instances where I need a
function that has quite a few "knobs", of which the user will likely
never need all of them at any given call site, but *which* ones vary.

Right now the solution is to have a lot of overloads with the arguments
in different orders. This is ugly, a pain to maintain, and possibly
inefficient.

>> I would not allow skipping for unnamed parameters.
>
> That's the catch, though.
>
> I suggested using a strong type mechanism for named parameters as a
> high-level solution. It just requires generating a struct from the named
> parameter at the declaration site, and reinterpreting the input as that
> struct when named through the call site (reinterpreting it as the expected
> type before entering the function itself). This can be done relatively
> early in translation (or even by running code through a few lines of perl
> before compilation). As such, it doesn't require changing that much in the
> language (in particular, mangling and selecting the right call at the call
> site - that's handled indirectly just by introducing the types).
>
> But this high-level solution doesn't suffice if we also want to have a
> special case (parameter skipping) - it would be more consistent to just
> make it apply to all function calls (which makes me nervous). The only way
> I can imagine it COULD work using this approach, but allowing skipping only
> for these calls, is if we generate the 2^N possible function calls (N:
> number of arguments with defaults) as unique symbols.

Doesn't the struct approach with designated initializers take care of
this, though?

Anyway, my own current thoughts are not to use a struct, but to make
each named parameter something like `arg<int, "foo"_lit>`. Where we need
language support, then, is:

  void foo(int, int .b=1, int .c=2);
  foo(5, .c=7);

Here, the compiler needs to know that, as soon as it sees a named
argument, it should consider all calls that match the argument list up
to that point *and* at some following point have an argument named `c`.
(And have defaulted arguments for whatever doesn't match up.)

IOW, what an implementation would do is:

- Start with all possible overloads of `foo`.
- Throw out any that can't match `foo(int, ...)`
- Look for one that has a named argument (with ordinal > 0) named `c`.
- Repeat for any more named arguments.
- Throw out anything that's left for which any "unbound" arguments do
not have defaults.
- Emit a call to the resulting function (if exactly one) or issue a
diagnostic.

At no point do we actually generate additional function prototypes.

> So unless I'm missing something (which is likely, this stuff isn't my
> forte), allowing skipping (and/or reordering) just for these will require a
> language change at a later translation phase. And in a later translation
> phase, the strong type approach seems rather pointless - it could just be
> done directly by the compiler, however the compiler wants to do it.

Ah, yes, I think I see. There is no *practical* reason why the logic I
outline above couldn't be applied to unnamed arguments also. That's more
a matter of "for sanity".

The main use for strong typing, at least in my current vision, is for
forwarding. (And maybe mangling.) In that sense, I think we agree.

For example, I can do this:

  void bar(int .x); // #1
  void bar(int .y); // #2

  template <typename Args...>
  void foo(Args... args)
  {
    bar(args...);
  }

  // okay, instantiates foo<arg<int, "y"_lit>> which calls #2
  foo(.y=1);

--
Matthew

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

.

------=_Part_949_1710152167.1534532195013
Content-Type: multipart/alternative;
 boundary="----=_Part_950_1028796982.1534532195013"

------=_Part_950_1028796982.1534532195013
Content-Type: text/plain; charset="UTF-8"

Some time ago I "proposed" something about this in other std thread.

My idea was just change 2 things in lambdas:

1 - Allow the lambda members to be public;
2 - Allow the '{}' to be optional in lambda definition;

So this will be a valid:
template < RectLeftTop Rect > // Concept RectLeftTop
void draw_rect(const Rect& r){
   ... // this uses r.left and r.top
}

template < RectX1Y1 Rect > // Concept RectX1Y1
void draw_rect(const Rect& r){
   ... // this overload uses r.x1 and r.y1
}

void test() {
  auto x = 10;
  auto lambda = [top=x, left=100, width=x+30, height=100]; // lambda
declaration without '{}'
  lambda.top = lambda.top * 2;   // using public members from lambda
  draw_rect(lambda);
  draw_rect([x1=x, x2=x+90, y1=30, y2=100]);  // Use directly a lambda
}

>
>

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

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

<div dir=3D"ltr">Some time ago I &quot;proposed&quot; something about this =
in other std thread.<div><br></div><div>My idea was just change 2 things in=
 lambdas:<div><br></div><div>1 - Allow the lambda members to be public;</di=
v><div>2 - Allow the &#39;{}&#39; to be optional in lambda definition;</div=
><div><br></div><div>So this will be a valid:<br></div><div><div class=3D"p=
rettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rg=
b(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-=
word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Rect</span><font color=3D"#000000"><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">Le</span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">ftTop Rect=C2=A0</span></font><span class=
=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0); font-family: Aria=
l, Helvetica, sans-serif;">&gt; // Concept=C2=A0</span><span class=3D"style=
d-by-prettify" style=3D"font-family: Arial, Helvetica, sans-serif; color: r=
gb(0, 0, 0);"></span><span class=3D"styled-by-prettify" style=3D"font-famil=
y: Arial, Helvetica, sans-serif; color: rgb(102, 0, 102);">Rect</span><font=
 color=3D"#000000" style=3D"font-family: Arial, Helvetica, sans-serif;"><sp=
an class=3D"styled-by-prettify" style=3D"color: rgb(102, 0, 102);">Le</span=
><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 0, 102);">ftTo=
p</span></font></div><div class=3D"subprettyprint"><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> draw_rect</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">const</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prett=
ify">Rect</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> r</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">){</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">...</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #800;" class=3D"styled-by-prettify">// this uses r.left and r.top</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">RectX1Y1</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Rect</span><font color=3D"#666600"><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&gt;=C2=A0</span></font><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><span class=3D"styled-by-prettify" style=3D"=
color: rgb(102, 102, 0); font-family: Arial, Helvetica, sans-serif;">// Con=
cept=C2=A0</span><span style=3D"color: rgb(102, 0, 102);">RectX1Y1</span><b=
r></span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> draw_rect</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">Rect</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> r</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">){</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>=C2=A0 =C2=A0</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">// this overload uses r.x1 and r.y1</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> test</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> x </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"=
styled-by-prettify">10</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;<br></span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">=C2=A0 auto lambda =3D=C2=A0<span class=3D"styled-by-prettify" style=
=3D"color: rgb(102, 102, 0);">[</span><span class=3D"styled-by-prettify">to=
p</span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0)=
;">=3D</span><span class=3D"styled-by-prettify">x</span><span class=3D"styl=
ed-by-prettify" style=3D"color: rgb(102, 102, 0);">,</span><span class=3D"s=
tyled-by-prettify">=C2=A0left</span><span class=3D"styled-by-prettify" styl=
e=3D"color: rgb(102, 102, 0);">=3D</span><span class=3D"styled-by-prettify"=
 style=3D"color: rgb(0, 102, 102);">100</span><span class=3D"styled-by-pret=
tify" style=3D"color: rgb(102, 102, 0);">,</span><span class=3D"styled-by-p=
rettify">=C2=A0width</span><span class=3D"styled-by-prettify" style=3D"colo=
r: rgb(102, 102, 0);">=3D</span><span class=3D"styled-by-prettify">x</span>=
<span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">+</sp=
an><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 102, 102);">30=
</span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);=
">,</span><span class=3D"styled-by-prettify">=C2=A0height</span><span class=
=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">=3D</span><font =
color=3D"#006666"><span class=3D"styled-by-prettify">100</span></font><span=
 class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">]; // lamb=
da declaration without &#39;{}&#39;<br></span>=C2=A0 lambda.top =3D lambda.=
top * 2;=C2=A0 =C2=A0// using public members from lambda<br>=C2=A0 </span><=
span style=3D"color: rgb(0, 0, 0);"><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">draw_rect</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span></span><span style=3D"color: rgb(0, 0, 0); font-f=
amily: Arial, Helvetica, sans-serif;">lambda</span><span style=3D"color: rg=
b(102, 102, 0); font-family: Arial, Helvetica, sans-serif;">);</span></div>=
<div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-=
by-prettify">=C2=A0 </span><span style=3D"color: rgb(0, 0, 0);"><span style=
=3D"color: #000;" class=3D"styled-by-prettify">draw_rect</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">x1</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">x</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> x2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify">x</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">+</span><span st=
yle=3D"color: #066;" class=3D"styled-by-prettify">90</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> y1</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">=3D</span><span style=3D"color: #066;" class=3D"s=
tyled-by-prettify">30</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> y2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</=
span><font color=3D"#006666"><span style=3D"color: #066;" class=3D"styled-b=
y-prettify">100</span></font><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">]);=C2=A0 // Use directly a lambda</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br></span></div></code></div><div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div class=3D"gmail_quote"><br=
></div></div>
</blockquote></div></div></div></div>

<p></p>

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

------=_Part_950_1028796982.1534532195013--

------=_Part_949_1710152167.1534532195013--

.

On 2018-08-17 14:42, David Brown wrote:
> On 17/08/18 19:53, Matthew Woehlke wrote:
>> Right now, changing the names of function parameters is SC+BC. IIUC, you
>> are proposing to make it at least SIC, if not also BIC. I honestly can't
>> see how you're going to convince the committee that that's okay.
>=20
> I'm sorry, I don't recognise the abbreviations SC, BC, SIC and BIC.

S/B =3D source (API) / binary (ABI)
C/IC =3D [in]compatible

IOW, right now if I release a new version of my library that changes a
parameter name, it has no effect. Under your proposal... does my
previously compiled application (which uses said library) still run
(BC)? Can I recompile it without needing to change its sources (SC)?

>> =C2=A0=C2=A0 class foo
>> =C2=A0=C2=A0 {
>> =C2=A0=C2=A0=C2=A0=C2=A0 ...interface...
>> =C2=A0=C2=A0 private:
>> =C2=A0=C2=A0=C2=A0=C2=A0 FooPrivate* d;
>> =C2=A0=C2=A0 };
>>
>> No so much "leaked" there...
>=20
> Well, no, not in a case like this.=C2=A0 But when the private section hol=
ds
> members and possibly inline implementations, it is leaked.=C2=A0 This is
> especially true of template libraries.

True. The point is that "some libraries are designed poorly" is not an
excuse to leak even *more*.

>> On 2018-08-17 13:12, David Brown wrote:=20
>>> I don't think your argument against allowing people to use named
>>> parameters for existing functions is at all convincing.
>>
>> Who's arguing that?
>>
>> I would make this perfectly legal:
>>
>> =C2=A0=C2=A0 void foo(int x); // note: not a named parameter
>> =C2=A0=C2=A0 foo(.x=3D5); // okay, but maybe warn in pedantic mode
>> =C2=A0=C2=A0 foo(.a=3D5); // okay, but probably warn
>=20
> Do you mean you would be happy to allow the parameter name in an
> existing declaration to be used in function calls as a check?

If I make a call with a named parameter that resolves to a function that
does not have explicitly named parameters, then yes, I'm fine with the
compiler *warning* me if the names don't match.

> But you would presumably not allow such names to be used for
> overloads - that would require a specific extra syntax in the
> declaration.  Is that correct?
Right.

I guess in that sense what I'm proposing is opt-out weak naming (that
only involves a possible compiler warning if you mismatch names) with
opt-in strong naming, where the "fun stuff" (argument skipping, and per
your question, name-based overloading) requires 'strong' naming.

The only way to opt out would be by not naming your parameters *at all*.
However, I guess if you wrote:

  void foo(int x, int y);
  void foo(int a, int b);

....then *either* `foo(.a=3D1)` or `foo(.x=3D1)` should be accepted with no
warning, and would call the same function. But this is all QoI stuff
that doesn't need to be part of the standard.

> I would be entirely happy with such a situation - my main objective is
> to aid in writing correct and readable code, and my compiler (given
> appropriate flags) would accept "foo(.x =3D 5)" without complaint while
> warning about "foo(.a =3D 5)", I'd be very satisfied.
>=20
> I'd been even happier if it accepted this:
>=20
> =C2=A0=C2=A0=C2=A0=C2=A0void foo(int x, int y);
> =C2=A0=C2=A0=C2=A0=C2=A0foo(.y =3D 1, .x =3D 2);=C2=A0=C2=A0=C2=A0 // Sam=
e as foo(2, 1)
>=20
> But if that's a problem, I'd be fine without it.

Well, it would *accept* that... with a warning... but it would be the
same as `foo(1, 2)` :-). If you wrote instead:

  void foo(int .x, int .y);

....then it would either do what you meant, or be a hard error. I'm on
the fence whether reordering should be allowed. (And by "on the fence" I
mean a) *I* don't feel strongly either way, and b) I think there are
strong arguments for either case.)

--=20
Matthew

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

.

On 17 August 2018 at 21:41,  <mihailnajdenov@gmail.com> wrote:
> Wouldn't the interface to a template still be its header? Aren't modules
> only for compiled code?

What "header"? You can put templates into a module just fine.

> How is the relation b/w modules and templates envisioned to be?

It would need to behave so that the names of parameters are handled in
the context
of the declaration site, not at the context of the instantiation site.

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

.

--0000000000008acdd70573ad646f
Content-Type: text/plain; charset="UTF-8"

What I've gathered from this discussion is that we want the simplest form
of named parameters that can make it into the standard while not
prohibiting a future proposal for some of the more niche features. After
deliberating on this, I arrived at something quite similar to P0671R0
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0671r0.html> .
Thus, the most important question that needs answering is: what were the
committee's concerns about P0671R0? What were the reasons behind the
changes made in R1 and R2? If we cannot address the concerns the committee
had, there's no reason to propose a similar proposal. Without knowing the
concerns, it's impossible to address them.

On Fri, Aug 17, 2018 at 12:21 PM Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 17 August 2018 at 21:41,  <mihailnajdenov@gmail.com> wrote:
> > Wouldn't the interface to a template still be its header? Aren't modules
> > only for compiled code?
>
> What "header"? You can put templates into a module just fine.
>
> > How is the relation b/w modules and templates envisioned to be?
>
> It would need to behave so that the names of parameters are handled in
> the context
> of the declaration site, not at the context of the instantiation site.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUb_iJ8B%3DELuJgBVo-R3fvPPOcgjMobr_4hvEQSR2%3DoALQ%40mail.gmail.com
> .
>

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

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

<div dir=3D"ltr">What I&#39;ve gathered from this discussion is that we wan=
t the simplest form of named parameters that can make it into the standard =
while not prohibiting a future proposal for some of the more niche features=
.. After deliberating on this, I arrived at something quite similar to=C2=A0=
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0671r0.=
html ">P0671R0</a>=C2=A0. Thus, the most important question that needs answ=
ering is: what were the committee&#39;s concerns about P0671R0? What were t=
he reasons behind the changes made in R1 and R2? If we cannot address the c=
oncerns the committee had, there&#39;s no reason to propose a similar propo=
sal. Without knowing the concerns, it&#39;s impossible to address them.</di=
v><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Aug 17, 2018 at 1=
2:21 PM Ville Voutilainen &lt;<a href=3D"mailto:ville.voutilainen@gmail.com=
">ville.voutilainen@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">On 17 August 2018 at 21:41,=C2=A0 &lt;<a href=3D"mailto:mihailnaj=
denov@gmail.com" target=3D"_blank">mihailnajdenov@gmail.com</a>&gt; wrote:<=
br>
&gt; Wouldn&#39;t the interface to a template still be its header? Aren&#39=
;t modules<br>
&gt; only for compiled code?<br>
<br>
What &quot;header&quot;? You can put templates into a module just fine.<br>
<br>
&gt; How is the relation b/w modules and templates envisioned to be?<br>
<br>
It would need to behave so that the names of parameters are handled in<br>
the context<br>
of the declaration site, not at the context of the instantiation site.<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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFk2RUb_iJ8B%3DELuJgBVo-R3fvPPOcgjMo=
br_4hvEQSR2%3DoALQ%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUb_iJ8B%3=
DELuJgBVo-R3fvPPOcgjMobr_4hvEQSR2%3DoALQ%40mail.gmail.com</a>.<br>
</blockquote></div>

<p></p>

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

--0000000000008acdd70573ad646f--

.

This is a multi-part message in MIME format.
--------------B56AEB7A046CE3C84933BD22
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 17/08/2018 =C3=A0 17:17, Justin Bassett a =C3=A9crit=C2=A0:
>
>
> On Fri, Aug 17, 2018, 7:46 AM Vicente J. Botet Escriba=20
> <vicente.botet@wanadoo.fr <mailto:vicente.botet@wanadoo.fr>> wrote:
>
>     * only one set of names is possible for all the TU (this need the
>     kind of mangling you are suggesting). I can live without this.
>     IIRC this was the approach that was rejected by the committee.
>
>
> Is there a way I can see the comments the committee has made on a=20
> proposal? My impression from my research was counter to this: I=20
> thought the committee didn't like that names could vary across=20
> translation units. I would like to read the comments on proposals,=20
> rather than just guess what the committee's concerns are
>

I don't know when this was reviewed. Maybe you can contact the author=20
directly.

Vicente

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/b9b3e05c-a9e3-e67b-35a0-549b60a556a8%40wanadoo.f=
r.

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

<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 17/08/2018 =C3=A0 17:17, Justin Basse=
tt a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"
cite=3D"mid:CAPuuy5eVi7Wns3augMyk0-F3eqCdLBZZ7Qwjmgsp-Hfjc0sq-A@mail.gmail.=
com">
      <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf=
-8">
      <div dir=3D"auto"><br>
        <br>
        <div class=3D"gmail_quote" dir=3D"auto">
          <div dir=3D"ltr">On Fri, Aug 17, 2018, 7:46 AM Vicente J. Botet
            Escriba &lt;<a href=3D"mailto:vicente.botet@wanadoo.fr"
              moz-do-not-send=3D"true">vicente.botet@wanadoo.fr</a>&gt;
            wrote:<br>
          </div>
          <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div text=3D"#000000" bgcolor=3D"#FFFFFF">
              <div class=3D"m_-1925368017976257733moz-cite-prefix">* only
                one set of names is possible for all the TU (this need
                the kind of mangling you are suggesting). I can live
                without this. IIRC this was the approach that was
                rejected by the committee.</div>
            </div>
          </blockquote>
        </div>
        <div dir=3D"auto"><br>
        </div>
        <div dir=3D"auto">Is there a way I can see the comments the
          committee has made on a proposal? My impression from my
          research was counter to this: I thought the committee didn't
          like that names could vary across translation units. I would
          like to read the comments on proposals, rather than just guess
          what the committee's concerns are</div>
        <div class=3D"gmail_quote" dir=3D"auto">
          <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
          </blockquote>
        </div>
      </div>
    </blockquote>
    <br>
    I don't know when this was reviewed. Maybe you can contact the
    author directly.<br>
    <br>
    Vicente<br>
  </body>
</html>

<p></p>

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

--------------B56AEB7A046CE3C84933BD22--

.

------=_Part_1042_2035426244.1534584417730
Content-Type: multipart/alternative;
 boundary="----=_Part_1043_859065193.1534584417730"

------=_Part_1043_859065193.1534584417730
Content-Type: text/plain; charset="UTF-8"



On Saturday, August 18, 2018 at 6:37:19 AM UTC+3, Justin Bassett wrote:
>
> What I've gathered from this discussion is that we want the simplest form
> of named parameters that can make it into the standard while not
> prohibiting a future proposal for some of the more niche features. After
> deliberating on this, I arrived at something quite similar to P0671R0
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0671r0.html> .
> Thus, the most important question that needs answering is: what were the
> committee's concerns about P0671R0? What were the reasons behind the
> changes made in R1 and R2? If we cannot address the concerns the committee
> had, there's no reason to propose a similar proposal. Without knowing the
> concerns, it's impossible to address them.
>

Here it is -> "introduce a new kind of functions". *That is the reason. *

Also, this obviously does not address the named arguments, that are
optional, the "weak" ones, so this solution will not make everyone happy.


The only solution that covers all use cases is the one that has both types,*
much like* Objective C (strong only) moved to Swift (strong, but some can
be *marked* optional).

We can argue about the syntax or if the name can be different from the
argument, but we should accept, one-sided solution will not work:
 - Strong-only will be infuriating and *hated* for every argument named,
that is *not* used for overload disambiguation, even now I hate Objective
C/Swift error:error calls, and for *many, many people *
   it is *not* what they expect.
 - Weak-only will be seen as "unneeded" by some and*, *in the same time,
not doing their "primary" job - to disambiguate.

We *could* probably introduce these in stages, though, as it is inevitable
to have a "different syntax", much like swift has to have "different
syntax" to mark ignorable ones.


>
> On Fri, Aug 17, 2018 at 12:21 PM Ville Voutilainen <ville.vo...@gmail.com
> <javascript:>> wrote:
>
>> On 17 August 2018 at 21:41,  <mihailn...@gmail.com <javascript:>> wrote:
>> > Wouldn't the interface to a template still be its header? Aren't modules
>> > only for compiled code?
>>
>> What "header"? You can put templates into a module just fine.
>>
>> > How is the relation b/w modules and templates envisioned to be?
>>
>> It would need to behave so that the names of parameters are handled in
>> the context
>> of the declaration site, not at the context of the instantiation site.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUb_iJ8B%3DELuJgBVo-R3fvPPOcgjMobr_4hvEQSR2%3DoALQ%40mail.gmail.com
>> .
>>
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/02b476cc-6a79-46a3-9721-59fcb57b6817%40isocpp.org.

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

<div dir=3D"ltr">=C2=A0<br><br>On Saturday, August 18, 2018 at 6:37:19 AM U=
TC+3, Justin Bassett wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr">What I&#39;ve gathered from this discussion is that we want t=
he simplest form of named parameters that can make it into the standard whi=
le not prohibiting a future proposal for some of the more niche features. A=
fter deliberating on this, I arrived at something quite similar to=C2=A0<a =
onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2=
Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2017%2Fp0671r0.htm=
l\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEmcvDAAWgpSrW32VJ9VCB4_3nS1g&#39;=
;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dh=
ttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2017%2F=
p0671r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEmcvDAAWgpSrW32VJ9VCB4=
_3nS1g&#39;;return true;" href=3D"http://www.open-std.org/jtc1/sc22/wg21/do=
cs/papers/2017/p0671r0.html" target=3D"_blank" rel=3D"nofollow">P0671R0</a>=
=C2=A0. Thus, the most important question that needs answering is: what wer=
e the committee&#39;s concerns about P0671R0? What were the reasons behind =
the changes made in R1 and R2? If we cannot address the concerns the commit=
tee had, there&#39;s no reason to propose a similar proposal. Without knowi=
ng the concerns, it&#39;s impossible to address them.</div></blockquote><di=
v><br></div><div>Here it is -&gt; &quot;<span style=3D"display: inline !imp=
ortant; float: none; background-color: transparent; color: rgb(0, 0, 0); fo=
nt-family: &quot;Book Antiqua&quot;,&quot;Times New Roman&quot;,&quot;Times=
&quot;,serif; font-size: 16px; font-style: normal; font-variant: normal; fo=
nt-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-=
decoration: none; text-indent: 0px; text-transform: none; -webkit-text-stro=
ke-width: 0px; white-space: normal; word-spacing: 0px;">introduce a new kin=
d of functions</span>&quot;. <i>That is the reason.=C2=A0</i><br></div><div=
><i></i><i></i><br></div><div>Also, this obviously does not address the nam=
ed arguments, that are optional, the &quot;weak&quot; ones, so this solutio=
n will not make everyone happy.=C2=A0</div><div><br></div><div><br></div><d=
iv>The only solution that covers all use cases is the one that has both typ=
es,<i> much like</i> Objective C (strong only) moved to Swift (strong, but =
some can be <i>marked</i> optional). =C2=A0</div><div><br></div><div>We can=
 argue about the syntax or if the name can be different from the argument, =
but we should accept, one-sided solution will not work:</div><div>=C2=A0- S=
trong-only will be infuriating and <i>hated</i> for every argument named, t=
hat is <i>not</i> used for overload <span style=3D"display: inline !importa=
nt; float: none; background-color: transparent; color: rgb(34, 34, 34); fon=
t-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13=
px; font-style: normal; font-variant: normal; font-weight: 400; letter-spac=
ing: normal; orphans: 2; text-align: left; text-decoration: none; text-inde=
nt: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space:=
 normal; word-spacing: 0px;">disambiguation, even now I hate <span style=3D=
"display: inline !important; float: none; background-color: transparent; co=
lor: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,=
sans-serif; font-size: 13px; font-style: normal; font-variant: normal; font=
-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-de=
coration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke=
-width: 0px; white-space: normal; word-spacing: 0px;">Objective C/S</span>w=
ift <font face=3D"courier new,monospace">error:error </font><font face=3D"a=
rial,sans-serif">calls, and for <i>many, many people=C2=A0</i></font></span=
></div>=C2=A0=C2=A0 it is <i>not</i> what they expect.=C2=A0<div>=C2=A0- We=
ak-only will be seen as &quot;unneeded&quot; by some and<i>,=C2=A0</i>in th=
e same time, not doing their &quot;primary&quot;<span style=3D"display: inl=
ine !important; float: none; background-color: transparent; color: rgb(34, =
34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; f=
ont-size: 13px; font-style: normal; font-variant: normal; font-weight: 400;=
 letter-spacing: normal; orphans: 2; text-align: left; text-decoration: non=
e; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; =
white-space: normal; word-spacing: 0px;"> </span>job - to disambiguate.=C2=
=A0</div><div><br></div><div>We <i>could</i> probably introduce these in st=
ages, though, as it is inevitable to have a &quot;different syntax&quot;, m=
uch like swift has to have &quot;different syntax&quot; to mark ignorable o=
nes.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br=
><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Aug 17, 2018 at 12:21 =
PM Ville Voutilainen &lt;<a onmousedown=3D"this.href=3D&#39;javascript:&#39=
;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;" =
href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mail=
to=3D"CsyZ-dTGDgAJ">ville.vo...@gmail.com</a>&gt; wrote:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">On 17 August 2018 at 21:41,=C2=A0 &lt;<a onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;" href=3D"javascript:" target=3D"_blank" =
rel=3D"nofollow" gdf-obfuscated-mailto=3D"CsyZ-dTGDgAJ">mihailn...@gmail.co=
m</a>&gt; wrote:<br>
&gt; Wouldn&#39;t the interface to a template still be its header? Aren&#39=
;t modules<br>
&gt; only for compiled code?<br>
<br>
What &quot;header&quot;? You can put templates into a module just fine.<br>
<br>
&gt; How is the relation b/w modules and templates envisioned to be?<br>
<br>
It would need to behave so that the names of parameters are handled in<br>
the context<br>
of the declaration site, not at the context of the instantiation site.<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 onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" o=
nclick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"javascrip=
t:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"CsyZ-dTGDgA=
J">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a onmousedown=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;re=
turn true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obf=
uscated-mailto=3D"CsyZ-dTGDgAJ">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a onmousedown=3D"this.href=3D&#39=
;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUb_iJ8B=
%3DELuJgBVo-R3fvPPOcgjMobr_4hvEQSR2%3DoALQ%40mail.gmail.com&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/ms=
gid/std-proposals/CAFk2RUb_iJ8B%3DELuJgBVo-R3fvPPOcgjMobr_4hvEQSR2%3DoALQ%4=
0mail.gmail.com&#39;;return true;" href=3D"https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/CAFk2RUb_iJ8B%3DELuJgBVo-R3fvPPOcgjMobr_4hvEQS=
R2%3DoALQ%40mail.gmail.com" target=3D"_blank" rel=3D"nofollow">https://grou=
ps.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/CAFk2RUb_iJ8B%<w=
br>3DELuJgBVo-R3fvPPOcgjMobr_<wbr>4hvEQSR2%3DoALQ%40mail.gmail.<wbr>com</a>=
..<br>
</blockquote></div>
</blockquote></div>

<p></p>

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

------=_Part_1043_859065193.1534584417730--

------=_Part_1042_2035426244.1534584417730--

.

On 18 August 2018 at 06:37, Justin Bassett <jbassett271@gmail.com> wrote:
> What I've gathered from this discussion is that we want the simplest form of
> named parameters that can make it into the standard while not prohibiting a
> future proposal for some of the more niche features. After deliberating on
> this, I arrived at something quite similar to P0671R0 . Thus, the most
> important question that needs answering is: what were the committee's
> concerns about P0671R0? What were the reasons behind the changes made in R1
> and R2? If we cannot address the concerns the committee had, there's no
> reason to propose a similar proposal. Without knowing the concerns, it's
> impossible to address them.

That proposal hasn't been discussed yet.

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

.

------=_Part_1028_835893462.1534591893823
Content-Type: multipart/alternative;
 boundary="----=_Part_1029_285536172.1534591893823"

------=_Part_1029_285536172.1534591893823
Content-Type: text/plain; charset="UTF-8"



On Saturday, August 18, 2018 at 2:05:13 PM UTC+3, Ville Voutilainen wrote:
>
> On 18 August 2018 at 06:37, Justin Bassett <jbass...@gmail.com
> <javascript:>> wrote:
> > What I've gathered from this discussion is that we want the simplest
> form of
> > named parameters that can make it into the standard while not
> prohibiting a
> > future proposal for some of the more niche features. After deliberating
> on
> > this, I arrived at something quite similar to P0671R0 . Thus, the most
> > important question that needs answering is: what were the committee's
> > concerns about P0671R0? What were the reasons behind the changes made in
> R1
> > and R2? If we cannot address the concerns the committee had, there's no
> > reason to propose a similar proposal. Without knowing the concerns, it's
> > impossible to address them.
>
> That proposal hasn't been discussed yet.
>

Do you mean the later iterations? Because the original was discouraged, according
to the trip report.
<https://blogs.msdn.microsoft.com/vcblog/2017/07/28/trip-report-evolution-working-group-at-the-summer-iso-c-standards-meeting-toronto/>

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

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

<div dir=3D"ltr"><br><br>On Saturday, August 18, 2018 at 2:05:13 PM UTC+3, =
Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 18 =
August 2018 at 06:37, Justin Bassett &lt;<a onmousedown=3D"this.href=3D&#39=
;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39=
;;return true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf=
-obfuscated-mailto=3D"T1xpLkbfDgAJ">jbass...@gmail.com</a>&gt; wrote:
<br>&gt; What I&#39;ve gathered from this discussion is that we want the si=
mplest form of
<br>&gt; named parameters that can make it into the standard while not proh=
ibiting a
<br>&gt; future proposal for some of the more niche features. After deliber=
ating on
<br>&gt; this, I arrived at something quite similar to P0671R0 . Thus, the =
most
<br>&gt; important question that needs answering is: what were the committe=
e&#39;s
<br>&gt; concerns about P0671R0? What were the reasons behind the changes m=
ade in R1
<br>&gt; and R2? If we cannot address the concerns the committee had, there=
&#39;s no
<br>&gt; reason to propose a similar proposal. Without knowing the concerns=
, it&#39;s
<br>&gt; impossible to address them.
<br>
<br>That proposal hasn&#39;t been discussed yet.
<br></blockquote><div><br></div><div>Do you mean the later iterations? Beca=
use the original was discouraged, <a href=3D"https://blogs.msdn.microsoft.c=
om/vcblog/2017/07/28/trip-report-evolution-working-group-at-the-summer-iso-=
c-standards-meeting-toronto/">according to the trip report.=C2=A0</a></div>=
</div>

<p></p>

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

------=_Part_1029_285536172.1534591893823--

------=_Part_1028_835893462.1534591893823--

.

On 18 August 2018 at 14:31,  <mihailnajdenov@gmail.com> wrote:
>
>
> On Saturday, August 18, 2018 at 2:05:13 PM UTC+3, Ville Voutilainen wrote:
>>
>> On 18 August 2018 at 06:37, Justin Bassett <jbass...@gmail.com> wrote:
>> > What I've gathered from this discussion is that we want the simplest
>> > form of
>> > named parameters that can make it into the standard while not
>> > prohibiting a
>> > future proposal for some of the more niche features. After deliberating
>> > on
>> > this, I arrived at something quite similar to P0671R0 . Thus, the most
>> > important question that needs answering is: what were the committee's
>> > concerns about P0671R0? What were the reasons behind the changes made in
>> > R1
>> > and R2? If we cannot address the concerns the committee had, there's no
>> > reason to propose a similar proposal. Without knowing the concerns, it's
>> > impossible to address them.
>>
>> That proposal hasn't been discussed yet.
>
>
> Do you mean the later iterations? Because the original was discouraged,
> according to the trip report.

The R2 version is a different approach. In its preamble, it says
"This is different and I appreciate that you make up your mind based
on what's written here. I am almost certain: you haven't seen this
before."

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

.

------=_Part_1084_1768597281.1534594008716
Content-Type: multipart/alternative;
 boundary="----=_Part_1085_1102986049.1534594008716"

------=_Part_1085_1102986049.1534594008716
Content-Type: text/plain; charset="UTF-8"



On Saturday, August 18, 2018 at 2:55:48 PM UTC+3, Ville Voutilainen wrote:
>
> On 18 August 2018 at 14:31,  <mihailn...@gmail.com <javascript:>> wrote:
> >
> >
> > On Saturday, August 18, 2018 at 2:05:13 PM UTC+3, Ville Voutilainen
> wrote:
> >>
> >> On 18 August 2018 at 06:37, Justin Bassett <jbass...@gmail.com> wrote:
> >> > What I've gathered from this discussion is that we want the simplest
> >> > form of
> >> > named parameters that can make it into the standard while not
> >> > prohibiting a
> >> > future proposal for some of the more niche features. After
> deliberating
> >> > on
> >> > this, I arrived at something quite similar to P0671R0 . Thus, the
> most
> >> > important question that needs answering is: what were the committee's
> >> > concerns about P0671R0? What were the reasons behind the changes made
> in
> >> > R1
> >> > and R2? If we cannot address the concerns the committee had, there's
> no
> >> > reason to propose a similar proposal. Without knowing the concerns,
> it's
> >> > impossible to address them.
> >>
> >> That proposal hasn't been discussed yet.
> >
> >
> > Do you mean the later iterations? Because the original was discouraged,
> > according to the trip report.
>
>

> The R2 version is a different approach. In its preamble, it says
> "This is different and I appreciate that you make up your mind based
> on what's written here. I am almost certain: you haven't seen this
> before."
>

Yeah, but the Basett was asking about the original, because his idea is the
same as R0
and he wanted to know what made the committee reject it.

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

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

<div dir=3D"ltr"><br><br>On Saturday, August 18, 2018 at 2:55:48 PM UTC+3, =
Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 18 =
August 2018 at 14:31, =C2=A0&lt;<a onmousedown=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return =
true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscat=
ed-mailto=3D"7daD2AjiDgAJ">mihailn...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt;
<br>&gt; On Saturday, August 18, 2018 at 2:05:13 PM UTC+3, Ville Voutilaine=
n wrote:
<br>&gt;&gt;
<br>&gt;&gt; On 18 August 2018 at 06:37, Justin Bassett &lt;<a>jbass...@gma=
il.com</a>&gt; wrote:
<br>&gt;&gt; &gt; What I&#39;ve gathered from this discussion is that we wa=
nt the simplest
<br>&gt;&gt; &gt; form of
<br>&gt;&gt; &gt; named parameters that can make it into the standard while=
 not
<br>&gt;&gt; &gt; prohibiting a
<br>&gt;&gt; &gt; future proposal for some of the more niche features. Afte=
r deliberating
<br>&gt;&gt; &gt; on
<br>&gt;&gt; &gt; this, I arrived at something quite similar to P0671R0 . T=
hus, the most
<br>&gt;&gt; &gt; important question that needs answering is: what were the=
 committee&#39;s
<br>&gt;&gt; &gt; concerns about P0671R0? What were the reasons behind the =
changes made in
<br>&gt;&gt; &gt; R1
<br>&gt;&gt; &gt; and R2? If we cannot address the concerns the committee h=
ad, there&#39;s no
<br>&gt;&gt; &gt; reason to propose a similar proposal. Without knowing the=
 concerns, it&#39;s
<br>&gt;&gt; &gt; impossible to address them.
<br>&gt;&gt;
<br>&gt;&gt; That proposal hasn&#39;t been discussed yet.
<br>&gt;
<br>&gt;
<br>&gt; Do you mean the later iterations? Because the original was discour=
aged,
<br>&gt; according to the trip report.
<br>
<br></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">The R2 version is a different approach. In its preamble, it says
<br>&quot;This is different and I appreciate that you make up your mind bas=
ed
<br>on what&#39;s written here. I am almost certain: you haven&#39;t seen t=
his
<br>before.&quot;
<br></blockquote><div><br></div><div>Yeah, but the Basett was asking about =
the original, because his idea is the same as R0<br></div><div><span style=
=3D"display: inline !important; float: none; background-color: transparent;=
 color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quo=
t;,sans-serif; font-size: 13px; font-style: normal; font-variant: normal; f=
ont-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text=
-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-str=
oke-width: 0px; white-space: normal; word-spacing: 0px;">and he wanted to k=
now what made the committee reject it.=C2=A0=C2=A0=C2=A0</span><b></b><i></=
i><u></u><sub></sub><sup></sup><strike></strike><br></div></div>

<p></p>

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

------=_Part_1085_1102986049.1534594008716--

------=_Part_1084_1768597281.1534594008716--

.

On 18 August 2018 at 15:06,  <mihailnajdenov@gmail.com> wrote:
>> >> That proposal hasn't been discussed yet.
>> >
>> >
>> > Do you mean the later iterations? Because the original was discouraged,
>> > according to the trip report.
>>
>
>>
>> The R2 version is a different approach. In its preamble, it says
>> "This is different and I appreciate that you make up your mind based
>> on what's written here. I am almost certain: you haven't seen this
>> before."
>
>
> Yeah, but the Basett was asking about the original, because his idea is the
> same as R0
> and he wanted to know what made the committee reject it.

I stand corrected. So, looking at the discussion, the R0 version was
so that you couldn't call the functions as usual, with
ordered-unnamed,
and it suggested that the names need to be baked into the ABI. But
even with that removed,
the proposal still didn't pass. There were suggestions that a "fluent
API" (aka a parameter
type that has separate setters for different arguments) should just be
used instead (to which
I commented that that approach was invented 30 years ago and users
refuse to use it). A parameter
struct and use of designated initializers was suggested as another
work-around. Based on the
discussion notes, it seems that Evolution was still unconvinced that
this language feature
is necessary, given the work-arounds. That has been the fate of almost
every one of such
proposals.

If someone wants to work on this, contact Axel. I summarized the
situation at the end of the discussion
on P0671R0 with "Proposals on this will come back. We will not be able
to kill the desire. "

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

.

------=_Part_1138_1610091791.1534604079332
Content-Type: multipart/alternative;
 boundary="----=_Part_1139_1866486676.1534604079332"

------=_Part_1139_1866486676.1534604079332
Content-Type: text/plain; charset="UTF-8"



On Saturday, August 18, 2018 at 3:15:13 PM UTC+3, Ville Voutilainen wrote:
>
> On 18 August 2018 at 15:06,  <mihailn...@gmail.com <javascript:>> wrote:
> >> >> That proposal hasn't been discussed yet.
> >> >
> >> >
> >> > Do you mean the later iterations? Because the original was
> discouraged,
> >> > according to the trip report.
> >>
> >
> >>
> >> The R2 version is a different approach. In its preamble, it says
> >> "This is different and I appreciate that you make up your mind based
> >> on what's written here. I am almost certain: you haven't seen this
> >> before."
> >
> >
> > Yeah, but the Basett was asking about the original, because his idea is
> the
> > same as R0
> > and he wanted to know what made the committee reject it.
>
> I stand corrected. So, looking at the discussion, the R0 version was
> so that you couldn't call the functions as usual, with
> ordered-unnamed,
> and it suggested that the names need to be baked into the ABI. But
> even with that removed,
> the proposal still didn't pass. There were suggestions that a "fluent
> API" (aka a parameter
> type that has separate setters for different arguments) should just be
> used instead (to which
> I commented that that approach was invented 30 years ago and users
> refuse to use it). A parameter
> struct and use of designated initializers was suggested as another
> work-around. Based on the
> discussion notes, it seems that Evolution was still unconvinced that
> this language feature
> is necessary, given the work-arounds. That has been the fate of almost
> every one of such
> proposals.
>

Last few days made it clear where the problem is - there is no such thing
like "named arguments" as self-explanatory topic.
Different people expect both different semantics and different
implementations.

This creates noise, and murks the goal - what is the problem need fixing.

If the community stands behind somethings and says:
"This is a problem, we know the workarounds, but they don't work for us
here and here, because this and this, we *really* like this to be improved."
Then the committee will know, they are *fixing* something, *improving* the
language, not just adding a gimmick.

This also goes for the proposals, they should really talk fixing problems
and where workarounds fall short.


>
> If someone wants to work on this, contact Axel. I summarized the
> situation at the end of the discussion
> on P0671R0 with "Proposals on this will come back. We will not be able
> to kill the desire. "
>

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

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

<div dir=3D"ltr"><br><br>On Saturday, August 18, 2018 at 3:15:13 PM UTC+3, =
Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 18 =
August 2018 at 15:06, =C2=A0&lt;<a onmousedown=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return =
true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscat=
ed-mailto=3D"xNSQHxjjDgAJ">mihailn...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; &gt;&gt; That proposal hasn&#39;t been discussed yet.
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; Do you mean the later iterations? Because the original wa=
s discouraged,
<br>&gt;&gt; &gt; according to the trip report.
<br>&gt;&gt;
<br>&gt;
<br>&gt;&gt;
<br>&gt;&gt; The R2 version is a different approach. In its preamble, it sa=
ys
<br>&gt;&gt; &quot;This is different and I appreciate that you make up your=
 mind based
<br>&gt;&gt; on what&#39;s written here. I am almost certain: you haven&#39=
;t seen this
<br>&gt;&gt; before.&quot;
<br>&gt;
<br>&gt;
<br>&gt; Yeah, but the Basett was asking about the original, because his id=
ea is the
<br>&gt; same as R0
<br>&gt; and he wanted to know what made the committee reject it.
<br>
<br>I stand corrected. So, looking at the discussion, the R0 version was
<br>so that you couldn&#39;t call the functions as usual, with
<br>ordered-unnamed,
<br>and it suggested that the names need to be baked into the ABI. But
<br>even with that removed,
<br>the proposal still didn&#39;t pass. There were suggestions that a &quot=
;fluent
<br>API&quot; (aka a parameter
<br>type that has separate setters for different arguments) should just be
<br>used instead (to which
<br>I commented that that approach was invented 30 years ago and users
<br>refuse to use it). A parameter
<br>struct and use of designated initializers was suggested as another
<br>work-around. Based on the
<br>discussion notes, it seems that Evolution was still unconvinced that
<br>this language feature
<br>is necessary, given the work-arounds. That has been the fate of almost
<br>every one of such
<br>proposals.
<br></blockquote><div><br></div><div>Last few days made it clear where the =
problem is - there is no such thing like &quot;named arguments&quot; as sel=
f-explanatory topic.</div><div>Different people expect both different seman=
tics and different implementations.</div><div><br></div><div>This creates n=
oise, and murks the goal - what is the problem need fixing.=C2=A0</div><div=
><br></div><div>If the community stands behind somethings and says:=C2=A0</=
div><div>&quot;This is a problem, we know the workarounds, but they don&#39=
;t work for us here and here, because this and this, we <i>really</i> like =
this to be improved.&quot;</div><div>Then the committee will know, they are=
 <i>fixing</i> something, <i>improving</i> the language, not just adding a =
gimmick.=C2=A0</div><div><br></div><div>This also goes for the proposals, t=
hey should really talk fixing problems and where workarounds fall short.=C2=
=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>If someone wants to work on this, contact Axel. I summarized the
<br>situation at the end of the discussion
<br>on P0671R0 with &quot;Proposals on this will come back. We will not be =
able
<br>to kill the desire. &quot;
<br></blockquote></div>

<p></p>

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

------=_Part_1139_1866486676.1534604079332--

------=_Part_1138_1610091791.1534604079332--

.

Le 17/08/2018 =C3=A0 17:05, Thiago Macieira a =C3=A9crit=C2=A0:
> On Friday, 17 August 2018 07:46:42 PDT Vicente J. Botet Escriba wrote:
>> As this would request to compiler to store somewhere all the
>> declarations of a specific function, I believe that in order to don't
>> pay for what we don't use, we would need to opt in for the feature is
>> some specific way, that I don't worry about. E.g.
>>
>>       void f(a:int, b:int);
>>
>>       void f(x:int x, y:int);
>>
>> Only in this case the named parameters should be allowed.
> Agreed. To me, parameter names need to be opt-in. Anything else is simply=
 not
> workable as the names have not and will continue not to be stable, so the=
y
> aren't usable by users in the first place.
>
> But my question to you is: are those two function declarations the same
> function? If they are, how do you propose we declare them so that they ar=
e
> *not* the same function?
Yes, they declare the same function.

If we wan to have two different overload, we would need something else,=20
that don't need to be a named parameter. We could use now just tag types

struct tag1 {}

struct tag2 {}


      void f(tag1, a:int, b:int);

      void f(tag2, x:int, y:int);

Now we can call f using the tag objects

 f(tag1{}, a:=3D1, b:=3D2);
 f(tag2{}, x:=3D1, y:=3D2);


and we could add any syntactic sugar that make it easier to define those ta=
gs, and make them even local to the function

      void f(@tag1, a:int, b:int);

      void f(@tag2, x:int, y:int);


Now we can call f using the local tags

 f(@tag1, a:=3D1, b:=3D2);
 f(@tag2, x:=3D1, y:=3D2);

Note that tagx is not associated to any named parameter.


Vicente


--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/4df1f86f-cdee-5275-bdd1-b53f2f10bef8%40wanadoo.f=
r.

.

On 2018-08-18 17:09, Vicente J. Botet Escriba wrote:
> Le 17/08/2018 =C3=A0 17:05, Thiago Macieira a =C3=A9crit=C2=A0:
>> On Friday, 17 August 2018 07:46:42 PDT Vicente J. Botet Escriba wrote:
>>> As this would request to compiler to store somewhere all the
>>> declarations of a specific function, I believe that in order to don't
>>> pay for what we don't use, we would need to opt in for the feature is
>>> some specific way, that I don't worry about. E.g.
>>>
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 void f(a:int, b:int);
>>>
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 void f(x:int x, y:int);
>>>
>>> Only in this case the named parameters should be allowed.
>> Agreed. To me, parameter names need to be opt-in. Anything else is=20
>> simply not
>> workable as the names have not and will continue not to be stable, so=20
>> they
>> aren't usable by users in the first place.
>>
>> But my question to you is: are those two function declarations the same
>> function? If they are, how do you propose we declare them so that they=
=20
>> are
>> *not* the same function?
> Yes, they declare the same function.
>=20
> If we wan to have two different overload, we would need something else,=
=20
> that don't need to be a named parameter. We could use now just tag types
>=20
> struct tag1 {}
>=20
> struct tag2 {}
>=20
>=20
>  =C2=A0=C2=A0=C2=A0=C2=A0 void f(tag1, a:int, b:int);
>=20
>  =C2=A0=C2=A0=C2=A0=C2=A0 void f(tag2, x:int, y:int);
>=20
> Now we can call f using the tag objects
>=20
>  =C2=A0=C2=A0=C2=A0=C2=A0f(tag1{}, a:=3D1, b:=3D2);
>  =C2=A0=C2=A0=C2=A0=C2=A0f(tag2{}, x:=3D1, y:=3D2);
>=20
>=20
> and we could add any syntactic sugar that make it easier to define those=
=20
> tags, and make them even local to the function
>=20
>  =C2=A0=C2=A0=C2=A0=C2=A0 void f(@tag1, a:int, b:int);
>=20
>  =C2=A0=C2=A0=C2=A0=C2=A0 void f(@tag2, x:int, y:int);
>=20
>=20
> Now we can call f using the local tags
>=20
>  =C2=A0=C2=A0=C2=A0=C2=A0f(@tag1, a:=3D1, b:=3D2);
>  =C2=A0=C2=A0=C2=A0=C2=A0f(@tag2, x:=3D1, y:=3D2);
>=20
> Note that tagx is not associated to any named parameter.
>=20

We can of course already do this as f_tag1(1,2) and f_tag2(1,2), without=20
changing the language.

What is the advantage of f(@tag1 over f_tag1( ?


     Bo Persson


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

.

On 17/08/18 21:11, Matthew Woehlke wrote:
> On 2018-08-17 14:42, David Brown wrote:
>> On 17/08/18 19:53, Matthew Woehlke wrote:
>>> Right now, changing the names of function parameters is SC+BC. IIUC, yo=
u
>>> are proposing to make it at least SIC, if not also BIC. I honestly can'=
t
>>> see how you're going to convince the committee that that's okay.
>>
>> I'm sorry, I don't recognise the abbreviations SC, BC, SIC and BIC.
>=20
> S/B =3D source (API) / binary (ABI)
> C/IC =3D [in]compatible
>=20
> IOW, right now if I release a new version of my library that changes a
> parameter name, it has no effect. Under your proposal... does my
> previously compiled application (which uses said library) still run
> (BC)? Can I recompile it without needing to change its sources (SC)?
>=20

Let's skip the name parameter overloading bit for now.  That is a new=20
feature, which would let you do something you could not do before, and=20
requires multiple changes (in compilers, and in source code that uses=20
it) to support.  I have given a suggestion of how it could be=20
implemented, because it is a feature some people want - I am not=20
personally convinced that it is an important feature to have, and=20
certainly not convinced it is worth the price in therms of changes.  So=20
here I am talking about the optional use of parameter names to improve=20
readability, help write correct code, help spot incorrect code, and -=20
optionally - to allow re-arranging of parameter order and skipping=20
defaults using names.

First, if you don't /use/ named parameters, then nothing (binary or=20
source) changes.  That is important to my proposal.

A library generally consists of four parts - documentation, headers to=20
allow code to use the library, source of the implementation, and=20
binaries of the implementation.  A release to others will have the first=20
two parts and one or both of the second two parts.

For code that uses the library, if they want to use named parameters=20
then the libraries headers need to be consistent about parameter names.=20
If the library documentation says that's okay, and considers the=20
parameter names to be part of the stable interface for the libraries,=20
then user could can use the names straight away - no library changes are=20
needed.  (It is not uncommon for library documentation to be wholly or=20
partly generated automatically by tools like doxygen, which do view=20
parameter names as significant.)  If the documentation does not say so,=20
then the user is taking a risk or tying their code to a specific library=20
release.

If you as the library implementer want to change a parameter name in the=20
headers, that's fair enough if you didn't say they would be consistent,=20
and a breaking change if you did - just like countless other kinds of=20
changes to a library API.  If you want to change the parameter names=20
inside the implementation code, that's also fine.  It would generally be=20
a bad idea to have them inconsistent with the headers, but it is=20
certainly allowable - the compiler would accept them, with optional=20
warnings.

I can't see how you would be any source or binary incompatibilities that=20
are not basically the same as you get with relying on any other kind of=20
implementation details that are not guaranteed to be fixed.



>>>  =C2=A0=C2=A0 class foo
>>>  =C2=A0=C2=A0 {
>>>  =C2=A0=C2=A0=C2=A0=C2=A0 ...interface...
>>>  =C2=A0=C2=A0 private:
>>>  =C2=A0=C2=A0=C2=A0=C2=A0 FooPrivate* d;
>>>  =C2=A0=C2=A0 };
>>>
>>> No so much "leaked" there...
>>
>> Well, no, not in a case like this.=C2=A0 But when the private section ho=
lds
>> members and possibly inline implementations, it is leaked.=C2=A0 This is
>> especially true of template libraries.
>=20
> True. The point is that "some libraries are designed poorly" is not an
> excuse to leak even *more*.
>=20

The use of PIMPLE is /not/ a black-or-white mark of good library design!

And the use of named parameters from the public header information does=20
not involve /any/ leak that was not already leaked from before.


>>> On 2018-08-17 13:12, David Brown wrote:
>>>> I don't think your argument against allowing people to use named
>>>> parameters for existing functions is at all convincing.
>>>
>>> Who's arguing that?
>>>
>>> I would make this perfectly legal:
>>>
>>>  =C2=A0=C2=A0 void foo(int x); // note: not a named parameter
>>>  =C2=A0=C2=A0 foo(.x=3D5); // okay, but maybe warn in pedantic mode
>>>  =C2=A0=C2=A0 foo(.a=3D5); // okay, but probably warn
>>
>> Do you mean you would be happy to allow the parameter name in an
>> existing declaration to be used in function calls as a check?
>=20
> If I make a call with a named parameter that resolves to a function that
> does not have explicitly named parameters, then yes, I'm fine with the
> compiler *warning* me if the names don't match.
>=20

I agree.

>> But you would presumably not allow such names to be used for
>> overloads - that would require a specific extra syntax in the
>> declaration.  Is that correct?
> Right.

Good.

>=20
> I guess in that sense what I'm proposing is opt-out weak naming (that
> only involves a possible compiler warning if you mismatch names) with
> opt-in strong naming, where the "fun stuff" (argument skipping, and per
> your question, name-based overloading) requires 'strong' naming.
>=20

Certainly I fully agree that name-based overloading requires "strong"=20
naming - where the declaration has a new syntax saying that names /must/=20
be used in some form, and where the parameter names become part of the=20
ABI for the function.  (I hope that could be achieved with name=20
mangling, or with types somehow, in order to minimise the implementation=20
changes needed.)

I also think that common use, checked with optional compiler warnings=20
(which could of course be errors if you choose appropriate compiler=20
flags), can be done with "weak" naming - using parameter names declared=20
as they are today in existing code.

I'd perhaps prefer somewhat strong warnings or errors - using parameter=20
names in a call when the declaration had no names could be an optional=20
warning, but using parameter names incorrectly when the declaration has=20
names should likely be an error by default.

There are two other use-cases where there could be debate about the best=20
solution:

If the call has the right parameter names, but the wrong order, should=20
that be a warning, or error, or should the compiler "magically" correct=20
the order?  If strong naming is used, the compiler should certainly be=20
able to re-order the parameters without giving any complaints.  But with=20
weak naming, opinions are going to be more varied.  I would like the=20
compiler to do the re-ordering, but I would be okay with an error=20
message - this would probably be the simplest and least risky solution.

The other case is for skipping arguments.  Again, with strong naming=20
this should be supported.  I believe it /could/ be supported fine with=20
weak naming, but would again be okay with the safer solution of not=20
allowing it without strong naming.



> The only way to opt out would be by not naming your parameters *at all*.
> However, I guess if you wrote:
>=20
>    void foo(int x, int y);
>    void foo(int a, int b);
>=20
> ...then *either* `foo(.a=3D1)` or `foo(.x=3D1)` should be accepted with n=
o
> warning, and would call the same function. But this is all QoI stuff
> that doesn't need to be part of the standard.
>=20
>> I would be entirely happy with such a situation - my main objective is
>> to aid in writing correct and readable code, and my compiler (given
>> appropriate flags) would accept "foo(.x =3D 5)" without complaint while
>> warning about "foo(.a =3D 5)", I'd be very satisfied.
>>
>> I'd been even happier if it accepted this:
>>
>>  =C2=A0=C2=A0=C2=A0=C2=A0void foo(int x, int y);
>>  =C2=A0=C2=A0=C2=A0=C2=A0foo(.y =3D 1, .x =3D 2);=C2=A0=C2=A0=C2=A0 // S=
ame as foo(2, 1)
>>
>> But if that's a problem, I'd be fine without it.
>=20
> Well, it would *accept* that... with a warning... but it would be the
> same as `foo(1, 2)` :-). If you wrote instead:
>=20
>    void foo(int .x, int .y);
>=20
> ...then it would either do what you meant, or be a hard error. I'm on
> the fence whether reordering should be allowed. (And by "on the fence" I
> mean a) *I* don't feel strongly either way, and b) I think there are
> strong arguments for either case.)
>=20

That all seems fine to me.  (I'm on the side that would /like/=20
reordering, but not far enough to feel it is a requirement.  And I agree=20
about there being arguments both ways.)

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5dde96f3-24bc-0499-8019-eb8195bdaded%40westcontr=
ol.com.

.

Le 19/08/2018 =C3=A0 10:27, Bo Persson a =C3=A9crit=C2=A0:
> On 2018-08-18 17:09, Vicente J. Botet Escriba wrote:
>>
>>
>>
>> and we could add any syntactic sugar that make it easier to define=20
>> those tags, and make them even local to the function
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 void f(@tag1, a:int, b:int);
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 void f(@tag2, x:int, y:int);
>>
>>
>> Now we can call f using the local tags
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f(@tag1, a:=3D1, b:=3D2);
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f(@tag2, x:=3D1, y:=3D2);
>>
>> Note that tagx is not associated to any named parameter.
>>
>
> We can of course already do this as f_tag1(1,2) and f_tag2(1,2),=20
> without changing the language.
>
> What is the advantage of f(@tag1 over f_tag1( ?
Independently of the language feature, using a tag type allows to=20
transport the tag between different functions. In addition, you cannot=20
change the class constructor name, so you will need a tag to be able to=20
overload it. Take for example the in_place_t tag.

Vicente

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7e07b857-8be0-f0b4-79e2-32d0f2d8e823%40wanadoo.f=
r.

.

------=_Part_112_247342288.1534683121640
Content-Type: multipart/alternative;
 boundary="----=_Part_113_150041763.1534683121641"

------=_Part_113_150041763.1534683121641
Content-Type: text/plain; charset="UTF-8"



On Sunday, August 19, 2018 at 2:23:06 PM UTC+3, David Brown wrote:
>
>
> On 17/08/18 21:11, Matthew Woehlke wrote:
> > On 2018-08-17 14:42, David Brown wrote:
> >> On 17/08/18 19:53, Matthew Woehlke wrote:
> >>> Right now, changing the names of function parameters is SC+BC. IIUC,
> you
> >>> are proposing to make it at least SIC, if not also BIC. I honestly
> can't
> >>> see how you're going to convince the committee that that's okay.
> >>
> >> I'm sorry, I don't recognise the abbreviations SC, BC, SIC and BIC.
> >
> > S/B = source (API) / binary (ABI)
> > C/IC = [in]compatible
> >
> > IOW, right now if I release a new version of my library that changes a
> > parameter name, it has no effect. Under your proposal... does my
> > previously compiled application (which uses said library) still run
> > (BC)? Can I recompile it without needing to change its sources (SC)?
> >
>
> Let's skip the name parameter overloading bit for now.  That is a new
> feature, which would let you do something you could not do before, and
> requires multiple changes (in compilers, and in source code that uses
> it) to support.  I have given a suggestion of how it could be
> implemented, because it is a feature some people want - I am not
> personally convinced that it is an important feature to have, and
> certainly not convinced it is worth the price in therms of changes.  So
> here I am talking about the optional use of parameter names to improve
> readability, help write correct code, help spot incorrect code, and -
> optionally - to allow re-arranging of parameter order and skipping
> defaults using names.
>
> First, if you don't /use/ named parameters, then nothing (binary or
> source) changes.  That is important to my proposal.
>
> A library generally consists of four parts - documentation, headers to
> allow code to use the library, source of the implementation, and
> binaries of the implementation.  A release to others will have the first
> two parts and one or both of the second two parts.
>
> For code that uses the library, if they want to use named parameters
> then the libraries headers need to be consistent about parameter names.
> If the library documentation says that's okay, and considers the
> parameter names to be part of the stable interface for the libraries,
> then user could can use the names straight away - no library changes are
> needed.  (It is not uncommon for library documentation to be wholly or
> partly generated automatically by tools like doxygen, which do view
> parameter names as significant.)  If the documentation does not say so,
> then the user is taking a risk or tying their code to a specific library
> release.
>
> If you as the library implementer want to change a parameter name in the
> headers, that's fair enough if you didn't say they would be consistent,
> and a breaking change if you did - just like countless other kinds of
> changes to a library API.  If you want to change the parameter names
> inside the implementation code, that's also fine.  It would generally be
> a bad idea to have them inconsistent with the headers, but it is
> certainly allowable - the compiler would accept them, with optional
> warnings.
>
> I can't see how you would be any source or binary incompatibilities that
> are not basically the same as you get with relying on any other kind of
> implementation details that are not guaranteed to be fixed.
>
>
>
> >>>     class foo
> >>>     {
> >>>       ...interface...
> >>>     private:
> >>>       FooPrivate* d;
> >>>     };
> >>>
> >>> No so much "leaked" there...
> >>
> >> Well, no, not in a case like this.  But when the private section holds
> >> members and possibly inline implementations, it is leaked.  This is
> >> especially true of template libraries.
> >
> > True. The point is that "some libraries are designed poorly" is not an
> > excuse to leak even *more*.
> >
>
> The use of PIMPLE is /not/ a black-or-white mark of good library design!
>
> And the use of named parameters from the public header information does
> not involve /any/ leak that was not already leaked from before.
>
>
> >>> On 2018-08-17 13:12, David Brown wrote:
> >>>> I don't think your argument against allowing people to use named
> >>>> parameters for existing functions is at all convincing.
> >>>
> >>> Who's arguing that?
> >>>
> >>> I would make this perfectly legal:
> >>>
> >>>     void foo(int x); // note: not a named parameter
> >>>     foo(.x=5); // okay, but maybe warn in pedantic mode
> >>>     foo(.a=5); // okay, but probably warn
> >>
> >> Do you mean you would be happy to allow the parameter name in an
> >> existing declaration to be used in function calls as a check?
> >
> > If I make a call with a named parameter that resolves to a function that
> > does not have explicitly named parameters, then yes, I'm fine with the
> > compiler *warning* me if the names don't match.
> >
>
> I agree.
>
> >> But you would presumably not allow such names to be used for
> >> overloads - that would require a specific extra syntax in the
> >> declaration.  Is that correct?
> > Right.
>
> Good.
>
> >
> > I guess in that sense what I'm proposing is opt-out weak naming (that
> > only involves a possible compiler warning if you mismatch names) with
> > opt-in strong naming, where the "fun stuff" (argument skipping, and per
> > your question, name-based overloading) requires 'strong' naming.
> >
>
> Certainly I fully agree that name-based overloading requires "strong"
> naming - where the declaration has a new syntax saying that names /must/
> be used in some form, and where the parameter names become part of the
> ABI for the function.  (I hope that could be achieved with name
> mangling, or with types somehow, in order to minimise the implementation
> changes needed.)
>
> I also think that common use, checked with optional compiler warnings
> (which could of course be errors if you choose appropriate compiler
> flags), can be done with "weak" naming - using parameter names declared
> as they are today in existing code.
>

No, they can't:

What I have established, having had discussions about named arguments
> on multiple occasions,
> is that the following pain points are important:
>
> 1) it needs to be an opt-in for the author of a library, so no
> automagic naming. Some library
> authors do not want users relying on names that the library author
> didn't expect them to rely
> on, in order to avoid breakage that wasn't considered beforehand.
>

This was suggested back in 1991(!), and rejected!
We need to drop that idea for good *and move on*, *make some progress!*

And no, documenting which arguments are stable API is not good enough.
C++ is trying for 30 years to fix the need for documentation to *use* the
code (concepts), no one needs more of it.

I am saying all this with best intentions - we need to stop repeating the
same mistakes and really, step by step make *some* progress.
Progress in *requirements (what we need)*, but progress in *implementation
(how can be done)*.

....

>
>

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

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

<div dir=3D"ltr"><br><br>On Sunday, August 19, 2018 at 2:23:06 PM UTC+3, Da=
vid Brown wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>On 17/08/18 21:11, Matthew Woehlke wrote:
<br>&gt; On 2018-08-17 14:42, David Brown wrote:
<br>&gt;&gt; On 17/08/18 19:53, Matthew Woehlke wrote:
<br>&gt;&gt;&gt; Right now, changing the names of function parameters is SC=
+BC. IIUC, you
<br>&gt;&gt;&gt; are proposing to make it at least SIC, if not also BIC. I =
honestly can&#39;t
<br>&gt;&gt;&gt; see how you&#39;re going to convince the committee that th=
at&#39;s okay.
<br>&gt;&gt;
<br>&gt;&gt; I&#39;m sorry, I don&#39;t recognise the abbreviations SC, BC,=
 SIC and BIC.
<br>&gt;=20
<br>&gt; S/B =3D source (API) / binary (ABI)
<br>&gt; C/IC =3D [in]compatible
<br>&gt;=20
<br>&gt; IOW, right now if I release a new version of my library that chang=
es a
<br>&gt; parameter name, it has no effect. Under your proposal... does my
<br>&gt; previously compiled application (which uses said library) still ru=
n
<br>&gt; (BC)? Can I recompile it without needing to change its sources (SC=
)?
<br>&gt;=20
<br>
<br>Let&#39;s skip the name parameter overloading bit for now. =C2=A0That i=
s a new=20
<br>feature, which would let you do something you could not do before, and=
=20
<br>requires multiple changes (in compilers, and in source code that uses=
=20
<br>it) to support. =C2=A0I have given a suggestion of how it could be=20
<br>implemented, because it is a feature some people want - I am not=20
<br>personally convinced that it is an important feature to have, and=20
<br>certainly not convinced it is worth the price in therms of changes. =C2=
=A0So=20
<br>here I am talking about the optional use of parameter names to improve=
=20
<br>readability, help write correct code, help spot incorrect code, and -=
=20
<br>optionally - to allow re-arranging of parameter order and skipping=20
<br>defaults using names.
<br>
<br>First, if you don&#39;t /use/ named parameters, then nothing (binary or=
=20
<br>source) changes. =C2=A0That is important to my proposal.
<br>
<br>A library generally consists of four parts - documentation, headers to=
=20
<br>allow code to use the library, source of the implementation, and=20
<br>binaries of the implementation. =C2=A0A release to others will have the=
 first=20
<br>two parts and one or both of the second two parts.
<br>
<br>For code that uses the library, if they want to use named parameters=20
<br>then the libraries headers need to be consistent about parameter names.=
=20
<br>If the library documentation says that&#39;s okay, and considers the=20
<br>parameter names to be part of the stable interface for the libraries,=
=20
<br>then user could can use the names straight away - no library changes ar=
e=20
<br>needed. =C2=A0(It is not uncommon for library documentation to be wholl=
y or=20
<br>partly generated automatically by tools like doxygen, which do view=20
<br>parameter names as significant.) =C2=A0If the documentation does not sa=
y so,=20
<br>then the user is taking a risk or tying their code to a specific librar=
y=20
<br>release.
<br>
<br>If you as the library implementer want to change a parameter name in th=
e=20
<br>headers, that&#39;s fair enough if you didn&#39;t say they would be con=
sistent,=20
<br>and a breaking change if you did - just like countless other kinds of=
=20
<br>changes to a library API. =C2=A0If you want to change the parameter nam=
es=20
<br>inside the implementation code, that&#39;s also fine. =C2=A0It would ge=
nerally be=20
<br>a bad idea to have them inconsistent with the headers, but it is=20
<br>certainly allowable - the compiler would accept them, with optional=20
<br>warnings.
<br>
<br>I can&#39;t see how you would be any source or binary incompatibilities=
 that=20
<br>are not basically the same as you get with relying on any other kind of=
=20
<br>implementation details that are not guaranteed to be fixed.
<br>
<br>
<br>
<br>&gt;&gt;&gt; =C2=A0=C2=A0=C2=A0 class foo
<br>&gt;&gt;&gt; =C2=A0=C2=A0=C2=A0 {
<br>&gt;&gt;&gt; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ...interface...
<br>&gt;&gt;&gt; =C2=A0=C2=A0=C2=A0 private:
<br>&gt;&gt;&gt; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FooPrivate* d;
<br>&gt;&gt;&gt; =C2=A0=C2=A0=C2=A0 };
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; No so much &quot;leaked&quot; there...
<br>&gt;&gt;
<br>&gt;&gt; Well, no, not in a case like this.=C2=A0 But when the private =
section holds
<br>&gt;&gt; members and possibly inline implementations, it is leaked.=C2=
=A0 This is
<br>&gt;&gt; especially true of template libraries.
<br>&gt;=20
<br>&gt; True. The point is that &quot;some libraries are designed poorly&q=
uot; is not an
<br>&gt; excuse to leak even *more*.
<br>&gt;=20
<br>
<br>The use of PIMPLE is /not/ a black-or-white mark of good library design=
!
<br>
<br>And the use of named parameters from the public header information does=
=20
<br>not involve /any/ leak that was not already leaked from before.
<br>
<br>
<br>&gt;&gt;&gt; On 2018-08-17 13:12, David Brown wrote:
<br>&gt;&gt;&gt;&gt; I don&#39;t think your argument against allowing peopl=
e to use named
<br>&gt;&gt;&gt;&gt; parameters for existing functions is at all convincing=
..
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; Who&#39;s arguing that?
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; I would make this perfectly legal:
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; =C2=A0=C2=A0=C2=A0 void foo(int x); // note: not a named p=
arameter
<br>&gt;&gt;&gt; =C2=A0=C2=A0=C2=A0 foo(.x=3D5); // okay, but maybe warn in=
 pedantic mode
<br>&gt;&gt;&gt; =C2=A0=C2=A0=C2=A0 foo(.a=3D5); // okay, but probably warn
<br>&gt;&gt;
<br>&gt;&gt; Do you mean you would be happy to allow the parameter name in =
an
<br>&gt;&gt; existing declaration to be used in function calls as a check?
<br>&gt;=20
<br>&gt; If I make a call with a named parameter that resolves to a functio=
n that
<br>&gt; does not have explicitly named parameters, then yes, I&#39;m fine =
with the
<br>&gt; compiler *warning* me if the names don&#39;t match.
<br>&gt;=20
<br>
<br>I agree.
<br>
<br>&gt;&gt; But you would presumably not allow such names to be used for
<br>&gt;&gt; overloads - that would require a specific extra syntax in the
<br>&gt;&gt; declaration. =C2=A0Is that correct?
<br>&gt; Right.
<br>
<br>Good.
<br>
<br>&gt;=20
<br>&gt; I guess in that sense what I&#39;m proposing is opt-out weak namin=
g (that
<br>&gt; only involves a possible compiler warning if you mismatch names) w=
ith
<br>&gt; opt-in strong naming, where the &quot;fun stuff&quot; (argument sk=
ipping, and per
<br>&gt; your question, name-based overloading) requires &#39;strong&#39; n=
aming.
<br>&gt;=20
<br>
<br>Certainly I fully agree that name-based overloading requires &quot;stro=
ng&quot;=20
<br>naming - where the declaration has a new syntax saying that names /must=
/=20
<br>be used in some form, and where the parameter names become part of the=
=20
<br>ABI for the function. =C2=A0(I hope that could be achieved with name=20
<br>mangling, or with types somehow, in order to minimise the implementatio=
n=20
<br>changes needed.)
<br>
<br>I also think that common use, checked with optional compiler warnings=
=20
<br>(which could of course be errors if you choose appropriate compiler=20
<br>flags), can be done with &quot;weak&quot; naming - using parameter name=
s declared=20
<br>as they are today in existing code.
<br></blockquote><div><br></div><div>No, they can&#39;t:</div><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; pad=
ding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1=
px; border-left-style: solid;"><span style=3D"display: inline !important; f=
loat: none; background-color: transparent; color: rgb(34, 34, 34); font-fam=
ily: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; f=
ont-style: normal; font-variant: normal; font-weight: 400; letter-spacing: =
normal; orphans: 2; text-align: left; text-decoration: none; text-indent: 0=
px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: norm=
al; word-spacing: 0px;">What I have established, having had discussions abo=
ut named arguments
</span><br style=3D"background-color: transparent; border-bottom-color: rgb=
(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-i=
mage-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; bor=
der-image-source: none; border-image-width: 1; border-left-color: rgb(34, 3=
4, 34); border-left-style: none; border-left-width: 0px; border-right-color=
: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; borde=
r-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px=
; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;=
Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-v=
ariant: normal; font-weight: 400; letter-spacing: normal; line-height: norm=
al; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0p=
x; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; =
padding-top: 0px; text-align: left; text-decoration: none; text-indent: 0px=
; text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal=
; word-spacing: 0px;"><span style=3D"display: inline !important; float: non=
e; background-color: transparent; color: rgb(34, 34, 34); font-family: &quo=
t;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style=
: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; o=
rphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-=
transform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-=
spacing: 0px;">on multiple occasions,
</span><br style=3D"background-color: transparent; border-bottom-color: rgb=
(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-i=
mage-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; bor=
der-image-source: none; border-image-width: 1; border-left-color: rgb(34, 3=
4, 34); border-left-style: none; border-left-width: 0px; border-right-color=
: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; borde=
r-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px=
; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;=
Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-v=
ariant: normal; font-weight: 400; letter-spacing: normal; line-height: norm=
al; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0p=
x; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; =
padding-top: 0px; text-align: left; text-decoration: none; text-indent: 0px=
; text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal=
; word-spacing: 0px;"><span style=3D"display: inline !important; float: non=
e; background-color: transparent; color: rgb(34, 34, 34); font-family: &quo=
t;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style=
: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; o=
rphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-=
transform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-=
spacing: 0px;">is that the following pain points are important:
</span><br style=3D"background-color: transparent; border-bottom-color: rgb=
(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-i=
mage-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; bor=
der-image-source: none; border-image-width: 1; border-left-color: rgb(34, 3=
4, 34); border-left-style: none; border-left-width: 0px; border-right-color=
: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; borde=
r-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px=
; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;=
Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-v=
ariant: normal; font-weight: 400; letter-spacing: normal; line-height: norm=
al; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0p=
x; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; =
padding-top: 0px; text-align: left; text-decoration: none; text-indent: 0px=
; text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal=
; word-spacing: 0px;"><span style=3D"display: inline !important; float: non=
e; background-color: transparent; color: rgb(34, 34, 34); font-family: &quo=
t;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style=
: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; o=
rphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-=
transform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-=
spacing: 0px;">
</span><br style=3D"background-color: transparent; border-bottom-color: rgb=
(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-i=
mage-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; bor=
der-image-source: none; border-image-width: 1; border-left-color: rgb(34, 3=
4, 34); border-left-style: none; border-left-width: 0px; border-right-color=
: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; borde=
r-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px=
; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;=
Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-v=
ariant: normal; font-weight: 400; letter-spacing: normal; line-height: norm=
al; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0p=
x; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; =
padding-top: 0px; text-align: left; text-decoration: none; text-indent: 0px=
; text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal=
; word-spacing: 0px;"><span style=3D"display: inline !important; float: non=
e; background-color: transparent; color: rgb(34, 34, 34); font-family: &quo=
t;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style=
: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; o=
rphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-=
transform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-=
spacing: 0px;">1) it needs to be an opt-in for the author of a library, so =
no
</span><br style=3D"background-color: transparent; border-bottom-color: rgb=
(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-i=
mage-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; bor=
der-image-source: none; border-image-width: 1; border-left-color: rgb(34, 3=
4, 34); border-left-style: none; border-left-width: 0px; border-right-color=
: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; borde=
r-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px=
; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;=
Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-v=
ariant: normal; font-weight: 400; letter-spacing: normal; line-height: norm=
al; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0p=
x; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; =
padding-top: 0px; text-align: left; text-decoration: none; text-indent: 0px=
; text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal=
; word-spacing: 0px;"><span style=3D"display: inline !important; float: non=
e; background-color: transparent; color: rgb(34, 34, 34); font-family: &quo=
t;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style=
: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; o=
rphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-=
transform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-=
spacing: 0px;">automagic naming. Some library
</span><br style=3D"background-color: transparent; border-bottom-color: rgb=
(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-i=
mage-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; bor=
der-image-source: none; border-image-width: 1; border-left-color: rgb(34, 3=
4, 34); border-left-style: none; border-left-width: 0px; border-right-color=
: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; borde=
r-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px=
; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;=
Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-v=
ariant: normal; font-weight: 400; letter-spacing: normal; line-height: norm=
al; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0p=
x; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; =
padding-top: 0px; text-align: left; text-decoration: none; text-indent: 0px=
; text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal=
; word-spacing: 0px;"><span style=3D"display: inline !important; float: non=
e; background-color: transparent; color: rgb(34, 34, 34); font-family: &quo=
t;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style=
: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; o=
rphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-=
transform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-=
spacing: 0px;">authors do not want users relying on names that the library =
author
</span><br style=3D"background-color: transparent; border-bottom-color: rgb=
(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-i=
mage-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; bor=
der-image-source: none; border-image-width: 1; border-left-color: rgb(34, 3=
4, 34); border-left-style: none; border-left-width: 0px; border-right-color=
: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; borde=
r-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px=
; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;=
Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-v=
ariant: normal; font-weight: 400; letter-spacing: normal; line-height: norm=
al; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0p=
x; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; =
padding-top: 0px; text-align: left; text-decoration: none; text-indent: 0px=
; text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal=
; word-spacing: 0px;"><span style=3D"display: inline !important; float: non=
e; background-color: transparent; color: rgb(34, 34, 34); font-family: &quo=
t;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style=
: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; o=
rphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-=
transform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-=
spacing: 0px;">didn&#39;t expect them to rely
</span><br style=3D"background-color: transparent; border-bottom-color: rgb=
(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-i=
mage-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; bor=
der-image-source: none; border-image-width: 1; border-left-color: rgb(34, 3=
4, 34); border-left-style: none; border-left-width: 0px; border-right-color=
: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; borde=
r-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px=
; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;=
Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-v=
ariant: normal; font-weight: 400; letter-spacing: normal; line-height: norm=
al; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0p=
x; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; =
padding-top: 0px; text-align: left; text-decoration: none; text-indent: 0px=
; text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal=
; word-spacing: 0px;"><span style=3D"display: inline !important; float: non=
e; background-color: transparent; color: rgb(34, 34, 34); font-family: &quo=
t;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style=
: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; o=
rphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-=
transform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-=
spacing: 0px;">on, in order to avoid breakage that wasn&#39;t considered be=
forehand.
</span><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><br></bl=
ockquote><div><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><=
br></div><div>This was suggested back in 1991(!), and rejected!</div><div>W=
e need to drop that idea for good <i>and move on</i>, <i>make some progress=
!</i></div><div><i></i><br></div><div>And no, documenting which arguments a=
re stable API is not good enough.</div><div>C++ is trying for 30 years to f=
ix the need for documentation to <i>use</i> the code (concepts), no one nee=
ds more of it.</div><div><br></div><div>I am saying all this with best inte=
ntions - we need to stop repeating the same mistakes and really, step by st=
ep make <i>some</i> progress.</div><div>Progress in <i>requirements (what w=
e need)</i>, but progress in <i>implementation (how can be done)</i>.</div>=
<div><br></div><div>...</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br></blockquote></div>

<p></p>

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

------=_Part_113_150041763.1534683121641--

------=_Part_112_247342288.1534683121640--

.

------=_Part_1282_1406651092.1534683890571
Content-Type: multipart/alternative;
 boundary="----=_Part_1283_914931803.1534683890571"

------=_Part_1283_914931803.1534683890571
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Sunday, August 19, 2018 at 3:26:12 PM UTC+3, Vicente J. Botet Escriba=20
wrote:
>
> Le 19/08/2018 =C3=A0 10:27, Bo Persson a =C3=A9crit :=20
> > On 2018-08-18 17:09, Vicente J. Botet Escriba wrote:=20
> >>=20
> >>=20
> >>=20
> >> and we could add any syntactic sugar that make it easier to define=20
> >> those tags, and make them even local to the function=20
> >>=20
> >>       void f(@tag1, a:int, b:int);=20
> >>=20
> >>       void f(@tag2, x:int, y:int);=20
> >>=20
> >>=20
> >> Now we can call f using the local tags=20
> >>=20
> >>      f(@tag1, a:=3D1, b:=3D2);=20
> >>      f(@tag2, x:=3D1, y:=3D2);=20
> >>=20
> >> Note that tagx is not associated to any named parameter.=20
> >>=20
> >=20
> > We can of course already do this as f_tag1(1,2) and f_tag2(1,2),=20
> > without changing the language.=20
> >=20
> > What is the advantage of f(@tag1 over f_tag1( ?=20
> Independently of the language feature, using a tag type allows to=20
> transport the tag between different functions. In addition, you cannot=20
> change the class constructor name, so you will need a tag to be able to=
=20
> overload it. Take for example the in_place_t tag.=20
>

I have thoroughly explored that idea a month=20
back: https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2GXb=
0/4OjT5Z4pBQAJ

Feel free to comment there, I am undecided on the topic.=20

=20

>
> Vicente=20
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7d28cd24-b43d-4e24-876b-a04adcbbe867%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Sunday, August 19, 2018 at 3:26:12 PM UTC+3, Vi=
cente J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">L=
e 19/08/2018 =C3=A0 10:27, Bo Persson a =C3=A9crit=C2=A0:
<br>&gt; On 2018-08-18 17:09, Vicente J. Botet Escriba wrote:
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; and we could add any syntactic sugar that make it easier to de=
fine=20
<br>&gt;&gt; those tags, and make them even local to the function
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 void f(@tag1, a:int, b:int);
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 void f(@tag2, x:int, y:int);
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; Now we can call f using the local tags
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f(@tag1, a:=3D1, b:=3D2);
<br>&gt;&gt; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f(@tag2, x:=3D1, y:=3D2);
<br>&gt;&gt;
<br>&gt;&gt; Note that tagx is not associated to any named parameter.
<br>&gt;&gt;
<br>&gt;
<br>&gt; We can of course already do this as f_tag1(1,2) and f_tag2(1,2),=
=20
<br>&gt; without changing the language.
<br>&gt;
<br>&gt; What is the advantage of f(@tag1 over f_tag1( ?
<br>Independently of the language feature, using a tag type allows to=20
<br>transport the tag between different functions. In addition, you cannot=
=20
<br>change the class constructor name, so you will need a tag to be able to=
=20
<br>overload it. Take for example the in_place_t tag.
<br></blockquote><div><br></div><div>I have thoroughly explored that idea a=
 month back:=C2=A0https://groups.google.com/a/isocpp.org/d/msg/std-proposal=
s/tPtdQE2GXb0/4OjT5Z4pBQAJ</div><div><br></div><div>Feel free to comment th=
ere, I am undecided on the topic.=C2=A0</div><div><br></div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">
<br>Vicente
<br></blockquote></div>

<p></p>

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

------=_Part_1283_914931803.1534683890571--

------=_Part_1282_1406651092.1534683890571--

.

This is a multi-part message in MIME format.
--------------34DF01199C664136E42D0CB7
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 19/08/2018 =C3=A0 15:04, mihailnajdenov@gmail.com a =C3=A9crit=C2=A0:
>
>
> On Sunday, August 19, 2018 at 3:26:12 PM UTC+3, Vicente J. Botet=20
> Escriba wrote:
>
>     Independently of the language feature, using a tag type allows to
>     transport the tag between different functions. In addition, you
>     cannot
>     change the class constructor name, so you will need a tag to be
>     able to
>     overload it. Take for example the in_place_t tag.
>
>
> I have thoroughly explored that idea a month=20
> back:=C2=A0https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPt=
dQE2GXb0/4OjT5Z4pBQAJ
>
> Feel free to comment there, I am undecided on the topic.
>
I'm not sure yet we need some syntactic sugar for this tag dispatching=20
feature neither.
I'm just trying to separate the named parameter part from the overload=20
part as orthogonal features.
You go too far for my taste in your proposal and you propose to have all=20
at once. I'll be against such a feature.

Vicente

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/19c6eb56-2188-b849-6ea1-87b37cb546de%40wanadoo.f=
r.

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

<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 19/08/2018 =C3=A0 15:04,
      <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:mihailnajdenov@g=
mail.com">mihailnajdenov@gmail.com</a> a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"
      cite=3D"mid:7d28cd24-b43d-4e24-876b-a04adcbbe867@isocpp.org">
      <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf=
-8">
      <div dir=3D"ltr"><br>
        <br>
        On Sunday, August 19, 2018 at 3:26:12 PM UTC+3, Vicente J. Botet
        Escriba wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Independent=
ly
          of the language feature, using a tag type allows to <br>
          transport the tag between different functions. In addition,
          you cannot <br>
          change the class constructor name, so you will need a tag to
          be able to <br>
          overload it. Take for example the in_place_t tag.
          <br>
        </blockquote>
        <div><br>
        </div>
        <div>I have thoroughly explored that idea a month
back:=C2=A0<a class=3D"moz-txt-link-freetext" href=3D"https://groups.google=
..com/a/isocpp.org/d/msg/std-proposals/tPtdQE2GXb0/4OjT5Z4pBQAJ">https://gro=
ups.google.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2GXb0/4OjT5Z4pBQAJ</a=
></div>
        <div><br>
        </div>
        <div>Feel free to comment there, I am undecided on the topic.=C2=A0=
</div>
        <div><br>
        </div>
        <div>=C2=A0</div>
      </div>
    </blockquote>
    I'm not sure yet we need some syntactic sugar for this tag
    dispatching feature neither.<br>
    I'm just trying to separate the named parameter part from the
    overload part as orthogonal features.<br>
    You go too far for my taste in your proposal and you propose to have
    all at once. I'll be against such a feature.<br>
    <br>
    Vicente<br>
  </body>
</html>

<p></p>

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

--------------34DF01199C664136E42D0CB7--

.

------=_Part_1212_2000730272.1534699372483
Content-Type: multipart/alternative;
 boundary="----=_Part_1213_286806137.1534699372483"

------=_Part_1213_286806137.1534699372483
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Sunday, August 19, 2018 at 7:46:58 PM UTC+3, Vicente J. Botet Escriba=20
wrote:
>
> Le 19/08/2018 =C3=A0 15:04, mihailn...@gmail.com <javascript:> a =C3=A9cr=
it :
>
>
>
> On Sunday, August 19, 2018 at 3:26:12 PM UTC+3, Vicente J. Botet Escriba=
=20
> wrote:=20
>>
>> Independently of the language feature, using a tag type allows to=20
>> transport the tag between different functions. In addition, you cannot=
=20
>> change the class constructor name, so you will need a tag to be able to=
=20
>> overload it. Take for example the in_place_t tag.=20
>>
>
> I have thoroughly explored that idea a month back:=20
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2GXb0/4O=
jT5Z4pBQAJ
>
> Feel free to comment there, I am undecided on the topic.=20
>
> =20
>
> I'm not sure yet we need some syntactic sugar for this tag dispatching=20
> feature neither.
> I'm just trying to separate the named parameter part from the overload=20
> part as orthogonal features.
> You go too far for my taste in your proposal and you propose to have all=
=20
> at once. I'll be against such a feature.
>

Can you elaborate a bit more, what are your expectations and where should a=
=20
line be drawn? As you can see in the comments to the post, there are=20
similar concerns.
In any case it is not a proposal, but an investigation. It is clear tags=20
have overlap with strong names, and if we can get an attractive=20
proposition, based on tags, we can mark at least one part (the harder=20
part?) of the named arguments equation "fixed".=20


> Vicente
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/3fc9fb1a-8803-4bcf-b928-c855e76f880e%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Sunday, August 19, 2018 at 7:46:58 PM UTC+3, Vi=
cente J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>Le 19/08/2018 =C3=A0 15:04,
      <a onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onc=
lick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"javascript:=
" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"oYhg1WhGAAAJ"=
>mihailn...@gmail.com</a> a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
     =20
      <div dir=3D"ltr"><br>
        <br>
        On Sunday, August 19, 2018 at 3:26:12 PM UTC+3, Vicente J. Botet
        Escriba wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">Independently
          of the language feature, using a tag type allows to <br>
          transport the tag between different functions. In addition,
          you cannot <br>
          change the class constructor name, so you will need a tag to
          be able to <br>
          overload it. Take for example the in_place_t tag.
          <br>
        </blockquote>
        <div><br>
        </div>
        <div>I have thoroughly explored that idea a month
back:=C2=A0<a onmousedown=3D"this.href=3D&#39;https://groups.google.com/a/i=
socpp.org/d/msg/std-proposals/tPtdQE2GXb0/4OjT5Z4pBQAJ&#39;;return true;" o=
nclick=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msg/std=
-proposals/tPtdQE2GXb0/4OjT5Z4pBQAJ&#39;;return true;" href=3D"https://grou=
ps.google.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2GXb0/4OjT5Z4pBQAJ" ta=
rget=3D"_blank" rel=3D"nofollow">https://groups.google.<wbr>com/a/isocpp.or=
g/d/msg/std-<wbr>proposals/tPtdQE2GXb0/<wbr>4OjT5Z4pBQAJ</a></div>
        <div><br>
        </div>
        <div>Feel free to comment there, I am undecided on the topic.=C2=A0=
</div>
        <div><br>
        </div>
        <div>=C2=A0</div>
      </div>
    </blockquote>
    I&#39;m not sure yet we need some syntactic sugar for this tag
    dispatching feature neither.<br>
    I&#39;m just trying to separate the named parameter part from the
    overload part as orthogonal features.<br>
    You go too far for my taste in your proposal and you propose to have
    all at once. I&#39;ll be against such a feature.<br></div></blockquote>=
<div><br></div><div>Can you elaborate a bit more, what are your expectation=
s and where should a line be drawn? As you can see in the comments to the p=
ost, there are similar concerns.</div><div>In any case it is not a proposal=
, but an <span style=3D"display: inline !important; float: none; background=
-color: transparent; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;=
,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: normal; fon=
t-variant: normal; font-weight: 400; letter-spacing: normal; orphans: 2; te=
xt-align: left; text-decoration: none; text-indent: 0px; text-transform: no=
ne; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;=
">investigation. </span><span style=3D"display: inline !important; float: n=
one; background-color: transparent; color: rgb(34, 34, 34); font-family: &q=
uot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-sty=
le: normal; font-variant: normal; font-weight: 400; letter-spacing: normal;=
 orphans: 2; text-align: left; text-decoration: none; text-indent: 0px; tex=
t-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; wor=
d-spacing: 0px;">It is clear tags have overlap with strong names, and if we=
 can get an attractive proposition, based on tags, we can mark at least one=
 part (the harder part?) of the named arguments equation &quot;fixed&quot;.=
=C2=A0</span></div><div><span style=3D"display: inline !important; float: n=
one; background-color: transparent; color: rgb(34, 34, 34); font-family: &q=
uot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-sty=
le: normal; font-variant: normal; font-weight: 400; letter-spacing: normal;=
 orphans: 2; text-align: left; text-decoration: none; text-indent: 0px; tex=
t-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; wor=
d-spacing: 0px;"><br></span></div><div></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <br>
    Vicente<br>
  </div>

</blockquote></div>

<p></p>

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

------=_Part_1213_286806137.1534699372483--

------=_Part_1212_2000730272.1534699372483--

.

This is a multi-part message in MIME format.
--------------95C3DFC677CE5BC52F3211C1
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 19/08/2018 =C3=A0 19:22, mihailnajdenov@gmail.com a =C3=A9crit=C2=A0:
>
>
> On Sunday, August 19, 2018 at 7:46:58 PM UTC+3, Vicente J. Botet=20
> Escriba wrote:
>
>     Le 19/08/2018 =C3=A0 15:04, mihailn...@gmail.com <javascript:> a =C3=
=A9crit=C2=A0:
>>
>>
>>     On Sunday, August 19, 2018 at 3:26:12 PM UTC+3, Vicente J. Botet
>>     Escriba wrote:
>>
>>         Independently of the language feature, using a tag type
>>         allows to
>>         transport the tag between different functions. In addition,
>>         you cannot
>>         change the class constructor name, so you will need a tag to
>>         be able to
>>         overload it. Take for example the in_place_t tag.
>>
>>
>>     I have thoroughly explored that idea a month back:
>>     https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2GX=
b0/4OjT5Z4pBQAJ
>>     <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2G=
Xb0/4OjT5Z4pBQAJ>
>>
>>     Feel free to comment there, I am undecided on the topic.
>>
>     I'm not sure yet we need some syntactic sugar for this tag
>     dispatching feature neither.
>     I'm just trying to separate the named parameter part from the
>     overload part as orthogonal features.
>     You go too far for my taste in your proposal and you propose to
>     have all at once. I'll be against such a feature.
>
>
> Can you elaborate a bit more, what are your expectations and where=20
> should a line be drawn? As you can see in the comments to the post,=20
> there are similar concerns.
> In any case it is not a proposal, but an investigation. It is clear=20
> tags have overlap with strong names, and if we can get an attractive=20
> proposition, based on tags, we can mark at least one part (the harder=20
> part?) of the named arguments equation "fixed".
>
I would like to see the two features proposed independently.

I see more added value for weak named parameters that are optional and=20
opt in on the author side (as the workarounds are not always friendly)=20
than the strong named parameters that can be used to overload function=20
or constructors and that are not optional (as tag types are an almost=20
friendly library solution, as the standard library has showed already=20
multiple times).

Vicente

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/01a106d3-cdaa-e348-2275-4222eed34dda%40wanadoo.f=
r.

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

<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 19/08/2018 =C3=A0 19:22,
      <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:mihailnajdenov@g=
mail.com">mihailnajdenov@gmail.com</a> a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"
      cite=3D"mid:3fc9fb1a-8803-4bcf-b928-c855e76f880e@isocpp.org">
      <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf=
-8">
      <div dir=3D"ltr"><br>
        <br>
        On Sunday, August 19, 2018 at 7:46:58 PM UTC+3, Vicente J. Botet
        Escriba wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
            <div>Le 19/08/2018 =C3=A0 15:04, <a
                onmousedown=3D"this.href=3D'javascript:';return true;"
                onclick=3D"this.href=3D'javascript:';return true;"
                href=3D"javascript:" target=3D"_blank" rel=3D"nofollow"
                gdf-obfuscated-mailto=3D"oYhg1WhGAAAJ"
                moz-do-not-send=3D"true">mihailn...@gmail.com</a> a
              =C3=A9crit=C2=A0:<br>
            </div>
            <blockquote type=3D"cite">
              <div dir=3D"ltr"><br>
                <br>
                On Sunday, August 19, 2018 at 3:26:12 PM UTC+3, Vicente
                J. Botet Escriba wrote:
                <blockquote class=3D"gmail_quote"
                  style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
                  solid;padding-left:1ex">Independently of the language
                  feature, using a tag type allows to <br>
                  transport the tag between different functions. In
                  addition, you cannot <br>
                  change the class constructor name, so you will need a
                  tag to be able to <br>
                  overload it. Take for example the in_place_t tag. <br>
                </blockquote>
                <div><br>
                </div>
                <div>I have thoroughly explored that idea a month
                  back:=C2=A0<a
onmousedown=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msg/st=
d-proposals/tPtdQE2GXb0/4OjT5Z4pBQAJ';return
                    true;"
onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msg/std-pr=
oposals/tPtdQE2GXb0/4OjT5Z4pBQAJ';return
                    true;"
href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2G=
Xb0/4OjT5Z4pBQAJ"
                    target=3D"_blank" rel=3D"nofollow"
                    moz-do-not-send=3D"true">https://groups.google.<wbr>com=
/a/isocpp.org/d/msg/std-<wbr>proposals/tPtdQE2GXb0/<wbr>4OjT5Z4pBQAJ</a></d=
iv>
                <div><br>
                </div>
                <div>Feel free to comment there, I am undecided on the
                  topic.=C2=A0</div>
                <div><br>
                </div>
                <div>=C2=A0</div>
              </div>
            </blockquote>
            I'm not sure yet we need some syntactic sugar for this tag
            dispatching feature neither.<br>
            I'm just trying to separate the named parameter part from
            the overload part as orthogonal features.<br>
            You go too far for my taste in your proposal and you propose
            to have all at once. I'll be against such a feature.<br>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>Can you elaborate a bit more, what are your expectations
          and where should a line be drawn? As you can see in the
          comments to the post, there are similar concerns.</div>
        <div>In any case it is not a proposal, but an <span
            style=3D"display: inline !important; float: none;
            background-color: transparent; color: rgb(34, 34, 34);
            font-family:
            &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;
            font-size: 13px; font-style: normal; font-variant: normal;
            font-weight: 400; letter-spacing: normal; orphans: 2;
            text-align: left; text-decoration: none; text-indent: 0px;
            text-transform: none; -webkit-text-stroke-width: 0px;
            white-space: normal; word-spacing: 0px;">investigation. </span>=
<span
            style=3D"display: inline !important; float: none;
            background-color: transparent; color: rgb(34, 34, 34);
            font-family:
            &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;
            font-size: 13px; font-style: normal; font-variant: normal;
            font-weight: 400; letter-spacing: normal; orphans: 2;
            text-align: left; text-decoration: none; text-indent: 0px;
            text-transform: none; -webkit-text-stroke-width: 0px;
            white-space: normal; word-spacing: 0px;">It is clear tags
            have overlap with strong names, and if we can get an
            attractive proposition, based on tags, we can mark at least
            one part (the harder part?) of the named arguments equation
            "fixed".=C2=A0</span></div>
        <div><span style=3D"display: inline !important; float: none;
            background-color: transparent; color: rgb(34, 34, 34);
            font-family:
            &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;
            font-size: 13px; font-style: normal; font-variant: normal;
            font-weight: 400; letter-spacing: normal; orphans: 2;
            text-align: left; text-decoration: none; text-indent: 0px;
            text-transform: none; -webkit-text-stroke-width: 0px;
            white-space: normal; word-spacing: 0px;"><br>
          </span></div>
      </div>
    </blockquote>
    I would like to see the two features proposed independently. <br>
    <br>
    I see more added value for weak named parameters that are optional
    and opt in on the author side (as the workarounds are not always
    friendly) than the strong named parameters that can be used to
    overload function or constructors and that are not optional (as tag
    types are an almost friendly library solution, as the standard
    library has showed already multiple times).<br>
    <br>
    Vicente<br>
  </body>
</html>

<p></p>

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

--------------95C3DFC677CE5BC52F3211C1--

.

------=_Part_255_475640907.1534715637401
Content-Type: multipart/alternative;
 boundary="----=_Part_256_2020530968.1534715637401"

------=_Part_256_2020530968.1534715637401
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Sunday, August 19, 2018 at 5:21:11 PM UTC-4, Vicente J. Botet Escriba=20
wrote:
>
> Le 19/08/2018 =C3=A0 19:22, mihailn...@gmail.com <javascript:> a =C3=A9cr=
it :
>
>
>
> On Sunday, August 19, 2018 at 7:46:58 PM UTC+3, Vicente J. Botet Escriba=
=20
> wrote:=20
>>
>> Le 19/08/2018 =C3=A0 15:04, mihailn...@gmail.com a =C3=A9crit :
>>
>>
>>
>> On Sunday, August 19, 2018 at 3:26:12 PM UTC+3, Vicente J. Botet Escriba=
=20
>> wrote:=20
>>>
>>> Independently of the language feature, using a tag type allows to=20
>>> transport the tag between different functions. In addition, you cannot=
=20
>>> change the class constructor name, so you will need a tag to be able to=
=20
>>> overload it. Take for example the in_place_t tag.=20
>>>
>>
>> I have thoroughly explored that idea a month back:=20
>> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2GXb0/4=
OjT5Z4pBQAJ
>>
>> Feel free to comment there, I am undecided on the topic.=20
>>
>> =20
>>
>> I'm not sure yet we need some syntactic sugar for this tag dispatching=
=20
>> feature neither.
>> I'm just trying to separate the named parameter part from the overload=
=20
>> part as orthogonal features.
>> You go too far for my taste in your proposal and you propose to have all=
=20
>> at once. I'll be against such a feature.
>>
>
> Can you elaborate a bit more, what are your expectations and where should=
=20
> a line be drawn? As you can see in the comments to the post, there are=20
> similar concerns.
> In any case it is not a proposal, but an investigation. It is clear tags=
=20
> have overlap with strong names, and if we can get an attractive=20
> proposition, based on tags, we can mark at least one part (the harder=20
> part?) of the named arguments equation "fixed".=20
>
> I would like to see the two features proposed independently.=20
>
> I see more added value for weak named parameters that are optional and op=
t=20
> in on the author side (as the workarounds are not always friendly) than t=
he=20
> strong named parameters that can be used to overload function or=20
> constructors and that are not optional (as tag types are an almost friend=
ly=20
> library solution, as the standard library has showed already multiple=20
> times).
>

The problem with having them be independent is that they're *not*=20
independent. They're both playing around in the same space: invoking a=20
parameter's name when you call the function.

The first question any named parameter proposal has to answer is whether to=
=20
rely on the existing parameter name infrastructure or to use a special way=
=20
to define them. There are arguments for both weak and strong parameters to=
=20
want to have syntax to declare named parameters on a function. This is=20
because, by having users rely on them to some degree (even if mis-matched=
=20
naming is just a warning), you are making those parameter names part of the=
=20
interface of the API. And that's different from how parameter names have=20
been treated in the past.

If you try to develop weak and strong parameters completely independently,=
=20
then what you can end up with are two proposals that provide completely=20
different ways of declaring such parameters. And considering all of the=20
stuff that we keep cramming into function declarations these days, giving=
=20
parameters *three names* is utterly absurd. Even if you forbid weak=20
parameter names on functions with strong names, that's still 3 separate=20
syntaxes for declaring parameter names.

So I don't think it's reasonable to develop the two proposals completely=20
independently from one another. They should at least be developed with the=
=20
knowledge that the other is a possibility, and with syntax that can=20
reasonably fit together.

Lastly, it should be noted that tagged dispatch doesn't help with what I=20
will refer to as "mega-functions": functions that take stupidly large=20
numbers of relatively independent parameters, but for some reason don't=20
want to take them as a convenient aggregate. This is a use case that some=
=20
people want to support, to avoid conceptual two-stage construction.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/67ab8a8c-4a0c-4b4f-8ea1-56822e660517%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Sunday, August 19, 2018 at 5:21:11 PM UTC-4, Vi=
cente J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div>Le 19/08/2018 =C3=A0 19:22,
      <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"5m=
g_tV9VAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#3=
9;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;"=
>mihailn...@gmail.com</a> a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
     =20
      <div dir=3D"ltr"><br>
        <br>
        On Sunday, August 19, 2018 at 7:46:58 PM UTC+3, Vicente J. Botet
        Escriba wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
            <div>Le 19/08/2018 =C3=A0 15:04, <a rel=3D"nofollow">mihailn...=
@gmail.com</a> a
              =C3=A9crit=C2=A0:<br>
            </div>
            <blockquote type=3D"cite">
              <div dir=3D"ltr"><br>
                <br>
                On Sunday, August 19, 2018 at 3:26:12 PM UTC+3, Vicente
                J. Botet Escriba wrote:
                <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Independently of th=
e language
                  feature, using a tag type allows to <br>
                  transport the tag between different functions. In
                  addition, you cannot <br>
                  change the class constructor name, so you will need a
                  tag to be able to <br>
                  overload it. Take for example the in_place_t tag. <br>
                </blockquote>
                <div><br>
                </div>
                <div>I have thoroughly explored that idea a month
                  back:=C2=A0<a href=3D"https://groups.google.com/a/isocpp.=
org/d/msg/std-proposals/tPtdQE2GXb0/4OjT5Z4pBQAJ" rel=3D"nofollow" target=
=3D"_blank" onmousedown=3D"this.href=3D&#39;https://groups.google.com/a/iso=
cpp.org/d/msg/std-proposals/tPtdQE2GXb0/4OjT5Z4pBQAJ&#39;;return true;" onc=
lick=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msg/std-p=
roposals/tPtdQE2GXb0/4OjT5Z4pBQAJ&#39;;return true;">https://groups.google.=
<wbr>com/a/isocpp.org/d/msg/std-<wbr>proposals/tPtdQE2GXb0/<wbr>4OjT5Z4pBQA=
J</a></div>
                <div><br>
                </div>
                <div>Feel free to comment there, I am undecided on the
                  topic.=C2=A0</div>
                <div><br>
                </div>
                <div>=C2=A0</div>
              </div>
            </blockquote>
            I&#39;m not sure yet we need some syntactic sugar for this tag
            dispatching feature neither.<br>
            I&#39;m just trying to separate the named parameter part from
            the overload part as orthogonal features.<br>
            You go too far for my taste in your proposal and you propose
            to have all at once. I&#39;ll be against such a feature.<br>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>Can you elaborate a bit more, what are your expectations
          and where should a line be drawn? As you can see in the
          comments to the post, there are similar concerns.</div>
        <div>In any case it is not a proposal, but an <span style=3D"displa=
y:inline!important;float:none;background-color:transparent;color:rgb(34,34,=
34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-siz=
e:13px;font-style:normal;font-variant:normal;font-weight:400;letter-spacing=
:normal;text-align:left;text-decoration:none;text-indent:0px;text-transform=
:none;white-space:normal;word-spacing:0px">investigation. </span><span styl=
e=3D"display:inline!important;float:none;background-color:transparent;color=
:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-ser=
if;font-size:13px;font-style:normal;font-variant:normal;font-weight:400;let=
ter-spacing:normal;text-align:left;text-decoration:none;text-indent:0px;tex=
t-transform:none;white-space:normal;word-spacing:0px">It is clear tags
            have overlap with strong names, and if we can get an
            attractive proposition, based on tags, we can mark at least
            one part (the harder part?) of the named arguments equation
            &quot;fixed&quot;.=C2=A0</span></div>
        <div><span style=3D"display:inline!important;float:none;background-=
color:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;H=
elvetica&quot;,sans-serif;font-size:13px;font-style:normal;font-variant:nor=
mal;font-weight:400;letter-spacing:normal;text-align:left;text-decoration:n=
one;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px=
"><br>
          </span></div>
      </div>
    </blockquote>
    I would like to see the two features proposed independently. <br>
    <br>
    I see more added value for weak named parameters that are optional
    and opt in on the author side (as the workarounds are not always
    friendly) than the strong named parameters that can be used to
    overload function or constructors and that are not optional (as tag
    types are an almost friendly library solution, as the standard
    library has showed already multiple times).<br></div></blockquote><div>=
<br></div><div>The problem with having them be independent is that they&#39=
;re <i>not</i> independent. They&#39;re both playing around in the same spa=
ce: invoking a parameter&#39;s name when you call the function.</div><div><=
br></div><div>The first question any named parameter proposal has to answer=
 is whether to rely on the existing parameter name infrastructure or to use=
 a special way to define them. There are arguments for both weak and strong=
 parameters to want to have syntax to declare named parameters on a functio=
n. This is because, by having users rely on them to some degree (even if mi=
s-matched naming is just a warning), you are making those parameter names p=
art of the interface of the API. And that&#39;s different from how paramete=
r names have been treated in the past.</div><div><br></div><div>If you try =
to develop weak and strong parameters completely independently, then what y=
ou can end up with are two proposals that provide completely different ways=
 of declaring such parameters. And considering all of the stuff that we kee=
p cramming into function declarations these days, giving parameters <i>thre=
e names</i> is utterly absurd. Even if you forbid weak parameter names on f=
unctions with strong names, that&#39;s still 3 separate syntaxes for declar=
ing parameter names.</div><div><br></div><div>So I don&#39;t think it&#39;s=
 reasonable to develop the two proposals completely independently from one =
another. They should at least be developed with the knowledge that the othe=
r is a possibility, and with syntax that can reasonably fit together.</div>=
<div><br></div><div>Lastly, it should be noted that tagged dispatch doesn&#=
39;t help with what I will refer to as &quot;mega-functions&quot;: function=
s that take stupidly large numbers of relatively independent parameters, bu=
t for some reason don&#39;t want to take them as a convenient aggregate. Th=
is is a use case that some people want to support, to avoid conceptual two-=
stage construction.<br></div></div>

<p></p>

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

------=_Part_256_2020530968.1534715637401--

------=_Part_255_475640907.1534715637401--

.

------=_Part_1254_291950823.1534717937153
Content-Type: text/plain; charset="UTF-8"

We already have a form of weak named parameters readily available in the form of /*parameter_name=*/value comments in combination with the clang-tidy bugprone-argument-comment check or similar functionality in other tools.

A mechanism that only warns and doesn't support forwarding/metaprogramming does not seem to me to provide much value over what we already have.

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

------=_Part_1254_291950823.1534717937153--

.

------=_Part_181_1223184789.1534720183625
Content-Type: multipart/alternative;
 boundary="----=_Part_182_1805299970.1534720183625"

------=_Part_182_1805299970.1534720183625
Content-Type: text/plain; charset="UTF-8"



On Sunday, August 19, 2018 at 6:32:17 PM UTC-4, Jeremy Maitin-Shepard wrote:
>
> We already have a form of weak named parameters readily available in the
> form of /*parameter_name=*/value comments in combination with the
> clang-tidy bugprone-argument-comment check or similar functionality in
> other tools.
>
> A mechanism that only warns and doesn't support forwarding/metaprogramming
> does not seem to me to provide much value over what we already have.
>

And how would you propose to make "forwarding/metaprogramming" work with
weak parameters? You can draw up a couple of simplistic cases that a
compiler can peek through, but you can't come up with a coherent set of
rules that work everywhere. And when I say "rules", I don't mean English
text or "something like this"; I mean something approaching standards
wording.

The fundamental issue with forwarding is about the transmission of
information from source to destination. Strong parameter proposals transmit
information in some explicit way: maybe it's a struct with known parameters
or the names are themselves parameters or something else. Most strong
parameter proposals handle parameter names in in ways C++ already
understands.

With strong parameters, `emplace(val: 2)` compiles when `emplace(2)` does
not because of normal C++ reasons. You're instantiating two different
functions, with different sets of parameters, which therefore can have
different behaviors.

Weak named parameters are intended to be purely notation information.
Therefore, `emplace(val: 2)` must instantiate and execute the same template
as `emplace(2)` does. Since the information is not passed in a channel that
C++ currently understands, you now have to create an entirely new channel
of information, which is somehow attached to a parameter yet otherwise is
undetectable by anything that isn't the compiler. One which allows such
intermediary functions to pass such named parameters to logging or other
functions without causing a compile error.

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

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

<div dir=3D"ltr"><br><br>On Sunday, August 19, 2018 at 6:32:17 PM UTC-4, Je=
remy Maitin-Shepard wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">We a=
lready have a form of weak named parameters readily available in the form o=
f /*parameter_name=3D*/value comments in combination with the clang-tidy bu=
gprone-argument-comment check or similar functionality in other tools.<p>A =
mechanism that only warns and doesn&#39;t support forwarding/metaprogrammin=
g does not seem to me to provide much value over what we already have.</p><=
/blockquote><div><br></div><div>And how would you propose to make &quot;for=
warding/metaprogramming&quot; work with weak parameters? You can draw up a =
couple of simplistic cases that a compiler can peek through, but you can&#3=
9;t come up with a coherent set of rules that work everywhere. And when I s=
ay &quot;rules&quot;, I don&#39;t mean English text or &quot;something like=
 this&quot;; I mean something approaching standards wording.<br></div><div>=
<br></div><div>The fundamental issue with forwarding is about the transmiss=
ion of information from source to destination. Strong parameter proposals t=
ransmit information in some explicit way: maybe it&#39;s a struct with know=
n parameters or the names are themselves parameters or something else. Most=
 strong parameter proposals handle parameter names in in ways C++ already u=
nderstands.</div><div><br></div><div>With strong parameters, `emplace(val: =
2)` compiles when `emplace(2)` does not because of normal C++ reasons. You&=
#39;re instantiating two different functions, with different sets of parame=
ters, which therefore can have different behaviors.<br></div><div><br></div=
><div>Weak named parameters are intended to be purely notation information.=
 Therefore, `emplace(val: 2)` must instantiate and execute the same templat=
e as `emplace(2)` does. Since the information is not passed in a channel th=
at C++ currently understands, you now have to create an entirely new channe=
l of information, which is somehow attached to a parameter yet otherwise is=
 undetectable by anything that isn&#39;t the compiler. One which allows suc=
h intermediary functions to pass such named parameters to logging or other =
functions without causing a compile error.<br></div></div>

<p></p>

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

------=_Part_182_1805299970.1534720183625--

------=_Part_181_1223184789.1534720183625--

.

------=_Part_1282_1139113941.1534741879909
Content-Type: text/plain; charset="UTF-8"

Yes, it seems to me that weak named parameters are inherently incompatible with forwarding and metaprogramming, and for that reason I'm not really in favor of a weak named parameters mechanism being standardized.

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

------=_Part_1282_1139113941.1534741879909--

.

This is a multi-part message in MIME format.
--------------E52C0ED5BB681DCFBF13D497
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 20/08/2018 =C3=A0 00:32, Jeremy Maitin-Shepard a =C3=A9crit=C2=A0:
> We already have a form of weak named parameters readily available in the =
form of /*parameter_name=3D*/value comments in combination with the clang-t=
idy bugprone-argument-comment check or similar functionality in other tools=
..
>
> A mechanism that only warns and doesn't support forwarding/metaprogrammin=
g does not seem to me to provide much value over what we already have.
>
If you find the clang tidy check is useful, the added value is that I=20
wouldn't need clang-tidy to check for it and we would have the feature=20
available with all the compliant compilers :)

I don't like these kind of comments. We could instead use attributes,=20
but they are too heavyweight to my taste.


Vicente

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2cb1c0c1-ff00-6864-b8bd-d0a708b5e504%40wanadoo.f=
r.

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

<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 20/08/2018 =C3=A0 00:32, Jeremy
      Maitin-Shepard a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"
      cite=3D"mid:31183044-e1e9-401f-812a-8f2e9b610b14@isocpp.org">
      <pre wrap=3D"">We already have a form of weak named parameters readil=
y available in the form of /*parameter_name=3D*/value comments in combinati=
on with the clang-tidy bugprone-argument-comment check or similar functiona=
lity in other tools.

A mechanism that only warns and doesn't support forwarding/metaprogramming =
does not seem to me to provide much value over what we already have.

</pre>
    </blockquote>
    <p><font size=3D"+1">If you find the clang tidy check is useful, the
        added value is that I wouldn't need clang-tidy to check for it
        and we would have the feature available with all the compliant
        compilers :)</font></p>
    <p><font size=3D"+1">I don't like these kind of comments. We could
        instead use attributes, but they are too heavyweight to my
        taste.<br>
      </font></p>
    <p><font size=3D"+1"><br>
      </font></p>
    <p><font size=3D"+1">Vicente</font><br>
    </p>
  </body>
</html>

<p></p>

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

--------------E52C0ED5BB681DCFBF13D497--

.

This is a multi-part message in MIME format.
--------------62004325443AD5CA29F009A9
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 19/08/2018 =C3=A0 23:53, Nicol Bolas a =C3=A9crit=C2=A0:
>
>
> On Sunday, August 19, 2018 at 5:21:11 PM UTC-4, Vicente J. Botet=20
> Escriba wrote:
>
>     Le 19/08/2018 =C3=A0 19:22, mihailn...@gmail.com <javascript:> a =C3=
=A9crit=C2=A0:
>>
>>
>>     On Sunday, August 19, 2018 at 7:46:58 PM UTC+3, Vicente J. Botet
>>     Escriba wrote:
>>
>>         Le 19/08/2018 =C3=A0 15:04, mihailn...@gmail.com a =C3=A9crit=C2=
=A0:
>>>
>>>
>>>         On Sunday, August 19, 2018 at 3:26:12 PM UTC+3, Vicente J.
>>>         Botet Escriba wrote:
>>>
>>>             Independently of the language feature, using a tag type
>>>             allows to
>>>             transport the tag between different functions. In
>>>             addition, you cannot
>>>             change the class constructor name, so you will need a
>>>             tag to be able to
>>>             overload it. Take for example the in_place_t tag.
>>>
>>>
>>>         I have thoroughly explored that idea a month back:
>>>         https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPtd=
QE2GXb0/4OjT5Z4pBQAJ
>>>         <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPt=
dQE2GXb0/4OjT5Z4pBQAJ>
>>>
>>>         Feel free to comment there, I am undecided on the topic.
>>>
>>         I'm not sure yet we need some syntactic sugar for this tag
>>         dispatching feature neither.
>>         I'm just trying to separate the named parameter part from the
>>         overload part as orthogonal features.
>>         You go too far for my taste in your proposal and you propose
>>         to have all at once. I'll be against such a feature.
>>
>>
>>     Can you elaborate a bit more, what are your expectations and
>>     where should a line be drawn? As you can see in the comments to
>>     the post, there are similar concerns.
>>     In any case it is not a proposal, but an investigation. It is
>>     clear tags have overlap with strong names, and if we can get an
>>     attractive proposition, based on tags, we can mark at least one
>>     part (the harder part?) of the named arguments equation "fixed".
>>
>     I would like to see the two features proposed independently.
>
>     I see more added value for weak named parameters that are optional
>     and opt in on the author side (as the workarounds are not always
>     friendly) than the strong named parameters that can be used to
>     overload function or constructors and that are not optional (as
>     tag types are an almost friendly library solution, as the standard
>     library has showed already multiple times).
>
>
> The problem with having them be independent is that they're /not/=20
> independent. They're both playing around in the same space: invoking a=20
> parameter's name when you call the function.
>
> The first question any named parameter proposal has to answer is=20
> whether to rely on the existing parameter name infrastructure or to=20
> use a special way to define them. There are arguments for both weak=20
> and strong parameters to want to have syntax to declare named=20
> parameters on a function. This is because, by having users rely on=20
> them to some degree (even if mis-matched naming is just a warning),=20
> you are making those parameter names part of the interface of the API.=20
> And that's different from how parameter names have been treated in the=20
> past.
I'm not for strong named parameters. For me, this is a disguised form of=20
mixing weak named parameters and tag dispatching. This is why I believe=20
the features are independent.
Now you can put them together and obtain named parameters and tag dispatch.
>
> If you try to develop weak and strong parameters completely=20
> independently, then what you can end up with are two proposals that=20
> provide completely different ways of declaring such parameters. And=20
> considering all of the stuff that we keep cramming into function=20
> declarations these days, giving parameters /three names/ is utterly=20
> absurd. Even if you forbid weak parameter names on functions with=20
> strong names, that's still 3 separate syntaxes for declaring parameter=20
> names.
If we want weak and strong named parameters and don't see another=20
solution than having two syntaxes :(

I don't believe that we want non op in named parametrs, so each one of=20
the weak/strong alternatives would need a specific syntax.

>
> So I don't think it's reasonable to develop the two proposals=20
> completely independently from one another. They should at least be=20
> developed with the knowledge that the other is a possibility, and with=20
> syntax that can reasonably fit together.
Maybe you are right, but I would like that the proposal are clearly=20
separated, so that we can be agains one from or the other.
>
> Lastly, it should be noted that tagged dispatch doesn't help with what=20
> I will refer to as "mega-functions": functions that take stupidly=20
> large numbers of relatively independent parameters, but for some=20
> reason don't want to take them as a convenient aggregate. This is a=20
> use case that some people want to support, to avoid conceptual=20
> two-stage construction.
IMHO, this case is covered by weak named parameters already.
If you accept that your signature changes and require that the argument=20
must be named, strong named parameters could as well cover it.

If you don't accept that your signature changes and require that the=20
argument must be named, weak named parameters + some static analysis=20
tool (as clang-tidy) help could as well cover it (but not that the=20
syantax will be already defined by the standard).

Maybe we need strong named parameters that don't change the signatures=20
as well ;-)

Vicente

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/0d02cfac-0504-62d2-9835-b400daff972b%40wanadoo.f=
r.

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

<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 19/08/2018 =C3=A0 23:53, Nicol Bolas =
a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"
      cite=3D"mid:67ab8a8c-4a0c-4b4f-8ea1-56822e660517@isocpp.org">
      <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf=
-8">
      <div dir=3D"ltr"><br>
        <br>
        On Sunday, August 19, 2018 at 5:21:11 PM UTC-4, Vicente J. Botet
        Escriba wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div text=3D"#000000" bgcolor=3D"#FFFFFF">
            <div>Le 19/08/2018 =C3=A0 19:22, <a href=3D"javascript:"
                target=3D"_blank" gdf-obfuscated-mailto=3D"5mg_tV9VAAAJ"
                rel=3D"nofollow"
                onmousedown=3D"this.href=3D'javascript:';return true;"
                onclick=3D"this.href=3D'javascript:';return true;"
                moz-do-not-send=3D"true">mihailn...@gmail.com</a> a
              =C3=A9crit=C2=A0:<br>
            </div>
            <blockquote type=3D"cite">
              <div dir=3D"ltr"><br>
                <br>
                On Sunday, August 19, 2018 at 7:46:58 PM UTC+3, Vicente
                J. Botet Escriba wrote:
                <blockquote class=3D"gmail_quote"
                  style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
                  solid;padding-left:1ex">
                  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
                    <div>Le 19/08/2018 =C3=A0 15:04, <a rel=3D"nofollow"
                        moz-do-not-send=3D"true">mihailn...@gmail.com</a>
                      a =C3=A9crit=C2=A0:<br>
                    </div>
                    <blockquote type=3D"cite">
                      <div dir=3D"ltr"><br>
                        <br>
                        On Sunday, August 19, 2018 at 3:26:12 PM UTC+3,
                        Vicente J. Botet Escriba wrote:
                        <blockquote class=3D"gmail_quote"
                          style=3D"margin:0;margin-left:0.8ex;border-left:1=
px
                          #ccc solid;padding-left:1ex">Independently of
                          the language feature, using a tag type allows
                          to <br>
                          transport the tag between different functions.
                          In addition, you cannot <br>
                          change the class constructor name, so you will
                          need a tag to be able to <br>
                          overload it. Take for example the in_place_t
                          tag. <br>
                        </blockquote>
                        <div><br>
                        </div>
                        <div>I have thoroughly explored that idea a
                          month back:=C2=A0<a
href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2G=
Xb0/4OjT5Z4pBQAJ"
                            rel=3D"nofollow" target=3D"_blank"
onmousedown=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msg/st=
d-proposals/tPtdQE2GXb0/4OjT5Z4pBQAJ';return
                            true;"
onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msg/std-pr=
oposals/tPtdQE2GXb0/4OjT5Z4pBQAJ';return
                            true;" moz-do-not-send=3D"true">https://groups.=
google.<wbr>com/a/isocpp.org/d/msg/std-<wbr>proposals/tPtdQE2GXb0/<wbr>4OjT=
5Z4pBQAJ</a></div>
                        <div><br>
                        </div>
                        <div>Feel free to comment there, I am undecided
                          on the topic.=C2=A0</div>
                        <div><br>
                        </div>
                        <div>=C2=A0</div>
                      </div>
                    </blockquote>
                    I'm not sure yet we need some syntactic sugar for
                    this tag dispatching feature neither.<br>
                    I'm just trying to separate the named parameter part
                    from the overload part as orthogonal features.<br>
                    You go too far for my taste in your proposal and you
                    propose to have all at once. I'll be against such a
                    feature.<br>
                  </div>
                </blockquote>
                <div><br>
                </div>
                <div>Can you elaborate a bit more, what are your
                  expectations and where should a line be drawn? As you
                  can see in the comments to the post, there are similar
                  concerns.</div>
                <div>In any case it is not a proposal, but an <span
style=3D"display:inline!important;float:none;background-color:transparent;c=
olor:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans=
-serif;font-size:13px;font-style:normal;font-variant:normal;font-weight:400=
;letter-spacing:normal;text-align:left;text-decoration:none;text-indent:0px=
;text-transform:none;white-space:normal;word-spacing:0px">investigation.
                  </span><span
style=3D"display:inline!important;float:none;background-color:transparent;c=
olor:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans=
-serif;font-size:13px;font-style:normal;font-variant:normal;font-weight:400=
;letter-spacing:normal;text-align:left;text-decoration:none;text-indent:0px=
;text-transform:none;white-space:normal;word-spacing:0px">It
                    is clear tags have overlap with strong names, and if
                    we can get an attractive proposition, based on tags,
                    we can mark at least one part (the harder part?) of
                    the named arguments equation "fixed".=C2=A0</span></div=
>
                <div><span
style=3D"display:inline!important;float:none;background-color:transparent;c=
olor:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans=
-serif;font-size:13px;font-style:normal;font-variant:normal;font-weight:400=
;letter-spacing:normal;text-align:left;text-decoration:none;text-indent:0px=
;text-transform:none;white-space:normal;word-spacing:0px"><br>
                  </span></div>
              </div>
            </blockquote>
            I would like to see the two features proposed independently.
            <br>
            <br>
            I see more added value for weak named parameters that are
            optional and opt in on the author side (as the workarounds
            are not always friendly) than the strong named parameters
            that can be used to overload function or constructors and
            that are not optional (as tag types are an almost friendly
            library solution, as the standard library has showed already
            multiple times).<br>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>The problem with having them be independent is that they're
          <i>not</i> independent. They're both playing around in the
          same space: invoking a parameter's name when you call the
          function.</div>
        <div><br>
        </div>
        <div>The first question any named parameter proposal has to
          answer is whether to rely on the existing parameter name
          infrastructure or to use a special way to define them. There
          are arguments for both weak and strong parameters to want to
          have syntax to declare named parameters on a function. This is
          because, by having users rely on them to some degree (even if
          mis-matched naming is just a warning), you are making those
          parameter names part of the interface of the API. And that's
          different from how parameter names have been treated in the
          past.</div>
      </div>
    </blockquote>
    I'm not for strong named parameters. For me, this is a disguised
    form of mixing weak named parameters and tag dispatching. This is
    why I believe the features are independent.<br>
    Now you can put them together and obtain named parameters and tag
    dispatch.<br>
    <blockquote type=3D"cite"
      cite=3D"mid:67ab8a8c-4a0c-4b4f-8ea1-56822e660517@isocpp.org">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>If you try to develop weak and strong parameters completely
          independently, then what you can end up with are two proposals
          that provide completely different ways of declaring such
          parameters. And considering all of the stuff that we keep
          cramming into function declarations these days, giving
          parameters <i>three names</i> is utterly absurd. Even if you
          forbid weak parameter names on functions with strong names,
          that's still 3 separate syntaxes for declaring parameter
          names.</div>
      </div>
    </blockquote>
    If we want weak and strong named parameters and don't see another
    solution than having two syntaxes :(<br>
    <br>
    I don't believe that we want non op in named parametrs, so each one
    of the weak/strong alternatives would need a specific syntax.<br>
    <br>
    <blockquote type=3D"cite"
      cite=3D"mid:67ab8a8c-4a0c-4b4f-8ea1-56822e660517@isocpp.org">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>So I don't think it's reasonable to develop the two
          proposals completely independently from one another. They
          should at least be developed with the knowledge that the other
          is a possibility, and with syntax that can reasonably fit
          together.</div>
      </div>
    </blockquote>
    Maybe you are right, but I would like that the proposal are clearly
    separated, so that we can be agains one from or the other.<br>
    <blockquote type=3D"cite"
      cite=3D"mid:67ab8a8c-4a0c-4b4f-8ea1-56822e660517@isocpp.org">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>Lastly, it should be noted that tagged dispatch doesn't
          help with what I will refer to as "mega-functions": functions
          that take stupidly large numbers of relatively independent
          parameters, but for some reason don't want to take them as a
          convenient aggregate. This is a use case that some people want
          to support, to avoid conceptual two-stage construction.<br>
        </div>
      </div>
    </blockquote>
    IMHO, this case is covered by weak named parameters already.=C2=A0 <br>
    If you accept that your signature changes and require that the
    argument must be named, strong named parameters could as well cover
    it.<br>
    <br>
    If you don't accept that your signature changes and require that the
    argument must be named, weak named parameters + some static analysis
    tool (as clang-tidy) help could as well cover it (but not that the
    syantax will be already defined by the standard).<br>
    <br>
    Maybe we need strong named parameters that don't change the
    signatures as well ;-)<br>
    <br>
    Vicente
  </body>
</html>

<p></p>

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

--------------62004325443AD5CA29F009A9--

.

This is a multi-part message in MIME format.
--------------3DFBE57ABCFC7BC72C9C125A
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 19/08/2018 =C3=A0 23:53, Nicol Bolas a =C3=A9crit=C2=A0:
>
>
> On Sunday, August 19, 2018 at 5:21:11 PM UTC-4, Vicente J. Botet=20
> Escriba wrote:
>
>     Le 19/08/2018 =C3=A0 19:22, mihailn...@gmail.com <javascript:> a =C3=
=A9crit=C2=A0:
>>
>>
>>     On Sunday, August 19, 2018 at 7:46:58 PM UTC+3, Vicente J. Botet
>>     Escriba wrote:
>>
>>         Le 19/08/2018 =C3=A0 15:04, mihailn...@gmail.com a =C3=A9crit=C2=
=A0:
>>>
>>>
>>>         On Sunday, August 19, 2018 at 3:26:12 PM UTC+3, Vicente J.
>>>         Botet Escriba wrote:
>>>
>>>             Independently of the language feature, using a tag type
>>>             allows to
>>>             transport the tag between different functions. In
>>>             addition, you cannot
>>>             change the class constructor name, so you will need a
>>>             tag to be able to
>>>             overload it. Take for example the in_place_t tag.
>>>
>>>
>>>         I have thoroughly explored that idea a month back:
>>>         https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPtd=
QE2GXb0/4OjT5Z4pBQAJ
>>>         <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPt=
dQE2GXb0/4OjT5Z4pBQAJ>
>>>
>>>         Feel free to comment there, I am undecided on the topic.
>>>
>>         I'm not sure yet we need some syntactic sugar for this tag
>>         dispatching feature neither.
>>         I'm just trying to separate the named parameter part from the
>>         overload part as orthogonal features.
>>         You go too far for my taste in your proposal and you propose
>>         to have all at once. I'll be against such a feature.
>>
>>
>>     Can you elaborate a bit more, what are your expectations and
>>     where should a line be drawn? As you can see in the comments to
>>     the post, there are similar concerns.
>>     In any case it is not a proposal, but an investigation. It is
>>     clear tags have overlap with strong names, and if we can get an
>>     attractive proposition, based on tags, we can mark at least one
>>     part (the harder part?) of the named arguments equation "fixed".
>>
>     I would like to see the two features proposed independently.
>
>     I see more added value for weak named parameters that are optional
>     and opt in on the author side (as the workarounds are not always
>     friendly) than the strong named parameters that can be used to
>     overload function or constructors and that are not optional (as
>     tag types are an almost friendly library solution, as the standard
>     library has showed already multiple times).
>
>
> The problem with having them be independent is that they're /not/=20
> independent. They're both playing around in the same space: invoking a=20
> parameter's name when you call the function.
>
> The first question any named parameter proposal has to answer is=20
> whether to rely on the existing parameter name infrastructure or to=20
> use a special way to define them. There are arguments for both weak=20
> and strong parameters to want to have syntax to declare named=20
> parameters on a function. This is because, by having users rely on=20
> them to some degree (even if mis-matched naming is just a warning),=20
> you are making those parameter names part of the interface of the API.=20
> And that's different from how parameter names have been treated in the=20
> past.
I'm not for strong named parameters. For me, this is a disguised form of=20
mixing weak named parameters and tag dispatching. This is why I believe=20
the features are independent.
Now you can put them together and obtain named parameters and tag dispatch.
>
> If you try to develop weak and strong parameters completely=20
> independently, then what you can end up with are two proposals that=20
> provide completely different ways of declaring such parameters. And=20
> considering all of the stuff that we keep cramming into function=20
> declarations these days, giving parameters /three names/ is utterly=20
> absurd. Even if you forbid weak parameter names on functions with=20
> strong names, that's still 3 separate syntaxes for declaring parameter=20
> names.
If we want weak and strong named parameters and don't see another=20
solution than having two syntax :(

I don't believe that we want non op in named parameters, so each one of=20
the weak/strong alternatives would need a specific syntax.

>
> So I don't think it's reasonable to develop the two proposals=20
> completely independently from one another. They should at least be=20
> developed with the knowledge that the other is a possibility, and with=20
> syntax that can reasonably fit together.
Maybe you are right, but I would like that the proposal are clearly=20
separated, so that we can be against one from or the other.
>
> Lastly, it should be noted that tagged dispatch doesn't help with what=20
> I will refer to as "mega-functions": functions that take stupidly=20
> large numbers of relatively independent parameters, but for some=20
> reason don't want to take them as a convenient aggregate. This is a=20
> use case that some people want to support, to avoid conceptual=20
> two-stage construction.
IMHO, this case is covered by weak named parameters already.
If you accept that your signature changes and require that the argument=20
must be named, strong named parameters could as well cover it.

If you don't accept that your signature changes and require that the=20
argument must be named, weak named parameters + some static analysis=20
tool (as clang-tidy) help could as well cover it (but not that the=20
syantax will be already defined by the standard).

Maybe we need strong named parameters that don't change the signatures=20
as well ;-)




Vicente

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/e97ada03-8b7c-39c3-cc85-514a3b67091d%40wanadoo.f=
r.

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

<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 19/08/2018 =C3=A0 23:53, Nicol Bolas =
a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"
      cite=3D"mid:67ab8a8c-4a0c-4b4f-8ea1-56822e660517@isocpp.org">
      <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf=
-8">
      <div dir=3D"ltr"><br>
        <br>
        On Sunday, August 19, 2018 at 5:21:11 PM UTC-4, Vicente J. Botet
        Escriba wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div text=3D"#000000" bgcolor=3D"#FFFFFF">
            <div>Le 19/08/2018 =C3=A0 19:22, <a href=3D"javascript:"
                target=3D"_blank" gdf-obfuscated-mailto=3D"5mg_tV9VAAAJ"
                rel=3D"nofollow"
                onmousedown=3D"this.href=3D'javascript:';return true;"
                onclick=3D"this.href=3D'javascript:';return true;"
                moz-do-not-send=3D"true">mihailn...@gmail.com</a> a
              =C3=A9crit=C2=A0:<br>
            </div>
            <blockquote type=3D"cite">
              <div dir=3D"ltr"><br>
                <br>
                On Sunday, August 19, 2018 at 7:46:58 PM UTC+3, Vicente
                J. Botet Escriba wrote:
                <blockquote class=3D"gmail_quote"
                  style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
                  solid;padding-left:1ex">
                  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
                    <div>Le 19/08/2018 =C3=A0 15:04, <a rel=3D"nofollow"
                        moz-do-not-send=3D"true">mihailn...@gmail.com</a>
                      a =C3=A9crit=C2=A0:<br>
                    </div>
                    <blockquote type=3D"cite">
                      <div dir=3D"ltr"><br>
                        <br>
                        On Sunday, August 19, 2018 at 3:26:12 PM UTC+3,
                        Vicente J. Botet Escriba wrote:
                        <blockquote class=3D"gmail_quote"
                          style=3D"margin:0;margin-left:0.8ex;border-left:1=
px
                          #ccc solid;padding-left:1ex">Independently of
                          the language feature, using a tag type allows
                          to <br>
                          transport the tag between different functions.
                          In addition, you cannot <br>
                          change the class constructor name, so you will
                          need a tag to be able to <br>
                          overload it. Take for example the in_place_t
                          tag. <br>
                        </blockquote>
                        <div><br>
                        </div>
                        <div>I have thoroughly explored that idea a
                          month back:=C2=A0<a
href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2G=
Xb0/4OjT5Z4pBQAJ"
                            rel=3D"nofollow" target=3D"_blank"
onmousedown=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msg/st=
d-proposals/tPtdQE2GXb0/4OjT5Z4pBQAJ';return
                            true;"
onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msg/std-pr=
oposals/tPtdQE2GXb0/4OjT5Z4pBQAJ';return
                            true;" moz-do-not-send=3D"true">https://groups.=
google.<wbr>com/a/isocpp.org/d/msg/std-<wbr>proposals/tPtdQE2GXb0/<wbr>4OjT=
5Z4pBQAJ</a></div>
                        <div><br>
                        </div>
                        <div>Feel free to comment there, I am undecided
                          on the topic.=C2=A0</div>
                        <div><br>
                        </div>
                        <div>=C2=A0</div>
                      </div>
                    </blockquote>
                    I'm not sure yet we need some syntactic sugar for
                    this tag dispatching feature neither.<br>
                    I'm just trying to separate the named parameter part
                    from the overload part as orthogonal features.<br>
                    You go too far for my taste in your proposal and you
                    propose to have all at once. I'll be against such a
                    feature.<br>
                  </div>
                </blockquote>
                <div><br>
                </div>
                <div>Can you elaborate a bit more, what are your
                  expectations and where should a line be drawn? As you
                  can see in the comments to the post, there are similar
                  concerns.</div>
                <div>In any case it is not a proposal, but an <span
style=3D"display:inline!important;float:none;background-color:transparent;c=
olor:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans=
-serif;font-size:13px;font-style:normal;font-variant:normal;font-weight:400=
;letter-spacing:normal;text-align:left;text-decoration:none;text-indent:0px=
;text-transform:none;white-space:normal;word-spacing:0px">investigation.
                  </span><span
style=3D"display:inline!important;float:none;background-color:transparent;c=
olor:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans=
-serif;font-size:13px;font-style:normal;font-variant:normal;font-weight:400=
;letter-spacing:normal;text-align:left;text-decoration:none;text-indent:0px=
;text-transform:none;white-space:normal;word-spacing:0px">It
                    is clear tags have overlap with strong names, and if
                    we can get an attractive proposition, based on tags,
                    we can mark at least one part (the harder part?) of
                    the named arguments equation "fixed".=C2=A0</span></div=
>
                <div><span
style=3D"display:inline!important;float:none;background-color:transparent;c=
olor:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans=
-serif;font-size:13px;font-style:normal;font-variant:normal;font-weight:400=
;letter-spacing:normal;text-align:left;text-decoration:none;text-indent:0px=
;text-transform:none;white-space:normal;word-spacing:0px"><br>
                  </span></div>
              </div>
            </blockquote>
            I would like to see the two features proposed independently.
            <br>
            <br>
            I see more added value for weak named parameters that are
            optional and opt in on the author side (as the workarounds
            are not always friendly) than the strong named parameters
            that can be used to overload function or constructors and
            that are not optional (as tag types are an almost friendly
            library solution, as the standard library has showed already
            multiple times).<br>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>The problem with having them be independent is that they're
          <i>not</i> independent. They're both playing around in the
          same space: invoking a parameter's name when you call the
          function.</div>
        <div><br>
        </div>
        <div>The first question any named parameter proposal has to
          answer is whether to rely on the existing parameter name
          infrastructure or to use a special way to define them. There
          are arguments for both weak and strong parameters to want to
          have syntax to declare named parameters on a function. This is
          because, by having users rely on them to some degree (even if
          mis-matched naming is just a warning), you are making those
          parameter names part of the interface of the API. And that's
          different from how parameter names have been treated in the
          past.</div>
      </div>
    </blockquote>
    I'm not for strong named parameters. For me, this is a disguised
    form of mixing weak named parameters and tag dispatching. This is
    why I believe the features are independent.<br>
    Now you can put them together and obtain named parameters and tag
    dispatch.<br>
    <blockquote type=3D"cite"
      cite=3D"mid:67ab8a8c-4a0c-4b4f-8ea1-56822e660517@isocpp.org">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>If you try to develop weak and strong parameters completely
          independently, then what you can end up with are two proposals
          that provide completely different ways of declaring such
          parameters. And considering all of the stuff that we keep
          cramming into function declarations these days, giving
          parameters <i>three names</i> is utterly absurd. Even if you
          forbid weak parameter names on functions with strong names,
          that's still 3 separate syntaxes for declaring parameter
          names.</div>
      </div>
    </blockquote>
    If we want weak and strong named parameters and don't see another
    solution than having two syntax :(<br>
    <br>
    I don't believe that we want non op in named parameters, so each one
    of the weak/strong alternatives would need a specific syntax.<br>
    <br>
    <blockquote type=3D"cite"
      cite=3D"mid:67ab8a8c-4a0c-4b4f-8ea1-56822e660517@isocpp.org">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>So I don't think it's reasonable to develop the two
          proposals completely independently from one another. They
          should at least be developed with the knowledge that the other
          is a possibility, and with syntax that can reasonably fit
          together.</div>
      </div>
    </blockquote>
    Maybe you are right, but I would like that the proposal are clearly
    separated, so that we can be against one from or the other.<br>
    <blockquote type=3D"cite"
      cite=3D"mid:67ab8a8c-4a0c-4b4f-8ea1-56822e660517@isocpp.org">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>Lastly, it should be noted that tagged dispatch doesn't
          help with what I will refer to as "mega-functions": functions
          that take stupidly large numbers of relatively independent
          parameters, but for some reason don't want to take them as a
          convenient aggregate. This is a use case that some people want
          to support, to avoid conceptual two-stage construction.<br>
        </div>
      </div>
    </blockquote>
    IMHO, this case is covered by weak named parameters already.=C2=A0 <br>
    If you accept that your signature changes and require that the
    argument must be named, strong named parameters could as well cover
    it.<br>
    <br>
    If you don't accept that your signature changes and require that the
    argument must be named, weak named parameters + some static analysis
    tool (as clang-tidy) help could as well cover it (but not that the
    syantax will be already defined by the standard).<br>
    <br>
    Maybe we need strong named parameters that don't change the
    signatures as well ;-)<br>
    <br>
    <br>
    <br>
    <br>
    Vicente
  </body>
</html>

<p></p>

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

--------------3DFBE57ABCFC7BC72C9C125A--

.

------=_Part_17_955062732.1534749907064
Content-Type: multipart/alternative;
 boundary="----=_Part_18_79771036.1534749907064"

------=_Part_18_79771036.1534749907064
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Monday, August 20, 2018 at 12:21:11 AM UTC+3, Vicente J. Botet Escriba=
=20
wrote:
>
> Le 19/08/2018 =C3=A0 19:22, mihailn...@gmail.com <javascript:> a =C3=A9cr=
it :
>
>
>
> On Sunday, August 19, 2018 at 7:46:58 PM UTC+3, Vicente J. Botet Escriba=
=20
> wrote:=20
>>
>> Le 19/08/2018 =C3=A0 15:04, mihailn...@gmail.com a =C3=A9crit :
>>
>>
>>
>> On Sunday, August 19, 2018 at 3:26:12 PM UTC+3, Vicente J. Botet Escriba=
=20
>> wrote:=20
>>>
>>> Independently of the language feature, using a tag type allows to=20
>>> transport the tag between different functions. In addition, you cannot=
=20
>>> change the class constructor name, so you will need a tag to be able to=
=20
>>> overload it. Take for example the in_place_t tag.=20
>>>
>>
>> I have thoroughly explored that idea a month back:=20
>> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2GXb0/4=
OjT5Z4pBQAJ
>>
>> Feel free to comment there, I am undecided on the topic.=20
>>
>> =20
>>
>> I'm not sure yet we need some syntactic sugar for this tag dispatching=
=20
>> feature neither.
>> I'm just trying to separate the named parameter part from the overload=
=20
>> part as orthogonal features.
>> You go too far for my taste in your proposal and you propose to have all=
=20
>> at once. I'll be against such a feature.
>>
>
> Can you elaborate a bit more, what are your expectations and where should=
=20
> a line be drawn? As you can see in the comments to the post, there are=20
> similar concerns.
> In any case it is not a proposal, but an investigation. It is clear tags=
=20
> have overlap with strong names, and if we can get an attractive=20
> proposition, based on tags, we can mark at least one part (the harder=20
> part?) of the named arguments equation "fixed".=20
>
> =20

> I would like to see the two features proposed independently.=20
>
> I see more added value for weak named parameters that are optional and op=
t=20
> in on the author side (as the workarounds are not always friendly) than t=
he=20
> strong named parameters that can be used to overload function or=20
> constructors and that are not optional (as tag types are an almost friend=
ly=20
> library solution, as the standard library has showed already multiple=20
> times).
>

This is also my PoV in general, especially with more friendly tags.=20
However, many people hate the idea names will be for weak only and they are=
=20
left to use workarounds for overload resolution - after all, they consider=
=20
names the correct way of handling this.

The second issue is, neither tags nor named functions are perfect=20
solutions. Tags are a technically a working solution, but they don't convey=
=20
the same meaning as label would.=20
Natural naming like for:, to:, with:, if:, relativeTo:, ignoring:,=20
including:, are pretty much unattainable for tags, both for the words that=
=20
can be used and the lack of semicolon to give context when reading the code=
..

If we say "just use tags", people will still demand strong names, this is=
=20
what I am trying to say.=20

Sadly, strong names do not eliminate the need for tags!=20
To still have tag as an idiom AND strong names, this is probably too much,=
=20
but I might be wrong -=20
after all if we eliminate static/free functions as constructors, it will be=
=20
a massive win, even if there are some use for tags left.
This is what I mean by "where should we draw the line".=20

=20

>
> Vicente
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a1ea778c-4b2c-4af0-90ac-0ba0792cc439%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Monday, August 20, 2018 at 12:21:11 AM UTC+3, V=
icente J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>Le 19/08/2018 =C3=A0 19:22,
      <a onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onc=
lick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"javascript:=
" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"5mg_tV9VAAAJ"=
>mihailn...@gmail.com</a> a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
     =20
      <div dir=3D"ltr"><br>
        <br>
        On Sunday, August 19, 2018 at 7:46:58 PM UTC+3, Vicente J. Botet
        Escriba wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
            <div>Le 19/08/2018 =C3=A0 15:04, <a rel=3D"nofollow">mihailn...=
@gmail.com</a> a
              =C3=A9crit=C2=A0:<br>
            </div>
            <blockquote type=3D"cite">
              <div dir=3D"ltr"><br>
                <br>
                On Sunday, August 19, 2018 at 3:26:12 PM UTC+3, Vicente
                J. Botet Escriba wrote:
                <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Independently of th=
e language
                  feature, using a tag type allows to <br>
                  transport the tag between different functions. In
                  addition, you cannot <br>
                  change the class constructor name, so you will need a
                  tag to be able to <br>
                  overload it. Take for example the in_place_t tag. <br>
                </blockquote>
                <div><br>
                </div>
                <div>I have thoroughly explored that idea a month
                  back:=C2=A0<a onmousedown=3D"this.href=3D&#39;https://gro=
ups.google.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2GXb0/4OjT5Z4pBQAJ&#3=
9;;return true;" onclick=3D"this.href=3D&#39;https://groups.google.com/a/is=
ocpp.org/d/msg/std-proposals/tPtdQE2GXb0/4OjT5Z4pBQAJ&#39;;return true;" hr=
ef=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2GXb=
0/4OjT5Z4pBQAJ" target=3D"_blank" rel=3D"nofollow">https://groups.google.<w=
br>com/a/isocpp.org/d/msg/std-<wbr>proposals/tPtdQE2GXb0/<wbr>4OjT5Z4pBQAJ<=
/a></div>
                <div><br>
                </div>
                <div>Feel free to comment there, I am undecided on the
                  topic.=C2=A0</div>
                <div><br>
                </div>
                <div>=C2=A0</div>
              </div>
            </blockquote>
            I&#39;m not sure yet we need some syntactic sugar for this tag
            dispatching feature neither.<br>
            I&#39;m just trying to separate the named parameter part from
            the overload part as orthogonal features.<br>
            You go too far for my taste in your proposal and you propose
            to have all at once. I&#39;ll be against such a feature.<br>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>Can you elaborate a bit more, what are your expectations
          and where should a line be drawn? As you can see in the
          comments to the post, there are similar concerns.</div>
        <div>In any case it is not a proposal, but an <span style=3D"displa=
y:inline!important;float:none;background-color:transparent;color:rgb(34,34,=
34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-siz=
e:13px;font-style:normal;font-variant:normal;font-weight:400;letter-spacing=
:normal;text-align:left;text-decoration:none;text-indent:0px;text-transform=
:none;white-space:normal;word-spacing:0px">investigation. </span><span styl=
e=3D"display:inline!important;float:none;background-color:transparent;color=
:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-ser=
if;font-size:13px;font-style:normal;font-variant:normal;font-weight:400;let=
ter-spacing:normal;text-align:left;text-decoration:none;text-indent:0px;tex=
t-transform:none;white-space:normal;word-spacing:0px">It is clear tags
            have overlap with strong names, and if we can get an
            attractive proposition, based on tags, we can mark at least
            one part (the harder part?) of the named arguments equation
            &quot;fixed&quot;.=C2=A0</span></div>
        <div><span style=3D"display:inline!important;float:none;background-=
color:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;H=
elvetica&quot;,sans-serif;font-size:13px;font-style:normal;font-variant:nor=
mal;font-weight:400;letter-spacing:normal;text-align:left;text-decoration:n=
one;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px=
"><br></span></div></div></blockquote></div></blockquote><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=
=3D"#000000"><blockquote type=3D"cite"><div dir=3D"ltr"><div><span style=3D=
"display:inline!important;float:none;background-color:transparent;color:rgb=
(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;f=
ont-size:13px;font-style:normal;font-variant:normal;font-weight:400;letter-=
spacing:normal;text-align:left;text-decoration:none;text-indent:0px;text-tr=
ansform:none;white-space:normal;word-spacing:0px">
          </span></div>
      </div>
    </blockquote>
    I would like to see the two features proposed independently. <br>
    <br>
    I see more added value for weak named parameters that are optional
    and opt in on the author side (as the workarounds are not always
    friendly) than the strong named parameters that can be used to
    overload function or constructors and that are not optional (as tag
    types are an almost friendly library solution, as the standard
    library has showed already multiple times).<br></div></blockquote><div>=
<br></div><div>This is also my PoV in general, especially with more friendl=
y tags.=C2=A0</div><div>However, many people hate the idea names will be fo=
r weak only and they are left to use workarounds for overload resolution - =
after all, they consider names the correct way of handling this.</div><div>=
<br></div><div>The second issue is, neither tags nor named functions are pe=
rfect solutions. Tags are a technically a working solution, but they don&#3=
9;t convey the same meaning as label would.=C2=A0</div><div>Natural naming =
like <font face=3D"courier new,monospace">for:, to:, with:, if:, relativeTo=
:, ignoring:, including:,</font> are pretty much unattainable for tags, bot=
h for the words that can be used and the lack of semicolon to give context =
when reading the code.</div><div><br></div><div>If we say &quot;just use ta=
gs&quot;, people will still demand strong names, this is what I am trying t=
o say.=C2=A0</div><div><br></div><div>Sadly, strong names do not eliminate =
the need for tags!=C2=A0</div><div>To still have tag as an idiom AND strong=
 names, this is probably too much, but I might be wrong -=C2=A0</div><div>a=
fter all if we eliminate static/free functions as constructors, it will be =
a massive win, even if there are some use for tags left.<br></div><div>This=
 is what I mean by &quot;where should we draw the line&quot;.=C2=A0</div><d=
iv><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <br>
    Vicente<br>
  </div>

</blockquote></div>

<p></p>

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

------=_Part_18_79771036.1534749907064--

------=_Part_17_955062732.1534749907064--

.

------=_Part_1593_479415867.1534779459153
Content-Type: multipart/alternative;
 boundary="----=_Part_1594_1004941905.1534779459153"

------=_Part_1594_1004941905.1534779459153
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Monday, August 20, 2018 at 2:15:17 AM UTC-4, Vicente J. Botet Escriba=20
wrote:
>
> Le 19/08/2018 =C3=A0 23:53, Nicol Bolas a =C3=A9crit :
>
>
>
> On Sunday, August 19, 2018 at 5:21:11 PM UTC-4, Vicente J. Botet Escriba=
=20
> wrote:=20
>>
>> Le 19/08/2018 =C3=A0 19:22, mihailn...@gmail.com a =C3=A9crit :
>>
>>
>>
>> On Sunday, August 19, 2018 at 7:46:58 PM UTC+3, Vicente J. Botet Escriba=
=20
>> wrote:=20
>>>
>>> Le 19/08/2018 =C3=A0 15:04, mihailn...@gmail.com a =C3=A9crit :
>>>
>>>
>>>
>>> On Sunday, August 19, 2018 at 3:26:12 PM UTC+3, Vicente J. Botet Escrib=
a=20
>>> wrote:=20
>>>>
>>>> Independently of the language feature, using a tag type allows to=20
>>>> transport the tag between different functions. In addition, you cannot=
=20
>>>> change the class constructor name, so you will need a tag to be able t=
o=20
>>>> overload it. Take for example the in_place_t tag.=20
>>>>
>>>
>>> I have thoroughly explored that idea a month back:=20
>>> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2GXb0/=
4OjT5Z4pBQAJ
>>>
>>> Feel free to comment there, I am undecided on the topic.=20
>>>
>>> =20
>>>
>>> I'm not sure yet we need some syntactic sugar for this tag dispatching=
=20
>>> feature neither.
>>> I'm just trying to separate the named parameter part from the overload=
=20
>>> part as orthogonal features.
>>> You go too far for my taste in your proposal and you propose to have al=
l=20
>>> at once. I'll be against such a feature.
>>>
>>
>> Can you elaborate a bit more, what are your expectations and where shoul=
d=20
>> a line be drawn? As you can see in the comments to the post, there are=
=20
>> similar concerns.
>> In any case it is not a proposal, but an investigation. It is clear tags=
=20
>> have overlap with strong names, and if we can get an attractive=20
>> proposition, based on tags, we can mark at least one part (the harder=20
>> part?) of the named arguments equation "fixed".=20
>>
>> I would like to see the two features proposed independently.=20
>>
>> I see more added value for weak named parameters that are optional and=
=20
>> opt in on the author side (as the workarounds are not always friendly) t=
han=20
>> the strong named parameters that can be used to overload function or=20
>> constructors and that are not optional (as tag types are an almost frien=
dly=20
>> library solution, as the standard library has showed already multiple=20
>> times).
>>
>
> The problem with having them be independent is that they're *not*=20
> independent. They're both playing around in the same space: invoking a=20
> parameter's name when you call the function.
>
> The first question any named parameter proposal has to answer is whether=
=20
> to rely on the existing parameter name infrastructure or to use a special=
=20
> way to define them. There are arguments for both weak and strong paramete=
rs=20
> to want to have syntax to declare named parameters on a function. This is=
=20
> because, by having users rely on them to some degree (even if mis-matched=
=20
> naming is just a warning), you are making those parameter names part of t=
he=20
> interface of the API. And that's different from how parameter names have=
=20
> been treated in the past.
>
> I'm not for strong named parameters. For me, this is a disguised form of=
=20
> mixing weak named parameters and tag dispatching. This is why I believe t=
he=20
> features are independent.
> Now you can put them together and obtain named parameters and tag dispatc=
h.
>

> If you try to develop weak and strong parameters completely independently=
,=20
> then what you can end up with are two proposals that provide completely=
=20
> different ways of declaring such parameters. And considering all of the=
=20
> stuff that we keep cramming into function declarations these days, giving=
=20
> parameters *three names* is utterly absurd. Even if you forbid weak=20
> parameter names on functions with strong names, that's still 3 separate=
=20
> syntaxes for declaring parameter names.
>
> If we want weak and strong named parameters and don't see another solutio=
n=20
> than having two syntaxes :(
>

If that's the case, then we shouldn't have weak named parameters at all.=20
Remember: weak named parameters are purely notational; they catch errors.=
=20
That makes them a "nice to have". Strong named parameters provide genuine=
=20
functionality, allowing you to express things that could not be expressed=
=20
before.

If the design space is sufficiently constrained to only permit one or the=
=20
other, then it should be the one that actually does something.

I don't believe that we want non op in named parametrs, so each one of the=
=20
> weak/strong alternatives would need a specific syntax.
>
>
> So I don't think it's reasonable to develop the two proposals completely=
=20
> independently from one another. They should at least be developed with th=
e=20
> knowledge that the other is a possibility, and with syntax that can=20
> reasonably fit together.
>
> Maybe you are right, but I would like that the proposal are clearly=20
> separated, so that we can be agains one from or the other.
>

So, you can't be against one part of a proposal? The standards committee=20
does it all the time.

> Lastly, it should be noted that tagged dispatch doesn't help with what I=
=20
> will refer to as "mega-functions": functions that take stupidly large=20
> numbers of relatively independent parameters, but for some reason don't=
=20
> want to take them as a convenient aggregate. This is a use case that some=
=20
> people want to support, to avoid conceptual two-stage construction.
>
> IMHO, this case is covered by weak named parameters already.
>

Then perhaps you're not understanding what a "mega-function" is. We're=20
talking about functions with *dozens* of parameters, most of which are=20
optional. Consider all of the various parameters you deal with when setting=
=20
up a window. Window styles, size, position, hierarchy, font choice, and=20
other things. Each of those are conceptually one or more parameters to the=
=20
window creation function.

"Ideally", these would be literal parameters to a hypothetical Window=20
class's constructor. But they're not; most such classes give relatively=20
limited numbers of parameters to the Window's constructor. The rest are=20
values set after the Window's construction, which means that defaults are=
=20
used until those get set. Basically, it's two-stage construction.

The only way you can get the "ideal" case is if order for parameters is *co=
mpletely=20
removed* for such functions. You can specify the arguments in any order=20
when you call them, and the caller can default any parameter with a default=
=20
value simply by not specifying it.

Weak named parameters can't do that. Tag dispatch can't do that (not=20
without extraordinary pain on the callee side). Even designated=20
initializers have to be specified in the right order.

If you accept that your signature changes and require that the argument=20
> must be named, strong named parameters could as well cover it.
>
> If you don't accept that your signature changes and require that the=20
> argument must be named, weak named parameters + some static analysis tool=
=20
> (as clang-tidy) help could as well cover it (but not that the syantax wil=
l=20
> be already defined by the standard).
>
> Maybe we need strong named parameters that don't change the signatures as=
=20
> well ;-)
>
> Vicente=20
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9f3550db-0cce-4259-85ef-428d8cfba63c%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Monday, August 20, 2018 at 2:15:17 AM UTC-4, Vi=
cente J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div>Le 19/08/2018 =C3=A0 23:53, Nicol Bolas a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
     =20
      <div dir=3D"ltr"><br>
        <br>
        On Sunday, August 19, 2018 at 5:21:11 PM UTC-4, Vicente J. Botet
        Escriba wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
          <div text=3D"#000000" bgcolor=3D"#FFFFFF">
            <div>Le 19/08/2018 =C3=A0 19:22, <a rel=3D"nofollow">mihailn...=
@gmail.com</a> a
              =C3=A9crit=C2=A0:<br>
            </div>
            <blockquote type=3D"cite">
              <div dir=3D"ltr"><br>
                <br>
                On Sunday, August 19, 2018 at 7:46:58 PM UTC+3, Vicente
                J. Botet Escriba wrote:
                <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
                  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
                    <div>Le 19/08/2018 =C3=A0 15:04, <a rel=3D"nofollow">mi=
hailn...@gmail.com</a>
                      a =C3=A9crit=C2=A0:<br>
                    </div>
                    <blockquote type=3D"cite">
                      <div dir=3D"ltr"><br>
                        <br>
                        On Sunday, August 19, 2018 at 3:26:12 PM UTC+3,
                        Vicente J. Botet Escriba wrote:
                        <blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Independent=
ly of
                          the language feature, using a tag type allows
                          to <br>
                          transport the tag between different functions.
                          In addition, you cannot <br>
                          change the class constructor name, so you will
                          need a tag to be able to <br>
                          overload it. Take for example the in_place_t
                          tag. <br>
                        </blockquote>
                        <div><br>
                        </div>
                        <div>I have thoroughly explored that idea a
                          month back:=C2=A0<a href=3D"https://groups.google=
..com/a/isocpp.org/d/msg/std-proposals/tPtdQE2GXb0/4OjT5Z4pBQAJ" rel=3D"nofo=
llow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;https://groups.goog=
le.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2GXb0/4OjT5Z4pBQAJ&#39;;retur=
n true;" onclick=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org=
/d/msg/std-proposals/tPtdQE2GXb0/4OjT5Z4pBQAJ&#39;;return true;">https://gr=
oups.google.<wbr>com/a/isocpp.org/d/msg/std-<wbr>proposals/tPtdQE2GXb0/<wbr=
>4OjT5Z4pBQAJ</a></div>
                        <div><br>
                        </div>
                        <div>Feel free to comment there, I am undecided
                          on the topic.=C2=A0</div>
                        <div><br>
                        </div>
                        <div>=C2=A0</div>
                      </div>
                    </blockquote>
                    I&#39;m not sure yet we need some syntactic sugar for
                    this tag dispatching feature neither.<br>
                    I&#39;m just trying to separate the named parameter par=
t
                    from the overload part as orthogonal features.<br>
                    You go too far for my taste in your proposal and you
                    propose to have all at once. I&#39;ll be against such a
                    feature.<br>
                  </div>
                </blockquote>
                <div><br>
                </div>
                <div>Can you elaborate a bit more, what are your
                  expectations and where should a line be drawn? As you
                  can see in the comments to the post, there are similar
                  concerns.</div>
                <div>In any case it is not a proposal, but an <span style=
=3D"display:inline!important;float:none;background-color:transparent;color:=
rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-seri=
f;font-size:13px;font-style:normal;font-variant:normal;font-weight:400;lett=
er-spacing:normal;text-align:left;text-decoration:none;text-indent:0px;text=
-transform:none;white-space:normal;word-spacing:0px">investigation.
                  </span><span style=3D"display:inline!important;float:none=
;background-color:transparent;color:rgb(34,34,34);font-family:&quot;Arial&q=
uot;,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-style:normal;font=
-variant:normal;font-weight:400;letter-spacing:normal;text-align:left;text-=
decoration:none;text-indent:0px;text-transform:none;white-space:normal;word=
-spacing:0px">It
                    is clear tags have overlap with strong names, and if
                    we can get an attractive proposition, based on tags,
                    we can mark at least one part (the harder part?) of
                    the named arguments equation &quot;fixed&quot;.=C2=A0</=
span></div>
                <div><span style=3D"display:inline!important;float:none;bac=
kground-color:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;=
,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-style:normal;font-var=
iant:normal;font-weight:400;letter-spacing:normal;text-align:left;text-deco=
ration:none;text-indent:0px;text-transform:none;white-space:normal;word-spa=
cing:0px"><br>
                  </span></div>
              </div>
            </blockquote>
            I would like to see the two features proposed independently.
            <br>
            <br>
            I see more added value for weak named parameters that are
            optional and opt in on the author side (as the workarounds
            are not always friendly) than the strong named parameters
            that can be used to overload function or constructors and
            that are not optional (as tag types are an almost friendly
            library solution, as the standard library has showed already
            multiple times).<br>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>The problem with having them be independent is that they&#39;r=
e
          <i>not</i> independent. They&#39;re both playing around in the
          same space: invoking a parameter&#39;s name when you call the
          function.</div>
        <div><br>
        </div>
        <div>The first question any named parameter proposal has to
          answer is whether to rely on the existing parameter name
          infrastructure or to use a special way to define them. There
          are arguments for both weak and strong parameters to want to
          have syntax to declare named parameters on a function. This is
          because, by having users rely on them to some degree (even if
          mis-matched naming is just a warning), you are making those
          parameter names part of the interface of the API. And that&#39;s
          different from how parameter names have been treated in the
          past.</div>
      </div>
    </blockquote>
    I&#39;m not for strong named parameters. For me, this is a disguised
    form of mixing weak named parameters and tag dispatching. This is
    why I believe the features are independent.<br>
    Now you can put them together and obtain named parameters and tag
    dispatch.</div></blockquote><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div text=3D"#000000" bgcolor=3D"#FFFFFF"><blockquote type=3D"cite"><div =
dir=3D"ltr"><br><div>If you try to develop weak and strong parameters compl=
etely
          independently, then what you can end up with are two proposals
          that provide completely different ways of declaring such
          parameters. And considering all of the stuff that we keep
          cramming into function declarations these days, giving
          parameters <i>three names</i> is utterly absurd. Even if you
          forbid weak parameter names on functions with strong names,
          that&#39;s still 3 separate syntaxes for declaring parameter
          names.</div>
      </div>
    </blockquote>
    If we want weak and strong named parameters and don&#39;t see another
    solution than having two syntaxes :(<br></div></blockquote><div><br></d=
iv><div>If that&#39;s the case, then we shouldn&#39;t have weak named param=
eters at all. Remember: weak named parameters are purely notational; they c=
atch errors. That makes them a &quot;nice to have&quot;. Strong named param=
eters provide genuine functionality, allowing you to express things that co=
uld not be expressed before.</div><div><br></div><div>If the design space i=
s sufficiently constrained to only permit one or the other, then it should =
be the one that actually does something.<br></div><div><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div text=3D"#000000" bgcolor=3D"#FFFFFF=
">
   =20
    I don&#39;t believe that we want non op in named parametrs, so each one
    of the weak/strong alternatives would need a specific syntax.<br>
    <br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>So I don&#39;t think it&#39;s reasonable to develop the two
          proposals completely independently from one another. They
          should at least be developed with the knowledge that the other
          is a possibility, and with syntax that can reasonably fit
          together.</div>
      </div>
    </blockquote>
    Maybe you are right, but I would like that the proposal are clearly
    separated, so that we can be agains one from or the other.<br></div></b=
lockquote><div><br></div><div>So, you can&#39;t be against one part of a pr=
oposal? The standards committee does it all the time.<br></div><div></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div text=3D"#000000" bgcolor=
=3D"#FFFFFF">
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
        </div>
        <div>Lastly, it should be noted that tagged dispatch doesn&#39;t
          help with what I will refer to as &quot;mega-functions&quot;: fun=
ctions
          that take stupidly large numbers of relatively independent
          parameters, but for some reason don&#39;t want to take them as a
          convenient aggregate. This is a use case that some people want
          to support, to avoid conceptual two-stage construction.<br>
        </div>
      </div>
    </blockquote>
    IMHO, this case is covered by weak named parameters already.<br></div><=
/blockquote><div><br></div><div>Then perhaps you&#39;re not understanding w=
hat a &quot;mega-function&quot; is. We&#39;re talking about functions with =
<i>dozens</i> of parameters, most of which are optional. Consider all of th=
e various parameters you deal with when setting up a window. Window styles,=
 size, position, hierarchy, font choice, and other things. Each of those ar=
e conceptually one or more parameters to the window creation function.</div=
><div><br></div><div>&quot;Ideally&quot;, these would be literal parameters=
 to a hypothetical Window class&#39;s constructor. But they&#39;re not; mos=
t such classes give relatively limited numbers of parameters to the Window&=
#39;s constructor. The rest are values set after the Window&#39;s construct=
ion, which means that defaults are used until those get set. Basically, it&=
#39;s two-stage construction.<br></div><div><br></div><div>The only way you=
 can get the &quot;ideal&quot; case is if order for parameters is <i>comple=
tely removed</i> for such functions. You can specify the arguments in any o=
rder when you call them, and the caller can default any parameter with a de=
fault value simply by not specifying it.</div><div><br></div><div>Weak name=
d parameters can&#39;t do that. Tag dispatch can&#39;t do that (not without=
 extraordinary pain on the callee side). Even designated initializers have =
to be specified in the right order.<br></div><div></div><div><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div text=3D"#000000" bgcolor=3D"#=
FFFFFF">
    If you accept that your signature changes and require that the
    argument must be named, strong named parameters could as well cover
    it.<br>
    <br>
    If you don&#39;t accept that your signature changes and require that th=
e
    argument must be named, weak named parameters + some static analysis
    tool (as clang-tidy) help could as well cover it (but not that the
    syantax will be already defined by the standard).<br>
    <br>
    Maybe we need strong named parameters that don&#39;t change the
    signatures as well ;-)<br>
    <br>
    Vicente
  </div>

</blockquote></div>

<p></p>

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

------=_Part_1594_1004941905.1534779459153--

------=_Part_1593_479415867.1534779459153--

.

------=_Part_256_600707684.1534781485758
Content-Type: multipart/alternative;
 boundary="----=_Part_257_439212295.1534781485830"

------=_Part_257_439212295.1534781485830
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Monday, August 20, 2018 at 2:00:25 AM UTC-4, Vicente J. Botet Escriba=20
wrote:
>
> Le 20/08/2018 =C3=A0 00:32, Jeremy Maitin-Shepard a =C3=A9crit :
>
> We already have a form of weak named parameters readily available in the =
form of /*parameter_name=3D*/value comments in combination with the clang-t=
idy bugprone-argument-comment check or similar functionality in other tools=
..
>
> A mechanism that only warns and doesn't support forwarding/metaprogrammin=
g does not seem to me to provide much value over what we already have.
>
>
> If you find the clang tidy check is useful, the added value is that I=20
> wouldn't need clang-tidy to check for it and we would have the feature=20
> available with all the compliant compilers :)
>
> I don't like these kind of comments. We could instead use attributes, but=
=20
> they are too heavyweight to my taste.
>

I think his point (and if it's not his, then it's mine) is that, if there's=
=20
a way to just let implementations handle it outside of the language itself,=
=20
then why not just do that?

Weak named parameters are pure notation. They exist to communicate=20
information to the reader about what's going on. And that's all they do.

Weak named parameters do not communicate information to the implementation=
=20
for the purpose of code generation. The only interaction the implementation=
=20
has with them is to verify that the caller and callee used the same name.=
=20
They merely ensure that the reader's information is accurate.

Weak named parameters do not change how you implement your functions, not=
=20
on an API level. Since you can't overload based on weak parameters, you=20
can't write `rectangle(top_left: ...)` as opposed to=20
`rectangle(bottom_right: ...)`. You can express which convention the=20
function uses, but you cannot allow the caller to *select* a convention.

Compare this to concepts and contracts. Concepts change what the language=
=20
is doing. When you constrain a template, that *does something* to the=20
template. It changes how code is generated (or more specifically, when it=
=20
is not generated).

Contracts seem like notation, but they're not. Why? Pre-contracts,=20
exceptions were sometimes used for logic errors; we even have=20
`std::logic_error` as an exception base class. Once we have contracts in=20
place, we can take stuff like that out, turning contract violations into=20
actual *contract violations*.

Contracts change how you write code (or rather, make it easier for you to=
=20
write code the way you should have been writing it). They allow you to=20
specify a different kind of meaning in the language, compared to what you=
=20
could have before.

Weak parameters change neither of these. There are very few C++ language=20
features (outside of certain attributes) like this.

Given this fact, why should the committee spend time on something that is=
=20
purely rotational? Don't they have more useful things to be getting on with=
?

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5315cec3-6d25-4c92-b31b-e5dcd5d8f68c%40isocpp.or=
g.

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

<div dir=3D"ltr">On Monday, August 20, 2018 at 2:00:25 AM UTC-4, Vicente J.=
 Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div>Le 20/08/2018 =C3=A0 00:32, Jeremy
      Maitin-Shepard a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
      <pre>We already have a form of weak named parameters readily availabl=
e in the form of /*parameter_name=3D*/value comments in combination with th=
e clang-tidy bugprone-argument-comment check or similar functionality in ot=
her tools.

A mechanism that only warns and doesn&#39;t support forwarding/metaprogramm=
ing does not seem to me to provide much value over what we already have.

</pre>
    </blockquote>
    <p><font size=3D"+1">If you find the clang tidy check is useful, the
        added value is that I wouldn&#39;t need clang-tidy to check for it
        and we would have the feature available with all the compliant
        compilers :)</font></p>
    <p><font size=3D"+1">I don&#39;t like these kind of comments. We could
        instead use attributes, but they are too heavyweight to my
        taste.<br></font></p></div></blockquote><div><br></div><div>I think=
 his point (and if it&#39;s not his, then it&#39;s mine) is that, if there&=
#39;s a way to just let implementations handle it outside of the language i=
tself, then why not just do that?</div><div><br></div><div>Weak named param=
eters are pure notation. They exist to communicate information to the reade=
r about what&#39;s going on. And that&#39;s all they do.<br></div><div><br>=
</div><div>Weak named parameters do not communicate information to the impl=
ementation for the purpose of code generation. The only interaction the imp=
lementation has with them is to verify that the caller and callee used the =
same name. They merely ensure that the reader&#39;s information is accurate=
..<br></div><div><div><br></div>Weak named parameters do not change how you =
implement your functions, not on an API level. Since you can&#39;t overload=
 based on weak parameters, you can&#39;t=20
write `rectangle(top_left: ...)` as opposed to `rectangle(bottom_right:=20
....)`. You can express which convention the function uses, but you cannot a=
llow=20
the caller to <i>select</i> a convention.</div><div><br></div><div>Compare =
this to concepts and contracts. Concepts change what the language is doing.=
 When you constrain a template, that <i>does something</i> to the template.=
 It changes how code is generated (or more specifically, when it is not gen=
erated).<br></div><div><br></div><div>Contracts seem like notation, but the=
y&#39;re not. Why? Pre-contracts, exceptions were sometimes used for logic =
errors; we even have `std::logic_error` as an exception base class. Once we=
 have contracts in place, we can take stuff like that out, turning contract=
 violations into actual <i>contract violations</i>.</div><div><br></div><di=
v>Contracts change how you write code (or rather, make it easier for you to=
 write code the way you should have been writing it). They allow you to spe=
cify a different kind of meaning in the language, compared to what you coul=
d have before.</div><div><br></div><div>Weak parameters change neither of t=
hese. There are very few C++ language features (outside of certain attribut=
es) like this.</div><div><br></div><div>Given this fact, why should the com=
mittee spend time on something that is purely rotational? Don&#39;t they ha=
ve more useful things to be getting on with?<br></div></div>

<p></p>

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

------=_Part_257_439212295.1534781485830--

------=_Part_256_600707684.1534781485758--

.

------=_Part_1593_898653651.1534782020444
Content-Type: multipart/alternative;
 boundary="----=_Part_1594_636285012.1534782020445"

------=_Part_1594_636285012.1534782020445
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Monday, August 20, 2018 at 6:37:39 PM UTC+3, Nicol Bolas wrote:
>
>
>
> On Monday, August 20, 2018 at 2:15:17 AM UTC-4, Vicente J. Botet Escriba=
=20
> wrote:
>>
>> Le 19/08/2018 =C3=A0 23:53, Nicol Bolas a =C3=A9crit :
>>
>>
>>
>> On Sunday, August 19, 2018 at 5:21:11 PM UTC-4, Vicente J. Botet Escriba=
=20
>> wrote:=20
>>>
>>> Le 19/08/2018 =C3=A0 19:22, mihailn...@gmail.com a =C3=A9crit :
>>>
>>>
>>>
>>> On Sunday, August 19, 2018 at 7:46:58 PM UTC+3, Vicente J. Botet Escrib=
a=20
>>> wrote:=20
>>>>
>>>> Le 19/08/2018 =C3=A0 15:04, mihailn...@gmail.com a =C3=A9crit :
>>>>
>>>>
>>>>
>>>> On Sunday, August 19, 2018 at 3:26:12 PM UTC+3, Vicente J. Botet=20
>>>> Escriba wrote:=20
>>>>>
>>>>> Independently of the language feature, using a tag type allows to=20
>>>>> transport the tag between different functions. In addition, you canno=
t=20
>>>>> change the class constructor name, so you will need a tag to be able=
=20
>>>>> to=20
>>>>> overload it. Take for example the in_place_t tag.=20
>>>>>
>>>>
>>>> I have thoroughly explored that idea a month back:=20
>>>> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2GXb0=
/4OjT5Z4pBQAJ
>>>>
>>>> Feel free to comment there, I am undecided on the topic.=20
>>>>
>>>> =20
>>>>
>>>> I'm not sure yet we need some syntactic sugar for this tag dispatching=
=20
>>>> feature neither.
>>>> I'm just trying to separate the named parameter part from the overload=
=20
>>>> part as orthogonal features.
>>>> You go too far for my taste in your proposal and you propose to have=
=20
>>>> all at once. I'll be against such a feature.
>>>>
>>>
>>> Can you elaborate a bit more, what are your expectations and where=20
>>> should a line be drawn? As you can see in the comments to the post, the=
re=20
>>> are similar concerns.
>>> In any case it is not a proposal, but an investigation. It is clear=20
>>> tags have overlap with strong names, and if we can get an attractive=20
>>> proposition, based on tags, we can mark at least one part (the harder=
=20
>>> part?) of the named arguments equation "fixed".=20
>>>
>>> I would like to see the two features proposed independently.=20
>>>
>>> I see more added value for weak named parameters that are optional and=
=20
>>> opt in on the author side (as the workarounds are not always friendly) =
than=20
>>> the strong named parameters that can be used to overload function or=20
>>> constructors and that are not optional (as tag types are an almost frie=
ndly=20
>>> library solution, as the standard library has showed already multiple=
=20
>>> times).
>>>
>>
>> The problem with having them be independent is that they're *not*=20
>> independent. They're both playing around in the same space: invoking a=
=20
>> parameter's name when you call the function.
>>
>> The first question any named parameter proposal has to answer is whether=
=20
>> to rely on the existing parameter name infrastructure or to use a specia=
l=20
>> way to define them. There are arguments for both weak and strong paramet=
ers=20
>> to want to have syntax to declare named parameters on a function. This i=
s=20
>> because, by having users rely on them to some degree (even if mis-matche=
d=20
>> naming is just a warning), you are making those parameter names part of =
the=20
>> interface of the API. And that's different from how parameter names have=
=20
>> been treated in the past.
>>
>> I'm not for strong named parameters. For me, this is a disguised form of=
=20
>> mixing weak named parameters and tag dispatching. This is why I believe =
the=20
>> features are independent.
>> Now you can put them together and obtain named parameters and tag=20
>> dispatch.
>>
>
>> If you try to develop weak and strong parameters completely=20
>> independently, then what you can end up with are two proposals that prov=
ide=20
>> completely different ways of declaring such parameters. And considering =
all=20
>> of the stuff that we keep cramming into function declarations these days=
,=20
>> giving parameters *three names* is utterly absurd. Even if you forbid=20
>> weak parameter names on functions with strong names, that's still 3=20
>> separate syntaxes for declaring parameter names.
>>
>> If we want weak and strong named parameters and don't see another=20
>> solution than having two syntaxes :(
>>
>
> If that's the case, then we shouldn't have weak named parameters at all.=
=20
> Remember: weak named parameters are purely notational; they catch errors.=
=20
> That makes them a "nice to have". Strong named parameters provide genuine=
=20
> functionality, allowing you to express things that could not be expressed=
=20
> before.
>
> If the design space is sufficiently constrained to only permit one or the=
=20
> other, then it should be the one that actually does something.
>
> I don't believe that we want non op in named parametrs, so each one of th=
e=20
>> weak/strong alternatives would need a specific syntax.
>>
>>
>> So I don't think it's reasonable to develop the two proposals completely=
=20
>> independently from one another. They should at least be developed with t=
he=20
>> knowledge that the other is a possibility, and with syntax that can=20
>> reasonably fit together.
>>
>> Maybe you are right, but I would like that the proposal are clearly=20
>> separated, so that we can be agains one from or the other.
>>
>
> So, you can't be against one part of a proposal? The standards committee=
=20
> does it all the time.
>
>> Lastly, it should be noted that tagged dispatch doesn't help with what I=
=20
>> will refer to as "mega-functions": functions that take stupidly large=20
>> numbers of relatively independent parameters, but for some reason don't=
=20
>> want to take them as a convenient aggregate. This is a use case that som=
e=20
>> people want to support, to avoid conceptual two-stage construction.
>>
>> IMHO, this case is covered by weak named parameters already.
>>
>
> =20

> Then perhaps you're not understanding what a "mega-function" is. We're=20
> talking about functions with *dozens* of parameters, most of which are=20
> optional. Consider all of the various parameters you deal with when setti=
ng=20
> up a window. Window styles, size, position, hierarchy, font choice, and=
=20
> other things. Each of those are conceptually one or more parameters to th=
e=20
> window creation function.
>
> "Ideally", these would be literal parameters to a hypothetical Window=20
> class's constructor. But they're not; most such classes give relatively=
=20
> limited numbers of parameters to the Window's constructor. The rest are=
=20
> values set after the Window's construction, which means that defaults are=
=20
> used until those get set. Basically, it's two-stage construction.
>
> The only way you can get the "ideal" case is if order for parameters is *=
completely=20
> removed* for such functions. You can specify the arguments in any order=
=20
> when you call them, and the caller can default any parameter with a defau=
lt=20
> value simply by not specifying it.
>
> Weak named parameters can't do that. Tag dispatch can't do that (not=20
> without extraordinary pain on the callee side). Even designated=20
> initializers have to be specified in the right order.
>

Are sure about that? Argument rearrangement is doable without changing the=
=20
signature (a.k.a. strong)=20

Where do you think it will fail?=20


> If you accept that your signature changes and require that the argument=
=20
>> must be named, strong named parameters could as well cover it.
>>
>> If you don't accept that your signature changes and require that the=20
>> argument must be named, weak named parameters + some static analysis too=
l=20
>> (as clang-tidy) help could as well cover it (but not that the syantax wi=
ll=20
>> be already defined by the standard).
>>
>> Maybe we need strong named parameters that don't change the signatures a=
s=20
>> well ;-)
>>
>> Vicente=20
>>
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/89483da2-1435-49ef-94ea-d9d90fbac549%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Monday, August 20, 2018 at 6:37:39 PM UTC+3, Ni=
col Bolas 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"lt=
r"><br><br>On Monday, August 20, 2018 at 2:15:17 AM UTC-4, Vicente J. Botet=
 Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>Le 19/08/2018 =C3=A0 23:53, Nicol Bolas a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
     =20
      <div dir=3D"ltr"><br>
        <br>
        On Sunday, August 19, 2018 at 5:21:11 PM UTC-4, Vicente J. Botet
        Escriba wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
            <div>Le 19/08/2018 =C3=A0 19:22, <a rel=3D"nofollow">mihailn...=
@gmail.com</a> a
              =C3=A9crit=C2=A0:<br>
            </div>
            <blockquote type=3D"cite">
              <div dir=3D"ltr"><br>
                <br>
                On Sunday, August 19, 2018 at 7:46:58 PM UTC+3, Vicente
                J. Botet Escriba wrote:
                <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
                  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
                    <div>Le 19/08/2018 =C3=A0 15:04, <a rel=3D"nofollow">mi=
hailn...@gmail.com</a>
                      a =C3=A9crit=C2=A0:<br>
                    </div>
                    <blockquote type=3D"cite">
                      <div dir=3D"ltr"><br>
                        <br>
                        On Sunday, August 19, 2018 at 3:26:12 PM UTC+3,
                        Vicente J. Botet Escriba wrote:
                        <blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Independent=
ly of
                          the language feature, using a tag type allows
                          to <br>
                          transport the tag between different functions.
                          In addition, you cannot <br>
                          change the class constructor name, so you will
                          need a tag to be able to <br>
                          overload it. Take for example the in_place_t
                          tag. <br>
                        </blockquote>
                        <div><br>
                        </div>
                        <div>I have thoroughly explored that idea a
                          month back:=C2=A0<a onmousedown=3D"this.href=3D&#=
39;https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2GXb0/4=
OjT5Z4pBQAJ&#39;;return true;" onclick=3D"this.href=3D&#39;https://groups.g=
oogle.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2GXb0/4OjT5Z4pBQAJ&#39;;re=
turn true;" href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-propos=
als/tPtdQE2GXb0/4OjT5Z4pBQAJ" target=3D"_blank" rel=3D"nofollow">https://gr=
oups.google.<wbr>com/a/isocpp.org/d/msg/std-<wbr>proposals/tPtdQE2GXb0/<wbr=
>4OjT5Z4pBQAJ</a></div>
                        <div><br>
                        </div>
                        <div>Feel free to comment there, I am undecided
                          on the topic.=C2=A0</div>
                        <div><br>
                        </div>
                        <div>=C2=A0</div>
                      </div>
                    </blockquote>
                    I&#39;m not sure yet we need some syntactic sugar for
                    this tag dispatching feature neither.<br>
                    I&#39;m just trying to separate the named parameter par=
t
                    from the overload part as orthogonal features.<br>
                    You go too far for my taste in your proposal and you
                    propose to have all at once. I&#39;ll be against such a
                    feature.<br>
                  </div>
                </blockquote>
                <div><br>
                </div>
                <div>Can you elaborate a bit more, what are your
                  expectations and where should a line be drawn? As you
                  can see in the comments to the post, there are similar
                  concerns.</div>
                <div>In any case it is not a proposal, but an <span style=
=3D"display:inline!important;float:none;background-color:transparent;color:=
rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-seri=
f;font-size:13px;font-style:normal;font-variant:normal;font-weight:400;lett=
er-spacing:normal;text-align:left;text-decoration:none;text-indent:0px;text=
-transform:none;white-space:normal;word-spacing:0px">investigation.
                  </span><span style=3D"display:inline!important;float:none=
;background-color:transparent;color:rgb(34,34,34);font-family:&quot;Arial&q=
uot;,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-style:normal;font=
-variant:normal;font-weight:400;letter-spacing:normal;text-align:left;text-=
decoration:none;text-indent:0px;text-transform:none;white-space:normal;word=
-spacing:0px">It
                    is clear tags have overlap with strong names, and if
                    we can get an attractive proposition, based on tags,
                    we can mark at least one part (the harder part?) of
                    the named arguments equation &quot;fixed&quot;.=C2=A0</=
span></div>
                <div><span style=3D"display:inline!important;float:none;bac=
kground-color:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;=
,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-style:normal;font-var=
iant:normal;font-weight:400;letter-spacing:normal;text-align:left;text-deco=
ration:none;text-indent:0px;text-transform:none;white-space:normal;word-spa=
cing:0px"><br>
                  </span></div>
              </div>
            </blockquote>
            I would like to see the two features proposed independently.
            <br>
            <br>
            I see more added value for weak named parameters that are
            optional and opt in on the author side (as the workarounds
            are not always friendly) than the strong named parameters
            that can be used to overload function or constructors and
            that are not optional (as tag types are an almost friendly
            library solution, as the standard library has showed already
            multiple times).<br>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>The problem with having them be independent is that they&#39;r=
e
          <i>not</i> independent. They&#39;re both playing around in the
          same space: invoking a parameter&#39;s name when you call the
          function.</div>
        <div><br>
        </div>
        <div>The first question any named parameter proposal has to
          answer is whether to rely on the existing parameter name
          infrastructure or to use a special way to define them. There
          are arguments for both weak and strong parameters to want to
          have syntax to declare named parameters on a function. This is
          because, by having users rely on them to some degree (even if
          mis-matched naming is just a warning), you are making those
          parameter names part of the interface of the API. And that&#39;s
          different from how parameter names have been treated in the
          past.</div>
      </div>
    </blockquote>
    I&#39;m not for strong named parameters. For me, this is a disguised
    form of mixing weak named parameters and tag dispatching. This is
    why I believe the features are independent.<br>
    Now you can put them together and obtain named parameters and tag
    dispatch.</div></blockquote><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v bgcolor=3D"#FFFFFF" text=3D"#000000"><blockquote type=3D"cite"><div dir=
=3D"ltr"><br><div>If you try to develop weak and strong parameters complete=
ly
          independently, then what you can end up with are two proposals
          that provide completely different ways of declaring such
          parameters. And considering all of the stuff that we keep
          cramming into function declarations these days, giving
          parameters <i>three names</i> is utterly absurd. Even if you
          forbid weak parameter names on functions with strong names,
          that&#39;s still 3 separate syntaxes for declaring parameter
          names.</div>
      </div>
    </blockquote>
    If we want weak and strong named parameters and don&#39;t see another
    solution than having two syntaxes :(<br></div></blockquote><div><br></d=
iv><div>If that&#39;s the case, then we shouldn&#39;t have weak named param=
eters at all. Remember: weak named parameters are purely notational; they c=
atch errors. That makes them a &quot;nice to have&quot;. Strong named param=
eters provide genuine functionality, allowing you to express things that co=
uld not be expressed before.</div><div><br></div><div>If the design space i=
s sufficiently constrained to only permit one or the other, then it should =
be the one that actually does something.<br></div><div><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
   =20
    I don&#39;t believe that we want non op in named parametrs, so each one
    of the weak/strong alternatives would need a specific syntax.<br>
    <br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>So I don&#39;t think it&#39;s reasonable to develop the two
          proposals completely independently from one another. They
          should at least be developed with the knowledge that the other
          is a possibility, and with syntax that can reasonably fit
          together.</div>
      </div>
    </blockquote>
    Maybe you are right, but I would like that the proposal are clearly
    separated, so that we can be agains one from or the other.<br></div></b=
lockquote><div><br></div><div>So, you can&#39;t be against one part of a pr=
oposal? The standards committee does it all the time.<br></div><div></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#00=
0000">
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
        </div>
        <div>Lastly, it should be noted that tagged dispatch doesn&#39;t
          help with what I will refer to as &quot;mega-functions&quot;: fun=
ctions
          that take stupidly large numbers of relatively independent
          parameters, but for some reason don&#39;t want to take them as a
          convenient aggregate. This is a use case that some people want
          to support, to avoid conceptual two-stage construction.<br>
        </div>
      </div>
    </blockquote>
    IMHO, this case is covered by weak named parameters already.<br></div><=
/blockquote><div><br></div></div></blockquote><div>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>Then perh=
aps you&#39;re not understanding what a &quot;mega-function&quot; is. We&#3=
9;re talking about functions with <i>dozens</i> of parameters, most of whic=
h are optional. Consider all of the various parameters you deal with when s=
etting up a window. Window styles, size, position, hierarchy, font choice, =
and other things. Each of those are conceptually one or more parameters to =
the window creation function.</div><div><br></div><div>&quot;Ideally&quot;,=
 these would be literal parameters to a hypothetical Window class&#39;s con=
structor. But they&#39;re not; most such classes give relatively limited nu=
mbers of parameters to the Window&#39;s constructor. The rest are values se=
t after the Window&#39;s construction, which means that defaults are used u=
ntil those get set. Basically, it&#39;s two-stage construction.<br></div><d=
iv><br></div><div>The only way you can get the &quot;ideal&quot; case is if=
 order for parameters is <i>completely removed</i> for such functions. You =
can specify the arguments in any order when you call them, and the caller c=
an default any parameter with a default value simply by not specifying it.<=
/div><div><br></div><div>Weak named parameters can&#39;t do that. Tag dispa=
tch can&#39;t do that (not without extraordinary pain on the callee side). =
Even designated initializers have to be specified in the right order.<br></=
div></div></blockquote><div><br></div><div><div style=3D"background-color: =
transparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: non=
e; border-bottom-width: 0px; border-image-outset: 0; border-image-repeat: s=
tretch; border-image-slice: 100%; border-image-source: none; border-image-w=
idth: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; borde=
r-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style:=
 none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-t=
op-style: none; border-top-width: 0px; color: rgb(34, 34, 34); font-family:=
 &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-s=
ize: 13px; font-style: normal; font-variant: normal; font-weight: 400; lett=
er-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px=
; margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padd=
ing-right: 0px; padding-top: 0px; text-align: left; text-decoration: none; =
text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; whi=
te-space: normal; word-spacing: 0px;">Are sure about that? Argument rearran=
gement is doable without changing the signature (a.k.a. strong)=C2=A0</div>=
<div style=3D"background-color: transparent; border-bottom-color: rgb(34, 3=
4, 34); border-bottom-style: none; border-bottom-width: 0px; border-image-o=
utset: 0; border-image-repeat: stretch; border-image-slice: 100%; border-im=
age-source: none; border-image-width: 1; border-left-color: rgb(34, 34, 34)=
; border-left-style: none; border-left-width: 0px; border-right-color: rgb(=
34, 34, 34); border-right-style: none; border-right-width: 0px; border-top-=
color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; colo=
r: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvet=
ica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-variant=
: normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; mar=
gin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bott=
om: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-alig=
n: left; text-decoration: none; text-indent: 0px; text-transform: none; -we=
bkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"><br><=
/div><div style=3D"background-color: transparent; border-bottom-color: rgb(=
34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-im=
age-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; bord=
er-image-source: none; border-image-width: 1; border-left-color: rgb(34, 34=
, 34); border-left-style: none; border-left-width: 0px; border-right-color:=
 rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; border=
-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px;=
 color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;H=
elvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-va=
riant: normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0px=
; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding=
-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text=
-align: left; text-decoration: none; text-indent: 0px; text-transform: none=
; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">=
Where do you think it will fail?=C2=A0</div><div style=3D"background-color:=
 transparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: no=
ne; border-bottom-width: 0px; border-image-outset: 0; border-image-repeat: =
stretch; border-image-slice: 100%; border-image-source: none; border-image-=
width: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; bord=
er-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style=
: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-=
top-style: none; border-top-width: 0px; color: rgb(34, 34, 34); font-family=
: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-=
size: 13px; font-style: normal; font-variant: normal; font-weight: 400; let=
ter-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0p=
x; margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; pad=
ding-right: 0px; padding-top: 0px; text-align: left; text-decoration: none;=
 text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; wh=
ite-space: normal; word-spacing: 0px;"><br></div></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div></div><div><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=
=3D"#000000">
    If you accept that your signature changes and require that the
    argument must be named, strong named parameters could as well cover
    it.<br>
    <br>
    If you don&#39;t accept that your signature changes and require that th=
e
    argument must be named, weak named parameters + some static analysis
    tool (as clang-tidy) help could as well cover it (but not that the
    syantax will be already defined by the standard).<br>
    <br>
    Maybe we need strong named parameters that don&#39;t change the
    signatures as well ;-)<br>
    <br>
    Vicente
  </div>

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

<p></p>

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

------=_Part_1594_636285012.1534782020445--

------=_Part_1593_898653651.1534782020444--

.

------=_Part_490_2044119226.1534790702057
Content-Type: multipart/alternative;
 boundary="----=_Part_491_1793215703.1534790702058"

------=_Part_491_1793215703.1534790702058
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Monday, August 20, 2018 at 12:20:20 PM UTC-4, mihailn...@gmail.com wrote=
:
>
>
>
> On Monday, August 20, 2018 at 6:37:39 PM UTC+3, Nicol Bolas wrote:
>>
>>
>>
>> On Monday, August 20, 2018 at 2:15:17 AM UTC-4, Vicente J. Botet Escriba=
=20
>> wrote:
>>>
>>> Le 19/08/2018 =C3=A0 23:53, Nicol Bolas a =C3=A9crit :
>>>
>>>
>>>
>>> On Sunday, August 19, 2018 at 5:21:11 PM UTC-4, Vicente J. Botet Escrib=
a=20
>>> wrote:=20
>>>>
>>>> Le 19/08/2018 =C3=A0 19:22, mihailn...@gmail.com a =C3=A9crit :
>>>>
>>>>
>>>>
>>>> On Sunday, August 19, 2018 at 7:46:58 PM UTC+3, Vicente J. Botet=20
>>>> Escriba wrote:=20
>>>>>
>>>>> Le 19/08/2018 =C3=A0 15:04, mihailn...@gmail.com a =C3=A9crit :
>>>>>
>>>>>
>>>>>
>>>>> On Sunday, August 19, 2018 at 3:26:12 PM UTC+3, Vicente J. Botet=20
>>>>> Escriba wrote:=20
>>>>>>
>>>>>> Independently of the language feature, using a tag type allows to=20
>>>>>> transport the tag between different functions. In addition, you=20
>>>>>> cannot=20
>>>>>> change the class constructor name, so you will need a tag to be able=
=20
>>>>>> to=20
>>>>>> overload it. Take for example the in_place_t tag.=20
>>>>>>
>>>>>
>>>>> I have thoroughly explored that idea a month back:=20
>>>>> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2GXb=
0/4OjT5Z4pBQAJ
>>>>>
>>>>> Feel free to comment there, I am undecided on the topic.=20
>>>>>
>>>>> =20
>>>>>
>>>>> I'm not sure yet we need some syntactic sugar for this tag dispatchin=
g=20
>>>>> feature neither.
>>>>> I'm just trying to separate the named parameter part from the overloa=
d=20
>>>>> part as orthogonal features.
>>>>> You go too far for my taste in your proposal and you propose to have=
=20
>>>>> all at once. I'll be against such a feature.
>>>>>
>>>>
>>>> Can you elaborate a bit more, what are your expectations and where=20
>>>> should a line be drawn? As you can see in the comments to the post, th=
ere=20
>>>> are similar concerns.
>>>> In any case it is not a proposal, but an investigation. It is clear=20
>>>> tags have overlap with strong names, and if we can get an attractive=
=20
>>>> proposition, based on tags, we can mark at least one part (the harder=
=20
>>>> part?) of the named arguments equation "fixed".=20
>>>>
>>>> I would like to see the two features proposed independently.=20
>>>>
>>>> I see more added value for weak named parameters that are optional and=
=20
>>>> opt in on the author side (as the workarounds are not always friendly)=
 than=20
>>>> the strong named parameters that can be used to overload function or=
=20
>>>> constructors and that are not optional (as tag types are an almost fri=
endly=20
>>>> library solution, as the standard library has showed already multiple=
=20
>>>> times).
>>>>
>>>
>>> The problem with having them be independent is that they're *not*=20
>>> independent. They're both playing around in the same space: invoking a=
=20
>>> parameter's name when you call the function.
>>>
>>> The first question any named parameter proposal has to answer is whethe=
r=20
>>> to rely on the existing parameter name infrastructure or to use a speci=
al=20
>>> way to define them. There are arguments for both weak and strong parame=
ters=20
>>> to want to have syntax to declare named parameters on a function. This =
is=20
>>> because, by having users rely on them to some degree (even if mis-match=
ed=20
>>> naming is just a warning), you are making those parameter names part of=
 the=20
>>> interface of the API. And that's different from how parameter names hav=
e=20
>>> been treated in the past.
>>>
>>> I'm not for strong named parameters. For me, this is a disguised form o=
f=20
>>> mixing weak named parameters and tag dispatching. This is why I believe=
 the=20
>>> features are independent.
>>> Now you can put them together and obtain named parameters and tag=20
>>> dispatch.
>>>
>>
>>> If you try to develop weak and strong parameters completely=20
>>> independently, then what you can end up with are two proposals that pro=
vide=20
>>> completely different ways of declaring such parameters. And considering=
 all=20
>>> of the stuff that we keep cramming into function declarations these day=
s,=20
>>> giving parameters *three names* is utterly absurd. Even if you forbid=
=20
>>> weak parameter names on functions with strong names, that's still 3=20
>>> separate syntaxes for declaring parameter names.
>>>
>>> If we want weak and strong named parameters and don't see another=20
>>> solution than having two syntaxes :(
>>>
>>
>> If that's the case, then we shouldn't have weak named parameters at all.=
=20
>> Remember: weak named parameters are purely notational; they catch errors=
..=20
>> That makes them a "nice to have". Strong named parameters provide genuin=
e=20
>> functionality, allowing you to express things that could not be expresse=
d=20
>> before.
>>
>> If the design space is sufficiently constrained to only permit one or th=
e=20
>> other, then it should be the one that actually does something.
>>
>> I don't believe that we want non op in named parametrs, so each one of=
=20
>>> the weak/strong alternatives would need a specific syntax.
>>>
>>>
>>> So I don't think it's reasonable to develop the two proposals completel=
y=20
>>> independently from one another. They should at least be developed with =
the=20
>>> knowledge that the other is a possibility, and with syntax that can=20
>>> reasonably fit together.
>>>
>>> Maybe you are right, but I would like that the proposal are clearly=20
>>> separated, so that we can be agains one from or the other.
>>>
>>
>> So, you can't be against one part of a proposal? The standards committee=
=20
>> does it all the time.
>>
>>> Lastly, it should be noted that tagged dispatch doesn't help with what =
I=20
>>> will refer to as "mega-functions": functions that take stupidly large=
=20
>>> numbers of relatively independent parameters, but for some reason don't=
=20
>>> want to take them as a convenient aggregate. This is a use case that so=
me=20
>>> people want to support, to avoid conceptual two-stage construction.
>>>
>>> IMHO, this case is covered by weak named parameters already.
>>>
>>
>> =20
>
>> Then perhaps you're not understanding what a "mega-function" is. We're=
=20
>> talking about functions with *dozens* of parameters, most of which are=
=20
>> optional. Consider all of the various parameters you deal with when sett=
ing=20
>> up a window. Window styles, size, position, hierarchy, font choice, and=
=20
>> other things. Each of those are conceptually one or more parameters to t=
he=20
>> window creation function.
>>
>> "Ideally", these would be literal parameters to a hypothetical Window=20
>> class's constructor. But they're not; most such classes give relatively=
=20
>> limited numbers of parameters to the Window's constructor. The rest are=
=20
>> values set after the Window's construction, which means that defaults ar=
e=20
>> used until those get set. Basically, it's two-stage construction.
>>
>> The only way you can get the "ideal" case is if order for parameters is =
*completely=20
>> removed* for such functions. You can specify the arguments in any order=
=20
>> when you call them, and the caller can default any parameter with a defa=
ult=20
>> value simply by not specifying it.
>>
>> Weak named parameters can't do that. Tag dispatch can't do that (not=20
>> without extraordinary pain on the callee side). Even designated=20
>> initializers have to be specified in the right order.
>>
>
> Are sure about that? Argument rearrangement is doable without changing th=
e=20
> signature (a.k.a. strong)
>

Maybe we have very different ideas about what "strong named parameters"=20
means. The question of "changing the signature" is not the distinction=20
between "strong" and "weak". At least, it's not the distinction that I'm=20
talking about it.

"Weak named parameters" to me refers to named parameters which are all of=
=20
the following:

1. Optional. You can call a function that has named parameters without=20
naming the parameter(s) at the call site.
2. Ordered. The order of the arguments must match the parameter order of=20
the function, regardless of the names you specify at the call site.
3. Overload-neutral. The presence or absence of names at the call site has=
=20
no effect on function overloading.

Essentially, if your rules require that all named parameter function calls=
=20
will invoke the same function with the same behavior if you stripped out=20
all of the names, then the named parameter proposal is "weak".

Any named parameter feature which imposes rules antithetical to at least=20
one of the above is "strong". With the strongest being the antithesis to=20
all of them.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/333693b1-38a8-424f-bc15-0b36131b97f4%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Monday, August 20, 2018 at 12:20:20 PM UTC-4, m=
ihailn...@gmail.com 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><br>On Monday, August 20, 2018 at 6:37:39 PM UTC+3, Nicol =
Bolas 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><b=
r>On Monday, August 20, 2018 at 2:15:17 AM UTC-4, Vicente J. Botet Escriba =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>Le 19/08/2018 =C3=A0 23:53, Nicol Bolas a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
     =20
      <div dir=3D"ltr"><br>
        <br>
        On Sunday, August 19, 2018 at 5:21:11 PM UTC-4, Vicente J. Botet
        Escriba wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
            <div>Le 19/08/2018 =C3=A0 19:22, <a rel=3D"nofollow">mihailn...=
@gmail.com</a> a
              =C3=A9crit=C2=A0:<br>
            </div>
            <blockquote type=3D"cite">
              <div dir=3D"ltr"><br>
                <br>
                On Sunday, August 19, 2018 at 7:46:58 PM UTC+3, Vicente
                J. Botet Escriba wrote:
                <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
                  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
                    <div>Le 19/08/2018 =C3=A0 15:04, <a rel=3D"nofollow">mi=
hailn...@gmail.com</a>
                      a =C3=A9crit=C2=A0:<br>
                    </div>
                    <blockquote type=3D"cite">
                      <div dir=3D"ltr"><br>
                        <br>
                        On Sunday, August 19, 2018 at 3:26:12 PM UTC+3,
                        Vicente J. Botet Escriba wrote:
                        <blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Independent=
ly of
                          the language feature, using a tag type allows
                          to <br>
                          transport the tag between different functions.
                          In addition, you cannot <br>
                          change the class constructor name, so you will
                          need a tag to be able to <br>
                          overload it. Take for example the in_place_t
                          tag. <br>
                        </blockquote>
                        <div><br>
                        </div>
                        <div>I have thoroughly explored that idea a
                          month back:=C2=A0<a href=3D"https://groups.google=
..com/a/isocpp.org/d/msg/std-proposals/tPtdQE2GXb0/4OjT5Z4pBQAJ" rel=3D"nofo=
llow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;https://groups.goog=
le.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2GXb0/4OjT5Z4pBQAJ&#39;;retur=
n true;" onclick=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org=
/d/msg/std-proposals/tPtdQE2GXb0/4OjT5Z4pBQAJ&#39;;return true;">https://gr=
oups.google.<wbr>com/a/isocpp.org/d/msg/std-<wbr>proposals/tPtdQE2GXb0/<wbr=
>4OjT5Z4pBQAJ</a></div>
                        <div><br>
                        </div>
                        <div>Feel free to comment there, I am undecided
                          on the topic.=C2=A0</div>
                        <div><br>
                        </div>
                        <div>=C2=A0</div>
                      </div>
                    </blockquote>
                    I&#39;m not sure yet we need some syntactic sugar for
                    this tag dispatching feature neither.<br>
                    I&#39;m just trying to separate the named parameter par=
t
                    from the overload part as orthogonal features.<br>
                    You go too far for my taste in your proposal and you
                    propose to have all at once. I&#39;ll be against such a
                    feature.<br>
                  </div>
                </blockquote>
                <div><br>
                </div>
                <div>Can you elaborate a bit more, what are your
                  expectations and where should a line be drawn? As you
                  can see in the comments to the post, there are similar
                  concerns.</div>
                <div>In any case it is not a proposal, but an <span style=
=3D"display:inline!important;float:none;background-color:transparent;color:=
rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-seri=
f;font-size:13px;font-style:normal;font-variant:normal;font-weight:400;lett=
er-spacing:normal;text-align:left;text-decoration:none;text-indent:0px;text=
-transform:none;white-space:normal;word-spacing:0px">investigation.
                  </span><span style=3D"display:inline!important;float:none=
;background-color:transparent;color:rgb(34,34,34);font-family:&quot;Arial&q=
uot;,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-style:normal;font=
-variant:normal;font-weight:400;letter-spacing:normal;text-align:left;text-=
decoration:none;text-indent:0px;text-transform:none;white-space:normal;word=
-spacing:0px">It
                    is clear tags have overlap with strong names, and if
                    we can get an attractive proposition, based on tags,
                    we can mark at least one part (the harder part?) of
                    the named arguments equation &quot;fixed&quot;.=C2=A0</=
span></div>
                <div><span style=3D"display:inline!important;float:none;bac=
kground-color:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;=
,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-style:normal;font-var=
iant:normal;font-weight:400;letter-spacing:normal;text-align:left;text-deco=
ration:none;text-indent:0px;text-transform:none;white-space:normal;word-spa=
cing:0px"><br>
                  </span></div>
              </div>
            </blockquote>
            I would like to see the two features proposed independently.
            <br>
            <br>
            I see more added value for weak named parameters that are
            optional and opt in on the author side (as the workarounds
            are not always friendly) than the strong named parameters
            that can be used to overload function or constructors and
            that are not optional (as tag types are an almost friendly
            library solution, as the standard library has showed already
            multiple times).<br>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>The problem with having them be independent is that they&#39;r=
e
          <i>not</i> independent. They&#39;re both playing around in the
          same space: invoking a parameter&#39;s name when you call the
          function.</div>
        <div><br>
        </div>
        <div>The first question any named parameter proposal has to
          answer is whether to rely on the existing parameter name
          infrastructure or to use a special way to define them. There
          are arguments for both weak and strong parameters to want to
          have syntax to declare named parameters on a function. This is
          because, by having users rely on them to some degree (even if
          mis-matched naming is just a warning), you are making those
          parameter names part of the interface of the API. And that&#39;s
          different from how parameter names have been treated in the
          past.</div>
      </div>
    </blockquote>
    I&#39;m not for strong named parameters. For me, this is a disguised
    form of mixing weak named parameters and tag dispatching. This is
    why I believe the features are independent.<br>
    Now you can put them together and obtain named parameters and tag
    dispatch.</div></blockquote><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v bgcolor=3D"#FFFFFF" text=3D"#000000"><blockquote type=3D"cite"><div dir=
=3D"ltr"><br><div>If you try to develop weak and strong parameters complete=
ly
          independently, then what you can end up with are two proposals
          that provide completely different ways of declaring such
          parameters. And considering all of the stuff that we keep
          cramming into function declarations these days, giving
          parameters <i>three names</i> is utterly absurd. Even if you
          forbid weak parameter names on functions with strong names,
          that&#39;s still 3 separate syntaxes for declaring parameter
          names.</div>
      </div>
    </blockquote>
    If we want weak and strong named parameters and don&#39;t see another
    solution than having two syntaxes :(<br></div></blockquote><div><br></d=
iv><div>If that&#39;s the case, then we shouldn&#39;t have weak named param=
eters at all. Remember: weak named parameters are purely notational; they c=
atch errors. That makes them a &quot;nice to have&quot;. Strong named param=
eters provide genuine functionality, allowing you to express things that co=
uld not be expressed before.</div><div><br></div><div>If the design space i=
s sufficiently constrained to only permit one or the other, then it should =
be the one that actually does something.<br></div><div><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
   =20
    I don&#39;t believe that we want non op in named parametrs, so each one
    of the weak/strong alternatives would need a specific syntax.<br>
    <br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>So I don&#39;t think it&#39;s reasonable to develop the two
          proposals completely independently from one another. They
          should at least be developed with the knowledge that the other
          is a possibility, and with syntax that can reasonably fit
          together.</div>
      </div>
    </blockquote>
    Maybe you are right, but I would like that the proposal are clearly
    separated, so that we can be agains one from or the other.<br></div></b=
lockquote><div><br></div><div>So, you can&#39;t be against one part of a pr=
oposal? The standards committee does it all the time.<br></div><div></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#00=
0000">
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
        </div>
        <div>Lastly, it should be noted that tagged dispatch doesn&#39;t
          help with what I will refer to as &quot;mega-functions&quot;: fun=
ctions
          that take stupidly large numbers of relatively independent
          parameters, but for some reason don&#39;t want to take them as a
          convenient aggregate. This is a use case that some people want
          to support, to avoid conceptual two-stage construction.<br>
        </div>
      </div>
    </blockquote>
    IMHO, this case is covered by weak named parameters already.<br></div><=
/blockquote><div><br></div></div></blockquote><div>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>Then perhaps y=
ou&#39;re not understanding what a &quot;mega-function&quot; is. We&#39;re =
talking about functions with <i>dozens</i> of parameters, most of which are=
 optional. Consider all of the various parameters you deal with when settin=
g up a window. Window styles, size, position, hierarchy, font choice, and o=
ther things. Each of those are conceptually one or more parameters to the w=
indow creation function.</div><div><br></div><div>&quot;Ideally&quot;, thes=
e would be literal parameters to a hypothetical Window class&#39;s construc=
tor. But they&#39;re not; most such classes give relatively limited numbers=
 of parameters to the Window&#39;s constructor. The rest are values set aft=
er the Window&#39;s construction, which means that defaults are used until =
those get set. Basically, it&#39;s two-stage construction.<br></div><div><b=
r></div><div>The only way you can get the &quot;ideal&quot; case is if orde=
r for parameters is <i>completely removed</i> for such functions. You can s=
pecify the arguments in any order when you call them, and the caller can de=
fault any parameter with a default value simply by not specifying it.</div>=
<div><br></div><div>Weak named parameters can&#39;t do that. Tag dispatch c=
an&#39;t do that (not without extraordinary pain on the callee side). Even =
designated initializers have to be specified in the right order.<br></div><=
/div></blockquote><div><br></div><div><div>Are sure about that? Argument re=
arrangement is doable without changing the signature (a.k.a. strong)</div><=
/div></div></blockquote><div><br></div><div>Maybe we have very different id=
eas about what &quot;strong named parameters&quot; means. The question of &=
quot;changing the signature&quot; is not the distinction between=20
&quot;strong&quot; and &quot;weak&quot;. At least, it&#39;s not the distinc=
tion that I&#39;m talking about it.</div><div><br></div><div>&quot;Weak nam=
ed parameters&quot; to me refers to named parameters which are all of the f=
ollowing:</div><div><br></div><div>1. Optional. You can call a function tha=
t has named parameters without naming the parameter(s) at the call site.</d=
iv><div>2. Ordered. The order of the arguments must match the parameter ord=
er of the function, regardless of the names you specify at the call site.<b=
r></div><div>3. Overload-neutral. The presence or absence of names at the c=
all site has no effect on function overloading.</div><div><br></div><div>Es=
sentially, if your rules require that all named parameter function calls wi=
ll invoke the same function with the same behavior if you stripped out all =
of the names, then the named parameter proposal is &quot;weak&quot;.<br></d=
iv><div><br></div><div></div><div>Any named parameter feature which imposes=
 rules antithetical to at least one of the above is &quot;strong&quot;. Wit=
h the strongest being the antithesis to all of them.<br></div></div>

<p></p>

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

------=_Part_491_1793215703.1534790702058--

------=_Part_490_2044119226.1534790702057--

.

--0000000000004d63a80573e2edde
Content-Type: text/plain; charset="UTF-8"

On Mon, Aug 20, 2018 at 2:45 PM Nicol Bolas <jmckesson@gmail.com> wrote:

> "Weak named parameters" to me refers to named parameters which are all of
> the following:
>
> 1. Optional. You can call a function that has named parameters without
> naming the parameter(s) at the call site.
> 2. Ordered. The order of the arguments must match the parameter order of
> the function, regardless of the names you specify at the call site.
> 3. Overload-neutral. The presence or absence of names at the call site has
> no effect on function overloading.
>
> Essentially, if your rules require that all named parameter function calls
> will invoke the same function with the same behavior if you stripped out
> all of the names, then the named parameter proposal is "weak".
>
> Any named parameter feature which imposes rules antithetical to at least
> one of the above is "strong". With the strongest being the antithesis to
> all of them.
>

Just for reference, Ada has
1.  Optional/Mixed: You may call a function with a number of leading
positional arguments followed by named ones:
        my_proc(1, 2, 3, foo => 7, bar => 9);
2.  Not Ordered: named arguments can be specified in any order, after any
ordered positional ones
3.  Affects Overloading:  See <
https://www2.adacore.com/gap-static/GNAT_Book/html/node10.htm>

Ada has the caveat that "... operations that only differ in the names of
the formal parameters,
but not their types, cannot be visible at the same point: either one hides
the other through
scope and visibility rules, or else the declarations are illegal."
However, you can still have

    *function* F(A: Integer, B: Integer := 0) *return* Integer;
    *function* F(C: Integer                 ) *return* Integer;

and the call f(5) will be ambiguous, while the call f(C => 5) will call the
second function.

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

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Aug 20=
, 2018 at 2:45 PM Nicol Bolas &lt;<a href=3D"mailto:jmckesson@gmail.com">jm=
ckesson@gmail.com</a>&gt; wrote:</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr"><div>&quot;Weak named parameters&quot; to me =
refers to named parameters which are all of the following:</div><div><br></=
div><div>1. Optional. You can call a function that has named parameters wit=
hout naming the parameter(s) at the call site.</div><div>2. Ordered. The or=
der of the arguments must match the parameter order of the function, regard=
less of the names you specify at the call site.<br></div><div>3. Overload-n=
eutral. The presence or absence of names at the call site has no effect on =
function overloading.</div><div><br></div><div>Essentially, if your rules r=
equire that all named parameter function calls will invoke the same functio=
n with the same behavior if you stripped out all of the names, then the nam=
ed parameter proposal is &quot;weak&quot;.<br></div><div><br></div><div></d=
iv><div>Any named parameter feature which imposes rules antithetical to at =
least one of the above is &quot;strong&quot;. With the strongest being the =
antithesis to all of them.</div></div></blockquote><div><br>Just for refere=
nce, Ada has<br>1.=C2=A0 Optional/Mixed: You may call a function with a num=
ber of leading positional arguments followed by named ones:<br>=C2=A0<font =
face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0my_proc(1, 2, 3, f=
oo =3D&gt; 7, bar =3D&gt; 9);</font><br>2.=C2=A0 Not Ordered: named argumen=
ts can be specified in any order, after any ordered positional ones<br>3.=
=C2=A0 Affects Overloading:=C2=A0 See &lt;<a href=3D"https://www2.adacore.c=
om/gap-static/GNAT_Book/html/node10.htm">https://www2.adacore.com/gap-stati=
c/GNAT_Book/html/node10.htm</a>&gt;<br><br>Ada has the caveat that &quot;<s=
pan style=3D"color:rgb(0,0,0);font-size:medium"><font face=3D"Times New Rom=
an">... operations that only differ in the names of the formal parameters,<=
/font><br><font face=3D"Times New Roman">but not their types, cannot be vis=
ible at the same point: either one hides the other through</font><br><font =
face=3D"Times New Roman">scope and visibility rules, or else the declaratio=
ns are illegal.&quot;=C2=A0 However, you can still have</font><br><br><font=
 face=3D"monospace, monospace">=C2=A0 =C2=A0 </font><b style=3D"font-family=
:monospace,monospace">function</b><font face=3D"monospace, monospace"> F(A:=
 Integer, B: Integer :=3D 0) </font><b style=3D"font-family:monospace,monos=
pace">return</b><font face=3D"monospace, monospace"> Integer;</font><br><fo=
nt face=3D"monospace, monospace">=C2=A0 =C2=A0 </font><b style=3D"font-fami=
ly:monospace,monospace">function</b><font face=3D"monospace, monospace"> F(=
C: Integer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0) <=
/font><b style=3D"font-family:monospace,monospace">return</b><font face=3D"=
monospace, monospace"> Integer;</font><br><font face=3D"times new roman, se=
rif"><br>and the call </font><font face=3D"monospace, monospace">f(5)</font=
><font face=3D"times new roman, serif"> will be ambiguous, while the call <=
/font><font face=3D"monospace, monospace">f(C =3D&gt; 5)</font><font face=
=3D"times new roman, serif"> will call the second function.</font></span></=
div></div></div>

<p></p>

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

--0000000000004d63a80573e2edde--

.

------=_Part_1242_1255399920.1534796314698
Content-Type: multipart/alternative;
 boundary="----=_Part_1243_199046079.1534796314699"

------=_Part_1243_199046079.1534796314699
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Monday, August 20, 2018 at 9:45:02 PM UTC+3, Nicol Bolas wrote:
>
>
>
> On Monday, August 20, 2018 at 12:20:20 PM UTC-4, mihailn...@gmail.com=20
> wrote:
>>
>>
>>
>> On Monday, August 20, 2018 at 6:37:39 PM UTC+3, Nicol Bolas wrote:
>>>
>>>
>>>
>>> On Monday, August 20, 2018 at 2:15:17 AM UTC-4, Vicente J. Botet Escrib=
a=20
>>> wrote:
>>>>
>>>> Le 19/08/2018 =C3=A0 23:53, Nicol Bolas a =C3=A9crit :
>>>>
>>>>
>>>>
>>>> On Sunday, August 19, 2018 at 5:21:11 PM UTC-4, Vicente J. Botet=20
>>>> Escriba wrote:=20
>>>>>
>>>>> Le 19/08/2018 =C3=A0 19:22, mihailn...@gmail.com a =C3=A9crit :
>>>>>
>>>>>
>>>>>
>>>>> On Sunday, August 19, 2018 at 7:46:58 PM UTC+3, Vicente J. Botet=20
>>>>> Escriba wrote:=20
>>>>>>
>>>>>> Le 19/08/2018 =C3=A0 15:04, mihailn...@gmail.com a =C3=A9crit :
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sunday, August 19, 2018 at 3:26:12 PM UTC+3, Vicente J. Botet=20
>>>>>> Escriba wrote:=20
>>>>>>>
>>>>>>> Independently of the language feature, using a tag type allows to=
=20
>>>>>>> transport the tag between different functions. In addition, you=20
>>>>>>> cannot=20
>>>>>>> change the class constructor name, so you will need a tag to be abl=
e=20
>>>>>>> to=20
>>>>>>> overload it. Take for example the in_place_t tag.=20
>>>>>>>
>>>>>>
>>>>>> I have thoroughly explored that idea a month back:=20
>>>>>> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2GX=
b0/4OjT5Z4pBQAJ
>>>>>>
>>>>>> Feel free to comment there, I am undecided on the topic.=20
>>>>>>
>>>>>> =20
>>>>>>
>>>>>> I'm not sure yet we need some syntactic sugar for this tag=20
>>>>>> dispatching feature neither.
>>>>>> I'm just trying to separate the named parameter part from the=20
>>>>>> overload part as orthogonal features.
>>>>>> You go too far for my taste in your proposal and you propose to have=
=20
>>>>>> all at once. I'll be against such a feature.
>>>>>>
>>>>> ...
>>>>>
>>>>> Lastly, it should be noted that tagged dispatch doesn't help with wha=
t=20
>>>> I will refer to as "mega-functions": functions that take stupidly larg=
e=20
>>>> numbers of relatively independent parameters, but for some reason don'=
t=20
>>>> want to take them as a convenient aggregate. This is a use case that s=
ome=20
>>>> people want to support, to avoid conceptual two-stage construction.
>>>>
>>>> IMHO, this case is covered by weak named parameters already.
>>>>
>>>
>>> =20
>>
>>> Then perhaps you're not understanding what a "mega-function" is. We're=
=20
>>> talking about functions with *dozens* of parameters, most of which are=
=20
>>> optional. Consider all of the various parameters you deal with when set=
ting=20
>>> up a window. Window styles, size, position, hierarchy, font choice, and=
=20
>>> other things. Each of those are conceptually one or more parameters to =
the=20
>>> window creation function.
>>>
>>> "Ideally", these would be literal parameters to a hypothetical Window=
=20
>>> class's constructor. But they're not; most such classes give relatively=
=20
>>> limited numbers of parameters to the Window's constructor. The rest are=
=20
>>> values set after the Window's construction, which means that defaults a=
re=20
>>> used until those get set. Basically, it's two-stage construction.
>>>
>>> The only way you can get the "ideal" case is if order for parameters is=
 *completely=20
>>> removed* for such functions. You can specify the arguments in any order=
=20
>>> when you call them, and the caller can default any parameter with a def=
ault=20
>>> value simply by not specifying it.
>>>
>>> Weak named parameters can't do that. Tag dispatch can't do that (not=20
>>> without extraordinary pain on the callee side). Even designated=20
>>> initializers have to be specified in the right order.
>>>
>>
>> =20

> Are sure about that? Argument rearrangement is doable without changing th=
e=20
>> signature (a.k.a. strong)
>>
>
> Maybe we have very different ideas about what "strong named parameters"=
=20
> means. The question of "changing the signature" is not the distinction=20
> between "strong" and "weak". At least, it's not the distinction that I'm=
=20
> talking about it.
>
> "Weak named parameters" to me refers to named parameters which are all of=
=20
> the following:
>
> 1. Optional. You can call a function that has named parameters without=20
> naming the parameter(s) at the call site.
> 2. Ordered. The order of the arguments must match the parameter order of=
=20
> the function, regardless of the names you specify at the call site.
> 3. Overload-neutral. The presence or absence of names at the call site ha=
s=20
> no effect on function overloading.
>
> Essentially, if your rules require that all named parameter function call=
s=20
> will invoke the same function with the same behavior if you stripped out=
=20
> all of the names, then the named parameter proposal is "weak".
>
> Any named parameter feature which imposes rules antithetical to at least=
=20
> one of the above is "strong". With the strongest being the antithesis to=
=20
> all of them.
>

I see, for you weak refers to the notion the call is the same, but=20
unchecked, without them.

For me strong is referring to "does it introduce a new signature", the same=
=20
way strong typedef introduces a new type. Everything else is weak as it is=
=20
about the compiler not the code.

Changing the signature is a clear boundary in both semantics and=20
implementation. =20

But in the realm of non-changing-the-signature names, a lot can be done,=20
granted the calls *will* differ w/ and w/o names.=20
Should it be done is a different matter, this is a debate as heated as the=
=20
one about signature - some people consider names useless if they don't=20
rearrange/skip defaults, some are happy with just checking alone. =20

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a9c81a6a-3fdb-41c3-afee-9e5041f6815f%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Monday, August 20, 2018 at 9:45:02 PM UTC+3, Ni=
col Bolas 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"lt=
r"><br><br>On Monday, August 20, 2018 at 12:20:20 PM UTC-4, <a>mihailn...@g=
mail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><br><br>On Monday, August 20, 2018 at 6:37:39 PM UTC+3, Nicol Bolas wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Monday,=
 August 20, 2018 at 2:15:17 AM UTC-4, Vicente J. Botet Escriba wrote:<block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div>Le 19/08/2018 =C3=A0 23:53, Nicol Bolas a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
     =20
      <div dir=3D"ltr"><br>
        <br>
        On Sunday, August 19, 2018 at 5:21:11 PM UTC-4, Vicente J. Botet
        Escriba wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
          <div text=3D"#000000" bgcolor=3D"#FFFFFF">
            <div>Le 19/08/2018 =C3=A0 19:22, <a rel=3D"nofollow">mihailn...=
@gmail.com</a> a
              =C3=A9crit=C2=A0:<br>
            </div>
            <blockquote type=3D"cite">
              <div dir=3D"ltr"><br>
                <br>
                On Sunday, August 19, 2018 at 7:46:58 PM UTC+3, Vicente
                J. Botet Escriba wrote:
                <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
                  <div text=3D"#000000" bgcolor=3D"#FFFFFF">
                    <div>Le 19/08/2018 =C3=A0 15:04, <a rel=3D"nofollow">mi=
hailn...@gmail.com</a>
                      a =C3=A9crit=C2=A0:<br>
                    </div>
                    <blockquote type=3D"cite">
                      <div dir=3D"ltr"><br>
                        <br>
                        On Sunday, August 19, 2018 at 3:26:12 PM UTC+3,
                        Vicente J. Botet Escriba wrote:
                        <blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Independent=
ly of
                          the language feature, using a tag type allows
                          to <br>
                          transport the tag between different functions.
                          In addition, you cannot <br>
                          change the class constructor name, so you will
                          need a tag to be able to <br>
                          overload it. Take for example the in_place_t
                          tag. <br>
                        </blockquote>
                        <div><br>
                        </div>
                        <div>I have thoroughly explored that idea a
                          month back:=C2=A0<a onmousedown=3D"this.href=3D&#=
39;https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2GXb0/4=
OjT5Z4pBQAJ&#39;;return true;" onclick=3D"this.href=3D&#39;https://groups.g=
oogle.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2GXb0/4OjT5Z4pBQAJ&#39;;re=
turn true;" href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-propos=
als/tPtdQE2GXb0/4OjT5Z4pBQAJ" target=3D"_blank" rel=3D"nofollow">https://gr=
oups.google.<wbr>com/a/isocpp.org/d/msg/std-<wbr>proposals/tPtdQE2GXb0/<wbr=
>4OjT5Z4pBQAJ</a></div>
                        <div><br>
                        </div>
                        <div>Feel free to comment there, I am undecided
                          on the topic.=C2=A0</div>
                        <div><br>
                        </div>
                        <div>=C2=A0</div>
                      </div>
                    </blockquote>
                    I&#39;m not sure yet we need some syntactic sugar for
                    this tag dispatching feature neither.<br>
                    I&#39;m just trying to separate the named parameter par=
t
                    from the overload part as orthogonal features.<br>
                    You go too far for my taste in your proposal and you
                    propose to have all at once. I&#39;ll be against such a
                    feature.<br>
                  </div>
                </blockquote>
                <div>...</div></div></blockquote></div></blockquote></div><=
/blockquote></div></blockquote><div></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div text=3D"#000000" bgcolor=3D"#FFFFFF">
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
        </div>
        <div>Lastly, it should be noted that tagged dispatch doesn&#39;t
          help with what I will refer to as &quot;mega-functions&quot;: fun=
ctions
          that take stupidly large numbers of relatively independent
          parameters, but for some reason don&#39;t want to take them as a
          convenient aggregate. This is a use case that some people want
          to support, to avoid conceptual two-stage construction.<br>
        </div>
      </div>
    </blockquote>
    IMHO, this case is covered by weak named parameters already.<br></div><=
/blockquote><div><br></div></div></blockquote><div>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>Then perhaps y=
ou&#39;re not understanding what a &quot;mega-function&quot; is. We&#39;re =
talking about functions with <i>dozens</i> of parameters, most of which are=
 optional. Consider all of the various parameters you deal with when settin=
g up a window. Window styles, size, position, hierarchy, font choice, and o=
ther things. Each of those are conceptually one or more parameters to the w=
indow creation function.</div><div><br></div><div>&quot;Ideally&quot;, thes=
e would be literal parameters to a hypothetical Window class&#39;s construc=
tor. But they&#39;re not; most such classes give relatively limited numbers=
 of parameters to the Window&#39;s constructor. The rest are values set aft=
er the Window&#39;s construction, which means that defaults are used until =
those get set. Basically, it&#39;s two-stage construction.<br></div><div><b=
r></div><div>The only way you can get the &quot;ideal&quot; case is if orde=
r for parameters is <i>completely removed</i> for such functions. You can s=
pecify the arguments in any order when you call them, and the caller can de=
fault any parameter with a default value simply by not specifying it.</div>=
<div><br></div><div>Weak named parameters can&#39;t do that. Tag dispatch c=
an&#39;t do that (not without extraordinary pain on the callee side). Even =
designated initializers have to be specified in the right order.<br></div><=
/div></blockquote><div><br></div></div></blockquote></div></blockquote><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div><d=
iv>Are sure about that? Argument rearrangement is doable without changing t=
he signature (a.k.a. strong)</div></div></div></blockquote><div><br></div><=
div>Maybe we have very different ideas about what &quot;strong named parame=
ters&quot; means. The question of &quot;changing the signature&quot; is not=
 the distinction between=20
&quot;strong&quot; and &quot;weak&quot;. At least, it&#39;s not the distinc=
tion that I&#39;m talking about it.</div><div><br></div><div>&quot;Weak nam=
ed parameters&quot; to me refers to named parameters which are all of the f=
ollowing:</div><div><br></div><div>1. Optional. You can call a function tha=
t has named parameters without naming the parameter(s) at the call site.</d=
iv><div>2. Ordered. The order of the arguments must match the parameter ord=
er of the function, regardless of the names you specify at the call site.<b=
r></div><div>3. Overload-neutral. The presence or absence of names at the c=
all site has no effect on function overloading.</div><div><br></div><div>Es=
sentially, if your rules require that all named parameter function calls wi=
ll invoke the same function with the same behavior if you stripped out all =
of the names, then the named parameter proposal is &quot;weak&quot;.<br></d=
iv><div><br></div><div></div><div>Any named parameter feature which imposes=
 rules antithetical to at least one of the above is &quot;strong&quot;. Wit=
h the strongest being the antithesis to all of them.<br></div></div></block=
quote><div><br></div><div>I see, for you weak refers to the notion the call=
 is the same, but unchecked, without them.</div><div><br></div><div>For me =
strong is referring to &quot;does it introduce a new signature&quot;, the s=
ame way strong typedef introduces a new type. Everything else is weak as it=
 is about the compiler not the code.</div><div><br></div><div>Changing the =
signature is a clear boundary in both semantics and implementation. =C2=A0<=
/div><div><br></div><div>But in the realm of non-changing-the-signature nam=
es, a lot can be done, granted the calls <i>will</i> differ w/ and w/o name=
s.=C2=A0</div><div>Should it be done is a different matter, this is a debat=
e as heated as the one about signature - some people consider names useless=
 if they don&#39;t rearrange/skip defaults, some are happy with just checki=
ng alone. =C2=A0<br></div><div><br></div></div>

<p></p>

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

------=_Part_1243_199046079.1534796314699--

------=_Part_1242_1255399920.1534796314698--

.

This is a multi-part message in MIME format.
--------------A28E3E8193BA31BE9897584E
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 20/08/2018 =C3=A0 17:37, Nicol Bolas a =C3=A9crit=C2=A0:
>
>
> On Monday, August 20, 2018 at 2:15:17 AM UTC-4, Vicente J. Botet=20
> Escriba wrote:
>
>     Le 19/08/2018 =C3=A0 23:53, Nicol Bolas a =C3=A9crit=C2=A0:
>>
>>
>>     On Sunday, August 19, 2018 at 5:21:11 PM UTC-4, Vicente J. Botet
>>     Escriba wrote:
>>
>>         Le 19/08/2018 =C3=A0 19:22, mihailn...@gmail.com a =C3=A9crit=C2=
=A0:
>>>
>>>
>>>         On Sunday, August 19, 2018 at 7:46:58 PM UTC+3, Vicente J.
>>>         Botet Escriba wrote:
>>>
>>>             Le 19/08/2018 =C3=A0 15:04, mihailn...@gmail.com a =C3=A9cr=
it=C2=A0:
>>>>
>>>>
>>>>             On Sunday, August 19, 2018 at 3:26:12 PM UTC+3, Vicente
>>>>             J. Botet Escriba wrote:
>>>>
>>>>                 Independently of the language feature, using a tag
>>>>                 type allows to
>>>>                 transport the tag between different functions. In
>>>>                 addition, you cannot
>>>>                 change the class constructor name, so you will need
>>>>                 a tag to be able to
>>>>                 overload it. Take for example the in_place_t tag.
>>>>
>>>>
>>>>             I have thoroughly explored that idea a month back:
>>>>             https://groups.google.com/a/isocpp.org/d/msg/std-proposals=
/tPtdQE2GXb0/4OjT5Z4pBQAJ
>>>>             <https://groups.google.com/a/isocpp.org/d/msg/std-proposal=
s/tPtdQE2GXb0/4OjT5Z4pBQAJ>
>>>>
>>>>             Feel free to comment there, I am undecided on the topic.
>>>>
>>>             I'm not sure yet we need some syntactic sugar for this
>>>             tag dispatching feature neither.
>>>             I'm just trying to separate the named parameter part
>>>             from the overload part as orthogonal features.
>>>             You go too far for my taste in your proposal and you
>>>             propose to have all at once. I'll be against such a feature=
..
>>>
>>>
>>>         Can you elaborate a bit more, what are your expectations and
>>>         where should a line be drawn? As you can see in the comments
>>>         to the post, there are similar concerns.
>>>         In any case it is not a proposal, but an investigation. It
>>>         is clear tags have overlap with strong names, and if we can
>>>         get an attractive proposition, based on tags, we can mark at
>>>         least one part (the harder part?) of the named arguments
>>>         equation "fixed".
>>>
>>         I would like to see the two features proposed independently.
>>
>>         I see more added value for weak named parameters that are
>>         optional and opt in on the author side (as the workarounds
>>         are not always friendly) than the strong named parameters
>>         that can be used to overload function or constructors and
>>         that are not optional (as tag types are an almost friendly
>>         library solution, as the standard library has showed already
>>         multiple times).
>>
>>
>>     The problem with having them be independent is that they're /not/
>>     independent. They're both playing around in the same space:
>>     invoking a parameter's name when you call the function.
>>
>>     The first question any named parameter proposal has to answer is
>>     whether to rely on the existing parameter name infrastructure or
>>     to use a special way to define them. There are arguments for both
>>     weak and strong parameters to want to have syntax to declare
>>     named parameters on a function. This is because, by having users
>>     rely on them to some degree (even if mis-matched naming is just a
>>     warning), you are making those parameter names part of the
>>     interface of the API. And that's different from how parameter
>>     names have been treated in the past.
>     I'm not for strong named parameters. For me, this is a disguised
>     form of mixing weak named parameters and tag dispatching. This is
>     why I believe the features are independent.
>     Now you can put them together and obtain named parameters and tag
>     dispatch.
>
>>
>>     If you try to develop weak and strong parameters completely
>>     independently, then what you can end up with are two proposals
>>     that provide completely different ways of declaring such
>>     parameters. And considering all of the stuff that we keep
>>     cramming into function declarations these days, giving parameters
>>     /three names/ is utterly absurd. Even if you forbid weak
>>     parameter names on functions with strong names, that's still 3
>>     separate syntaxes for declaring parameter names.
>     If we want weak and strong named parameters and don't see another
>     solution than having two syntaxes :(
>
>
> If that's the case, then we shouldn't have weak named parameters at=20
> all. Remember: weak named parameters are purely notational; they catch=20
> errors. That makes them a "nice to have". Strong named parameters=20
> provide genuine functionality, allowing you to express things that=20
> could not be expressed before.
>
> If the design space is sufficiently constrained to only permit one or=20
> the other, then it should be the one that actually does something.
Well, I believe that if the design space is limited, I prefer to have=20
named parameters that don't change the signature.

The other I can do them with tag types :)

You see, we disagree.
>
>     I don't believe that we want non op in named parametrs, so each
>     one of the weak/strong alternatives would need a specific syntax.
>
>>
>>     So I don't think it's reasonable to develop the two proposals
>>     completely independently from one another. They should at least
>>     be developed with the knowledge that the other is a possibility,
>>     and with syntax that can reasonably fit together.
>     Maybe you are right, but I would like that the proposal are
>     clearly separated, so that we can be agains one from or the other.
>
>
> So, you can't be against one part of a proposal? The standards=20
> committee does it all the time.
Better to split them. For me of course.
>
>>     Lastly, it should be noted that tagged dispatch doesn't help with
>>     what I will refer to as "mega-functions": functions that take
>>     stupidly large numbers of relatively independent parameters, but
>>     for some reason don't want to take them as a convenient
>>     aggregate. This is a use case that some people want to support,
>>     to avoid conceptual two-stage construction.
>     IMHO, this case is covered by weak named parameters already.
>
>
> Then perhaps you're not understanding what a "mega-function" is. We're=20
> talking about functions with /dozens/ of parameters, most of which are=20
> optional. Consider all of the various parameters you deal with when=20
> setting up a window. Window styles, size, position, hierarchy, font=20
> choice, and other things. Each of those are conceptually one or more=20
> parameters to the window creation function.
Maybe you don't understand the same thing as me. week named parameters=20
allow optionals for me :)
>
> "Ideally", these would be literal parameters to a hypothetical Window=20
> class's constructor. But they're not; most such classes give=20
> relatively limited numbers of parameters to the Window's constructor.=20
> The rest are values set after the Window's construction, which means=20
> that defaults are used until those get set. Basically, it's two-stage=20
> construction.
>
> The only way you can get the "ideal" case is if order for parameters=20
> is /completely removed/ for such functions. You can specify the=20
> arguments in any order when you call them, and the caller can default=20
> any parameter with a default value simply by not specifying it.
>
> Weak named parameters can't do that. Tag dispatch can't do that (not=20
> without extraordinary pain on the callee side). Even designated=20
> initializers have to be specified in the right order.
Why are you so sure my weak named parameters can't do that?

Vicente

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/694eec5e-0bb9-6a94-21db-d0112db55a73%40wanadoo.f=
r.

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

<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 20/08/2018 =C3=A0 17:37, Nicol Bolas =
a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"
      cite=3D"mid:9f3550db-0cce-4259-85ef-428d8cfba63c@isocpp.org">
      <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf=
-8">
      <div dir=3D"ltr"><br>
        <br>
        On Monday, August 20, 2018 at 2:15:17 AM UTC-4, Vicente J. Botet
        Escriba wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div text=3D"#000000" bgcolor=3D"#FFFFFF">
            <div>Le 19/08/2018 =C3=A0 23:53, Nicol Bolas a =C3=A9crit=C2=A0=
:<br>
            </div>
            <blockquote type=3D"cite">
              <div dir=3D"ltr"><br>
                <br>
                On Sunday, August 19, 2018 at 5:21:11 PM UTC-4, Vicente
                J. Botet Escriba wrote:
                <blockquote class=3D"gmail_quote"
                  style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
                  solid;padding-left:1ex">
                  <div text=3D"#000000" bgcolor=3D"#FFFFFF">
                    <div>Le 19/08/2018 =C3=A0 19:22, <a rel=3D"nofollow"
                        moz-do-not-send=3D"true">mihailn...@gmail.com</a>
                      a =C3=A9crit=C2=A0:<br>
                    </div>
                    <blockquote type=3D"cite">
                      <div dir=3D"ltr"><br>
                        <br>
                        On Sunday, August 19, 2018 at 7:46:58 PM UTC+3,
                        Vicente J. Botet Escriba wrote:
                        <blockquote class=3D"gmail_quote"
                          style=3D"margin:0;margin-left:0.8ex;border-left:1=
px
                          #ccc solid;padding-left:1ex">
                          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
                            <div>Le 19/08/2018 =C3=A0 15:04, <a
                                rel=3D"nofollow" moz-do-not-send=3D"true">m=
ihailn...@gmail.com</a>
                              a =C3=A9crit=C2=A0:<br>
                            </div>
                            <blockquote type=3D"cite">
                              <div dir=3D"ltr"><br>
                                <br>
                                On Sunday, August 19, 2018 at 3:26:12 PM
                                UTC+3, Vicente J. Botet Escriba wrote:
                                <blockquote class=3D"gmail_quote"
                                  style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px
                                  #ccc solid;padding-left:1ex">Independentl=
y
                                  of the language feature, using a tag
                                  type allows to <br>
                                  transport the tag between different
                                  functions. In addition, you cannot <br>
                                  change the class constructor name, so
                                  you will need a tag to be able to <br>
                                  overload it. Take for example the
                                  in_place_t tag. <br>
                                </blockquote>
                                <div><br>
                                </div>
                                <div>I have thoroughly explored that
                                  idea a month back:=C2=A0<a
href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2G=
Xb0/4OjT5Z4pBQAJ"
                                    rel=3D"nofollow" target=3D"_blank"
onmousedown=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msg/st=
d-proposals/tPtdQE2GXb0/4OjT5Z4pBQAJ';return
                                    true;"
onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msg/std-pr=
oposals/tPtdQE2GXb0/4OjT5Z4pBQAJ';return
                                    true;" moz-do-not-send=3D"true">https:/=
/groups.google.<wbr>com/a/isocpp.org/d/msg/std-<wbr>proposals/tPtdQE2GXb0/<=
wbr>4OjT5Z4pBQAJ</a></div>
                                <div><br>
                                </div>
                                <div>Feel free to comment there, I am
                                  undecided on the topic.=C2=A0</div>
                                <div><br>
                                </div>
                                <div>=C2=A0</div>
                              </div>
                            </blockquote>
                            I'm not sure yet we need some syntactic
                            sugar for this tag dispatching feature
                            neither.<br>
                            I'm just trying to separate the named
                            parameter part from the overload part as
                            orthogonal features.<br>
                            You go too far for my taste in your proposal
                            and you propose to have all at once. I'll be
                            against such a feature.<br>
                          </div>
                        </blockquote>
                        <div><br>
                        </div>
                        <div>Can you elaborate a bit more, what are your
                          expectations and where should a line be drawn?
                          As you can see in the comments to the post,
                          there are similar concerns.</div>
                        <div>In any case it is not a proposal, but an <span
style=3D"display:inline!important;float:none;background-color:transparent;c=
olor:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans=
-serif;font-size:13px;font-style:normal;font-variant:normal;font-weight:400=
;letter-spacing:normal;text-align:left;text-decoration:none;text-indent:0px=
;text-transform:none;white-space:normal;word-spacing:0px">investigation.
                          </span><span
style=3D"display:inline!important;float:none;background-color:transparent;c=
olor:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans=
-serif;font-size:13px;font-style:normal;font-variant:normal;font-weight:400=
;letter-spacing:normal;text-align:left;text-decoration:none;text-indent:0px=
;text-transform:none;white-space:normal;word-spacing:0px">It
                            is clear tags have overlap with strong
                            names, and if we can get an attractive
                            proposition, based on tags, we can mark at
                            least one part (the harder part?) of the
                            named arguments equation "fixed".=C2=A0</span><=
/div>
                        <div><span
style=3D"display:inline!important;float:none;background-color:transparent;c=
olor:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans=
-serif;font-size:13px;font-style:normal;font-variant:normal;font-weight:400=
;letter-spacing:normal;text-align:left;text-decoration:none;text-indent:0px=
;text-transform:none;white-space:normal;word-spacing:0px"><br>
                          </span></div>
                      </div>
                    </blockquote>
                    I would like to see the two features proposed
                    independently. <br>
                    <br>
                    I see more added value for weak named parameters
                    that are optional and opt in on the author side (as
                    the workarounds are not always friendly) than the
                    strong named parameters that can be used to overload
                    function or constructors and that are not optional
                    (as tag types are an almost friendly library
                    solution, as the standard library has showed already
                    multiple times).<br>
                  </div>
                </blockquote>
                <div><br>
                </div>
                <div>The problem with having them be independent is that
                  they're <i>not</i> independent. They're both playing
                  around in the same space: invoking a parameter's name
                  when you call the function.</div>
                <div><br>
                </div>
                <div>The first question any named parameter proposal has
                  to answer is whether to rely on the existing parameter
                  name infrastructure or to use a special way to define
                  them. There are arguments for both weak and strong
                  parameters to want to have syntax to declare named
                  parameters on a function. This is because, by having
                  users rely on them to some degree (even if mis-matched
                  naming is just a warning), you are making those
                  parameter names part of the interface of the API. And
                  that's different from how parameter names have been
                  treated in the past.</div>
              </div>
            </blockquote>
            I'm not for strong named parameters. For me, this is a
            disguised form of mixing weak named parameters and tag
            dispatching. This is why I believe the features are
            independent.<br>
            Now you can put them together and obtain named parameters
            and tag dispatch.</div>
        </blockquote>
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div text=3D"#000000" bgcolor=3D"#FFFFFF">
            <blockquote type=3D"cite">
              <div dir=3D"ltr"><br>
                <div>If you try to develop weak and strong parameters
                  completely independently, then what you can end up
                  with are two proposals that provide completely
                  different ways of declaring such parameters. And
                  considering all of the stuff that we keep cramming
                  into function declarations these days, giving
                  parameters <i>three names</i> is utterly absurd. Even
                  if you forbid weak parameter names on functions with
                  strong names, that's still 3 separate syntaxes for
                  declaring parameter names.</div>
              </div>
            </blockquote>
            If we want weak and strong named parameters and don't see
            another solution than having two syntaxes :(<br>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>If that's the case, then we shouldn't have weak named
          parameters at all. Remember: weak named parameters are purely
          notational; they catch errors. That makes them a "nice to
          have". Strong named parameters provide genuine functionality,
          allowing you to express things that could not be expressed
          before.</div>
        <div><br>
        </div>
        <div>If the design space is sufficiently constrained to only
          permit one or the other, then it should be the one that
          actually does something.<br>
        </div>
      </div>
    </blockquote>
    Well, I believe that if the design space is limited, I prefer to
    have named parameters that don't change the signature.<br>
    <br>
    The other I can do them with tag types :)<br>
    <br>
    You see, we disagree.<br>
    <blockquote type=3D"cite"
      cite=3D"mid:9f3550db-0cce-4259-85ef-428d8cfba63c@isocpp.org">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div text=3D"#000000" bgcolor=3D"#FFFFFF"> I don't believe that w=
e
            want non op in named parametrs, so each one of the
            weak/strong alternatives would need a specific syntax.<br>
            <br>
            <blockquote type=3D"cite">
              <div dir=3D"ltr">
                <div><br>
                </div>
                <div>So I don't think it's reasonable to develop the two
                  proposals completely independently from one another.
                  They should at least be developed with the knowledge
                  that the other is a possibility, and with syntax that
                  can reasonably fit together.</div>
              </div>
            </blockquote>
            Maybe you are right, but I would like that the proposal are
            clearly separated, so that we can be agains one from or the
            other.<br>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>So, you can't be against one part of a proposal? The
          standards committee does it all the time.<br>
        </div>
      </div>
    </blockquote>
    Better to split them. For me of course.<br>
    <blockquote type=3D"cite"
      cite=3D"mid:9f3550db-0cce-4259-85ef-428d8cfba63c@isocpp.org">
      <div dir=3D"ltr">
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div text=3D"#000000" bgcolor=3D"#FFFFFF">
            <blockquote type=3D"cite">
              <div dir=3D"ltr">
                <div> </div>
                <div>Lastly, it should be noted that tagged dispatch
                  doesn't help with what I will refer to as
                  "mega-functions": functions that take stupidly large
                  numbers of relatively independent parameters, but for
                  some reason don't want to take them as a convenient
                  aggregate. This is a use case that some people want to
                  support, to avoid conceptual two-stage construction.<br>
                </div>
              </div>
            </blockquote>
            IMHO, this case is covered by weak named parameters already.<br=
>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>Then perhaps you're not understanding what a
          "mega-function" is. We're talking about functions with <i>dozens<=
/i>
          of parameters, most of which are optional. Consider all of the
          various parameters you deal with when setting up a window.
          Window styles, size, position, hierarchy, font choice, and
          other things. Each of those are conceptually one or more
          parameters to the window creation function.</div>
      </div>
    </blockquote>
    Maybe you don't understand the same thing as me. week named
    parameters allow optionals for me :)<br>
    <blockquote type=3D"cite"
      cite=3D"mid:9f3550db-0cce-4259-85ef-428d8cfba63c@isocpp.org">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>"Ideally", these would be literal parameters to a
          hypothetical Window class's constructor. But they're not; most
          such classes give relatively limited numbers of parameters to
          the Window's constructor. The rest are values set after the
          Window's construction, which means that defaults are used
          until those get set. Basically, it's two-stage construction.<br>
        </div>
        <div><br>
        </div>
        <div>The only way you can get the "ideal" case is if order for
          parameters is <i>completely removed</i> for such functions.
          You can specify the arguments in any order when you call them,
          and the caller can default any parameter with a default value
          simply by not specifying it.</div>
        <div><br>
        </div>
        <div>Weak named parameters can't do that. Tag dispatch can't do
          that (not without extraordinary pain on the callee side). Even
          designated initializers have to be specified in the right
          order.<br>
        </div>
      </div>
    </blockquote>
    Why are you so sure my weak named parameters can't do that?<br>
    <br>
    Vicente<br>
    <br>
  </body>
</html>

<p></p>

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

--------------A28E3E8193BA31BE9897584E--

.

This is a multi-part message in MIME format.
--------------579E9939090D081EE7604D36
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 20/08/2018 =C3=A0 20:45, Nicol Bolas a =C3=A9crit=C2=A0:
>
>
> On Monday, August 20, 2018 at 12:20:20 PM UTC-4, mihailn...@gmail.com=20
> wrote:
>
>
>
>     On Monday, August 20, 2018 at 6:37:39 PM UTC+3, Nicol Bolas wrote:
>
>
>
>         On Monday, August 20, 2018 at 2:15:17 AM UTC-4, Vicente J.
>         Botet Escriba wrote:
>
>             Le 19/08/2018 =C3=A0 23:53, Nicol Bolas a =C3=A9crit=C2=A0:
>>
>>
>>             On Sunday, August 19, 2018 at 5:21:11 PM UTC-4, Vicente
>>             J. Botet Escriba wrote:
>>
>>                 Le 19/08/2018 =C3=A0 19:22, mihailn...@gmail.com a =C3=
=A9crit=C2=A0:
>>>
>>>
>>>                 On Sunday, August 19, 2018 at 7:46:58 PM UTC+3,
>>>                 Vicente J. Botet Escriba wrote:
>>>
>>>                     Le 19/08/2018 =C3=A0 15:04, mihailn...@gmail.com a
>>>                     =C3=A9crit=C2=A0:
>>>>
>>>>
>>>>                     On Sunday, August 19, 2018 at 3:26:12 PM UTC+3,
>>>>                     Vicente J. Botet Escriba wrote:
>>>>
>>>>                         Independently of the language feature,
>>>>                         using a tag type allows to
>>>>                         transport the tag between different
>>>>                         functions. In addition, you cannot
>>>>                         change the class constructor name, so you
>>>>                         will need a tag to be able to
>>>>                         overload it. Take for example the
>>>>                         in_place_t tag.
>>>>
>>>>
>>>>                     I have thoroughly explored that idea a month
>>>>                     back:
>>>>                     https://groups.google.com/a/isocpp.org/d/msg/std-p=
roposals/tPtdQE2GXb0/4OjT5Z4pBQAJ
>>>>                     <https://groups.google.com/a/isocpp.org/d/msg/std-=
proposals/tPtdQE2GXb0/4OjT5Z4pBQAJ>
>>>>
>>>>                     Feel free to comment there, I am undecided on
>>>>                     the topic.
>>>>
>>>                     I'm not sure yet we need some syntactic sugar
>>>                     for this tag dispatching feature neither.
>>>                     I'm just trying to separate the named parameter
>>>                     part from the overload part as orthogonal features.
>>>                     You go too far for my taste in your proposal and
>>>                     you propose to have all at once. I'll be against
>>>                     such a feature.
>>>
>>>
>>>                 Can you elaborate a bit more, what are your
>>>                 expectations and where should a line be drawn? As
>>>                 you can see in the comments to the post, there are
>>>                 similar concerns.
>>>                 In any case it is not a proposal, but an
>>>                 investigation. It is clear tags have overlap with
>>>                 strong names, and if we can get an attractive
>>>                 proposition, based on tags, we can mark at least one
>>>                 part (the harder part?) of the named arguments
>>>                 equation "fixed".
>>>
>>                 I would like to see the two features proposed
>>                 independently.
>>
>>                 I see more added value for weak named parameters that
>>                 are optional and opt in on the author side (as the
>>                 workarounds are not always friendly) than the strong
>>                 named parameters that can be used to overload
>>                 function or constructors and that are not optional
>>                 (as tag types are an almost friendly library
>>                 solution, as the standard library has showed already
>>                 multiple times).
>>
>>
>>             The problem with having them be independent is that
>>             they're /not/ independent. They're both playing around in
>>             the same space: invoking a parameter's name when you call
>>             the function.
>>
>>             The first question any named parameter proposal has to
>>             answer is whether to rely on the existing parameter name
>>             infrastructure or to use a special way to define them.
>>             There are arguments for both weak and strong parameters
>>             to want to have syntax to declare named parameters on a
>>             function. This is because, by having users rely on them
>>             to some degree (even if mis-matched naming is just a
>>             warning), you are making those parameter names part of
>>             the interface of the API. And that's different from how
>>             parameter names have been treated in the past.
>             I'm not for strong named parameters. For me, this is a
>             disguised form of mixing weak named parameters and tag
>             dispatching. This is why I believe the features are
>             independent.
>             Now you can put them together and obtain named parameters
>             and tag dispatch.
>
>>
>>             If you try to develop weak and strong parameters
>>             completely independently, then what you can end up with
>>             are two proposals that provide completely different ways
>>             of declaring such parameters. And considering all of the
>>             stuff that we keep cramming into function declarations
>>             these days, giving parameters /three names/ is utterly
>>             absurd. Even if you forbid weak parameter names on
>>             functions with strong names, that's still 3 separate
>>             syntaxes for declaring parameter names.
>             If we want weak and strong named parameters and don't see
>             another solution than having two syntaxes :(
>
>
>         If that's the case, then we shouldn't have weak named
>         parameters at all. Remember: weak named parameters are purely
>         notational; they catch errors. That makes them a "nice to
>         have". Strong named parameters provide genuine functionality,
>         allowing you to express things that could not be expressed before=
..
>
>         If the design space is sufficiently constrained to only permit
>         one or the other, then it should be the one that actually does
>         something.
>
>             I don't believe that we want non op in named parametrs, so
>             each one of the weak/strong alternatives would need a
>             specific syntax.
>
>>
>>             So I don't think it's reasonable to develop the two
>>             proposals completely independently from one another. They
>>             should at least be developed with the knowledge that the
>>             other is a possibility, and with syntax that can
>>             reasonably fit together.
>             Maybe you are right, but I would like that the proposal
>             are clearly separated, so that we can be agains one from
>             or the other.
>
>
>         So, you can't be against one part of a proposal? The standards
>         committee does it all the time.
>
>>             Lastly, it should be noted that tagged dispatch doesn't
>>             help with what I will refer to as "mega-functions":
>>             functions that take stupidly large numbers of relatively
>>             independent parameters, but for some reason don't want to
>>             take them as a convenient aggregate. This is a use case
>>             that some people want to support, to avoid conceptual
>>             two-stage construction.
>             IMHO, this case is covered by weak named parameters already.
>
>
>         Then perhaps you're not understanding what a "mega-function"
>         is. We're talking about functions with /dozens/ of parameters,
>         most of which are optional. Consider all of the various
>         parameters you deal with when setting up a window. Window
>         styles, size, position, hierarchy, font choice, and other
>         things. Each of those are conceptually one or more parameters
>         to the window creation function.
>
>         "Ideally", these would be literal parameters to a hypothetical
>         Window class's constructor. But they're not; most such classes
>         give relatively limited numbers of parameters to the Window's
>         constructor. The rest are values set after the Window's
>         construction, which means that defaults are used until those
>         get set. Basically, it's two-stage construction.
>
>         The only way you can get the "ideal" case is if order for
>         parameters is /completely removed/ for such functions. You can
>         specify the arguments in any order when you call them, and the
>         caller can default any parameter with a default value simply
>         by not specifying it.
>
>         Weak named parameters can't do that. Tag dispatch can't do
>         that (not without extraordinary pain on the callee side). Even
>         designated initializers have to be specified in the right order.
>
>
>     Are sure about that? Argument rearrangement is doable without
>     changing the signature (a.k.a. strong)
>
>
> Maybe we have very different ideas about what "strong named=20
> parameters" means. The question of "changing the signature" is not the=20
> distinction between "strong" and "weak". At least, it's not the=20
> distinction that I'm talking about it.
>
Maybe it is not for you. It is for me and others. Another distinction=20
that we have not discused so much, is if the names are needed for the=20
arguments or are optional.
> "Weak named parameters" to me refers to named parameters which are all=20
> of the following:
>
> 1. Optional. You can call a function that has named parameters without=20
> naming the parameter(s) at the call site.
> 2. Ordered. The order of the arguments must match the parameter order=20
> of the function, regardless of the names you specify at the call site.
Why? This is a simplification, that could be wished or not.
> 3. Overload-neutral. The presence or absence of names at the call site=20
> has no effect on function overloading.
So it doesn't change the function signature.

4. You are missing that we can skip some of them.
>
> Essentially, if your rules require that all named parameter function=20
> calls will invoke the same function with the same behavior if you=20
> stripped out all of the names, then the named parameter proposal is=20
> "weak".
>
> Any named parameter feature which imposes rules antithetical to at=20
> least one of the above is "strong". With the strongest being the=20
> antithesis to all of them.
You should write a proposal so that we know what you are talking of :)


Vicente

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/409803d8-c7cc-79ac-2e1c-d823b6cc0b36%40wanadoo.f=
r.

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

<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 20/08/2018 =C3=A0 20:45, Nicol Bolas =
a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"
      cite=3D"mid:333693b1-38a8-424f-bc15-0b36131b97f4@isocpp.org">
      <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf=
-8">
      <div dir=3D"ltr"><br>
        <br>
        On Monday, August 20, 2018 at 12:20:20 PM UTC-4,
        <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:mihailn...@gma=
il.com">mihailn...@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"><br>
            <br>
            On Monday, August 20, 2018 at 6:37:39 PM UTC+3, Nicol Bolas
            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>
                <br>
                On Monday, August 20, 2018 at 2:15:17 AM UTC-4, Vicente
                J. Botet Escriba wrote:
                <blockquote class=3D"gmail_quote"
                  style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
                  solid;padding-left:1ex">
                  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
                    <div>Le 19/08/2018 =C3=A0 23:53, Nicol Bolas a =C3=A9cr=
it=C2=A0:<br>
                    </div>
                    <blockquote type=3D"cite">
                      <div dir=3D"ltr"><br>
                        <br>
                        On Sunday, August 19, 2018 at 5:21:11 PM UTC-4,
                        Vicente J. Botet Escriba wrote:
                        <blockquote class=3D"gmail_quote"
                          style=3D"margin:0;margin-left:0.8ex;border-left:1=
px
                          #ccc solid;padding-left:1ex">
                          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
                            <div>Le 19/08/2018 =C3=A0 19:22, <a
                                rel=3D"nofollow" moz-do-not-send=3D"true">m=
ihailn...@gmail.com</a>
                              a =C3=A9crit=C2=A0:<br>
                            </div>
                            <blockquote type=3D"cite">
                              <div dir=3D"ltr"><br>
                                <br>
                                On Sunday, August 19, 2018 at 7:46:58 PM
                                UTC+3, Vicente J. Botet Escriba wrote:
                                <blockquote class=3D"gmail_quote"
                                  style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px
                                  #ccc solid;padding-left:1ex">
                                  <div bgcolor=3D"#FFFFFF" text=3D"#000000"=
>
                                    <div>Le 19/08/2018 =C3=A0 15:04, <a
                                        rel=3D"nofollow"
                                        moz-do-not-send=3D"true">mihailn...=
@gmail.com</a>
                                      a =C3=A9crit=C2=A0:<br>
                                    </div>
                                    <blockquote type=3D"cite">
                                      <div dir=3D"ltr"><br>
                                        <br>
                                        On Sunday, August 19, 2018 at
                                        3:26:12 PM UTC+3, Vicente J.
                                        Botet Escriba wrote:
                                        <blockquote class=3D"gmail_quote"
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
                                          solid;padding-left:1ex">Independe=
ntly
                                          of the language feature, using
                                          a tag type allows to <br>
                                          transport the tag between
                                          different functions. In
                                          addition, you cannot <br>
                                          change the class constructor
                                          name, so you will need a tag
                                          to be able to <br>
                                          overload it. Take for example
                                          the in_place_t tag. <br>
                                        </blockquote>
                                        <div><br>
                                        </div>
                                        <div>I have thoroughly explored
                                          that idea a month back:=C2=A0<a
href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2G=
Xb0/4OjT5Z4pBQAJ"
                                            rel=3D"nofollow"
                                            target=3D"_blank"
onmousedown=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msg/st=
d-proposals/tPtdQE2GXb0/4OjT5Z4pBQAJ';return
                                            true;"
onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msg/std-pr=
oposals/tPtdQE2GXb0/4OjT5Z4pBQAJ';return
                                            true;"
                                            moz-do-not-send=3D"true">https:=
//groups.google.<wbr>com/a/isocpp.org/d/msg/std-<wbr>proposals/tPtdQE2GXb0/=
<wbr>4OjT5Z4pBQAJ</a></div>
                                        <div><br>
                                        </div>
                                        <div>Feel free to comment there,
                                          I am undecided on the topic.=C2=
=A0</div>
                                        <div><br>
                                        </div>
                                        <div>=C2=A0</div>
                                      </div>
                                    </blockquote>
                                    I'm not sure yet we need some
                                    syntactic sugar for this tag
                                    dispatching feature neither.<br>
                                    I'm just trying to separate the
                                    named parameter part from the
                                    overload part as orthogonal
                                    features.<br>
                                    You go too far for my taste in your
                                    proposal and you propose to have all
                                    at once. I'll be against such a
                                    feature.<br>
                                  </div>
                                </blockquote>
                                <div><br>
                                </div>
                                <div>Can you elaborate a bit more, what
                                  are your expectations and where should
                                  a line be drawn? As you can see in the
                                  comments to the post, there are
                                  similar concerns.</div>
                                <div>In any case it is not a proposal,
                                  but an <span
style=3D"display:inline!important;float:none;background-color:transparent;c=
olor:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans=
-serif;font-size:13px;font-style:normal;font-variant:normal;font-weight:400=
;letter-spacing:normal;text-align:left;text-decoration:none;text-indent:0px=
;text-transform:none;white-space:normal;word-spacing:0px">investigation.
                                  </span><span
style=3D"display:inline!important;float:none;background-color:transparent;c=
olor:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans=
-serif;font-size:13px;font-style:normal;font-variant:normal;font-weight:400=
;letter-spacing:normal;text-align:left;text-decoration:none;text-indent:0px=
;text-transform:none;white-space:normal;word-spacing:0px">It
                                    is clear tags have overlap with
                                    strong names, and if we can get an
                                    attractive proposition, based on
                                    tags, we can mark at least one part
                                    (the harder part?) of the named
                                    arguments equation "fixed".=C2=A0</span=
></div>
                                <div><span
style=3D"display:inline!important;float:none;background-color:transparent;c=
olor:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans=
-serif;font-size:13px;font-style:normal;font-variant:normal;font-weight:400=
;letter-spacing:normal;text-align:left;text-decoration:none;text-indent:0px=
;text-transform:none;white-space:normal;word-spacing:0px"><br>
                                  </span></div>
                              </div>
                            </blockquote>
                            I would like to see the two features
                            proposed independently. <br>
                            <br>
                            I see more added value for weak named
                            parameters that are optional and opt in on
                            the author side (as the workarounds are not
                            always friendly) than the strong named
                            parameters that can be used to overload
                            function or constructors and that are not
                            optional (as tag types are an almost
                            friendly library solution, as the standard
                            library has showed already multiple times).<br>
                          </div>
                        </blockquote>
                        <div><br>
                        </div>
                        <div>The problem with having them be independent
                          is that they're <i>not</i> independent.
                          They're both playing around in the same space:
                          invoking a parameter's name when you call the
                          function.</div>
                        <div><br>
                        </div>
                        <div>The first question any named parameter
                          proposal has to answer is whether to rely on
                          the existing parameter name infrastructure or
                          to use a special way to define them. There are
                          arguments for both weak and strong parameters
                          to want to have syntax to declare named
                          parameters on a function. This is because, by
                          having users rely on them to some degree (even
                          if mis-matched naming is just a warning), you
                          are making those parameter names part of the
                          interface of the API. And that's different
                          from how parameter names have been treated in
                          the past.</div>
                      </div>
                    </blockquote>
                    I'm not for strong named parameters. For me, this is
                    a disguised form of mixing weak named parameters and
                    tag dispatching. This is why I believe the features
                    are independent.<br>
                    Now you can put them together and obtain named
                    parameters and tag dispatch.</div>
                </blockquote>
                <blockquote class=3D"gmail_quote"
                  style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
                  solid;padding-left:1ex">
                  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
                    <blockquote type=3D"cite">
                      <div dir=3D"ltr"><br>
                        <div>If you try to develop weak and strong
                          parameters completely independently, then what
                          you can end up with are two proposals that
                          provide completely different ways of declaring
                          such parameters. And considering all of the
                          stuff that we keep cramming into function
                          declarations these days, giving parameters <i>thr=
ee
                            names</i> is utterly absurd. Even if you
                          forbid weak parameter names on functions with
                          strong names, that's still 3 separate syntaxes
                          for declaring parameter names.</div>
                      </div>
                    </blockquote>
                    If we want weak and strong named parameters and
                    don't see another solution than having two syntaxes
                    :(<br>
                  </div>
                </blockquote>
                <div><br>
                </div>
                <div>If that's the case, then we shouldn't have weak
                  named parameters at all. Remember: weak named
                  parameters are purely notational; they catch errors.
                  That makes them a "nice to have". Strong named
                  parameters provide genuine functionality, allowing you
                  to express things that could not be expressed before.</di=
v>
                <div><br>
                </div>
                <div>If the design space is sufficiently constrained to
                  only permit one or the other, then it should be the
                  one that actually does something.<br>
                </div>
                <div><br>
                </div>
                <blockquote class=3D"gmail_quote"
                  style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
                  solid;padding-left:1ex">
                  <div bgcolor=3D"#FFFFFF" text=3D"#000000"> I don't believ=
e
                    that we want non op in named parametrs, so each one
                    of the weak/strong alternatives would need a
                    specific syntax.<br>
                    <br>
                    <blockquote type=3D"cite">
                      <div dir=3D"ltr">
                        <div><br>
                        </div>
                        <div>So I don't think it's reasonable to develop
                          the two proposals completely independently
                          from one another. They should at least be
                          developed with the knowledge that the other is
                          a possibility, and with syntax that can
                          reasonably fit together.</div>
                      </div>
                    </blockquote>
                    Maybe you are right, but I would like that the
                    proposal are clearly separated, so that we can be
                    agains one from or the other.<br>
                  </div>
                </blockquote>
                <div><br>
                </div>
                <div>So, you can't be against one part of a proposal?
                  The standards committee does it all the time.<br>
                </div>
                <blockquote class=3D"gmail_quote"
                  style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
                  solid;padding-left:1ex">
                  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
                    <blockquote type=3D"cite">
                      <div dir=3D"ltr">
                        <div> </div>
                        <div>Lastly, it should be noted that tagged
                          dispatch doesn't help with what I will refer
                          to as "mega-functions": functions that take
                          stupidly large numbers of relatively
                          independent parameters, but for some reason
                          don't want to take them as a convenient
                          aggregate. This is a use case that some people
                          want to support, to avoid conceptual two-stage
                          construction.<br>
                        </div>
                      </div>
                    </blockquote>
                    IMHO, this case is covered by weak named parameters
                    already.<br>
                  </div>
                </blockquote>
                <div><br>
                </div>
              </div>
            </blockquote>
            <div>=C2=A0</div>
            <blockquote class=3D"gmail_quote"
              style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
              solid;padding-left:1ex">
              <div dir=3D"ltr">
                <div>Then perhaps you're not understanding what a
                  "mega-function" is. We're talking about functions with
                  <i>dozens</i> of parameters, most of which are
                  optional. Consider all of the various parameters you
                  deal with when setting up a window. Window styles,
                  size, position, hierarchy, font choice, and other
                  things. Each of those are conceptually one or more
                  parameters to the window creation function.</div>
                <div><br>
                </div>
                <div>"Ideally", these would be literal parameters to a
                  hypothetical Window class's constructor. But they're
                  not; most such classes give relatively limited numbers
                  of parameters to the Window's constructor. The rest
                  are values set after the Window's construction, which
                  means that defaults are used until those get set.
                  Basically, it's two-stage construction.<br>
                </div>
                <div><br>
                </div>
                <div>The only way you can get the "ideal" case is if
                  order for parameters is <i>completely removed</i> for
                  such functions. You can specify the arguments in any
                  order when you call them, and the caller can default
                  any parameter with a default value simply by not
                  specifying it.</div>
                <div><br>
                </div>
                <div>Weak named parameters can't do that. Tag dispatch
                  can't do that (not without extraordinary pain on the
                  callee side). Even designated initializers have to be
                  specified in the right order.<br>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>
              <div>Are sure about that? Argument rearrangement is doable
                without changing the signature (a.k.a. strong)</div>
            </div>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>Maybe we have very different ideas about what "strong named
          parameters" means. The question of "changing the signature" is
          not the distinction between "strong" and "weak". At least,
          it's not the distinction that I'm talking about it.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    Maybe it is not for you. It is for me and others. Another
    distinction that we have not discused so much, is if the names are
    needed for the arguments or are optional.<br>
    <blockquote type=3D"cite"
      cite=3D"mid:333693b1-38a8-424f-bc15-0b36131b97f4@isocpp.org">
      <div dir=3D"ltr">
        <div>"Weak named parameters" to me refers to named parameters
          which are all of the following:</div>
        <div><br>
        </div>
        <div>1. Optional. You can call a function that has named
          parameters without naming the parameter(s) at the call site.</div=
>
        <div>2. Ordered. The order of the arguments must match the
          parameter order of the function, regardless of the names you
          specify at the call site.<br>
        </div>
      </div>
    </blockquote>
    Why? This is a simplification, that could be wished or not. <br>
    <blockquote type=3D"cite"
      cite=3D"mid:333693b1-38a8-424f-bc15-0b36131b97f4@isocpp.org">
      <div dir=3D"ltr">
        <div>3. Overload-neutral. The presence or absence of names at
          the call site has no effect on function overloading.</div>
      </div>
    </blockquote>
    So it doesn't change the function signature.<br>
    <br>
    4. You are missing that we can skip some of them.<br>
    <blockquote type=3D"cite"
      cite=3D"mid:333693b1-38a8-424f-bc15-0b36131b97f4@isocpp.org">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>Essentially, if your rules require that all named parameter
          function calls will invoke the same function with the same
          behavior if you stripped out all of the names, then the named
          parameter proposal is "weak".<br>
        </div>
        <div><br>
        </div>
        <div>Any named parameter feature which imposes rules
          antithetical to at least one of the above is "strong". With
          the strongest being the antithesis to all of them.<br>
        </div>
      </div>
    </blockquote>
    You should write a proposal so that we know what you are talking of
    :)<br>
    <br>
    <br>
    Vicente<br>
    <br>
  </body>
</html>

<p></p>

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

--------------579E9939090D081EE7604D36--

.

------=_Part_559_708631620.1534816376823
Content-Type: multipart/alternative;
 boundary="----=_Part_560_171467974.1534816376824"

------=_Part_560_171467974.1534816376824
Content-Type: text/plain; charset="UTF-8"

On Monday, August 20, 2018 at 4:18:34 PM UTC-4, mihailn...@gmail.com wrote:
>
> On Monday, August 20, 2018 at 9:45:02 PM UTC+3, Nicol Bolas wrote:
>>
>> On Monday, August 20, 2018 at 12:20:20 PM UTC-4, mihailn...@gmail.com
>> wrote:
>>>
>>> Are sure about that? Argument rearrangement is doable without changing
>>> the signature (a.k.a. strong)
>>>
>>
>> Maybe we have very different ideas about what "strong named parameters"
>> means. The question of "changing the signature" is not the distinction
>> between "strong" and "weak". At least, it's not the distinction that I'm
>> talking about it.
>>
>> "Weak named parameters" to me refers to named parameters which are all of
>> the following:
>>
>> 1. Optional. You can call a function that has named parameters without
>> naming the parameter(s) at the call site.
>> 2. Ordered. The order of the arguments must match the parameter order of
>> the function, regardless of the names you specify at the call site.
>> 3. Overload-neutral. The presence or absence of names at the call site
>> has no effect on function overloading.
>>
>> Essentially, if your rules require that all named parameter function
>> calls will invoke the same function with the same behavior if you stripped
>> out all of the names, then the named parameter proposal is "weak".
>>
>> Any named parameter feature which imposes rules antithetical to at least
>> one of the above is "strong". With the strongest being the antithesis to
>> all of them.
>>
>
> I see, for you weak refers to the notion the call is the same, but
> unchecked, without them.
>
> For me strong is referring to "does it introduce a new signature", the
> same way strong typedef introduces a new type. Everything else is weak as
> it is about the compiler not the code.
>

That's not what you said earlier
<https://groups.google.com/a/isocpp.org/d/msg/std-proposals/MbDT0vsA2j0/1VPQM7AsAAAJ>
:

Also, this obviously does not address the named arguments, *that are
> optional, the "weak" ones*, so this solution will not make everyone
> happy.
>

Emphasis added. And there's this post
<https://groups.google.com/a/isocpp.org/d/msg/std-proposals/MbDT0vsA2j0/uWG77JxeDQAJ>
:

//weak argument names, not mandatory
>
....
>
//strong argument name, adds an overload, not ignorable
>

Yes, that post is talking about how you would declare weak names
differently from strong names, but it's also talking about how they get
used at the call site: "not mandatory" vs. "not ignorable".

Changing the signature is a clear boundary in both semantics and
> implementation.
>
But in the realm of non-changing-the-signature names, a lot can be done,
> granted the calls *will* differ w/ and w/o names.
>

I think you're too focused on signature as the notion of a function's
identity. There are aspects of functions which are not their signature yet
directly relate to its identity.

Return values. If you declare two functions with the same name and
signatures with different return values, then you get a compile error.
`noexcept` works that way too; you can't be inconsistent about that. Both
of these are part of the function's type, but not its signature (though
`noexcept` can be cast away).

Contracts affect neither type nor signature, but even that requires some
basic consistency. You can declare contracts on a function or not. But all
contract declarations for the same function must be consistent.

If a parameter name can be used as a syntactic modifier when calling the
function (for the purposes of this discussion, anything which affects
actual code generation. This includes reordering of arguments), then that
name ought to be, if not part of the function's type, then at least have as
much consistency as its contracts. That is, if you want to be able to
reorder parameters, then the function should consistently assign each
parameter a single name or a single "unnamed".

If names can be inconsistent and still affect syntax, bad things result.

Should it be done is a different matter, this is a debate as heated as the
> one about signature - some people consider names useless if they don't
> rearrange/skip defaults, some are happy with just checking alone.
>

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

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

<div dir=3D"ltr">On Monday, August 20, 2018 at 4:18:34 PM UTC-4, mihailn...=
@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">On Monday, August 20, 2018 at 9:45:02 PM UTC+3, Nicol Bolas wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Monday, August 20, 2=
018 at 12:20:20 PM UTC-4, <a>mihailn...@gmail.com</a> wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr"><div></div></div></blockquote></d=
iv></blockquote><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"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div><div=
>Are sure about that? Argument rearrangement is doable without changing the=
 signature (a.k.a. strong)</div></div></div></blockquote><div><br></div><di=
v>Maybe we have very different ideas about what &quot;strong named paramete=
rs&quot; means. The question of &quot;changing the signature&quot; is not t=
he distinction between=20
&quot;strong&quot; and &quot;weak&quot;. At least, it&#39;s not the distinc=
tion that I&#39;m talking about it.</div><div><br></div><div>&quot;Weak nam=
ed parameters&quot; to me refers to named parameters which are all of the f=
ollowing:</div><div><br></div><div>1. Optional. You can call a function tha=
t has named parameters without naming the parameter(s) at the call site.</d=
iv><div>2. Ordered. The order of the arguments must match the parameter ord=
er of the function, regardless of the names you specify at the call site.<b=
r></div><div>3. Overload-neutral. The presence or absence of names at the c=
all site has no effect on function overloading.</div><div><br></div><div>Es=
sentially, if your rules require that all named parameter function calls wi=
ll invoke the same function with the same behavior if you stripped out all =
of the names, then the named parameter proposal is &quot;weak&quot;.<br></d=
iv><div><br></div><div></div><div>Any named parameter feature which imposes=
 rules antithetical to at least one of the above is &quot;strong&quot;. Wit=
h the strongest being the antithesis to all of them.<br></div></div></block=
quote><div><br></div><div>I see, for you weak refers to the notion the call=
 is the same, but unchecked, without them.</div><div><br></div><div>For me =
strong is referring to &quot;does it introduce a new signature&quot;, the s=
ame way strong typedef introduces a new type. Everything else is weak as it=
 is about the compiler not the code.</div></div></blockquote><div><br></div=
><div>That&#39;s not what <a href=3D"https://groups.google.com/a/isocpp.org=
/d/msg/std-proposals/MbDT0vsA2j0/1VPQM7AsAAAJ">you said earlier</a>:</div><=
div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0p=
x 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><di=
v>Also, this obviously does not address the named arguments, <b>that are=20
optional, the &quot;weak&quot; ones</b>, so this solution will not make eve=
ryone=20
happy. <br></div></blockquote><div><br></div><div>Emphasis added. And there=
&#39;s <a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposal=
s/MbDT0vsA2j0/uWG77JxeDQAJ">this post</a>:<br></div><div><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: =
1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>//weak argument name=
s, not mandatory <br></div></blockquote><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204=
); padding-left: 1ex;"><div>... <br></div></blockquote><blockquote class=3D=
"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rg=
b(204, 204, 204); padding-left: 1ex;"><div></div><div>//strong argument nam=
e, adds an overload, not ignorable <br></div></blockquote><div><br></div><d=
iv>Yes, that post is talking about how you would declare weak names differe=
ntly from strong names, but it&#39;s also talking about how they get used a=
t the call site: &quot;not mandatory&quot; vs. &quot;not ignorable&quot;.</=
div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div></div><div>Changing the signature is a clear boundary in both se=
mantics and implementation.<br></div></div></blockquote><div></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div></div=
><div>But in the realm of non-changing-the-signature names, a lot can be do=
ne, granted the calls <i>will</i> differ w/ and w/o names.</div></div></blo=
ckquote><div><br></div><div>I think you&#39;re too focused on signature as =
the notion of a function&#39;s identity. There are aspects of functions whi=
ch are not their signature yet directly relate to its identity.</div><div><=
br></div><div>Return values. If you declare two functions with the same nam=
e and signatures with different return values, then you get a compile error=
.. `noexcept` works that way too; you can&#39;t be inconsistent about that. =
Both of these are part of the function&#39;s type, but not its signature (t=
hough `noexcept` can be cast away).</div><div><br></div><div>Contracts affe=
ct neither type nor signature, but even that requires some basic consistenc=
y. You can declare contracts on a function or not. But all contract declara=
tions for the same function must be consistent.</div><div><br></div><div>If=
 a parameter name can be used as a syntactic modifier when calling the func=
tion (for the purposes of this discussion, anything which affects actual co=
de generation. This includes reordering of arguments), then that name ought=
 to be, if not part of the function&#39;s type, then at least have as much =
consistency as its contracts. That is, if you want to be able to reorder pa=
rameters, then the function should consistently assign each parameter a sin=
gle name or a single &quot;unnamed&quot;.</div><div><br></div><div></div><d=
iv>If names can be inconsistent and still affect syntax, bad things result.=
</div><div></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div dir=3D"ltr"><div>Should it be done is a different matter, this is a =
debate as heated as the one about signature - some people consider names us=
eless if they don&#39;t rearrange/skip defaults, some are happy with just c=
hecking alone.=C2=A0 <br></div></div></blockquote></div>

<p></p>

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

------=_Part_560_171467974.1534816376824--

------=_Part_559_708631620.1534816376823--

.

------=_Part_1919_1883430474.1534838666602
Content-Type: multipart/alternative;
 boundary="----=_Part_1920_1938981769.1534838666602"

------=_Part_1920_1938981769.1534838666602
Content-Type: text/plain; charset="UTF-8"



On Tuesday, August 21, 2018 at 4:52:56 AM UTC+3, Nicol Bolas wrote:
>
> On Monday, August 20, 2018 at 4:18:34 PM UTC-4, mihailn...@gmail.com
> wrote:
>>
>> On Monday, August 20, 2018 at 9:45:02 PM UTC+3, Nicol Bolas wrote:
>>>
>>> On Monday, August 20, 2018 at 12:20:20 PM UTC-4, mihailn...@gmail.com
>>> wrote:
>>>>
>>>> Are sure about that? Argument rearrangement is doable without changing
>>>> the signature (a.k.a. strong)
>>>>
>>>
>>> Maybe we have very different ideas about what "strong named parameters"
>>> means. The question of "changing the signature" is not the distinction
>>> between "strong" and "weak". At least, it's not the distinction that I'm
>>> talking about it.
>>>
>>> "Weak named parameters" to me refers to named parameters which are all
>>> of the following:
>>>
>>> 1. Optional. You can call a function that has named parameters without
>>> naming the parameter(s) at the call site.
>>> 2. Ordered. The order of the arguments must match the parameter order of
>>> the function, regardless of the names you specify at the call site.
>>> 3. Overload-neutral. The presence or absence of names at the call site
>>> has no effect on function overloading.
>>>
>>> Essentially, if your rules require that all named parameter function
>>> calls will invoke the same function with the same behavior if you stripped
>>> out all of the names, then the named parameter proposal is "weak".
>>>
>>> Any named parameter feature which imposes rules antithetical to at least
>>> one of the above is "strong". With the strongest being the antithesis to
>>> all of them.
>>>
>>
>> I see, for you weak refers to the notion the call is the same, but
>> unchecked, without them.
>>
>> For me strong is referring to "does it introduce a new signature", the
>> same way strong typedef introduces a new type. Everything else is weak as
>> it is about the compiler not the code.
>>
>
> That's not what you said earlier
> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/MbDT0vsA2j0/1VPQM7AsAAAJ>
> :
>
> Also, this obviously does not address the named arguments, *that are
>> optional, the "weak" ones*, so this solution will not make everyone
>> happy.
>>
>
> Emphasis added. And there's this post
> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/MbDT0vsA2j0/uWG77JxeDQAJ>
> :
>
> //weak argument names, not mandatory
>>
> ...
>>
> //strong argument name, adds an overload, not ignorable
>>
>
> Yes, that post is talking about how you would declare weak names
> differently from strong names, but it's also talking about how they get
> used at the call site: "not mandatory" vs. "not ignorable".
>

There is no contradiction, they are optional, and ignorable by the user (he
might not use them).
Now, it depends on how much features they have, they might also be as weak
as you assume they are, so they are (can be) ignored by the compiler as
well and the call is the same.

Most of the time here we talked about these weakest ones, and considered
"extra features" as "bonuses".

For me personally strong were always the one changing the signature, that's
why the first post about tags-as-labels was called "Strong named arguments
as tag overloads"

And weak for me were not rearranging or skipping, but having
defaulted-by-naming f(a:, b:, 10)

Of course even these are not ignorable as the call will fail without them.
Probably using the word ignorable was not correct.

In any case weak names are optional.
This is not to say, they do not affect overloading, they do, but only on
the call site.

void func(int a, int b);
void func(int a, int b: b=1, int c: c=2);

func(1, 3); //< overload 1
func(1, b: 3); //< overload 2
func(1, c: 3); //< overload 2


> Changing the signature is a clear boundary in both semantics and
>> implementation.
>>
> But in the realm of non-changing-the-signature names, a lot can be done,
>> granted the calls *will* differ w/ and w/o names.
>>
>
> I think you're too focused on signature as the notion of a function's
> identity. There are aspects of functions which are not their signature yet
> directly relate to its identity.
>
> Return values. If you declare two functions with the same name and
> signatures with different return values, then you get a compile error.
> `noexcept` works that way too; you can't be inconsistent about that. Both
> of these are part of the function's type, but not its signature (though
> `noexcept` can be cast away).
>
> Contracts affect neither type nor signature, but even that requires some
> basic consistency. You can declare contracts on a function or not. But all
> contract declarations for the same function must be consistent.
>
> If a parameter name can be used as a syntactic modifier when calling the
> function (for the purposes of this discussion, anything which affects
> actual code generation. This includes reordering of arguments), then that
> name ought to be, if not part of the function's type, then at least have as
> much consistency as its contracts. That is, if you want to be able to
> reorder parameters, then the function should consistently assign each
> parameter a single name or a single "unnamed".
>


In the original post about weak arguments, I suggested they obey the rules
of default arguments - you name your arguments only in the first
declaration. No names afterwards, not even the same.

auto child(name mother: mom, name dad);

// auto child(name mother: mom, name dad); *//< error*
// auto child(name mom, name father: dad); *//< error*
auto child(name mutter, vater); *//< OK*
auto child(name mother, name father) *//< OK*
{
  // implementation
}

This seems the be the most consistent approach as (weak) named arguments
ultimately inhabit *exactly* the same design space as default arguments - a
compiler helper.

With default arguments the compiler is only obligated to copy-paste the
default expression if we don't pass a value.

With names it is a matter of what features we want to have:

   - to only name-check
   - to paste in place of name-only
   - to paste on omission
   - to rearrange




> If names can be inconsistent and still affect syntax, bad things result.
>
> Should it be done is a different matter, this is a debate as heated as the
>> one about signature - some people consider names useless if they don't
>> rearrange/skip defaults, some are happy with just checking alone.
>>
>

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

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

<div dir=3D"ltr"><br><br>On Tuesday, August 21, 2018 at 4:52:56 AM UTC+3, N=
icol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">On Monday, August 20, 2018 at 4:18:34 PM UTC-4, <a>mihailn...@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">On Mond=
ay, August 20, 2018 at 9:45:02 PM UTC+3, Nicol Bolas wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr">On Monday, August 20, 2018 at 12:2=
0:20 PM UTC-4, <a>mihailn...@gmail.com</a> wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div></div></div></blockquote></div></blockq=
uote><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"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div><div>Are sure a=
bout that? Argument rearrangement is doable without changing the signature =
(a.k.a. strong)</div></div></div></blockquote><div><br></div><div>Maybe we =
have very different ideas about what &quot;strong named parameters&quot; me=
ans. The question of &quot;changing the signature&quot; is not the distinct=
ion between=20
&quot;strong&quot; and &quot;weak&quot;. At least, it&#39;s not the distinc=
tion that I&#39;m talking about it.</div><div><br></div><div>&quot;Weak nam=
ed parameters&quot; to me refers to named parameters which are all of the f=
ollowing:</div><div><br></div><div>1. Optional. You can call a function tha=
t has named parameters without naming the parameter(s) at the call site.</d=
iv><div>2. Ordered. The order of the arguments must match the parameter ord=
er of the function, regardless of the names you specify at the call site.<b=
r></div><div>3. Overload-neutral. The presence or absence of names at the c=
all site has no effect on function overloading.</div><div><br></div><div>Es=
sentially, if your rules require that all named parameter function calls wi=
ll invoke the same function with the same behavior if you stripped out all =
of the names, then the named parameter proposal is &quot;weak&quot;.<br></d=
iv><div><br></div><div></div><div>Any named parameter feature which imposes=
 rules antithetical to at least one of the above is &quot;strong&quot;. Wit=
h the strongest being the antithesis to all of them.<br></div></div></block=
quote><div><br></div><div>I see, for you weak refers to the notion the call=
 is the same, but unchecked, without them.</div><div><br></div><div>For me =
strong is referring to &quot;does it introduce a new signature&quot;, the s=
ame way strong typedef introduces a new type. Everything else is weak as it=
 is about the compiler not the code.</div></div></blockquote><div><br></div=
><div>That&#39;s not what <a onmousedown=3D"this.href=3D&#39;https://groups=
..google.com/a/isocpp.org/d/msg/std-proposals/MbDT0vsA2j0/1VPQM7AsAAAJ&#39;;=
return true;" onclick=3D"this.href=3D&#39;https://groups.google.com/a/isocp=
p.org/d/msg/std-proposals/MbDT0vsA2j0/1VPQM7AsAAAJ&#39;;return true;" href=
=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/MbDT0vsA2j0/=
1VPQM7AsAAAJ" target=3D"_blank" rel=3D"nofollow">you said earlier</a>:</div=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Also=
, this obviously does not address the named arguments, <b>that are=20
optional, the &quot;weak&quot; ones</b>, so this solution will not make eve=
ryone=20
happy. <br></div></blockquote><div><br></div><div>Emphasis added. And there=
&#39;s <a onmousedown=3D"this.href=3D&#39;https://groups.google.com/a/isocp=
p.org/d/msg/std-proposals/MbDT0vsA2j0/uWG77JxeDQAJ&#39;;return true;" oncli=
ck=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msg/std-pro=
posals/MbDT0vsA2j0/uWG77JxeDQAJ&#39;;return true;" href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msg/std-proposals/MbDT0vsA2j0/uWG77JxeDQAJ" target=
=3D"_blank" rel=3D"nofollow">this post</a>:<br></div><div><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div>//weak argument names, not =
mandatory <br></div></blockquote><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div>... <br></div></blockquote><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div></div><div>//strong argument name, adds an overload, no=
t ignorable <br></div></blockquote><div><br></div><div>Yes, that post is ta=
lking about how you would declare weak names differently from strong names,=
 but it&#39;s also talking about how they get used at the call site: &quot;=
not mandatory&quot; vs. &quot;not ignorable&quot;.</div></div></blockquote>=
<div><br></div><div>There is no contradiction, they are optional, and ignor=
able by the user (he might not use them).=C2=A0</div><div>Now, it depends o=
n how much features they have, they might also be as weak as you assume the=
y are, so they are (can be) ignored by the compiler as well and the call is=
 the same.</div><div><br></div><div>Most of the time here we talked about t=
hese weakest ones, and considered &quot;extra features&quot; as &quot;bonus=
es&quot;.</div><div><br></div><div>For me personally strong were always the=
 one changing the signature, that&#39;s why the first post about tags-as-la=
bels was called &quot;Strong named arguments as tag overloads&quot;</div><d=
iv><br></div><div>And weak for me were not rearranging or skipping, but hav=
ing defaulted-by-naming <font face=3D"courier new,monospace">f(a:, b:, 10)=
=C2=A0</font></div><div>=C2=A0</div><div>Of course even these are not ignor=
able as the call will fail without them. Probably using the word ignorable =
was not correct.=C2=A0</div><div><br></div><div>In any case weak names are =
optional.=C2=A0</div><div>This is not to say, they do not affect overloadin=
g, they do, but only on the call site.</div><div><br></div><div><span style=
=3D"text-align: left; color: rgb(34, 34, 34); text-transform: none; text-in=
dent: 0px; letter-spacing: normal; font-size: 13px; font-style: normal; fon=
t-variant: normal; font-weight: 400; text-decoration: none; word-spacing: 0=
px; display: inline !important; white-space: normal; orphans: 2; float: non=
e; -webkit-text-stroke-width: 0px; background-color: transparent;"><font fa=
ce=3D"courier new,monospace">void func(int a, int b);</font></span><b></b><=
i></i><u></u><sub></sub><sup></sup><strike></strike><br></div><div><font fa=
ce=3D"courier new,monospace">void func(int a, int b: b=3D1, int c: c=3D2);<=
/font></div><div><font face=3D"courier new,monospace"></font><br></div><div=
><font face=3D"courier new,monospace">func(1, 3); //&lt; overload 1</font><=
/div><div><span style=3D"text-align: left; color: rgb(34, 34, 34); text-tra=
nsform: none; text-indent: 0px; letter-spacing: normal; font-size: 13px; fo=
nt-style: normal; font-variant: normal; font-weight: 400; text-decoration: =
none; word-spacing: 0px; display: inline !important; white-space: normal; o=
rphans: 2; float: none; -webkit-text-stroke-width: 0px; background-color: t=
ransparent;"><font face=3D"courier new,monospace">func(1, b: 3);<span style=
=3D"display: inline !important; float: none; background-color: transparent;=
 color: rgb(34, 34, 34); font-family: courier new,monospace; font-size: 13p=
x; font-style: normal; font-variant: normal; font-weight: 400; letter-spaci=
ng: normal; orphans: 2; text-align: left; text-decoration: none; text-inden=
t: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: =
normal; word-spacing: 0px;"> //&lt; overload 2</span></font></span><br></di=
v><div><span style=3D"background-color: transparent; border-bottom-color: r=
gb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border=
-image-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; b=
order-image-source: none; border-image-width: 1; border-left-color: rgb(34,=
 34, 34); border-left-style: none; border-left-width: 0px; border-right-col=
or: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; bor=
der-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0=
px; color: rgb(34, 34, 34); display: inline; float: none; font-family: &amp=
;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: =
13px; font-style: normal; font-variant: normal; font-weight: 400; letter-sp=
acing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; mar=
gin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-r=
ight: 0px; padding-top: 0px; text-align: left; text-decoration: none; text-=
indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-sp=
ace: normal; word-spacing: 0px;"><font face=3D"courier new,monospace" style=
=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border=
-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stretch; b=
order-image-slice: 100%; border-image-source: none; border-image-width: 1; =
border-left-color: rgb(34, 34, 34); border-left-style: none; border-left-wi=
dth: 0px; border-right-color: rgb(34, 34, 34); border-right-style: none; bo=
rder-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style:=
 none; border-top-width: 0px; margin-bottom: 0px; margin-left: 0px; margin-=
right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; paddin=
g-right: 0px; padding-top: 0px;">func(1, c: 3);<span style=3D"background-co=
lor: transparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style=
: none; border-bottom-width: 0px; border-image-outset: 0; border-image-repe=
at: stretch; border-image-slice: 100%; border-image-source: none; border-im=
age-width: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; =
border-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-s=
tyle: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); bor=
der-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34); display=
: inline; float: none; font-family: courier new,monospace; font-size: 13px;=
 font-style: normal; font-variant: normal; font-weight: 400; letter-spacing=
: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-t=
op: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right:=
 0px; padding-top: 0px; text-align: left; text-decoration: none; text-inden=
t: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: =
normal; word-spacing: 0px;"> //&lt; overload 2</span></font></span><b></b><=
i></i><u></u><sub></sub><sup></sup><strike></strike><br></div><div><b></b><=
i></i><u></u><sub></sub><sup></sup><strike></strike><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>Changing the =
signature is a clear boundary in both semantics and implementation.<br></di=
v></div></blockquote><div></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div></div><div></div><div>But in the realm of non-changing-t=
he-signature names, a lot can be done, granted the calls <i>will</i> differ=
 w/ and w/o names.</div></div></blockquote><div><br></div><div>I think you&=
#39;re too focused on signature as the notion of a function&#39;s identity.=
 There are aspects of functions which are not their signature yet directly =
relate to its identity.</div><div><br></div><div>Return values. If you decl=
are two functions with the same name and signatures with different return v=
alues, then you get a compile error. `noexcept` works that way too; you can=
&#39;t be inconsistent about that. Both of these are part of the function&#=
39;s type, but not its signature (though `noexcept` can be cast away).</div=
><div><br></div><div>Contracts affect neither type nor signature, but even =
that requires some basic consistency. You can declare contracts on a functi=
on or not. But all contract declarations for the same function must be cons=
istent.</div><div><br></div><div>If a parameter name can be used as a synta=
ctic modifier when calling the function (for the purposes of this discussio=
n, anything which affects actual code generation. This includes reordering =
of arguments), then that name ought to be, if not part of the function&#39;=
s type, then at least have as much consistency as its contracts. That is, i=
f you want to be able to reorder parameters, then the function should consi=
stently assign each parameter a single name or a single &quot;unnamed&quot;=
..</div></div></blockquote><div><br></div><div><br></div><div>In the origina=
l post about weak arguments, I suggested they obey the rules of default arg=
uments - you name your arguments only in the first declaration. No names af=
terwards, not even the same.=C2=A0</div><div><br></div><div><div style=3D"b=
ackground-color: transparent; border-bottom-color: rgb(34, 34, 34); border-=
bottom-style: none; border-bottom-width: 0px; border-image-outset: 0; borde=
r-image-repeat: stretch; border-image-slice: 100%; border-image-source: non=
e; border-image-width: 1; border-left-color: rgb(34, 34, 34); border-left-s=
tyle: none; border-left-width: 0px; border-right-color: rgb(34, 34, 34); bo=
rder-right-style: none; border-right-width: 0px; border-top-color: rgb(34, =
34, 34); border-top-style: none; border-top-width: 0px; color: rgb(34, 34, =
34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,s=
ans-serif; font-size: 13px; font-style: normal; font-variant: normal; font-=
weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px; =
margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; paddin=
g-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; text-d=
ecoration: none; text-indent: 0px; text-transform: none; -webkit-text-strok=
e-width: 0px; white-space: normal; word-spacing: 0px;"><span style=3D"backg=
round-color: transparent; border-bottom-color: rgb(34, 34, 34); border-bott=
om-style: none; border-bottom-width: 0px; border-image-outset: 0; border-im=
age-repeat: stretch; border-image-slice: 100%; border-image-source: none; b=
order-image-width: 1; border-left-color: rgb(34, 34, 34); border-left-style=
: none; border-left-width: 0px; border-right-color: rgb(34, 34, 34); border=
-right-style: none; border-right-width: 0px; border-top-color: rgb(34, 34, =
34); border-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34);=
 display: inline; float: none; font-size: 13px; font-style: normal; font-va=
riant: normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0px=
; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px=
; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left=
; text-decoration: none; text-indent: 0px; text-transform: none; white-spac=
e: normal; word-spacing: 0px;"><font face=3D"courier new,monospace" style=
=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border=
-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stretch; b=
order-image-slice: 100%; border-image-source: none; border-image-width: 1; =
border-left-color: rgb(34, 34, 34); border-left-style: none; border-left-wi=
dth: 0px; border-right-color: rgb(34, 34, 34); border-right-style: none; bo=
rder-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style:=
 none; border-top-width: 0px; margin-bottom: 0px; margin-left: 0px; margin-=
right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; paddin=
g-right: 0px; padding-top: 0px;">auto child(name mother: mom, name dad);=C2=
=A0</font></span></div><div style=3D"background-color: transparent; border-=
bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-wid=
th: 0px; border-image-outset: 0; border-image-repeat: stretch; border-image=
-slice: 100%; border-image-source: none; border-image-width: 1; border-left=
-color: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; b=
order-right-color: rgb(34, 34, 34); border-right-style: none; border-right-=
width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; bord=
er-top-width: 0px; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp=
;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-styl=
e: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; =
margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; o=
rphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padd=
ing-top: 0px; text-align: left; text-decoration: none; text-indent: 0px; te=
xt-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; wo=
rd-spacing: 0px;"><span style=3D"background-color: transparent; border-bott=
om-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: =
0px; border-image-outset: 0; border-image-repeat: stretch; border-image-sli=
ce: 100%; border-image-source: none; border-image-width: 1; border-left-col=
or: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; borde=
r-right-color: rgb(34, 34, 34); border-right-style: none; border-right-widt=
h: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-t=
op-width: 0px; color: rgb(34, 34, 34); display: inline; float: none; font-s=
ize: 13px; font-style: normal; font-variant: normal; font-weight: 400; lett=
er-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px=
; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0=
px; padding-top: 0px; text-align: left; text-decoration: none; text-indent:=
 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><font =
face=3D"courier new,monospace" style=3D"border-bottom-color: rgb(34, 34, 34=
); border-bottom-style: none; border-bottom-width: 0px; border-image-outset=
: 0; border-image-repeat: stretch; border-image-slice: 100%; border-image-s=
ource: none; border-image-width: 1; border-left-color: rgb(34, 34, 34); bor=
der-left-style: none; border-left-width: 0px; border-right-color: rgb(34, 3=
4, 34); border-right-style: none; border-right-width: 0px; border-top-color=
: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; margin-bo=
ttom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bo=
ttom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;"><br></=
font></span></div><div style=3D"background-color: transparent; border-botto=
m-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0=
px; border-image-outset: 0; border-image-repeat: stretch; border-image-slic=
e: 100%; border-image-source: none; border-image-width: 1; border-left-colo=
r: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; border=
-right-color: rgb(34, 34, 34); border-right-style: none; border-right-width=
: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-to=
p-width: 0px; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot=
;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: no=
rmal; font-variant: normal; font-weight: 400; letter-spacing: normal; margi=
n-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphan=
s: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-t=
op: 0px; text-align: left; text-decoration: none; text-indent: 0px; text-tr=
ansform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-sp=
acing: 0px;"><font face=3D"courier new,monospace">// <span style=3D"border-=
bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-wid=
th: 0px; border-image-outset: 0; border-image-repeat: stretch; border-image=
-slice: 100%; border-image-source: none; border-image-width: 1; border-left=
-color: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; b=
order-right-color: rgb(34, 34, 34); border-right-style: none; border-right-=
width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; bord=
er-top-width: 0px; margin-bottom: 0px; margin-left: 0px; margin-right: 0px;=
 margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0p=
x; padding-top: 0px;"><font style=3D"border-bottom-color: rgb(34, 34, 34); =
border-bottom-style: none; border-bottom-width: 0px; border-image-outset: 0=
; border-image-repeat: stretch; border-image-slice: 100%; border-image-sour=
ce: none; border-image-width: 1; border-left-color: rgb(34, 34, 34); border=
-left-style: none; border-left-width: 0px; border-right-color: rgb(34, 34, =
34); border-right-style: none; border-right-width: 0px; border-top-color: r=
gb(34, 34, 34); border-top-style: none; border-top-width: 0px; margin-botto=
m: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-botto=
m: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">auto chil=
d(name mother: mom, name dad); <i>//&lt; error</i></font></span></font></di=
v><div style=3D"background-color: transparent; border-bottom-color: rgb(34,=
 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-image=
-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; border-=
image-source: none; border-image-width: 1; border-left-color: rgb(34, 34, 3=
4); border-left-style: none; border-left-width: 0px; border-right-color: rg=
b(34, 34, 34); border-right-style: none; border-right-width: 0px; border-to=
p-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; co=
lor: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helv=
etica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-varia=
nt: normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; m=
argin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bo=
ttom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-al=
ign: left; text-decoration: none; text-indent: 0px; text-transform: none; -=
webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"><sp=
an style=3D"background-color: transparent; border-bottom-color: rgb(34, 34,=
 34); border-bottom-style: none; border-bottom-width: 0px; border-image-out=
set: 0; border-image-repeat: stretch; border-image-slice: 100%; border-imag=
e-source: none; border-image-width: 1; border-left-color: rgb(34, 34, 34); =
border-left-style: none; border-left-width: 0px; border-right-color: rgb(34=
, 34, 34); border-right-style: none; border-right-width: 0px; border-top-co=
lor: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; color:=
 rgb(34, 34, 34); display: inline; float: none; font-size: 13px; font-varia=
nt: normal; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px; m=
argin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; =
padding-right: 0px; padding-top: 0px; text-align: left; text-indent: 0px; t=
ext-transform: none; white-space: normal; word-spacing: 0px;"><font style=
=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border=
-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stretch; b=
order-image-slice: 100%; border-image-source: none; border-image-width: 1; =
border-left-color: rgb(34, 34, 34); border-left-style: none; border-left-wi=
dth: 0px; border-right-color: rgb(34, 34, 34); border-right-style: none; bo=
rder-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style:=
 none; border-top-width: 0px; margin-bottom: 0px; margin-left: 0px; margin-=
right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; paddin=
g-right: 0px; padding-top: 0px;"><font face=3D"courier new,monospace"><span=
 style=3D"background-color: transparent; border-bottom-color: rgb(34, 34, 3=
4); border-bottom-style: none; border-bottom-width: 0px; border-image-outse=
t: 0; border-image-repeat: stretch; border-image-slice: 100%; border-image-=
source: none; border-image-width: 1; border-left-color: rgb(34, 34, 34); bo=
rder-left-style: none; border-left-width: 0px; border-right-color: rgb(34, =
34, 34); border-right-style: none; border-right-width: 0px; border-top-colo=
r: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; color: r=
gb(34, 34, 34); display: inline; float: none; font-family: &amp;quot;Arial&=
amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-s=
tyle: normal; font-variant: normal; font-weight: 400; letter-spacing: norma=
l; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px=
; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: =
0px; text-align: left; text-decoration: none; text-indent: 0px; text-transf=
orm: none; white-space: normal; word-spacing: 0px;">// </span><span style=
=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border=
-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stretch; b=
order-image-slice: 100%; border-image-source: none; border-image-width: 1; =
border-left-color: rgb(34, 34, 34); border-left-style: none; border-left-wi=
dth: 0px; border-right-color: rgb(34, 34, 34); border-right-style: none; bo=
rder-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style:=
 none; border-top-width: 0px; margin-bottom: 0px; margin-left: 0px; margin-=
right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; paddin=
g-right: 0px; padding-top: 0px;"><font style=3D"border-bottom-color: rgb(34=
, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-imag=
e-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; border=
-image-source: none; border-image-width: 1; border-left-color: rgb(34, 34, =
34); border-left-style: none; border-left-width: 0px; border-right-color: r=
gb(34, 34, 34); border-right-style: none; border-right-width: 0px; border-t=
op-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; m=
argin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; pa=
dding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;=
">auto child(name mom, name father: dad); <i>//&lt; error</i></font></span>=
</font><b style=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-styl=
e: none; border-bottom-width: 0px; border-image-outset: 0; border-image-rep=
eat: stretch; border-image-slice: 100%; border-image-source: none; border-i=
mage-width: 1; border-left-color: rgb(34, 34, 34); border-left-style: none;=
 border-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-=
style: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); bo=
rder-top-style: none; border-top-width: 0px; margin-bottom: 0px; margin-lef=
t: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-le=
ft: 0px; padding-right: 0px; padding-top: 0px;"></b><u style=3D"border-bott=
om-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: =
0px; border-image-outset: 0; border-image-repeat: stretch; border-image-sli=
ce: 100%; border-image-source: none; border-image-width: 1; border-left-col=
or: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; borde=
r-right-color: rgb(34, 34, 34); border-right-style: none; border-right-widt=
h: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-t=
op-width: 0px; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; mar=
gin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; p=
adding-top: 0px;"></u><sub style=3D"border-bottom-color: rgb(34, 34, 34); b=
order-bottom-style: none; border-bottom-width: 0px; border-image-outset: 0;=
 border-image-repeat: stretch; border-image-slice: 100%; border-image-sourc=
e: none; border-image-width: 1; border-left-color: rgb(34, 34, 34); border-=
left-style: none; border-left-width: 0px; border-right-color: rgb(34, 34, 3=
4); border-right-style: none; border-right-width: 0px; border-top-color: rg=
b(34, 34, 34); border-top-style: none; border-top-width: 0px; margin-bottom=
: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom=
: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;"></sub><sup=
 style=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; =
border-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stre=
tch; border-image-slice: 100%; border-image-source: none; border-image-widt=
h: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; border-l=
eft-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: no=
ne; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-=
style: none; border-top-width: 0px; margin-bottom: 0px; margin-left: 0px; m=
argin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; =
padding-right: 0px; padding-top: 0px;"></sup><strike style=3D"border-bottom=
-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0p=
x; border-image-outset: 0; border-image-repeat: stretch; border-image-slice=
: 100%; border-image-source: none; border-image-width: 1; border-left-color=
: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; border-=
right-color: rgb(34, 34, 34); border-right-style: none; border-right-width:=
 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-top=
-width: 0px; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margi=
n-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; pad=
ding-top: 0px;"></strike><br style=3D"border-bottom-color: rgb(34, 34, 34);=
 border-bottom-style: none; border-bottom-width: 0px; border-image-outset: =
0; border-image-repeat: stretch; border-image-slice: 100%; border-image-sou=
rce: none; border-image-width: 1; border-left-color: rgb(34, 34, 34); borde=
r-left-style: none; border-left-width: 0px; border-right-color: rgb(34, 34,=
 34); border-right-style: none; border-right-width: 0px; border-top-color: =
rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; margin-bott=
om: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bott=
om: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;"></font><=
/span></div><div style=3D"background-color: transparent; border-bottom-colo=
r: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; bo=
rder-image-outset: 0; border-image-repeat: stretch; border-image-slice: 100=
%; border-image-source: none; border-image-width: 1; border-left-color: rgb=
(34, 34, 34); border-left-style: none; border-left-width: 0px; border-right=
-color: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px;=
 border-top-color: rgb(34, 34, 34); border-top-style: none; border-top-widt=
h: 0px; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp=
;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; =
font-variant: normal; font-weight: 400; letter-spacing: normal; margin-bott=
om: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; =
padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0p=
x; text-align: left; text-decoration: none; text-indent: 0px; text-transfor=
m: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing:=
 0px;"><span style=3D"background-color: transparent; border-bottom-color: r=
gb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border=
-image-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; b=
order-image-source: none; border-image-width: 1; border-left-color: rgb(34,=
 34, 34); border-left-style: none; border-left-width: 0px; border-right-col=
or: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; bor=
der-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0=
px; color: rgb(34, 34, 34); display: inline; float: none; font-size: 13px; =
font-style: normal; font-variant: normal; font-weight: 400; letter-spacing:=
 normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-to=
p: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding=
-top: 0px; text-align: left; text-decoration: none; text-indent: 0px; text-=
transform: none; white-space: normal; word-spacing: 0px;"><font face=3D"cou=
rier new,monospace" style=3D"border-bottom-color: rgb(34, 34, 34); border-b=
ottom-style: none; border-bottom-width: 0px; border-image-outset: 0; border=
-image-repeat: stretch; border-image-slice: 100%; border-image-source: none=
; border-image-width: 1; border-left-color: rgb(34, 34, 34); border-left-st=
yle: none; border-left-width: 0px; border-right-color: rgb(34, 34, 34); bor=
der-right-style: none; border-right-width: 0px; border-top-color: rgb(34, 3=
4, 34); border-top-style: none; border-top-width: 0px; margin-bottom: 0px; =
margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; =
padding-left: 0px; padding-right: 0px; padding-top: 0px;">auto child(name m=
utter, vater); <i>//&lt; OK</i></font></span><b style=3D"border-bottom-colo=
r: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; bo=
rder-image-outset: 0; border-image-repeat: stretch; border-image-slice: 100=
%; border-image-source: none; border-image-width: 1; border-left-color: rgb=
(34, 34, 34); border-left-style: none; border-left-width: 0px; border-right=
-color: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px;=
 border-top-color: rgb(34, 34, 34); border-top-style: none; border-top-widt=
h: 0px; color: rgb(34, 34, 34); line-height: normal; margin-bottom: 0px; ma=
rgin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; pa=
dding-left: 0px; padding-right: 0px; padding-top: 0px;"></b><u style=3D"bor=
der-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom=
-width: 0px; border-image-outset: 0; border-image-repeat: stretch; border-i=
mage-slice: 100%; border-image-source: none; border-image-width: 1; border-=
left-color: rgb(34, 34, 34); border-left-style: none; border-left-width: 0p=
x; border-right-color: rgb(34, 34, 34); border-right-style: none; border-ri=
ght-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; =
border-top-width: 0px; color: rgb(34, 34, 34); line-height: normal; margin-=
bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-=
bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;"></u>=
<sub style=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-style: no=
ne; border-bottom-width: 0px; border-image-outset: 0; border-image-repeat: =
stretch; border-image-slice: 100%; border-image-source: none; border-image-=
width: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; bord=
er-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style=
: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-=
top-style: none; border-top-width: 0px; margin-bottom: 0px; margin-left: 0p=
x; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0=
px; padding-right: 0px; padding-top: 0px;"></sub><sup style=3D"border-botto=
m-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0=
px; border-image-outset: 0; border-image-repeat: stretch; border-image-slic=
e: 100%; border-image-source: none; border-image-width: 1; border-left-colo=
r: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; border=
-right-color: rgb(34, 34, 34); border-right-style: none; border-right-width=
: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-to=
p-width: 0px; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; marg=
in-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; pa=
dding-top: 0px;"></sup><strike style=3D"border-bottom-color: rgb(34, 34, 34=
); border-bottom-style: none; border-bottom-width: 0px; border-image-outset=
: 0; border-image-repeat: stretch; border-image-slice: 100%; border-image-s=
ource: none; border-image-width: 1; border-left-color: rgb(34, 34, 34); bor=
der-left-style: none; border-left-width: 0px; border-right-color: rgb(34, 3=
4, 34); border-right-style: none; border-right-width: 0px; border-top-color=
: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; margin-bo=
ttom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bo=
ttom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;"></stri=
ke></div><div style=3D"background-color: transparent; border-bottom-color: =
rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; borde=
r-image-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; =
border-image-source: none; border-image-width: 1; border-left-color: rgb(34=
, 34, 34); border-left-style: none; border-left-width: 0px; border-right-co=
lor: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; bo=
rder-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: =
0px; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;qu=
ot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; fon=
t-variant: normal; font-weight: 400; letter-spacing: normal; margin-bottom:=
 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; pad=
ding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; =
text-align: left; text-decoration: none; text-indent: 0px; text-transform: =
none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0p=
x;"><span style=3D"margin: 0px; padding: 0px; border: 0px rgb(34, 34, 34); =
border-image: none; text-align: left; color: rgb(34, 34, 34); text-transfor=
m: none; text-indent: 0px; letter-spacing: normal; font-size: 13px; font-st=
yle: normal; font-variant: normal; font-weight: 400; text-decoration: none;=
 word-spacing: 0px; display: inline; white-space: normal; float: none; back=
ground-color: transparent;"><font face=3D"courier new,monospace">auto child=
(name mother, name father) <i>//&lt; OK</i></font></span></div><b></b><i></=
i><u></u><sub></sub><sup></sup><strike></strike><font face=3D"courier new,m=
onospace">{=C2=A0</font></div><div><font face=3D"courier new,monospace">=C2=
=A0 // implementation</font></div><div><font face=3D"courier new,monospace"=
>}</font><br></div><div>=C2=A0</div><div>This seems the be the most consist=
ent approach as (weak) named arguments ultimately inhabit <i>exactly</i> th=
e same design space as default arguments - a compiler helper.</div><div><br=
></div><div>With default arguments the compiler is only obligated to copy-p=
aste the default expression if we don&#39;t pass a value.</div><div><br></d=
iv><div>With names it is a matter of what features we want to have:</div><u=
l><li>to only name-check</li><li>to paste in place of name-only</li><li>to =
paste on omission<br></li><li>to rearrange<br></li></ul><div><br></div><div=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><d=
iv><br></div><div></div><div>If names can be inconsistent and still affect =
syntax, bad things result.</div><div></div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div>Should it be done is a differe=
nt matter, this is a debate as heated as the one about signature - some peo=
ple consider names useless if they don&#39;t rearrange/skip defaults, some =
are happy with just checking alone.=C2=A0 <br></div></div></blockquote></di=
v></blockquote></div>

<p></p>

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

------=_Part_1920_1938981769.1534838666602--

------=_Part_1919_1883430474.1534838666602--

.

------=_Part_1639_506452266.1534970849185
Content-Type: multipart/alternative;
 boundary="----=_Part_1640_1997879759.1534970849186"

------=_Part_1640_1997879759.1534970849186
Content-Type: text/plain; charset="UTF-8"

On Tuesday, August 21, 2018 at 4:04:26 AM UTC-4, mihailn...@gmail.com wrote:
>
> On Tuesday, August 21, 2018 at 4:52:56 AM UTC+3, Nicol Bolas wrote:
>>
>> On Monday, August 20, 2018 at 4:18:34 PM UTC-4, mihailn...@gmail.com
>> wrote:
>>>
>>> On Monday, August 20, 2018 at 9:45:02 PM UTC+3, Nicol Bolas wrote:
>>>>
>>>> On Monday, August 20, 2018 at 12:20:20 PM UTC-4, mihailn...@gmail.com
>>>> wrote:
>>>>>
>>>>> Are sure about that? Argument rearrangement is doable without changing
>>>>> the signature (a.k.a. strong)
>>>>>
>>>>
>>>> Maybe we have very different ideas about what "strong named parameters"
>>>> means. The question of "changing the signature" is not the distinction
>>>> between "strong" and "weak". At least, it's not the distinction that I'm
>>>> talking about it.
>>>>
>>>> "Weak named parameters" to me refers to named parameters which are all
>>>> of the following:
>>>>
>>>> 1. Optional. You can call a function that has named parameters without
>>>> naming the parameter(s) at the call site.
>>>> 2. Ordered. The order of the arguments must match the parameter order
>>>> of the function, regardless of the names you specify at the call site.
>>>> 3. Overload-neutral. The presence or absence of names at the call site
>>>> has no effect on function overloading.
>>>>
>>>> Essentially, if your rules require that all named parameter function
>>>> calls will invoke the same function with the same behavior if you stripped
>>>> out all of the names, then the named parameter proposal is "weak".
>>>>
>>>> Any named parameter feature which imposes rules antithetical to at
>>>> least one of the above is "strong". With the strongest being the antithesis
>>>> to all of them.
>>>>
>>>
>>> I see, for you weak refers to the notion the call is the same, but
>>> unchecked, without them.
>>>
>>> For me strong is referring to "does it introduce a new signature", the
>>> same way strong typedef introduces a new type. Everything else is weak as
>>> it is about the compiler not the code.
>>>
>>
>> That's not what you said earlier
>> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/MbDT0vsA2j0/1VPQM7AsAAAJ>
>> :
>>
>> Also, this obviously does not address the named arguments, *that are
>>> optional, the "weak" ones*, so this solution will not make everyone
>>> happy.
>>>
>>
>> Emphasis added. And there's this post
>> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/MbDT0vsA2j0/uWG77JxeDQAJ>
>> :
>>
>> //weak argument names, not mandatory
>>>
>> ...
>>>
>> //strong argument name, adds an overload, not ignorable
>>>
>>
>> Yes, that post is talking about how you would declare weak names
>> differently from strong names, but it's also talking about how they get
>> used at the call site: "not mandatory" vs. "not ignorable".
>>
>
> There is no contradiction, they are optional, and ignorable by the user
> (he might not use them).
> Now, it depends on how much features they have, they might also be as weak
> as you assume they are, so they are (can be) ignored by the compiler as
> well and the call is the same.
>
> Most of the time here we talked about these weakest ones, and considered
> "extra features" as "bonuses".
>
> For me personally strong were always the one changing the signature,
> that's why the first post about tags-as-labels was called "Strong named
> arguments as tag overloads"
>
> And weak for me were not rearranging or skipping, but having
> defaulted-by-naming f(a:, b:, 10)
>
> Of course even these are not ignorable as the call will fail without them.
> Probably using the word ignorable was not correct.
>
> In any case weak names are optional.
> This is not to say, they do not affect overloading, they do, but only on
> the call site.
>
> void func(int a, int b);
> void func(int a, int b: b=1, int c: c=2);
>
> func(1, 3); //< overload 1
> func(1, b: 3); //< overload 2
> func(1, c: 3); //< overload 2
>
>
If names are important enough to affect what overload gets called, then
they ought to be part of a function's type. If they are truly "optional",
then they should not be able to affect overloading.

To me, "optional" means exactly that: optional. The choice of whether to
use names or not is entirely the prerogative of the caller. A caller should
be able to call the same function, providing the same parameters, without
using parameter names if they so desire.

You call the second overload, passing it the first two parameters. That is
not possible without using parameter names. You call the third overload,
passing only the first and third parameters. That too is not possible
without using parameter names.

For your proposal, parameter names are not optional. That's different from
saying that they are mandatory. There are cases in your design where you
can call a named parameter function overload without providing names for
those parameters.

The key here is that in your proposal, parameter names are *part of the
overload set's interface*. Just like the various conversion operators and
constructors on the types used as parameters.

That's what makes them different from default parameters: the fact that
`func(1, 3)` is not ambiguous. With default parameters, users who don't
specify all of the parameters can create ambiguous call relative to other
overloads in the set. With your design, that doesn't happen. This is what
makes the parameter name *more* than just a default argument; it makes it
part of the overload set's interface.

Changing the signature is a clear boundary in both semantics and
>>> implementation.
>>>
>> But in the realm of non-changing-the-signature names, a lot can be done,
>>> granted the calls *will* differ w/ and w/o names.
>>>
>>
>> I think you're too focused on signature as the notion of a function's
>> identity. There are aspects of functions which are not their signature yet
>> directly relate to its identity.
>>
>> Return values. If you declare two functions with the same name and
>> signatures with different return values, then you get a compile error.
>> `noexcept` works that way too; you can't be inconsistent about that. Both
>> of these are part of the function's type, but not its signature (though
>> `noexcept` can be cast away).
>>
>> Contracts affect neither type nor signature, but even that requires some
>> basic consistency. You can declare contracts on a function or not. But all
>> contract declarations for the same function must be consistent.
>>
>> If a parameter name can be used as a syntactic modifier when calling the
>> function (for the purposes of this discussion, anything which affects
>> actual code generation. This includes reordering of arguments), then that
>> name ought to be, if not part of the function's type, then at least have as
>> much consistency as its contracts. That is, if you want to be able to
>> reorder parameters, then the function should consistently assign each
>> parameter a single name or a single "unnamed".
>>
>
>
> In the original post about weak arguments, I suggested they obey the rules
> of default arguments - you name your arguments only in the first
> declaration. No names afterwards, not even the same.
>
> auto child(name mother: mom, name dad);
>
> // auto child(name mother: mom, name dad); *//< error*
> // auto child(name mom, name father: dad); *//< error*
> auto child(name mutter, vater); *//< OK*
> auto child(name mother, name father) *//< OK*
> {
>   // implementation
> }
>
> This seems the be the most consistent approach as (weak) named arguments
> ultimately inhabit *exactly* the same design space as default arguments -
> a compiler helper.
>

Default arguments generate code (conditionally or not). Weak named
arguments do not. I have some difficulty considering those to be "exactly
the same design space". Or even similar design spaces.

With default arguments the compiler is only obligated to copy-paste the
> default expression if we don't pass a value.
>
> With names it is a matter of what features we want to have:
>
>    - to only name-check
>    - to paste in place of name-only
>    - to paste on omission
>    - to rearrange
>
>
>
>
>> If names can be inconsistent and still affect syntax, bad things result.
>>
>> Should it be done is a different matter, this is a debate as heated as
>>> the one about signature - some people consider names useless if they don't
>>> rearrange/skip defaults, some are happy with just checking alone.
>>>
>>

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

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

<div dir=3D"ltr">On Tuesday, August 21, 2018 at 4:04:26 AM UTC-4, mihailn..=
..@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">On Tuesday, August 21, 2018 at 4:52:56 AM UTC+3, Nicol Bolas wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Monday, August 20,=
 2018 at 4:18:34 PM UTC-4, <a>mihailn...@gmail.com</a> wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr">On Monday, August 20, 2018 at 9:=
45:02 PM UTC+3, Nicol Bolas 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">On Monday, August 20, 2018 at 12:20:20 PM UTC-4, <a>mihai=
ln...@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"><div></div></div></blockquote></div></blockquote><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div></div><div><div>Are sure about that? Argument re=
arrangement is doable without changing the signature (a.k.a. strong)</div><=
/div></div></blockquote><div><br></div><div>Maybe we have very different id=
eas about what &quot;strong named parameters&quot; means. The question of &=
quot;changing the signature&quot; is not the distinction between=20
&quot;strong&quot; and &quot;weak&quot;. At least, it&#39;s not the distinc=
tion that I&#39;m talking about it.</div><div><br></div><div>&quot;Weak nam=
ed parameters&quot; to me refers to named parameters which are all of the f=
ollowing:</div><div><br></div><div>1. Optional. You can call a function tha=
t has named parameters without naming the parameter(s) at the call site.</d=
iv><div>2. Ordered. The order of the arguments must match the parameter ord=
er of the function, regardless of the names you specify at the call site.<b=
r></div><div>3. Overload-neutral. The presence or absence of names at the c=
all site has no effect on function overloading.</div><div><br></div><div>Es=
sentially, if your rules require that all named parameter function calls wi=
ll invoke the same function with the same behavior if you stripped out all =
of the names, then the named parameter proposal is &quot;weak&quot;.<br></d=
iv><div><br></div><div></div><div>Any named parameter feature which imposes=
 rules antithetical to at least one of the above is &quot;strong&quot;. Wit=
h the strongest being the antithesis to all of them.<br></div></div></block=
quote><div><br></div><div>I see, for you weak refers to the notion the call=
 is the same, but unchecked, without them.</div><div><br></div><div>For me =
strong is referring to &quot;does it introduce a new signature&quot;, the s=
ame way strong typedef introduces a new type. Everything else is weak as it=
 is about the compiler not the code.</div></div></blockquote><div><br></div=
><div>That&#39;s not what <a href=3D"https://groups.google.com/a/isocpp.org=
/d/msg/std-proposals/MbDT0vsA2j0/1VPQM7AsAAAJ" rel=3D"nofollow" target=3D"_=
blank" onmousedown=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.o=
rg/d/msg/std-proposals/MbDT0vsA2j0/1VPQM7AsAAAJ&#39;;return true;" onclick=
=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msg/std-propo=
sals/MbDT0vsA2j0/1VPQM7AsAAAJ&#39;;return true;">you said earlier</a>:</div=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Also=
, this obviously does not address the named arguments, <b>that are=20
optional, the &quot;weak&quot; ones</b>, so this solution will not make eve=
ryone=20
happy. <br></div></blockquote><div><br></div><div>Emphasis added. And there=
&#39;s <a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposal=
s/MbDT0vsA2j0/uWG77JxeDQAJ" rel=3D"nofollow" target=3D"_blank" onmousedown=
=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msg/std-propo=
sals/MbDT0vsA2j0/uWG77JxeDQAJ&#39;;return true;" onclick=3D"this.href=3D&#3=
9;https://groups.google.com/a/isocpp.org/d/msg/std-proposals/MbDT0vsA2j0/uW=
G77JxeDQAJ&#39;;return true;">this post</a>:<br></div><div><br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div>//weak argument names, not=
 mandatory <br></div></blockquote><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div>... <br></div></blockquote><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex"><div></div><div>//strong argument name, adds an overload,=
 not ignorable <br></div></blockquote><div><br></div><div>Yes, that post is=
 talking about how you would declare weak names differently from strong nam=
es, but it&#39;s also talking about how they get used at the call site: &qu=
ot;not mandatory&quot; vs. &quot;not ignorable&quot;.</div></div></blockquo=
te><div><br></div><div>There is no contradiction, they are optional, and ig=
norable by the user (he might not use them).=C2=A0</div><div>Now, it depend=
s on how much features they have, they might also be as weak as you assume =
they are, so they are (can be) ignored by the compiler as well and the call=
 is the same.</div><div><br></div><div>Most of the time here we talked abou=
t these weakest ones, and considered &quot;extra features&quot; as &quot;bo=
nuses&quot;.</div><div><br></div><div>For me personally strong were always =
the one changing the signature, that&#39;s why the first post about tags-as=
-labels was called &quot;Strong named arguments as tag overloads&quot;</div=
><div><br></div><div>And weak for me were not rearranging or skipping, but =
having defaulted-by-naming <font face=3D"courier new,monospace">f(a:, b:, 1=
0)=C2=A0</font></div><div>=C2=A0</div><div>Of course even these are not ign=
orable as the call will fail without them. Probably using the word ignorabl=
e was not correct.=C2=A0</div><div><br></div><div>In any case weak names ar=
e optional.=C2=A0</div><div>This is not to say, they do not affect overload=
ing, they do, but only on the call site.</div><div><br></div><div><span sty=
le=3D"text-align:left;color:rgb(34,34,34);text-transform:none;text-indent:0=
px;letter-spacing:normal;font-size:13px;font-style:normal;font-variant:norm=
al;font-weight:400;text-decoration:none;word-spacing:0px;display:inline!imp=
ortant;white-space:normal;float:none;background-color:transparent"><font fa=
ce=3D"courier new,monospace">void func(int a, int b);</font></span><b></b><=
i></i><u></u><sub></sub><sup></sup><strike></strike><br></div><div><font fa=
ce=3D"courier new,monospace">void func(int a, int b: b=3D1, int c: c=3D2);<=
/font></div><div><font face=3D"courier new,monospace"></font><br></div><div=
><font face=3D"courier new,monospace">func(1, 3); //&lt; overload 1</font><=
/div><div><span style=3D"text-align:left;color:rgb(34,34,34);text-transform=
:none;text-indent:0px;letter-spacing:normal;font-size:13px;font-style:norma=
l;font-variant:normal;font-weight:400;text-decoration:none;word-spacing:0px=
;display:inline!important;white-space:normal;float:none;background-color:tr=
ansparent"><font face=3D"courier new,monospace">func(1, b: 3);<span style=
=3D"display:inline!important;float:none;background-color:transparent;color:=
rgb(34,34,34);font-family:courier new,monospace;font-size:13px;font-style:n=
ormal;font-variant:normal;font-weight:400;letter-spacing:normal;text-align:=
left;text-decoration:none;text-indent:0px;text-transform:none;white-space:n=
ormal;word-spacing:0px"> //&lt; overload 2</span></font></span><br></div><d=
iv><span><font style=3D"border-bottom-color:rgb(34,34,34);border-bottom-sty=
le:none;border-bottom-width:0px;border-left-color:rgb(34,34,34);border-left=
-style:none;border-left-width:0px;border-right-color:rgb(34,34,34);border-r=
ight-style:none;border-right-width:0px;border-top-color:rgb(34,34,34);borde=
r-top-style:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;mar=
gin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-ri=
ght:0px;padding-top:0px" face=3D"courier new,monospace">func(1, c: 3);<span=
 style=3D"background-color:transparent;border-bottom-color:rgb(34,34,34);bo=
rder-bottom-style:none;border-bottom-width:0px;border-left-color:rgb(34,34,=
34);border-left-style:none;border-left-width:0px;border-right-color:rgb(34,=
34,34);border-right-style:none;border-right-width:0px;border-top-color:rgb(=
34,34,34);border-top-style:none;border-top-width:0px;color:rgb(34,34,34);di=
splay:inline;float:none;font-family:courier new,monospace;font-size:13px;fo=
nt-style:normal;font-variant:normal;font-weight:400;letter-spacing:normal;m=
argin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bo=
ttom:0px;padding-left:0px;padding-right:0px;padding-top:0px;text-align:left=
;text-decoration:none;text-indent:0px;text-transform:none;white-space:norma=
l;word-spacing:0px"> //&lt; overload 2</span></font></span><b></b><i></i><u=
></u><sub></sub><sup></sup><strike></strike><br></div><div><b></b><i></i><u=
></u><sub></sub><sup></sup><strike></strike><br></div></div></blockquote><d=
iv><br></div><div>If names are important enough to affect what overload get=
s called, then they ought to be part of a function&#39;s type. If they are =
truly &quot;optional&quot;, then they should not be able to affect overload=
ing.</div><div><br></div><div>To me, &quot;optional&quot; means exactly tha=
t: optional. The choice of whether to use names or not is entirely the prer=
ogative of the caller. A caller should be able to call the same function, p=
roviding the same parameters, without using parameter names if they so desi=
re.</div><div><br></div><div>You call the second overload, passing it the f=
irst two parameters. That is not possible without using parameter names. Yo=
u call the third overload, passing only the first and third parameters. Tha=
t too is not possible without using parameter names.</div><div><br></div><d=
iv>For your proposal, parameter names are not optional. That&#39;s differen=
t from saying that they are mandatory. There are cases in your design where=
 you can call a named parameter function overload without providing names f=
or those parameters.</div><div><br></div><div>The key here is that in your =
proposal, parameter names are <i>part of the overload set&#39;s interface</=
i>. Just like the various conversion operators and constructors on the type=
s used as parameters.</div><div><br></div><div>That&#39;s what makes them d=
ifferent from default parameters: the fact that `func(1, 3)` is not ambiguo=
us. With default parameters, users who don&#39;t specify all of the paramet=
ers can create ambiguous call relative to other overloads in the set. With =
your design, that doesn&#39;t happen. This is what makes the parameter name=
 <i>more</i> than just a default argument; it makes it part of the overload=
 set&#39;s interface.<br></div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div></div><div>Changing the signature is a clear bounda=
ry in both semantics and implementation.<br></div></div></blockquote><div><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><d=
iv></div><div>But in the realm of non-changing-the-signature names, a lot c=
an be done, granted the calls <i>will</i> differ w/ and w/o names.</div></d=
iv></blockquote><div><br></div><div>I think you&#39;re too focused on signa=
ture as the notion of a function&#39;s identity. There are aspects of funct=
ions which are not their signature yet directly relate to its identity.</di=
v><div><br></div><div>Return values. If you declare two functions with the =
same name and signatures with different return values, then you get a compi=
le error. `noexcept` works that way too; you can&#39;t be inconsistent abou=
t that. Both of these are part of the function&#39;s type, but not its sign=
ature (though `noexcept` can be cast away).</div><div><br></div><div>Contra=
cts affect neither type nor signature, but even that requires some basic co=
nsistency. You can declare contracts on a function or not. But all contract=
 declarations for the same function must be consistent.</div><div><br></div=
><div>If a parameter name can be used as a syntactic modifier when calling =
the function (for the purposes of this discussion, anything which affects a=
ctual code generation. This includes reordering of arguments), then that na=
me ought to be, if not part of the function&#39;s type, then at least have =
as much consistency as its contracts. That is, if you want to be able to re=
order parameters, then the function should consistently assign each paramet=
er a single name or a single &quot;unnamed&quot;.</div></div></blockquote><=
div><br></div><div><br></div><div>In the original post about weak arguments=
, I suggested they obey the rules of default arguments - you name your argu=
ments only in the first declaration. No names afterwards, not even the same=
..=C2=A0</div><div><br></div><div><div><span style=3D"background-color:trans=
parent;border-bottom-color:rgb(34,34,34);border-bottom-style:none;border-bo=
ttom-width:0px;border-left-color:rgb(34,34,34);border-left-style:none;borde=
r-left-width:0px;border-right-color:rgb(34,34,34);border-right-style:none;b=
order-right-width:0px;border-top-color:rgb(34,34,34);border-top-style:none;=
border-top-width:0px;color:rgb(34,34,34);display:inline;float:none;font-siz=
e:13px;font-style:normal;font-variant:normal;font-weight:400;letter-spacing=
:normal;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;p=
adding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px;text-a=
lign:left;text-decoration:none;text-indent:0px;text-transform:none;white-sp=
ace:normal;word-spacing:0px"><font style=3D"border-bottom-color:rgb(34,34,3=
4);border-bottom-style:none;border-bottom-width:0px;border-left-color:rgb(3=
4,34,34);border-left-style:none;border-left-width:0px;border-right-color:rg=
b(34,34,34);border-right-style:none;border-right-width:0px;border-top-color=
:rgb(34,34,34);border-top-style:none;border-top-width:0px;margin-bottom:0px=
;margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding=
-left:0px;padding-right:0px;padding-top:0px" face=3D"courier new,monospace"=
>auto child(name mother: mom, name dad);=C2=A0</font></span></div><div><spa=
n style=3D"background-color:transparent;border-bottom-color:rgb(34,34,34);b=
order-bottom-style:none;border-bottom-width:0px;border-left-color:rgb(34,34=
,34);border-left-style:none;border-left-width:0px;border-right-color:rgb(34=
,34,34);border-right-style:none;border-right-width:0px;border-top-color:rgb=
(34,34,34);border-top-style:none;border-top-width:0px;color:rgb(34,34,34);d=
isplay:inline;float:none;font-size:13px;font-style:normal;font-variant:norm=
al;font-weight:400;letter-spacing:normal;margin-bottom:0px;margin-left:0px;=
margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding=
-right:0px;padding-top:0px;text-align:left;text-decoration:none;text-indent=
:0px;text-transform:none;white-space:normal;word-spacing:0px"><font style=
=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:none;border-botto=
m-width:0px;border-left-color:rgb(34,34,34);border-left-style:none;border-l=
eft-width:0px;border-right-color:rgb(34,34,34);border-right-style:none;bord=
er-right-width:0px;border-top-color:rgb(34,34,34);border-top-style:none;bor=
der-top-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin=
-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:=
0px" face=3D"courier new,monospace"><br></font></span></div><div><font face=
=3D"courier new,monospace">// <span style=3D"border-bottom-color:rgb(34,34,=
34);border-bottom-style:none;border-bottom-width:0px;border-left-color:rgb(=
34,34,34);border-left-style:none;border-left-width:0px;border-right-color:r=
gb(34,34,34);border-right-style:none;border-right-width:0px;border-top-colo=
r:rgb(34,34,34);border-top-style:none;border-top-width:0px;margin-bottom:0p=
x;margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;paddin=
g-left:0px;padding-right:0px;padding-top:0px"><font style=3D"border-bottom-=
color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;border=
-left-color:rgb(34,34,34);border-left-style:none;border-left-width:0px;bord=
er-right-color:rgb(34,34,34);border-right-style:none;border-right-width:0px=
;border-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0px;=
margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-b=
ottom:0px;padding-left:0px;padding-right:0px;padding-top:0px">auto child(na=
me mother: mom, name dad); <i>//&lt; error</i></font></span></font></div><d=
iv><span style=3D"background-color:transparent;border-bottom-color:rgb(34,3=
4,34);border-bottom-style:none;border-bottom-width:0px;border-left-color:rg=
b(34,34,34);border-left-style:none;border-left-width:0px;border-right-color=
:rgb(34,34,34);border-right-style:none;border-right-width:0px;border-top-co=
lor:rgb(34,34,34);border-top-style:none;border-top-width:0px;color:rgb(34,3=
4,34);display:inline;float:none;font-size:13px;font-variant:normal;letter-s=
pacing:normal;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top=
:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px;=
text-align:left;text-indent:0px;text-transform:none;white-space:normal;word=
-spacing:0px"><font style=3D"border-bottom-color:rgb(34,34,34);border-botto=
m-style:none;border-bottom-width:0px;border-left-color:rgb(34,34,34);border=
-left-style:none;border-left-width:0px;border-right-color:rgb(34,34,34);bor=
der-right-style:none;border-right-width:0px;border-top-color:rgb(34,34,34);=
border-top-style:none;border-top-width:0px;margin-bottom:0px;margin-left:0p=
x;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;paddi=
ng-right:0px;padding-top:0px"><font face=3D"courier new,monospace"><span>//=
 </span><span style=3D"border-bottom-color:rgb(34,34,34);border-bottom-styl=
e:none;border-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-=
style:none;border-left-width:0px;border-right-color:rgb(34,34,34);border-ri=
ght-style:none;border-right-width:0px;border-top-color:rgb(34,34,34);border=
-top-style:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;marg=
in-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-rig=
ht:0px;padding-top:0px"><font style=3D"border-bottom-color:rgb(34,34,34);bo=
rder-bottom-style:none;border-bottom-width:0px;border-left-color:rgb(34,34,=
34);border-left-style:none;border-left-width:0px;border-right-color:rgb(34,=
34,34);border-right-style:none;border-right-width:0px;border-top-color:rgb(=
34,34,34);border-top-style:none;border-top-width:0px;margin-bottom:0px;marg=
in-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left=
:0px;padding-right:0px;padding-top:0px">auto child(name mom, name father: d=
ad); <i>//&lt; error</i></font></span></font><b style=3D"border-bottom-colo=
r:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;border-lef=
t-color:rgb(34,34,34);border-left-style:none;border-left-width:0px;border-r=
ight-color:rgb(34,34,34);border-right-style:none;border-right-width:0px;bor=
der-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0px;marg=
in-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-botto=
m:0px;padding-left:0px;padding-right:0px;padding-top:0px"></b><u style=3D"b=
order-bottom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-wid=
th:0px;border-left-color:rgb(34,34,34);border-left-style:none;border-left-w=
idth:0px;border-right-color:rgb(34,34,34);border-right-style:none;border-ri=
ght-width:0px;border-top-color:rgb(34,34,34);border-top-style:none;border-t=
op-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:=
0px;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px">=
</u><sub style=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:non=
e;border-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-style=
:none;border-left-width:0px;border-right-color:rgb(34,34,34);border-right-s=
tyle:none;border-right-width:0px;border-top-color:rgb(34,34,34);border-top-=
style:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin-ri=
ght:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0p=
x;padding-top:0px"></sub><sup style=3D"border-bottom-color:rgb(34,34,34);bo=
rder-bottom-style:none;border-bottom-width:0px;border-left-color:rgb(34,34,=
34);border-left-style:none;border-left-width:0px;border-right-color:rgb(34,=
34,34);border-right-style:none;border-right-width:0px;border-top-color:rgb(=
34,34,34);border-top-style:none;border-top-width:0px;margin-bottom:0px;marg=
in-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left=
:0px;padding-right:0px;padding-top:0px"></sup><strike style=3D"border-botto=
m-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;bord=
er-left-color:rgb(34,34,34);border-left-style:none;border-left-width:0px;bo=
rder-right-color:rgb(34,34,34);border-right-style:none;border-right-width:0=
px;border-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0p=
x;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding=
-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px"></strike><b=
r style=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:none;borde=
r-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-style:none;b=
order-left-width:0px;border-right-color:rgb(34,34,34);border-right-style:no=
ne;border-right-width:0px;border-top-color:rgb(34,34,34);border-top-style:n=
one;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px=
;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;paddi=
ng-top:0px"></font></span></div><div><span style=3D"background-color:transp=
arent;border-bottom-color:rgb(34,34,34);border-bottom-style:none;border-bot=
tom-width:0px;border-left-color:rgb(34,34,34);border-left-style:none;border=
-left-width:0px;border-right-color:rgb(34,34,34);border-right-style:none;bo=
rder-right-width:0px;border-top-color:rgb(34,34,34);border-top-style:none;b=
order-top-width:0px;color:rgb(34,34,34);display:inline;float:none;font-size=
:13px;font-style:normal;font-variant:normal;font-weight:400;letter-spacing:=
normal;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;pa=
dding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px;text-al=
ign:left;text-decoration:none;text-indent:0px;text-transform:none;white-spa=
ce:normal;word-spacing:0px"><font style=3D"border-bottom-color:rgb(34,34,34=
);border-bottom-style:none;border-bottom-width:0px;border-left-color:rgb(34=
,34,34);border-left-style:none;border-left-width:0px;border-right-color:rgb=
(34,34,34);border-right-style:none;border-right-width:0px;border-top-color:=
rgb(34,34,34);border-top-style:none;border-top-width:0px;margin-bottom:0px;=
margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-=
left:0px;padding-right:0px;padding-top:0px" face=3D"courier new,monospace">=
auto child(name mutter, vater); <i>//&lt; OK</i></font></span><b style=3D"b=
order-bottom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-wid=
th:0px;border-left-color:rgb(34,34,34);border-left-style:none;border-left-w=
idth:0px;border-right-color:rgb(34,34,34);border-right-style:none;border-ri=
ght-width:0px;border-top-color:rgb(34,34,34);border-top-style:none;border-t=
op-width:0px;color:rgb(34,34,34);line-height:normal;margin-bottom:0px;margi=
n-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:=
0px;padding-right:0px;padding-top:0px"></b><u style=3D"border-bottom-color:=
rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;border-left-=
color:rgb(34,34,34);border-left-style:none;border-left-width:0px;border-rig=
ht-color:rgb(34,34,34);border-right-style:none;border-right-width:0px;borde=
r-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0px;color:=
rgb(34,34,34);line-height:normal;margin-bottom:0px;margin-left:0px;margin-r=
ight:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0=
px;padding-top:0px"></u><sub style=3D"border-bottom-color:rgb(34,34,34);bor=
der-bottom-style:none;border-bottom-width:0px;border-left-color:rgb(34,34,3=
4);border-left-style:none;border-left-width:0px;border-right-color:rgb(34,3=
4,34);border-right-style:none;border-right-width:0px;border-top-color:rgb(3=
4,34,34);border-top-style:none;border-top-width:0px;margin-bottom:0px;margi=
n-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:=
0px;padding-right:0px;padding-top:0px"></sub><sup style=3D"border-bottom-co=
lor:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;border-l=
eft-color:rgb(34,34,34);border-left-style:none;border-left-width:0px;border=
-right-color:rgb(34,34,34);border-right-style:none;border-right-width:0px;b=
order-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0px;ma=
rgin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bot=
tom:0px;padding-left:0px;padding-right:0px;padding-top:0px"></sup><strike s=
tyle=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:none;border-b=
ottom-width:0px;border-left-color:rgb(34,34,34);border-left-style:none;bord=
er-left-width:0px;border-right-color:rgb(34,34,34);border-right-style:none;=
border-right-width:0px;border-top-color:rgb(34,34,34);border-top-style:none=
;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;ma=
rgin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-=
top:0px"></strike></div><div><span style=3D"margin:0px;padding:0px;border:0=
px rgb(34,34,34);text-align:left;color:rgb(34,34,34);text-transform:none;te=
xt-indent:0px;letter-spacing:normal;font-size:13px;font-style:normal;font-v=
ariant:normal;font-weight:400;text-decoration:none;word-spacing:0px;display=
:inline;white-space:normal;float:none;background-color:transparent"><font f=
ace=3D"courier new,monospace">auto child(name mother, name father) <i>//&lt=
; OK</i></font></span></div><b></b><i></i><u></u><sub></sub><sup></sup><str=
ike></strike><font face=3D"courier new,monospace">{=C2=A0</font></div><div>=
<font face=3D"courier new,monospace">=C2=A0 // implementation</font></div><=
div><font face=3D"courier new,monospace">}</font><br></div><div>=C2=A0</div=
><div>This seems the be the most consistent approach as (weak) named argume=
nts ultimately inhabit <i>exactly</i> the same design space as default argu=
ments - a compiler helper.</div></div></blockquote><div><br></div><div>Defa=
ult arguments generate code (conditionally or not). Weak named arguments do=
 not. I have some difficulty considering those to be &quot;exactly the same=
 design space&quot;. Or even similar design spaces.<br></div><div><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><=
div>With default arguments the compiler is only obligated to copy-paste the=
 default expression if we don&#39;t pass a value.</div><div><br></div><div>=
With names it is a matter of what features we want to have:</div><ul><li>to=
 only name-check</li><li>to paste in place of name-only</li><li>to paste on=
 omission<br></li><li>to rearrange<br></li></ul><div><br></div><div><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div>=
<div></div><div>If names can be inconsistent and still affect syntax, bad t=
hings result.</div><div></div><div><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div>Should it be done is a different matter, th=
is is a debate as heated as the one about signature - some people consider =
names useless if they don&#39;t rearrange/skip defaults, some are happy wit=
h just checking alone.=C2=A0 <br></div></div></blockquote></div></blockquot=
e></div></blockquote></div>

<p></p>

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

------=_Part_1640_1997879759.1534970849186--

------=_Part_1639_506452266.1534970849185--

.

------=_Part_2648_1589242274.1534971425551
Content-Type: multipart/alternative;
 boundary="----=_Part_2649_602971420.1534971425551"

------=_Part_2649_602971420.1534971425551
Content-Type: text/plain; charset="UTF-8"

On Wednesday, August 22, 2018 at 4:47:29 PM UTC-4, Nicol Bolas wrote:
>
> Default arguments generate code (conditionally or not). Weak named
> arguments do not. I have some difficulty considering those to be "exactly
> the same design space". Or even similar design spaces.
>

Disregard this paragraph; I meant to delete that before pressing "send".

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

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

<div dir=3D"ltr">On Wednesday, August 22, 2018 at 4:47:29 PM UTC-4, Nicol B=
olas 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"><d=
iv></div><div>Default arguments generate code (conditionally or not). Weak =
named arguments do not. I have some difficulty considering those to be &quo=
t;exactly the same design space&quot;. Or even similar design spaces.<br></=
div></div></blockquote><div><br></div><div>Disregard this paragraph; I mean=
t to delete that before pressing &quot;send&quot;.</div></div>

<p></p>

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

------=_Part_2649_602971420.1534971425551--

------=_Part_2648_1589242274.1534971425551--

.

------=_Part_2210_1097133904.1535013282972
Content-Type: multipart/alternative;
 boundary="----=_Part_2211_2114072163.1535013282974"

------=_Part_2211_2114072163.1535013282974
Content-Type: text/plain; charset="UTF-8"



On Wednesday, August 22, 2018 at 11:47:29 PM UTC+3, Nicol Bolas wrote:
>
> On Tuesday, August 21, 2018 at 4:04:26 AM UTC-4, mihailn...@gmail.com
> wrote:
>>
>> On Tuesday, August 21, 2018 at 4:52:56 AM UTC+3, Nicol Bolas wrote:
>>>
>>> On Monday, August 20, 2018 at 4:18:34 PM UTC-4, mihailn...@gmail.com
>>> wrote:
>>>>
>>>> On Monday, August 20, 2018 at 9:45:02 PM UTC+3, Nicol Bolas wrote:
>>>>>
>>>>> On Monday, August 20, 2018 at 12:20:20 PM UTC-4, mihailn...@gmail.com
>>>>> wrote:
>>>>>>
>>>>>> Are sure about that? Argument rearrangement is doable without
>>>>>> changing the signature (a.k.a. strong)
>>>>>>
>>>>>
>>>>> Maybe we have very different ideas about what "strong named
>>>>> parameters" means. The question of "changing the signature" is not the
>>>>> distinction between "strong" and "weak". At least, it's not the distinction
>>>>> that I'm talking about it.
>>>>>
>>>>> "Weak named parameters" to me refers to named parameters which are all
>>>>> of the following:
>>>>>
>>>>> 1. Optional. You can call a function that has named parameters without
>>>>> naming the parameter(s) at the call site.
>>>>> 2. Ordered. The order of the arguments must match the parameter order
>>>>> of the function, regardless of the names you specify at the call site.
>>>>> 3. Overload-neutral. The presence or absence of names at the call site
>>>>> has no effect on function overloading.
>>>>>
>>>>> Essentially, if your rules require that all named parameter function
>>>>> calls will invoke the same function with the same behavior if you stripped
>>>>> out all of the names, then the named parameter proposal is "weak".
>>>>>
>>>>> Any named parameter feature which imposes rules antithetical to at
>>>>> least one of the above is "strong". With the strongest being the antithesis
>>>>> to all of them.
>>>>>
>>>>
>>>> I see, for you weak refers to the notion the call is the same, but
>>>> unchecked, without them.
>>>>
>>>> For me strong is referring to "does it introduce a new signature", the
>>>> same way strong typedef introduces a new type. Everything else is weak as
>>>> it is about the compiler not the code.
>>>>
>>>
>>> That's not what you said earlier
>>> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/MbDT0vsA2j0/1VPQM7AsAAAJ>
>>> :
>>>
>>> Also, this obviously does not address the named arguments, *that are
>>>> optional, the "weak" ones*, so this solution will not make everyone
>>>> happy.
>>>>
>>>
>>> Emphasis added. And there's this post
>>> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/MbDT0vsA2j0/uWG77JxeDQAJ>
>>> :
>>>
>>> //weak argument names, not mandatory
>>>>
>>> ...
>>>>
>>> //strong argument name, adds an overload, not ignorable
>>>>
>>>
>>> Yes, that post is talking about how you would declare weak names
>>> differently from strong names, but it's also talking about how they get
>>> used at the call site: "not mandatory" vs. "not ignorable".
>>>
>>
>> There is no contradiction, they are optional, and ignorable by the user
>> (he might not use them).
>> Now, it depends on how much features they have, they might also be as
>> weak as you assume they are, so they are (can be) ignored by the compiler
>> as well and the call is the same.
>>
>> Most of the time here we talked about these weakest ones, and considered
>> "extra features" as "bonuses".
>>
>> For me personally strong were always the one changing the signature,
>> that's why the first post about tags-as-labels was called "Strong named
>> arguments as tag overloads"
>>
>> And weak for me were not rearranging or skipping, but having
>> defaulted-by-naming f(a:, b:, 10)
>>
>> Of course even these are not ignorable as the call will fail without
>> them. Probably using the word ignorable was not correct.
>>
>> In any case weak names are optional.
>> This is not to say, they do not affect overloading, they do, but only on
>> the call site.
>>
>>

> void func(int a, int b);
>> void func(int a, int b: b=1, int c: c=2);
>>
>> func(1, 3); //< overload 1
>> func(1, b: 3); //< overload 2
>> func(1, c: 3); //< overload 2
>>
>>
> If names are important enough to affect what overload gets called, then
> they ought to be part of a function's type. If they are truly "optional",
> then they should not be able to affect overloading.
>
> To me, "optional" means exactly that: optional. The choice of whether to
> use names or not is entirely the prerogative of the caller. A caller should
> be able to call the same function, providing the same parameters, without
> using parameter names if they so desire.
>
> You call the second overload, passing it the first two parameters. That is
> not possible without using parameter names. You call the third overload,
> passing only the first and third parameters. That too is not possible
> without using parameter names.
>
> For your proposal, parameter names are not optional. That's different from
> saying that they are mandatory. There are cases in your design where you
> can call a named parameter function overload without providing names for
> those parameters.
>
> The key here is that in your proposal, parameter names are *part of the
> overload set's interface*. Just like the various conversion operators and
> constructors on the types used as parameters.
>
> That's what makes them different from default parameters: the fact that
> `func(1, 3)` is not ambiguous. With default parameters, users who don't
> specify all of the parameters can create ambiguous call relative to other
> overloads in the set. With your design, that doesn't happen. This is what
> makes the parameter name *more* than just a default argument; it makes it
> part of the overload set's interface.
>
>
Boy, I made a mistake, func(1, 3) is *of course *ambiguous!

Bad example, here is the correct one

void func(int a, string b);
void func(int a, int b: b=1, string c: c="hi");
void func(int a, int b: b=1, int c: c=2);

func(1, "bye"); //< overload 1
func(1, c: "bye"); //< overload 2
func(1, c: 3); //< overload 3

The point was, on the call site (optional) names *can* affect overloading.

The more general argument was, optional names can service mega-functions,
as long as they allow skipping defaulted arguments.

But even mega-functions aside, *none of the current alternatives to the
above code are better*, even if possible - that's is way people want that
feature!



> Changing the signature is a clear boundary in both semantics and
>>>> implementation.
>>>>
>>> But in the realm of non-changing-the-signature names, a lot can be done,
>>>> granted the calls *will* differ w/ and w/o names.
>>>>
>>>
>>> I think you're too focused on signature as the notion of a function's
>>> identity. There are aspects of functions which are not their signature yet
>>> directly relate to its identity.
>>>
>>> Return values. If you declare two functions with the same name and
>>> signatures with different return values, then you get a compile error.
>>> `noexcept` works that way too; you can't be inconsistent about that. Both
>>> of these are part of the function's type, but not its signature (though
>>> `noexcept` can be cast away).
>>>
>>> Contracts affect neither type nor signature, but even that requires some
>>> basic consistency. You can declare contracts on a function or not. But all
>>> contract declarations for the same function must be consistent.
>>>
>>> If a parameter name can be used as a syntactic modifier when calling the
>>> function (for the purposes of this discussion, anything which affects
>>> actual code generation. This includes reordering of arguments), then that
>>> name ought to be, if not part of the function's type, then at least have as
>>> much consistency as its contracts. That is, if you want to be able to
>>> reorder parameters, then the function should consistently assign each
>>> parameter a single name or a single "unnamed".
>>>
>>
>>
>> In the original post about weak arguments, I suggested they obey the
>> rules of default arguments - you name your arguments only in the first
>> declaration. No names afterwards, not even the same.
>>
>> auto child(name mother: mom, name dad);
>>
>> // auto child(name mother: mom, name dad); *//< error*
>> // auto child(name mom, name father: dad); *//< error*
>> auto child(name mutter, vater); *//< OK*
>> auto child(name mother, name father) *//< OK*
>> {
>>   // implementation
>> }
>>
>> This seems the be the most consistent approach as (weak) named arguments
>> ultimately inhabit *exactly* the same design space as default arguments
>> - a compiler helper.
>>
>
> Default arguments generate code (conditionally or not). Weak named
> arguments do not. I have some difficulty considering those to be "exactly
> the same design space". Or even similar design spaces.
>
> With default arguments the compiler is only obligated to copy-paste the
>> default expression if we don't pass a value.
>>
>> With names it is a matter of what features we want to have:
>>
>>    - to only name-check
>>    - to paste in place of name-only
>>    - to paste on omission
>>    - to rearrange
>>
>>
>>
>>
>>> If names can be inconsistent and still affect syntax, bad things result.
>>>
>>> Should it be done is a different matter, this is a debate as heated as
>>>> the one about signature - some people consider names useless if they don't
>>>> rearrange/skip defaults, some are happy with just checking alone.
>>>>
>>>

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

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

<div dir=3D"ltr"><br><br>On Wednesday, August 22, 2018 at 11:47:29 PM UTC+3=
, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Tuesday, August 21, 2018 at 4:04:26 AM UTC-4, <a>mihailn...@gma=
il.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">O=
n Tuesday, August 21, 2018 at 4:52:56 AM UTC+3, Nicol Bolas wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Monday, August 20, 2018 =
at 4:18:34 PM UTC-4, <a>mihailn...@gmail.com</a> wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr">On Monday, August 20, 2018 at 9:45:02 =
PM UTC+3, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr">On Monday, August 20, 2018 at 12:20:20 PM UTC-4, <a>mihailn...@gm=
ail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div></div></div></blockquote></div></blockquote><blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div></div><div><div>Are sure about that? Argument rearrangeme=
nt is doable without changing the signature (a.k.a. strong)</div></div></di=
v></blockquote><div><br></div><div>Maybe we have very different ideas about=
 what &quot;strong named parameters&quot; means. The question of &quot;chan=
ging the signature&quot; is not the distinction between=20
&quot;strong&quot; and &quot;weak&quot;. At least, it&#39;s not the distinc=
tion that I&#39;m talking about it.</div><div><br></div><div>&quot;Weak nam=
ed parameters&quot; to me refers to named parameters which are all of the f=
ollowing:</div><div><br></div><div>1. Optional. You can call a function tha=
t has named parameters without naming the parameter(s) at the call site.</d=
iv><div>2. Ordered. The order of the arguments must match the parameter ord=
er of the function, regardless of the names you specify at the call site.<b=
r></div><div>3. Overload-neutral. The presence or absence of names at the c=
all site has no effect on function overloading.</div><div><br></div><div>Es=
sentially, if your rules require that all named parameter function calls wi=
ll invoke the same function with the same behavior if you stripped out all =
of the names, then the named parameter proposal is &quot;weak&quot;.<br></d=
iv><div><br></div><div></div><div>Any named parameter feature which imposes=
 rules antithetical to at least one of the above is &quot;strong&quot;. Wit=
h the strongest being the antithesis to all of them.<br></div></div></block=
quote><div><br></div><div>I see, for you weak refers to the notion the call=
 is the same, but unchecked, without them.</div><div><br></div><div>For me =
strong is referring to &quot;does it introduce a new signature&quot;, the s=
ame way strong typedef introduces a new type. Everything else is weak as it=
 is about the compiler not the code.</div></div></blockquote><div><br></div=
><div>That&#39;s not what <a onmousedown=3D"this.href=3D&#39;https://groups=
..google.com/a/isocpp.org/d/msg/std-proposals/MbDT0vsA2j0/1VPQM7AsAAAJ&#39;;=
return true;" onclick=3D"this.href=3D&#39;https://groups.google.com/a/isocp=
p.org/d/msg/std-proposals/MbDT0vsA2j0/1VPQM7AsAAAJ&#39;;return true;" href=
=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/MbDT0vsA2j0/=
1VPQM7AsAAAJ" target=3D"_blank" rel=3D"nofollow">you said earlier</a>:</div=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Also=
, this obviously does not address the named arguments, <b>that are=20
optional, the &quot;weak&quot; ones</b>, so this solution will not make eve=
ryone=20
happy. <br></div></blockquote><div><br></div><div>Emphasis added. And there=
&#39;s <a onmousedown=3D"this.href=3D&#39;https://groups.google.com/a/isocp=
p.org/d/msg/std-proposals/MbDT0vsA2j0/uWG77JxeDQAJ&#39;;return true;" oncli=
ck=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msg/std-pro=
posals/MbDT0vsA2j0/uWG77JxeDQAJ&#39;;return true;" href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msg/std-proposals/MbDT0vsA2j0/uWG77JxeDQAJ" target=
=3D"_blank" rel=3D"nofollow">this post</a>:<br></div><div><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div>//weak argument names, not =
mandatory <br></div></blockquote><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div>... <br></div></blockquote><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div></div><div>//strong argument name, adds an overload, no=
t ignorable <br></div></blockquote><div><br></div><div>Yes, that post is ta=
lking about how you would declare weak names differently from strong names,=
 but it&#39;s also talking about how they get used at the call site: &quot;=
not mandatory&quot; vs. &quot;not ignorable&quot;.</div></div></blockquote>=
<div><br></div><div>There is no contradiction, they are optional, and ignor=
able by the user (he might not use them).=C2=A0</div><div>Now, it depends o=
n how much features they have, they might also be as weak as you assume the=
y are, so they are (can be) ignored by the compiler as well and the call is=
 the same.</div><div><br></div><div>Most of the time here we talked about t=
hese weakest ones, and considered &quot;extra features&quot; as &quot;bonus=
es&quot;.</div><div><br></div><div>For me personally strong were always the=
 one changing the signature, that&#39;s why the first post about tags-as-la=
bels was called &quot;Strong named arguments as tag overloads&quot;</div><d=
iv><br></div><div>And weak for me were not rearranging or skipping, but hav=
ing defaulted-by-naming <font face=3D"courier new,monospace">f(a:, b:, 10)=
=C2=A0</font></div><div>=C2=A0</div><div>Of course even these are not ignor=
able as the call will fail without them. Probably using the word ignorable =
was not correct.=C2=A0</div><div><br></div><div>In any case weak names are =
optional.=C2=A0</div><div>This is not to say, they do not affect overloadin=
g, they do, but only on the call site.</div><div><br></div></div></blockquo=
te></div></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div></div><div><span style=3D"text-align:left;color:rgb(34,34,34)=
;text-transform:none;text-indent:0px;letter-spacing:normal;font-size:13px;f=
ont-style:normal;font-variant:normal;font-weight:400;text-decoration:none;w=
ord-spacing:0px;display:inline!important;white-space:normal;float:none;back=
ground-color:transparent"><font face=3D"courier new,monospace">void func(in=
t a, int b);</font></span><b></b><i></i><u></u><sub></sub><sup></sup><strik=
e></strike><br></div><div><font face=3D"courier new,monospace">void func(in=
t a, int b: b=3D1, int c: c=3D2);</font></div><div><font face=3D"courier ne=
w,monospace"></font><br></div><div><font face=3D"courier new,monospace">fun=
c(1, 3); //&lt; overload 1</font></div><div><span style=3D"text-align:left;=
color:rgb(34,34,34);text-transform:none;text-indent:0px;letter-spacing:norm=
al;font-size:13px;font-style:normal;font-variant:normal;font-weight:400;tex=
t-decoration:none;word-spacing:0px;display:inline!important;white-space:nor=
mal;float:none;background-color:transparent"><font face=3D"courier new,mono=
space">func(1, b: 3);<span style=3D"display:inline!important;float:none;bac=
kground-color:transparent;color:rgb(34,34,34);font-family:courier new,monos=
pace;font-size:13px;font-style:normal;font-variant:normal;font-weight:400;l=
etter-spacing:normal;text-align:left;text-decoration:none;text-indent:0px;t=
ext-transform:none;white-space:normal;word-spacing:0px"> //&lt; overload 2<=
/span></font></span><br></div><div><span><font face=3D"courier new,monospac=
e" style=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:none;bord=
er-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-style:none;=
border-left-width:0px;border-right-color:rgb(34,34,34);border-right-style:n=
one;border-right-width:0px;border-top-color:rgb(34,34,34);border-top-style:=
none;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0p=
x;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;padd=
ing-top:0px">func(1, c: 3);<span style=3D"background-color:transparent;bord=
er-bottom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:=
0px;border-left-color:rgb(34,34,34);border-left-style:none;border-left-widt=
h:0px;border-right-color:rgb(34,34,34);border-right-style:none;border-right=
-width:0px;border-top-color:rgb(34,34,34);border-top-style:none;border-top-=
width:0px;color:rgb(34,34,34);display:inline;float:none;font-family:courier=
 new,monospace;font-size:13px;font-style:normal;font-variant:normal;font-we=
ight:400;letter-spacing:normal;margin-bottom:0px;margin-left:0px;margin-rig=
ht:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px=
;padding-top:0px;text-align:left;text-decoration:none;text-indent:0px;text-=
transform:none;white-space:normal;word-spacing:0px"> //&lt; overload 2</spa=
n></font></span><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike=
><br></div><div><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike=
><br></div></div></blockquote><div><br></div><div>If names are important en=
ough to affect what overload gets called, then they ought to be part of a f=
unction&#39;s type. If they are truly &quot;optional&quot;, then they shoul=
d not be able to affect overloading.</div><div><br></div><div>To me, &quot;=
optional&quot; means exactly that: optional. The choice of whether to use n=
ames or not is entirely the prerogative of the caller. A caller should be a=
ble to call the same function, providing the same parameters, without using=
 parameter names if they so desire.</div><div><br></div><div>You call the s=
econd overload, passing it the first two parameters. That is not possible w=
ithout using parameter names. You call the third overload, passing only the=
 first and third parameters. That too is not possible without using paramet=
er names.</div><div><br></div><div>For your proposal, parameter names are n=
ot optional. That&#39;s different from saying that they are mandatory. Ther=
e are cases in your design where you can call a named parameter function ov=
erload without providing names for those parameters.</div><div><br></div><d=
iv>The key here is that in your proposal, parameter names are <i>part of th=
e overload set&#39;s interface</i>. Just like the various conversion operat=
ors and constructors on the types used as parameters.</div><div><br></div><=
div>That&#39;s what makes them different from default parameters: the fact =
that `func(1, 3)` is not ambiguous. With default parameters, users who don&=
#39;t specify all of the parameters can create ambiguous call relative to o=
ther overloads in the set. With your design, that doesn&#39;t happen. This =
is what makes the parameter name <i>more</i> than just a default argument; =
it makes it part of the overload set&#39;s interface.<br></div><div><br></d=
iv></div></blockquote><div>=C2=A0</div><div>Boy, I made a mistake,<font fac=
e=3D"courier new,monospace"> f</font><span style=3D"display: inline !import=
ant; float: none; background-color: transparent; color: rgb(34, 34, 34); fo=
nt-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 1=
3px; font-style: normal; font-variant: normal; font-weight: 400; letter-spa=
cing: normal; orphans: 2; text-align: left; text-decoration: none; text-ind=
ent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space=
: normal; word-spacing: 0px;"><font face=3D"courier new,monospace">unc(1, 3=
) </font>is <i>of course=C2=A0</i><span style=3D"display: inline !important=
; float: none; background-color: transparent; color: rgb(34, 34, 34); font-=
family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px=
; font-style: normal; font-variant: normal; font-weight: 400; letter-spacin=
g: normal; orphans: 2; text-align: left; text-decoration: none; text-indent=
: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: n=
ormal; word-spacing: 0px;">ambiguous!=C2=A0</span></span></div><div><span s=
tyle=3D"display: inline !important; float: none; background-color: transpar=
ent; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica=
&quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: norma=
l; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; =
text-decoration: none; text-indent: 0px; text-transform: none; -webkit-text=
-stroke-width: 0px; white-space: normal; word-spacing: 0px;"><span style=3D=
"display: inline !important; float: none; background-color: transparent; co=
lor: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,=
sans-serif; font-size: 13px; font-style: normal; font-variant: normal; font=
-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-de=
coration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke=
-width: 0px; white-space: normal; word-spacing: 0px;"><br></span></span></d=
iv><div><span style=3D"display: inline !important; float: none; background-=
color: transparent; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,=
&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: normal; font=
-variant: normal; font-weight: 400; letter-spacing: normal; orphans: 2; tex=
t-align: left; text-decoration: none; text-indent: 0px; text-transform: non=
e; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"=
><span style=3D"display: inline !important; float: none; background-color: =
transparent; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;H=
elvetica&quot;,sans-serif; font-size: 13px; font-style: normal; font-varian=
t: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align=
: left; text-decoration: none; text-indent: 0px; text-transform: none; -web=
kit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">Bad ex=
ample, </span></span><span style=3D"display: inline !important; float: none=
; background-color: transparent; color: rgb(34, 34, 34); font-family: &quot=
;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style:=
 normal; font-variant: normal; font-weight: 400; letter-spacing: normal; or=
phans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-t=
ransform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-s=
pacing: 0px;"><span style=3D"display: inline !important; float: none; backg=
round-color: transparent; color: rgb(34, 34, 34); font-family: &quot;Arial&=
quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: normal=
; font-variant: normal; font-weight: 400; letter-spacing: normal; orphans: =
2; text-align: left; text-decoration: none; text-indent: 0px; text-transfor=
m: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing:=
 0px;">here is the correct one</span></span></div><div><span style=3D"displ=
ay: inline !important; float: none; background-color: transparent; color: r=
gb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-s=
erif; font-size: 13px; font-style: normal; font-variant: normal; font-weigh=
t: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decorati=
on: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width=
: 0px; white-space: normal; word-spacing: 0px;"><span style=3D"display: inl=
ine !important; float: none; background-color: transparent; color: rgb(34, =
34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; f=
ont-size: 13px; font-style: normal; font-variant: normal; font-weight: 400;=
 letter-spacing: normal; orphans: 2; text-align: left; text-decoration: non=
e; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; =
white-space: normal; word-spacing: 0px;"><br></span></span></div><div><span=
 style=3D"text-align: left; color: rgb(34, 34, 34); text-transform: none; t=
ext-indent: 0px; letter-spacing: normal; font-family: &quot;Arial&quot;,&qu=
ot;Helvetica&quot;,sans-serif; font-size: 13px; font-variant: normal; word-=
spacing: 0px; display: inline !important; white-space: normal; orphans: 2; =
float: none; -webkit-text-stroke-width: 0px; background-color: transparent;=
"><span style=3D"text-align: left; color: rgb(34, 34, 34); text-transform: =
none; text-indent: 0px; letter-spacing: normal; font-family: &quot;Arial&qu=
ot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-variant: normal=
; word-spacing: 0px; display: inline !important; white-space: normal; orpha=
ns: 2; float: none; -webkit-text-stroke-width: 0px; background-color: trans=
parent;"><span style=3D"background-color: transparent; border-bottom-color:=
 rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; bord=
er-image-outset: 0; border-image-repeat: stretch; border-image-slice: 100%;=
 border-image-source: none; border-image-width: 1; border-left-color: rgb(3=
4, 34, 34); border-left-style: none; border-left-width: 0px; border-right-c=
olor: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; b=
order-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width:=
 0px; color: rgb(34, 34, 34); display: inline; float: none; font-family: &a=
mp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size=
: 13px; font-style: normal; font-variant: normal; font-weight: 400; letter-=
spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; m=
argin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding=
-right: 0px; padding-top: 0px; text-align: left; text-decoration: none; tex=
t-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-=
space: normal; word-spacing: 0px;"><font face=3D"courier new,monospace" sty=
le=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; bord=
er-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stretch;=
 border-image-slice: 100%; border-image-source: none; border-image-width: 1=
; border-left-color: rgb(34, 34, 34); border-left-style: none; border-left-=
width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: none; =
border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-styl=
e: none; border-top-width: 0px; margin-bottom: 0px; margin-left: 0px; margi=
n-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padd=
ing-right: 0px; padding-top: 0px;">void func(int a, <span style=3D"backgrou=
nd-color: transparent; border-bottom-color: rgb(34, 34, 34); border-bottom-=
style: none; border-bottom-width: 0px; border-image-outset: 0; border-image=
-repeat: stretch; border-image-slice: 100%; border-image-source: none; bord=
er-image-width: 1; border-left-color: rgb(34, 34, 34); border-left-style: n=
one; border-left-width: 0px; border-right-color: rgb(34, 34, 34); border-ri=
ght-style: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34)=
; border-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34); di=
splay: inline; float: none; font-family: courier new,monospace; font-size: =
13px; font-style: normal; font-variant: normal; font-weight: 400; letter-sp=
acing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; mar=
gin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-r=
ight: 0px; padding-top: 0px; text-align: left; text-decoration: none; text-=
indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-sp=
ace: normal; word-spacing: 0px;">string b</span>);</font></span><b style=3D=
"background-attachment: scroll; background-clip: border-box; background-col=
or: transparent; background-image: none; background-origin: padding-box; ba=
ckground-position-x: 0%; background-position-y: 0%; background-repeat: repe=
at; background-size: auto; border-bottom-color: rgb(34, 34, 34); border-bot=
tom-style: none; border-bottom-width: 0px; border-image-outset: 0; border-i=
mage-repeat: stretch; border-image-slice: 100%; border-image-source: none; =
border-image-width: 1; border-left-color: rgb(34, 34, 34); border-left-styl=
e: none; border-left-width: 0px; border-right-color: rgb(34, 34, 34); borde=
r-right-style: none; border-right-width: 0px; border-top-color: rgb(34, 34,=
 34); border-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34)=
; font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans=
-serif; font-size: 13px; font-style: normal; font-variant: normal; font-wei=
ght: 700; height: auto; letter-spacing: normal; margin-bottom: 0px; margin-=
left: 0px; margin-right: 0px; margin-top: 0px; min-width: 0px; orphans: 2; =
overflow: visible; overflow-x: visible; overflow-y: visible; padding-bottom=
: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align:=
 left; text-decoration: none; text-indent: 0px; text-transform: none; -webk=
it-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"></b><i =
style=3D"background-attachment: scroll; background-clip: border-box; backgr=
ound-color: transparent; background-image: none; background-origin: padding=
-box; background-position-x: 0%; background-position-y: 0%; background-repe=
at: repeat; background-size: auto; border-bottom-color: rgb(34, 34, 34); bo=
rder-bottom-style: none; border-bottom-width: 0px; border-image-outset: 0; =
border-image-repeat: stretch; border-image-slice: 100%; border-image-source=
: none; border-image-width: 1; border-left-color: rgb(34, 34, 34); border-l=
eft-style: none; border-left-width: 0px; border-right-color: rgb(34, 34, 34=
); border-right-style: none; border-right-width: 0px; border-top-color: rgb=
(34, 34, 34); border-top-style: none; border-top-width: 0px; color: rgb(34,=
 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;qu=
ot;,sans-serif; font-size: 13px; font-style: italic; font-variant: normal; =
font-weight: 400; height: auto; letter-spacing: normal; margin-bottom: 0px;=
 margin-left: 0px; margin-right: 0px; margin-top: 0px; min-width: 0px; orph=
ans: 2; overflow: visible; overflow-x: visible; overflow-y: visible; paddin=
g-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; tex=
t-align: left; text-decoration: none; text-indent: 0px; text-transform: non=
e; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"=
></i><u style=3D"background-attachment: scroll; background-clip: border-box=
; background-color: transparent; background-image: none; background-origin:=
 padding-box; background-position-x: 0%; background-position-y: 0%; backgro=
und-repeat: repeat; background-size: auto; border-bottom-color: rgb(34, 34,=
 34); border-bottom-style: none; border-bottom-width: 0px; border-image-out=
set: 0; border-image-repeat: stretch; border-image-slice: 100%; border-imag=
e-source: none; border-image-width: 1; border-left-color: rgb(34, 34, 34); =
border-left-style: none; border-left-width: 0px; border-right-color: rgb(34=
, 34, 34); border-right-style: none; border-right-width: 0px; border-top-co=
lor: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; color:=
 rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetic=
a&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: =
normal; font-weight: 400; height: auto; letter-spacing: normal; margin-bott=
om: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; min-width: 0=
px; orphans: 2; overflow: visible; overflow-x: visible; overflow-y: visible=
; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: =
0px; text-align: left; text-decoration: underline; text-indent: 0px; text-t=
ransform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-s=
pacing: 0px;"></u><sub style=3D"background-color: transparent; border-botto=
m-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0=
px; border-image-outset: 0; border-image-repeat: stretch; border-image-slic=
e: 100%; border-image-source: none; border-image-width: 1; border-left-colo=
r: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; border=
-right-color: rgb(34, 34, 34); border-right-style: none; border-right-width=
: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-to=
p-width: 0px; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot=
;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 9px; font-style: nor=
mal; font-variant: normal; font-weight: 400; letter-spacing: normal; margin=
-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans=
: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-to=
p: 0px; text-align: left; text-decoration: none; text-indent: 0px; text-tra=
nsform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spa=
cing: 0px;"></sub><sup style=3D"background-color: transparent; border-botto=
m-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0=
px; border-image-outset: 0; border-image-repeat: stretch; border-image-slic=
e: 100%; border-image-source: none; border-image-width: 1; border-left-colo=
r: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; border=
-right-color: rgb(34, 34, 34); border-right-style: none; border-right-width=
: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-to=
p-width: 0px; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot=
;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 9px; font-style: nor=
mal; font-variant: normal; font-weight: 400; letter-spacing: normal; margin=
-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans=
: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-to=
p: 0px; text-align: left; text-decoration: none; text-indent: 0px; text-tra=
nsform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spa=
cing: 0px;"></sup><strike style=3D"background-color: transparent; border-bo=
ttom-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width=
: 0px; border-image-outset: 0; border-image-repeat: stretch; border-image-s=
lice: 100%; border-image-source: none; border-image-width: 1; border-left-c=
olor: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; bor=
der-right-color: rgb(34, 34, 34); border-right-style: none; border-right-wi=
dth: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border=
-top-width: 0px; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;q=
uot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style:=
 normal; font-variant: normal; font-weight: 400; letter-spacing: normal; ma=
rgin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orp=
hans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; paddin=
g-top: 0px; text-align: left; text-decoration: line-through; text-indent: 0=
px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: norm=
al; word-spacing: 0px;"></strike><b></b><i></i><u></u><sub></sub><sup></sup=
><strike></strike><br></span></span></div><div><span style=3D"text-align: l=
eft; color: rgb(34, 34, 34); text-transform: none; text-indent: 0px; letter=
-spacing: normal; font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans=
-serif; font-size: 13px; font-variant: normal; word-spacing: 0px; display: =
inline !important; white-space: normal; orphans: 2; float: none; -webkit-te=
xt-stroke-width: 0px; background-color: transparent;"><span style=3D"text-a=
lign: left; color: rgb(34, 34, 34); text-transform: none; text-indent: 0px;=
 letter-spacing: normal; font-family: &quot;Arial&quot;,&quot;Helvetica&quo=
t;,sans-serif; font-size: 13px; font-variant: normal; word-spacing: 0px; di=
splay: inline !important; white-space: normal; orphans: 2; float: none; -we=
bkit-text-stroke-width: 0px; background-color: transparent;"><div style=3D"=
background-color: transparent; border-bottom-color: rgb(34, 34, 34); border=
-bottom-style: none; border-bottom-width: 0px; border-image-outset: 0; bord=
er-image-repeat: stretch; border-image-slice: 100%; border-image-source: no=
ne; border-image-width: 1; border-left-color: rgb(34, 34, 34); border-left-=
style: none; border-left-width: 0px; border-right-color: rgb(34, 34, 34); b=
order-right-style: none; border-right-width: 0px; border-top-color: rgb(34,=
 34, 34); border-top-style: none; border-top-width: 0px; color: rgb(34, 34,=
 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,=
sans-serif; font-size: 13px; font-style: normal; font-variant: normal; font=
-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px;=
 margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; paddi=
ng-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; text-=
decoration: none; text-indent: 0px; text-transform: none; -webkit-text-stro=
ke-width: 0px; white-space: normal; word-spacing: 0px;"><span style=3D"back=
ground-color: transparent; border-bottom-color: rgb(34, 34, 34); border-bot=
tom-style: none; border-bottom-width: 0px; border-image-outset: 0; border-i=
mage-repeat: stretch; border-image-slice: 100%; border-image-source: none; =
border-image-width: 1; border-left-color: rgb(34, 34, 34); border-left-styl=
e: none; border-left-width: 0px; border-right-color: rgb(34, 34, 34); borde=
r-right-style: none; border-right-width: 0px; border-top-color: rgb(34, 34,=
 34); border-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34)=
; display: inline; float: none; font-size: 13px; font-style: normal; font-v=
ariant: normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0p=
x; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0p=
x; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: lef=
t; text-decoration: none; text-indent: 0px; text-transform: none; white-spa=
ce: normal; word-spacing: 0px;"><font face=3D"courier new,monospace" style=
=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border=
-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stretch; b=
order-image-slice: 100%; border-image-source: none; border-image-width: 1; =
border-left-color: rgb(34, 34, 34); border-left-style: none; border-left-wi=
dth: 0px; border-right-color: rgb(34, 34, 34); border-right-style: none; bo=
rder-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style:=
 none; border-top-width: 0px; margin-bottom: 0px; margin-left: 0px; margin-=
right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; paddin=
g-right: 0px; padding-top: 0px;">void func(int a, int b: b=3D1, <span style=
=3D"display: inline !important; float: none; background-color: transparent;=
 color: rgb(34, 34, 34); font-family: courier new,monospace; font-size: 13p=
x; font-style: normal; font-variant: normal; font-weight: 400; letter-spaci=
ng: normal; orphans: 2; text-align: left; text-decoration: none; text-inden=
t: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: =
normal; word-spacing: 0px;">string c: c=3D&quot;hi&quot;</span>);</font></s=
pan><b style=3D"background-attachment: scroll; background-clip: border-box;=
 background-color: transparent; background-image: none; background-origin: =
padding-box; background-position-x: 0%; background-position-y: 0%; backgrou=
nd-repeat: repeat; background-size: auto; border-bottom-color: rgb(34, 34, =
34); border-bottom-style: none; border-bottom-width: 0px; border-image-outs=
et: 0; border-image-repeat: stretch; border-image-slice: 100%; border-image=
-source: none; border-image-width: 1; border-left-color: rgb(34, 34, 34); b=
order-left-style: none; border-left-width: 0px; border-right-color: rgb(34,=
 34, 34); border-right-style: none; border-right-width: 0px; border-top-col=
or: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; color: =
rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica=
&amp;quot;,sans-serif; font-size: 13px; height: auto; margin-bottom: 0px; m=
argin-left: 0px; margin-right: 0px; margin-top: 0px; min-width: 0px; overfl=
ow: visible; overflow-x: visible; overflow-y: visible; padding-bottom: 0px;=
 padding-left: 0px; padding-right: 0px; padding-top: 0px;"></b><i style=3D"=
background-attachment: scroll; background-clip: border-box; background-colo=
r: transparent; background-image: none; background-origin: padding-box; bac=
kground-position-x: 0%; background-position-y: 0%; background-repeat: repea=
t; background-size: auto; border-bottom-color: rgb(34, 34, 34); border-bott=
om-style: none; border-bottom-width: 0px; border-image-outset: 0; border-im=
age-repeat: stretch; border-image-slice: 100%; border-image-source: none; b=
order-image-width: 1; border-left-color: rgb(34, 34, 34); border-left-style=
: none; border-left-width: 0px; border-right-color: rgb(34, 34, 34); border=
-right-style: none; border-right-width: 0px; border-top-color: rgb(34, 34, =
34); border-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34);=
 font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-=
serif; font-size: 13px; height: auto; margin-bottom: 0px; margin-left: 0px;=
 margin-right: 0px; margin-top: 0px; min-width: 0px; overflow: visible; ove=
rflow-x: visible; overflow-y: visible; padding-bottom: 0px; padding-left: 0=
px; padding-right: 0px; padding-top: 0px;"></i><u style=3D"background-attac=
hment: scroll; background-clip: border-box; background-color: transparent; =
background-image: none; background-origin: padding-box; background-position=
-x: 0%; background-position-y: 0%; background-repeat: repeat; background-si=
ze: auto; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; =
border-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stre=
tch; border-image-slice: 100%; border-image-source: none; border-image-widt=
h: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; border-l=
eft-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: no=
ne; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-=
style: none; border-top-width: 0px; color: rgb(34, 34, 34); font-family: &a=
mp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size=
: 13px; height: auto; margin-bottom: 0px; margin-left: 0px; margin-right: 0=
px; margin-top: 0px; min-width: 0px; overflow: visible; overflow-x: visible=
; overflow-y: visible; padding-bottom: 0px; padding-left: 0px; padding-righ=
t: 0px; padding-top: 0px;"></u><sub style=3D"border-bottom-color: rgb(34, 3=
4, 34); border-bottom-style: none; border-bottom-width: 0px; border-image-o=
utset: 0; border-image-repeat: stretch; border-image-slice: 100%; border-im=
age-source: none; border-image-width: 1; border-left-color: rgb(34, 34, 34)=
; border-left-style: none; border-left-width: 0px; border-right-color: rgb(=
34, 34, 34); border-right-style: none; border-right-width: 0px; border-top-=
color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; marg=
in-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; paddi=
ng-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;"><=
/sub><sup style=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-styl=
e: none; border-bottom-width: 0px; border-image-outset: 0; border-image-rep=
eat: stretch; border-image-slice: 100%; border-image-source: none; border-i=
mage-width: 1; border-left-color: rgb(34, 34, 34); border-left-style: none;=
 border-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-=
style: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); bo=
rder-top-style: none; border-top-width: 0px; margin-bottom: 0px; margin-lef=
t: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-le=
ft: 0px; padding-right: 0px; padding-top: 0px;"></sup><strike style=3D"bord=
er-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-=
width: 0px; border-image-outset: 0; border-image-repeat: stretch; border-im=
age-slice: 100%; border-image-source: none; border-image-width: 1; border-l=
eft-color: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px=
; border-right-color: rgb(34, 34, 34); border-right-style: none; border-rig=
ht-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; b=
order-top-width: 0px; margin-bottom: 0px; margin-left: 0px; margin-right: 0=
px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right:=
 0px; padding-top: 0px;"></strike><br style=3D"background-attachment: scrol=
l; background-clip: border-box; background-color: transparent; background-i=
mage: none; background-origin: padding-box; background-position-x: 0%; back=
ground-position-y: 0%; background-repeat: repeat; background-size: auto; bo=
rder-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-botto=
m-width: 0px; border-image-outset: 0; border-image-repeat: stretch; border-=
image-slice: 100%; border-image-source: none; border-image-width: 1; border=
-left-color: rgb(34, 34, 34); border-left-style: none; border-left-width: 0=
px; border-right-color: rgb(34, 34, 34); border-right-style: none; border-r=
ight-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none;=
 border-top-width: 0px; color: rgb(34, 34, 34); font-family: &amp;quot;Aria=
l&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; heig=
ht: auto; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-t=
op: 0px; min-width: 0px; overflow: visible; overflow-x: visible; overflow-y=
: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padd=
ing-top: 0px;"></div><div style=3D"background-color: transparent; border-bo=
ttom-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width=
: 0px; border-image-outset: 0; border-image-repeat: stretch; border-image-s=
lice: 100%; border-image-source: none; border-image-width: 1; border-left-c=
olor: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; bor=
der-right-color: rgb(34, 34, 34); border-right-style: none; border-right-wi=
dth: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border=
-top-width: 0px; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;q=
uot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style:=
 normal; font-variant: normal; font-weight: 400; letter-spacing: normal; ma=
rgin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orp=
hans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; paddin=
g-top: 0px; text-align: left; text-decoration: none; text-indent: 0px; text=
-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; word=
-spacing: 0px;"><font face=3D"courier new,monospace" style=3D"border-bottom=
-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0p=
x; border-image-outset: 0; border-image-repeat: stretch; border-image-slice=
: 100%; border-image-source: none; border-image-width: 1; border-left-color=
: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; border-=
right-color: rgb(34, 34, 34); border-right-style: none; border-right-width:=
 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-top=
-width: 0px; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margi=
n-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; pad=
ding-top: 0px;">void func(int a, int b: b=3D1, int c: c=3D2);</font></div><=
div><br></div><div><span style=3D"background-color: transparent; border-bot=
tom-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width:=
 0px; border-image-outset: 0; border-image-repeat: stretch; border-image-sl=
ice: 100%; border-image-source: none; border-image-width: 1; border-left-co=
lor: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; bord=
er-right-color: rgb(34, 34, 34); border-right-style: none; border-right-wid=
th: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-=
top-width: 0px; color: rgb(34, 34, 34); display: inline; float: none; font-=
family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif;=
 font-size: 13px; font-style: normal; font-variant: normal; font-weight: 40=
0; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-rig=
ht: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0p=
x; padding-right: 0px; padding-top: 0px; text-align: left; text-decoration:=
 none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0=
px; white-space: normal; word-spacing: 0px;"><font face=3D"courier new,mono=
space" style=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-style: =
none; border-bottom-width: 0px; border-image-outset: 0; border-image-repeat=
: stretch; border-image-slice: 100%; border-image-source: none; border-imag=
e-width: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; bo=
rder-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-sty=
le: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); borde=
r-top-style: none; border-top-width: 0px; margin-bottom: 0px; margin-left: =
0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left:=
 0px; padding-right: 0px; padding-top: 0px;">func(1, &quot;bye&quot;);<span=
 style=3D"background-color: transparent; border-bottom-color: rgb(34, 34, 3=
4); border-bottom-style: none; border-bottom-width: 0px; border-image-outse=
t: 0; border-image-repeat: stretch; border-image-slice: 100%; border-image-=
source: none; border-image-width: 1; border-left-color: rgb(34, 34, 34); bo=
rder-left-style: none; border-left-width: 0px; border-right-color: rgb(34, =
34, 34); border-right-style: none; border-right-width: 0px; border-top-colo=
r: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; color: r=
gb(34, 34, 34); display: inline; float: none; font-family: courier new,mono=
space; font-size: 13px; font-style: normal; font-variant: normal; font-weig=
ht: 400; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px; marg=
in-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; pad=
ding-right: 0px; padding-top: 0px; text-align: left; text-decoration: none;=
 text-indent: 0px; text-transform: none; white-space: normal; word-spacing:=
 0px;"> //&lt; overload 1</span></font></span><b></b><i></i><u></u><sub></s=
ub><sup></sup><strike></strike><br></div><div><div style=3D"background-colo=
r: transparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: =
none; border-bottom-width: 0px; border-image-outset: 0; border-image-repeat=
: stretch; border-image-slice: 100%; border-image-source: none; border-imag=
e-width: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; bo=
rder-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-sty=
le: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); borde=
r-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34); font-fami=
ly: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; fon=
t-size: 13px; font-style: normal; font-variant: normal; font-weight: 400; l=
etter-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: =
0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; p=
adding-right: 0px; padding-top: 0px; text-align: left; text-decoration: non=
e; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; =
white-space: normal; word-spacing: 0px;"><span style=3D"background-color: t=
ransparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none=
; border-bottom-width: 0px; border-image-outset: 0; border-image-repeat: st=
retch; border-image-slice: 100%; border-image-source: none; border-image-wi=
dth: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; border=
-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: =
none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-to=
p-style: none; border-top-width: 0px; color: rgb(34, 34, 34); display: inli=
ne; float: none; font-size: 13px; font-style: normal; font-variant: normal;=
 font-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-left:=
 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left=
: 0px; padding-right: 0px; padding-top: 0px; text-align: left; text-decorat=
ion: none; text-indent: 0px; text-transform: none; white-space: normal; wor=
d-spacing: 0px;"><font face=3D"courier new,monospace" style=3D"border-botto=
m-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0=
px; border-image-outset: 0; border-image-repeat: stretch; border-image-slic=
e: 100%; border-image-source: none; border-image-width: 1; border-left-colo=
r: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; border=
-right-color: rgb(34, 34, 34); border-right-style: none; border-right-width=
: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-to=
p-width: 0px; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; marg=
in-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; pa=
dding-top: 0px;">func(1, c: &quot;bye&quot;);<span style=3D"background-colo=
r: transparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: =
none; border-bottom-width: 0px; border-image-outset: 0; border-image-repeat=
: stretch; border-image-slice: 100%; border-image-source: none; border-imag=
e-width: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; bo=
rder-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-sty=
le: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); borde=
r-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34); display: =
inline; float: none; font-family: courier new,monospace; font-size: 13px; f=
ont-style: normal; font-variant: normal; font-weight: 400; letter-spacing: =
normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top=
: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-=
top: 0px; text-align: left; text-decoration: none; text-indent: 0px; text-t=
ransform: none; white-space: normal; word-spacing: 0px;"> //&lt; overload 2=
</span></font></span><br style=3D"background-attachment: scroll; background=
-clip: border-box; background-color: transparent; background-image: none; b=
ackground-origin: padding-box; background-position-x: 0%; background-positi=
on-y: 0%; background-repeat: repeat; background-size: auto; border-bottom-c=
olor: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px;=
 border-image-outset: 0; border-image-repeat: stretch; border-image-slice: =
100%; border-image-source: none; border-image-width: 1; border-left-color: =
rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; border-ri=
ght-color: rgb(34, 34, 34); border-right-style: none; border-right-width: 0=
px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-top-w=
idth: 0px; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&=
amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; height: auto; mar=
gin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; min-=
width: 0px; overflow: visible; overflow-x: visible; overflow-y: visible; pa=
dding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;=
"></div><div style=3D"background-color: transparent; border-bottom-color: r=
gb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border=
-image-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; b=
order-image-source: none; border-image-width: 1; border-left-color: rgb(34,=
 34, 34); border-left-style: none; border-left-width: 0px; border-right-col=
or: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; bor=
der-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0=
px; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quo=
t;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font=
-variant: normal; font-weight: 400; letter-spacing: normal; margin-bottom: =
0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padd=
ing-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; t=
ext-align: left; text-decoration: none; text-indent: 0px; text-transform: n=
one; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px=
;"><span style=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-style=
: none; border-bottom-width: 0px; border-image-outset: 0; border-image-repe=
at: stretch; border-image-slice: 100%; border-image-source: none; border-im=
age-width: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; =
border-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-s=
tyle: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); bor=
der-top-style: none; border-top-width: 0px; margin-bottom: 0px; margin-left=
: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-lef=
t: 0px; padding-right: 0px; padding-top: 0px;"><font face=3D"courier new,mo=
nospace" style=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-style=
: none; border-bottom-width: 0px; border-image-outset: 0; border-image-repe=
at: stretch; border-image-slice: 100%; border-image-source: none; border-im=
age-width: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; =
border-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-s=
tyle: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); bor=
der-top-style: none; border-top-width: 0px; margin-bottom: 0px; margin-left=
: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-lef=
t: 0px; padding-right: 0px; padding-top: 0px;">func(1, c: 3);<span style=3D=
"background-color: transparent; border-bottom-color: rgb(34, 34, 34); borde=
r-bottom-style: none; border-bottom-width: 0px; border-image-outset: 0; bor=
der-image-repeat: stretch; border-image-slice: 100%; border-image-source: n=
one; border-image-width: 1; border-left-color: rgb(34, 34, 34); border-left=
-style: none; border-left-width: 0px; border-right-color: rgb(34, 34, 34); =
border-right-style: none; border-right-width: 0px; border-top-color: rgb(34=
, 34, 34); border-top-style: none; border-top-width: 0px; color: rgb(34, 34=
, 34); display: inline; float: none; font-family: courier new,monospace; fo=
nt-size: 13px; font-style: normal; font-variant: normal; font-weight: 400; =
letter-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right:=
 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-righ=
t: 0px; padding-top: 0px; text-align: left; text-decoration: none; text-ind=
ent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"> /=
/&lt; overload 3</span></font></span><span style=3D"border-bottom-color: rg=
b(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-=
image-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; bo=
rder-image-source: none; border-image-width: 1; border-left-color: rgb(34, =
34, 34); border-left-style: none; border-left-width: 0px; border-right-colo=
r: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; bord=
er-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0p=
x; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px=
; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: =
0px;"><font face=3D"courier new,monospace" style=3D"border-bottom-color: rg=
b(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-=
image-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; bo=
rder-image-source: none; border-image-width: 1; border-left-color: rgb(34, =
34, 34); border-left-style: none; border-left-width: 0px; border-right-colo=
r: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; bord=
er-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0p=
x; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px=
; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: =
0px;"><span style=3D"margin: 0px; padding: 0px; border: 0px rgb(34, 34, 34)=
; border-image: none; text-align: left; color: rgb(34, 34, 34); text-transf=
orm: none; text-indent: 0px; letter-spacing: normal; font-family: courier n=
ew,monospace; font-size: 13px; font-variant: normal; word-spacing: 0px; dis=
play: inline; white-space: normal; float: none; background-color: transpare=
nt;"><br></span></font></span></div><b></b><i></i><u></u><sub></sub><sup></=
sup><strike></strike><b></b><i></i><u></u><sub></sub><sup></sup><strike></s=
trike><br></div></span></span></div><div>The point was, on the call site (o=
ptional) names <i>can</i> affect overloading.=C2=A0</div><div><br></div><di=
v>The more general argument was, optional names can service mega-functions,=
 as long as they allow skipping defaulted arguments.=C2=A0</div><div><br></=
div><div>But even mega-functions aside, <i>none of the current alternatives=
 to the above code are better</i>, even if possible - that&#39;s is way peo=
ple want that feature!<br></div><div><br></div><div>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div></div><div>Changing the signature is a c=
lear boundary in both semantics and implementation.<br></div></div></blockq=
uote><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv></div><div></div><div>But in the realm of non-changing-the-signature nam=
es, a lot can be done, granted the calls <i>will</i> differ w/ and w/o name=
s.</div></div></blockquote><div><br></div><div>I think you&#39;re too focus=
ed on signature as the notion of a function&#39;s identity. There are aspec=
ts of functions which are not their signature yet directly relate to its id=
entity.</div><div><br></div><div>Return values. If you declare two function=
s with the same name and signatures with different return values, then you =
get a compile error. `noexcept` works that way too; you can&#39;t be incons=
istent about that. Both of these are part of the function&#39;s type, but n=
ot its signature (though `noexcept` can be cast away).</div><div><br></div>=
<div>Contracts affect neither type nor signature, but even that requires so=
me basic consistency. You can declare contracts on a function or not. But a=
ll contract declarations for the same function must be consistent.</div><di=
v><br></div><div>If a parameter name can be used as a syntactic modifier wh=
en calling the function (for the purposes of this discussion, anything whic=
h affects actual code generation. This includes reordering of arguments), t=
hen that name ought to be, if not part of the function&#39;s type, then at =
least have as much consistency as its contracts. That is, if you want to be=
 able to reorder parameters, then the function should consistently assign e=
ach parameter a single name or a single &quot;unnamed&quot;.</div></div></b=
lockquote><div><br></div><div><br></div><div>In the original post about wea=
k arguments, I suggested they obey the rules of default arguments - you nam=
e your arguments only in the first declaration. No names afterwards, not ev=
en the same.=C2=A0</div><div><br></div><div><div><span style=3D"background-=
color:transparent;border-bottom-color:rgb(34,34,34);border-bottom-style:non=
e;border-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-style=
:none;border-left-width:0px;border-right-color:rgb(34,34,34);border-right-s=
tyle:none;border-right-width:0px;border-top-color:rgb(34,34,34);border-top-=
style:none;border-top-width:0px;color:rgb(34,34,34);display:inline;float:no=
ne;font-size:13px;font-style:normal;font-variant:normal;font-weight:400;let=
ter-spacing:normal;margin-bottom:0px;margin-left:0px;margin-right:0px;margi=
n-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top=
:0px;text-align:left;text-decoration:none;text-indent:0px;text-transform:no=
ne;white-space:normal;word-spacing:0px"><font face=3D"courier new,monospace=
" style=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:none;borde=
r-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-style:none;b=
order-left-width:0px;border-right-color:rgb(34,34,34);border-right-style:no=
ne;border-right-width:0px;border-top-color:rgb(34,34,34);border-top-style:n=
one;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px=
;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;paddi=
ng-top:0px">auto child(name mother: mom, name dad);=C2=A0</font></span></di=
v><div><span style=3D"background-color:transparent;border-bottom-color:rgb(=
34,34,34);border-bottom-style:none;border-bottom-width:0px;border-left-colo=
r:rgb(34,34,34);border-left-style:none;border-left-width:0px;border-right-c=
olor:rgb(34,34,34);border-right-style:none;border-right-width:0px;border-to=
p-color:rgb(34,34,34);border-top-style:none;border-top-width:0px;color:rgb(=
34,34,34);display:inline;float:none;font-size:13px;font-style:normal;font-v=
ariant:normal;font-weight:400;letter-spacing:normal;margin-bottom:0px;margi=
n-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:=
0px;padding-right:0px;padding-top:0px;text-align:left;text-decoration:none;=
text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><f=
ont face=3D"courier new,monospace" style=3D"border-bottom-color:rgb(34,34,3=
4);border-bottom-style:none;border-bottom-width:0px;border-left-color:rgb(3=
4,34,34);border-left-style:none;border-left-width:0px;border-right-color:rg=
b(34,34,34);border-right-style:none;border-right-width:0px;border-top-color=
:rgb(34,34,34);border-top-style:none;border-top-width:0px;margin-bottom:0px=
;margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding=
-left:0px;padding-right:0px;padding-top:0px"><br></font></span></div><div><=
font face=3D"courier new,monospace">// <span style=3D"border-bottom-color:r=
gb(34,34,34);border-bottom-style:none;border-bottom-width:0px;border-left-c=
olor:rgb(34,34,34);border-left-style:none;border-left-width:0px;border-righ=
t-color:rgb(34,34,34);border-right-style:none;border-right-width:0px;border=
-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0px;margin-=
bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0=
px;padding-left:0px;padding-right:0px;padding-top:0px"><font style=3D"borde=
r-bottom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0=
px;border-left-color:rgb(34,34,34);border-left-style:none;border-left-width=
:0px;border-right-color:rgb(34,34,34);border-right-style:none;border-right-=
width:0px;border-top-color:rgb(34,34,34);border-top-style:none;border-top-w=
idth:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;=
padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px">auto=
 child(name mother: mom, name dad); <i>//&lt; error</i></font></span></font=
></div><div><span style=3D"background-color:transparent;border-bottom-color=
:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;border-left=
-color:rgb(34,34,34);border-left-style:none;border-left-width:0px;border-ri=
ght-color:rgb(34,34,34);border-right-style:none;border-right-width:0px;bord=
er-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0px;color=
:rgb(34,34,34);display:inline;float:none;font-size:13px;font-variant:normal=
;letter-spacing:normal;margin-bottom:0px;margin-left:0px;margin-right:0px;m=
argin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;padding=
-top:0px;text-align:left;text-indent:0px;text-transform:none;white-space:no=
rmal;word-spacing:0px"><font style=3D"border-bottom-color:rgb(34,34,34);bor=
der-bottom-style:none;border-bottom-width:0px;border-left-color:rgb(34,34,3=
4);border-left-style:none;border-left-width:0px;border-right-color:rgb(34,3=
4,34);border-right-style:none;border-right-width:0px;border-top-color:rgb(3=
4,34,34);border-top-style:none;border-top-width:0px;margin-bottom:0px;margi=
n-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:=
0px;padding-right:0px;padding-top:0px"><font face=3D"courier new,monospace"=
><span>// </span><span style=3D"border-bottom-color:rgb(34,34,34);border-bo=
ttom-style:none;border-bottom-width:0px;border-left-color:rgb(34,34,34);bor=
der-left-style:none;border-left-width:0px;border-right-color:rgb(34,34,34);=
border-right-style:none;border-right-width:0px;border-top-color:rgb(34,34,3=
4);border-top-style:none;border-top-width:0px;margin-bottom:0px;margin-left=
:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;pa=
dding-right:0px;padding-top:0px"><font style=3D"border-bottom-color:rgb(34,=
34,34);border-bottom-style:none;border-bottom-width:0px;border-left-color:r=
gb(34,34,34);border-left-style:none;border-left-width:0px;border-right-colo=
r:rgb(34,34,34);border-right-style:none;border-right-width:0px;border-top-c=
olor:rgb(34,34,34);border-top-style:none;border-top-width:0px;margin-bottom=
:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;pad=
ding-left:0px;padding-right:0px;padding-top:0px">auto child(name mom, name =
father: dad); <i>//&lt; error</i></font></span></font><b style=3D"border-bo=
ttom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;b=
order-left-color:rgb(34,34,34);border-left-style:none;border-left-width:0px=
;border-right-color:rgb(34,34,34);border-right-style:none;border-right-widt=
h:0px;border-top-color:rgb(34,34,34);border-top-style:none;border-top-width=
:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;padd=
ing-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px"></b><u s=
tyle=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:none;border-b=
ottom-width:0px;border-left-color:rgb(34,34,34);border-left-style:none;bord=
er-left-width:0px;border-right-color:rgb(34,34,34);border-right-style:none;=
border-right-width:0px;border-top-color:rgb(34,34,34);border-top-style:none=
;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;ma=
rgin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-=
top:0px"></u><sub style=3D"border-bottom-color:rgb(34,34,34);border-bottom-=
style:none;border-bottom-width:0px;border-left-color:rgb(34,34,34);border-l=
eft-style:none;border-left-width:0px;border-right-color:rgb(34,34,34);borde=
r-right-style:none;border-right-width:0px;border-top-color:rgb(34,34,34);bo=
rder-top-style:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;=
margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding=
-right:0px;padding-top:0px"></sub><sup style=3D"border-bottom-color:rgb(34,=
34,34);border-bottom-style:none;border-bottom-width:0px;border-left-color:r=
gb(34,34,34);border-left-style:none;border-left-width:0px;border-right-colo=
r:rgb(34,34,34);border-right-style:none;border-right-width:0px;border-top-c=
olor:rgb(34,34,34);border-top-style:none;border-top-width:0px;margin-bottom=
:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;pad=
ding-left:0px;padding-right:0px;padding-top:0px"></sup><strike style=3D"bor=
der-bottom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width=
:0px;border-left-color:rgb(34,34,34);border-left-style:none;border-left-wid=
th:0px;border-right-color:rgb(34,34,34);border-right-style:none;border-righ=
t-width:0px;border-top-color:rgb(34,34,34);border-top-style:none;border-top=
-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0p=
x;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px"></=
strike><br style=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:n=
one;border-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-sty=
le:none;border-left-width:0px;border-right-color:rgb(34,34,34);border-right=
-style:none;border-right-width:0px;border-top-color:rgb(34,34,34);border-to=
p-style:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin-=
right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:=
0px;padding-top:0px"></font></span></div><div><span style=3D"background-col=
or:transparent;border-bottom-color:rgb(34,34,34);border-bottom-style:none;b=
order-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-style:no=
ne;border-left-width:0px;border-right-color:rgb(34,34,34);border-right-styl=
e:none;border-right-width:0px;border-top-color:rgb(34,34,34);border-top-sty=
le:none;border-top-width:0px;color:rgb(34,34,34);display:inline;float:none;=
font-size:13px;font-style:normal;font-variant:normal;font-weight:400;letter=
-spacing:normal;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-t=
op:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0p=
x;text-align:left;text-decoration:none;text-indent:0px;text-transform:none;=
white-space:normal;word-spacing:0px"><font face=3D"courier new,monospace" s=
tyle=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:none;border-b=
ottom-width:0px;border-left-color:rgb(34,34,34);border-left-style:none;bord=
er-left-width:0px;border-right-color:rgb(34,34,34);border-right-style:none;=
border-right-width:0px;border-top-color:rgb(34,34,34);border-top-style:none=
;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;ma=
rgin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-=
top:0px">auto child(name mutter, vater); <i>//&lt; OK</i></font></span><b s=
tyle=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:none;border-b=
ottom-width:0px;border-left-color:rgb(34,34,34);border-left-style:none;bord=
er-left-width:0px;border-right-color:rgb(34,34,34);border-right-style:none;=
border-right-width:0px;border-top-color:rgb(34,34,34);border-top-style:none=
;border-top-width:0px;color:rgb(34,34,34);line-height:normal;margin-bottom:=
0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padd=
ing-left:0px;padding-right:0px;padding-top:0px"></b><u style=3D"border-bott=
om-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;bor=
der-left-color:rgb(34,34,34);border-left-style:none;border-left-width:0px;b=
order-right-color:rgb(34,34,34);border-right-style:none;border-right-width:=
0px;border-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0=
px;color:rgb(34,34,34);line-height:normal;margin-bottom:0px;margin-left:0px=
;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;paddin=
g-right:0px;padding-top:0px"></u><sub style=3D"border-bottom-color:rgb(34,3=
4,34);border-bottom-style:none;border-bottom-width:0px;border-left-color:rg=
b(34,34,34);border-left-style:none;border-left-width:0px;border-right-color=
:rgb(34,34,34);border-right-style:none;border-right-width:0px;border-top-co=
lor:rgb(34,34,34);border-top-style:none;border-top-width:0px;margin-bottom:=
0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padd=
ing-left:0px;padding-right:0px;padding-top:0px"></sub><sup style=3D"border-=
bottom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px=
;border-left-color:rgb(34,34,34);border-left-style:none;border-left-width:0=
px;border-right-color:rgb(34,34,34);border-right-style:none;border-right-wi=
dth:0px;border-top-color:rgb(34,34,34);border-top-style:none;border-top-wid=
th:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;pa=
dding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px"></sup>=
<strike style=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:none=
;border-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-style:=
none;border-left-width:0px;border-right-color:rgb(34,34,34);border-right-st=
yle:none;border-right-width:0px;border-top-color:rgb(34,34,34);border-top-s=
tyle:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin-rig=
ht:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px=
;padding-top:0px"></strike></div><div><span style=3D"margin:0px;padding:0px=
;border:0px rgb(34,34,34);text-align:left;color:rgb(34,34,34);text-transfor=
m:none;text-indent:0px;letter-spacing:normal;font-size:13px;font-style:norm=
al;font-variant:normal;font-weight:400;text-decoration:none;word-spacing:0p=
x;display:inline;white-space:normal;float:none;background-color:transparent=
"><font face=3D"courier new,monospace">auto child(name mother, name father)=
 <i>//&lt; OK</i></font></span></div><b></b><i></i><u></u><sub></sub><sup><=
/sup><strike></strike><font face=3D"courier new,monospace">{=C2=A0</font></=
div><div><font face=3D"courier new,monospace">=C2=A0 // implementation</fon=
t></div><div><font face=3D"courier new,monospace">}</font><br></div><div>=
=C2=A0</div><div>This seems the be the most consistent approach as (weak) n=
amed arguments ultimately inhabit <i>exactly</i> the same design space as d=
efault arguments - a compiler helper.</div></div></blockquote><div><br></di=
v><div>Default arguments generate code (conditionally or not). Weak named a=
rguments do not. I have some difficulty considering those to be &quot;exact=
ly the same design space&quot;. Or even similar design spaces.<br></div><di=
v><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><=
/div><div>With default arguments the compiler is only obligated to copy-pas=
te the default expression if we don&#39;t pass a value.</div><div><br></div=
><div>With names it is a matter of what features we want to have:</div><ul>=
<li>to only name-check</li><li>to paste in place of name-only</li><li>to pa=
ste on omission<br></li><li>to rearrange<br></li></ul><div><br></div><div><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>=
</div><div></div><div>If names can be inconsistent and still affect syntax,=
 bad things result.</div><div></div><div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div>Should it be done is a different matt=
er, this is a debate as heated as the one about signature - some people con=
sider names useless if they don&#39;t rearrange/skip defaults, some are hap=
py with just checking alone.=C2=A0 <br></div></div></blockquote></div></blo=
ckquote></div></blockquote></div></blockquote></div>

<p></p>

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

------=_Part_2211_2114072163.1535013282974--

------=_Part_2210_1097133904.1535013282972--

.

------=_Part_2718_906235636.1535013440445
Content-Type: multipart/alternative;
 boundary="----=_Part_2719_84395079.1535013440446"

------=_Part_2719_84395079.1535013440446
Content-Type: text/plain; charset="UTF-8"



On Wednesday, August 22, 2018 at 11:47:29 PM UTC+3, Nicol Bolas wrote:
>
> On Tuesday, August 21, 2018 at 4:04:26 AM UTC-4, mihailn...@gmail.com
> wrote:
>>
>> On Tuesday, August 21, 2018 at 4:52:56 AM UTC+3, Nicol Bolas wrote:
>>>
>>> On Monday, August 20, 2018 at 4:18:34 PM UTC-4, mihailn...@gmail.com
>>> wrote:
>>>>
>>>> On Monday, August 20, 2018 at 9:45:02 PM UTC+3, Nicol Bolas wrote:
>>>>>
>>>>> On Monday, August 20, 2018 at 12:20:20 PM UTC-4, mihailn...@gmail.com
>>>>> wrote:
>>>>>>
>>>>>> Are sure about that? Argument rearrangement is doable without
>>>>>> changing the signature (a.k.a. strong)
>>>>>>
>>>>>
>>>>> Maybe we have very different ideas about what "strong named
>>>>> parameters" means. The question of "changing the signature" is not the
>>>>> distinction between "strong" and "weak". At least, it's not the distinction
>>>>> that I'm talking about it.
>>>>>
>>>>> "Weak named parameters" to me refers to named parameters which are all
>>>>> of the following:
>>>>>
>>>>> 1. Optional. You can call a function that has named parameters without
>>>>> naming the parameter(s) at the call site.
>>>>> 2. Ordered. The order of the arguments must match the parameter order
>>>>> of the function, regardless of the names you specify at the call site.
>>>>> 3. Overload-neutral. The presence or absence of names at the call site
>>>>> has no effect on function overloading.
>>>>>
>>>>> Essentially, if your rules require that all named parameter function
>>>>> calls will invoke the same function with the same behavior if you stripped
>>>>> out all of the names, then the named parameter proposal is "weak".
>>>>>
>>>>> Any named parameter feature which imposes rules antithetical to at
>>>>> least one of the above is "strong". With the strongest being the antithesis
>>>>> to all of them.
>>>>>
>>>>
>>>> I see, for you weak refers to the notion the call is the same, but
>>>> unchecked, without them.
>>>>
>>>> For me strong is referring to "does it introduce a new signature", the
>>>> same way strong typedef introduces a new type. Everything else is weak as
>>>> it is about the compiler not the code.
>>>>
>>>
>>> That's not what you said earlier
>>> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/MbDT0vsA2j0/1VPQM7AsAAAJ>
>>> :
>>>
>>> Also, this obviously does not address the named arguments, *that are
>>>> optional, the "weak" ones*, so this solution will not make everyone
>>>> happy.
>>>>
>>>
>>> Emphasis added. And there's this post
>>> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/MbDT0vsA2j0/uWG77JxeDQAJ>
>>> :
>>>
>>> //weak argument names, not mandatory
>>>>
>>> ...
>>>>
>>> //strong argument name, adds an overload, not ignorable
>>>>
>>>
>>> Yes, that post is talking about how you would declare weak names
>>> differently from strong names, but it's also talking about how they get
>>> used at the call site: "not mandatory" vs. "not ignorable".
>>>
>>
>> There is no contradiction, they are optional, and ignorable by the user
>> (he might not use them).
>> Now, it depends on how much features they have, they might also be as
>> weak as you assume they are, so they are (can be) ignored by the compiler
>> as well and the call is the same.
>>
>> Most of the time here we talked about these weakest ones, and considered
>> "extra features" as "bonuses".
>>
>> For me personally strong were always the one changing the signature,
>> that's why the first post about tags-as-labels was called "Strong named
>> arguments as tag overloads"
>>
>> And weak for me were not rearranging or skipping, but having
>> defaulted-by-naming f(a:, b:, 10)
>>
>> Of course even these are not ignorable as the call will fail without
>> them. Probably using the word ignorable was not correct.
>>
>> In any case weak names are optional.
>> This is not to say, they do not affect overloading, they do, but only on
>> the call site.
>>
>> void func(int a, int b);
>> void func(int a, int b: b=1, int c: c=2);
>>
>> func(1, 3); //< overload 1
>> func(1, b: 3); //< overload 2
>> func(1, c: 3); //< overload 2
>>
>>
> If names are important enough to affect what overload gets called, then
> they ought to be part of a function's type. If they are truly "optional",
> then they should not be able to affect overloading.
>
> To me, "optional" means exactly that: optional. The choice of whether to
> use names or not is entirely the prerogative of the caller. A caller should
> be able to call the same function, providing the same parameters, without
> using parameter names if they so desire.
>
> You call the second overload, passing it the first two parameters. That is
> not possible without using parameter names. You call the third overload,
> passing only the first and third parameters. That too is not possible
> without using parameter names.
>
> For your proposal, parameter names are not optional. That's different from
> saying that they are mandatory. There are cases in your design where you
> can call a named parameter function overload without providing names for
> those parameters.
>
> The key here is that in your proposal, parameter names are *part of the
> overload set's interface*. Just like the various conversion operators and
> constructors on the types used as parameters.
>
> That's what makes them different from default parameters: the fact that
> `func(1, 3)` is not ambiguous. With default parameters, users who don't
> specify all of the parameters can create ambiguous call relative to other
> overloads in the set. With your design, that doesn't happen. This is what
> makes the parameter name *more* than just a default argument; it makes it
> part of the overload set's interface.
>


Boy, I made a mistake, func(1, 3) is of course ambiguous!

Bad example, here is the correct one:

void func(int a, string b);
void func(int a, int b: b=1, string c: c="hi");
void func(int a, int b: b=1, int c: c=2);

func(1, "bye"); //< overload 1
func(1, c: "bye"); //< overload 2
func(1, c: 3); //< overload 3

The point was, on the call site (optional) names *can* affect overloading.

The more general argument was, optional names can service mega-functions,
as long as they allow skipping defaulted arguments.
But even mega-functions aside, *none of the current alternatives to the
above code are better*, even if possible - that's is way people want that
feature!





>
> Changing the signature is a clear boundary in both semantics and
>>>> implementation.
>>>>
>>> But in the realm of non-changing-the-signature names, a lot can be done,
>>>> granted the calls *will* differ w/ and w/o names.
>>>>
>>>
>>> I think you're too focused on signature as the notion of a function's
>>> identity. There are aspects of functions which are not their signature yet
>>> directly relate to its identity.
>>>
>>> Return values. If you declare two functions with the same name and
>>> signatures with different return values, then you get a compile error.
>>> `noexcept` works that way too; you can't be inconsistent about that. Both
>>> of these are part of the function's type, but not its signature (though
>>> `noexcept` can be cast away).
>>>
>>> Contracts affect neither type nor signature, but even that requires some
>>> basic consistency. You can declare contracts on a function or not. But all
>>> contract declarations for the same function must be consistent.
>>>
>>> If a parameter name can be used as a syntactic modifier when calling the
>>> function (for the purposes of this discussion, anything which affects
>>> actual code generation. This includes reordering of arguments), then that
>>> name ought to be, if not part of the function's type, then at least have as
>>> much consistency as its contracts. That is, if you want to be able to
>>> reorder parameters, then the function should consistently assign each
>>> parameter a single name or a single "unnamed".
>>>
>>
>>
>> In the original post about weak arguments, I suggested they obey the
>> rules of default arguments - you name your arguments only in the first
>> declaration. No names afterwards, not even the same.
>>
>> auto child(name mother: mom, name dad);
>>
>> // auto child(name mother: mom, name dad); *//< error*
>> // auto child(name mom, name father: dad); *//< error*
>> auto child(name mutter, vater); *//< OK*
>> auto child(name mother, name father) *//< OK*
>> {
>>   // implementation
>> }
>>
>> This seems the be the most consistent approach as (weak) named arguments
>> ultimately inhabit *exactly* the same design space as default arguments
>> - a compiler helper.
>>
>
> Default arguments generate code (conditionally or not). Weak named
> arguments do not. I have some difficulty considering those to be "exactly
> the same design space". Or even similar design spaces.
>
> With default arguments the compiler is only obligated to copy-paste the
>> default expression if we don't pass a value.
>>
>> With names it is a matter of what features we want to have:
>>
>>    - to only name-check
>>    - to paste in place of name-only
>>    - to paste on omission
>>    - to rearrange
>>
>>
>>
>>
>>> If names can be inconsistent and still affect syntax, bad things result.
>>>
>>> Should it be done is a different matter, this is a debate as heated as
>>>> the one about signature - some people consider names useless if they don't
>>>> rearrange/skip defaults, some are happy with just checking alone.
>>>>
>>>

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

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

<div dir=3D"ltr"><br><br>On Wednesday, August 22, 2018 at 11:47:29 PM UTC+3=
, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Tuesday, August 21, 2018 at 4:04:26 AM UTC-4, <a>mihailn...@gma=
il.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">O=
n Tuesday, August 21, 2018 at 4:52:56 AM UTC+3, Nicol Bolas wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Monday, August 20, 2018 =
at 4:18:34 PM UTC-4, <a>mihailn...@gmail.com</a> wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr">On Monday, August 20, 2018 at 9:45:02 =
PM UTC+3, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr">On Monday, August 20, 2018 at 12:20:20 PM UTC-4, <a>mihailn...@gm=
ail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div></div></div></blockquote></div></blockquote><blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div></div><div><div>Are sure about that? Argument rearrangeme=
nt is doable without changing the signature (a.k.a. strong)</div></div></di=
v></blockquote><div><br></div><div>Maybe we have very different ideas about=
 what &quot;strong named parameters&quot; means. The question of &quot;chan=
ging the signature&quot; is not the distinction between=20
&quot;strong&quot; and &quot;weak&quot;. At least, it&#39;s not the distinc=
tion that I&#39;m talking about it.</div><div><br></div><div>&quot;Weak nam=
ed parameters&quot; to me refers to named parameters which are all of the f=
ollowing:</div><div><br></div><div>1. Optional. You can call a function tha=
t has named parameters without naming the parameter(s) at the call site.</d=
iv><div>2. Ordered. The order of the arguments must match the parameter ord=
er of the function, regardless of the names you specify at the call site.<b=
r></div><div>3. Overload-neutral. The presence or absence of names at the c=
all site has no effect on function overloading.</div><div><br></div><div>Es=
sentially, if your rules require that all named parameter function calls wi=
ll invoke the same function with the same behavior if you stripped out all =
of the names, then the named parameter proposal is &quot;weak&quot;.<br></d=
iv><div><br></div><div></div><div>Any named parameter feature which imposes=
 rules antithetical to at least one of the above is &quot;strong&quot;. Wit=
h the strongest being the antithesis to all of them.<br></div></div></block=
quote><div><br></div><div>I see, for you weak refers to the notion the call=
 is the same, but unchecked, without them.</div><div><br></div><div>For me =
strong is referring to &quot;does it introduce a new signature&quot;, the s=
ame way strong typedef introduces a new type. Everything else is weak as it=
 is about the compiler not the code.</div></div></blockquote><div><br></div=
><div>That&#39;s not what <a onmousedown=3D"this.href=3D&#39;https://groups=
..google.com/a/isocpp.org/d/msg/std-proposals/MbDT0vsA2j0/1VPQM7AsAAAJ&#39;;=
return true;" onclick=3D"this.href=3D&#39;https://groups.google.com/a/isocp=
p.org/d/msg/std-proposals/MbDT0vsA2j0/1VPQM7AsAAAJ&#39;;return true;" href=
=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/MbDT0vsA2j0/=
1VPQM7AsAAAJ" target=3D"_blank" rel=3D"nofollow">you said earlier</a>:</div=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Also=
, this obviously does not address the named arguments, <b>that are=20
optional, the &quot;weak&quot; ones</b>, so this solution will not make eve=
ryone=20
happy. <br></div></blockquote><div><br></div><div>Emphasis added. And there=
&#39;s <a onmousedown=3D"this.href=3D&#39;https://groups.google.com/a/isocp=
p.org/d/msg/std-proposals/MbDT0vsA2j0/uWG77JxeDQAJ&#39;;return true;" oncli=
ck=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msg/std-pro=
posals/MbDT0vsA2j0/uWG77JxeDQAJ&#39;;return true;" href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msg/std-proposals/MbDT0vsA2j0/uWG77JxeDQAJ" target=
=3D"_blank" rel=3D"nofollow">this post</a>:<br></div><div><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div>//weak argument names, not =
mandatory <br></div></blockquote><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div>... <br></div></blockquote><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div></div><div>//strong argument name, adds an overload, no=
t ignorable <br></div></blockquote><div><br></div><div>Yes, that post is ta=
lking about how you would declare weak names differently from strong names,=
 but it&#39;s also talking about how they get used at the call site: &quot;=
not mandatory&quot; vs. &quot;not ignorable&quot;.</div></div></blockquote>=
<div><br></div><div>There is no contradiction, they are optional, and ignor=
able by the user (he might not use them).=C2=A0</div><div>Now, it depends o=
n how much features they have, they might also be as weak as you assume the=
y are, so they are (can be) ignored by the compiler as well and the call is=
 the same.</div><div><br></div><div>Most of the time here we talked about t=
hese weakest ones, and considered &quot;extra features&quot; as &quot;bonus=
es&quot;.</div><div><br></div><div>For me personally strong were always the=
 one changing the signature, that&#39;s why the first post about tags-as-la=
bels was called &quot;Strong named arguments as tag overloads&quot;</div><d=
iv><br></div><div>And weak for me were not rearranging or skipping, but hav=
ing defaulted-by-naming <font face=3D"courier new,monospace">f(a:, b:, 10)=
=C2=A0</font></div><div>=C2=A0</div><div>Of course even these are not ignor=
able as the call will fail without them. Probably using the word ignorable =
was not correct.=C2=A0</div><div><br></div><div>In any case weak names are =
optional.=C2=A0</div><div>This is not to say, they do not affect overloadin=
g, they do, but only on the call site.</div><div><br></div><div><span style=
=3D"text-align:left;color:rgb(34,34,34);text-transform:none;text-indent:0px=
;letter-spacing:normal;font-size:13px;font-style:normal;font-variant:normal=
;font-weight:400;text-decoration:none;word-spacing:0px;display:inline!impor=
tant;white-space:normal;float:none;background-color:transparent"><font face=
=3D"courier new,monospace">void func(int a, int b);</font></span><b></b><i>=
</i><u></u><sub></sub><sup></sup><strike></strike><br></div><div><font face=
=3D"courier new,monospace">void func(int a, int b: b=3D1, int c: c=3D2);</f=
ont></div><div><font face=3D"courier new,monospace"></font><br></div><div><=
font face=3D"courier new,monospace">func(1, 3); //&lt; overload 1</font></d=
iv><div><span style=3D"text-align:left;color:rgb(34,34,34);text-transform:n=
one;text-indent:0px;letter-spacing:normal;font-size:13px;font-style:normal;=
font-variant:normal;font-weight:400;text-decoration:none;word-spacing:0px;d=
isplay:inline!important;white-space:normal;float:none;background-color:tran=
sparent"><font face=3D"courier new,monospace">func(1, b: 3);<span style=3D"=
display:inline!important;float:none;background-color:transparent;color:rgb(=
34,34,34);font-family:courier new,monospace;font-size:13px;font-style:norma=
l;font-variant:normal;font-weight:400;letter-spacing:normal;text-align:left=
;text-decoration:none;text-indent:0px;text-transform:none;white-space:norma=
l;word-spacing:0px"> //&lt; overload 2</span></font></span><br></div><div><=
span><font face=3D"courier new,monospace" style=3D"border-bottom-color:rgb(=
34,34,34);border-bottom-style:none;border-bottom-width:0px;border-left-colo=
r:rgb(34,34,34);border-left-style:none;border-left-width:0px;border-right-c=
olor:rgb(34,34,34);border-right-style:none;border-right-width:0px;border-to=
p-color:rgb(34,34,34);border-top-style:none;border-top-width:0px;margin-bot=
tom:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;=
padding-left:0px;padding-right:0px;padding-top:0px">func(1, c: 3);<span sty=
le=3D"background-color:transparent;border-bottom-color:rgb(34,34,34);border=
-bottom-style:none;border-bottom-width:0px;border-left-color:rgb(34,34,34);=
border-left-style:none;border-left-width:0px;border-right-color:rgb(34,34,3=
4);border-right-style:none;border-right-width:0px;border-top-color:rgb(34,3=
4,34);border-top-style:none;border-top-width:0px;color:rgb(34,34,34);displa=
y:inline;float:none;font-family:courier new,monospace;font-size:13px;font-s=
tyle:normal;font-variant:normal;font-weight:400;letter-spacing:normal;margi=
n-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom=
:0px;padding-left:0px;padding-right:0px;padding-top:0px;text-align:left;tex=
t-decoration:none;text-indent:0px;text-transform:none;white-space:normal;wo=
rd-spacing:0px"> //&lt; overload 2</span></font></span><b></b><i></i><u></u=
><sub></sub><sup></sup><strike></strike><br></div><div><b></b><i></i><u></u=
><sub></sub><sup></sup><strike></strike><br></div></div></blockquote><div><=
br></div><div>If names are important enough to affect what overload gets ca=
lled, then they ought to be part of a function&#39;s type. If they are trul=
y &quot;optional&quot;, then they should not be able to affect overloading.=
</div><div><br></div><div>To me, &quot;optional&quot; means exactly that: o=
ptional. The choice of whether to use names or not is entirely the prerogat=
ive of the caller. A caller should be able to call the same function, provi=
ding the same parameters, without using parameter names if they so desire.<=
/div><div><br></div><div>You call the second overload, passing it the first=
 two parameters. That is not possible without using parameter names. You ca=
ll the third overload, passing only the first and third parameters. That to=
o is not possible without using parameter names.</div><div><br></div><div>F=
or your proposal, parameter names are not optional. That&#39;s different fr=
om saying that they are mandatory. There are cases in your design where you=
 can call a named parameter function overload without providing names for t=
hose parameters.</div><div><br></div><div>The key here is that in your prop=
osal, parameter names are <i>part of the overload set&#39;s interface</i>. =
Just like the various conversion operators and constructors on the types us=
ed as parameters.</div><div><br></div><div>That&#39;s what makes them diffe=
rent from default parameters: the fact that `func(1, 3)` is not ambiguous. =
With default parameters, users who don&#39;t specify all of the parameters =
can create ambiguous call relative to other overloads in the set. With your=
 design, that doesn&#39;t happen. This is what makes the parameter name <i>=
more</i> than just a default argument; it makes it part of the overload set=
&#39;s interface.<br></div></div></blockquote><div><br></div><div>=C2=A0<br=
>Boy, I made a mistake,<font face=3D"courier new,monospace"> func(1, 3)</fo=
nt> is of course ambiguous!=C2=A0</div><div><br></div><div>Bad example, her=
e is the correct one:</div><div><br></div><div><font face=3D"courier new,mo=
nospace">void func(int a, string b);<br>void func(int a, int b: b=3D1, stri=
ng c: c=3D&quot;hi&quot;);<br>void func(int a, int b: b=3D1, int c: c=3D2);=
</font></div><div><font face=3D"courier new,monospace"><br></font></div><di=
v><font face=3D"courier new,monospace">func(1, &quot;bye&quot;); //&lt; ove=
rload 1<br>func(1, c: &quot;bye&quot;); //&lt; overload 2<br>func(1, c: 3);=
 //&lt; overload 3</font></div><div><font face=3D"courier new,monospace"></=
font><br></div><div>The point was, on the call site (optional) names <i>can=
</i> affect overloading.=C2=A0</div><div><br></div><div>The more general ar=
gument was, optional names can service mega-functions, as long as they allo=
w skipping defaulted arguments. </div><div>But even mega-functions aside, <=
i>none of the current alternatives to the above code are better</i>, even i=
f possible - that&#39;s is way people want that feature!<br><br></div><div>=
<br></div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;"><div dir=3D"ltr"><div></div><div><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div></div><div>Changing the signature is a clear bo=
undary in both semantics and implementation.<br></div></div></blockquote><d=
iv></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></di=
v><div></div><div>But in the realm of non-changing-the-signature names, a l=
ot can be done, granted the calls <i>will</i> differ w/ and w/o names.</div=
></div></blockquote><div><br></div><div>I think you&#39;re too focused on s=
ignature as the notion of a function&#39;s identity. There are aspects of f=
unctions which are not their signature yet directly relate to its identity.=
</div><div><br></div><div>Return values. If you declare two functions with =
the same name and signatures with different return values, then you get a c=
ompile error. `noexcept` works that way too; you can&#39;t be inconsistent =
about that. Both of these are part of the function&#39;s type, but not its =
signature (though `noexcept` can be cast away).</div><div><br></div><div>Co=
ntracts affect neither type nor signature, but even that requires some basi=
c consistency. You can declare contracts on a function or not. But all cont=
ract declarations for the same function must be consistent.</div><div><br><=
/div><div>If a parameter name can be used as a syntactic modifier when call=
ing the function (for the purposes of this discussion, anything which affec=
ts actual code generation. This includes reordering of arguments), then tha=
t name ought to be, if not part of the function&#39;s type, then at least h=
ave as much consistency as its contracts. That is, if you want to be able t=
o reorder parameters, then the function should consistently assign each par=
ameter a single name or a single &quot;unnamed&quot;.</div></div></blockquo=
te><div><br></div><div><br></div><div>In the original post about weak argum=
ents, I suggested they obey the rules of default arguments - you name your =
arguments only in the first declaration. No names afterwards, not even the =
same.=C2=A0</div><div><br></div><div><div><span style=3D"background-color:t=
ransparent;border-bottom-color:rgb(34,34,34);border-bottom-style:none;borde=
r-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-style:none;b=
order-left-width:0px;border-right-color:rgb(34,34,34);border-right-style:no=
ne;border-right-width:0px;border-top-color:rgb(34,34,34);border-top-style:n=
one;border-top-width:0px;color:rgb(34,34,34);display:inline;float:none;font=
-size:13px;font-style:normal;font-variant:normal;font-weight:400;letter-spa=
cing:normal;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0=
px;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px;te=
xt-align:left;text-decoration:none;text-indent:0px;text-transform:none;whit=
e-space:normal;word-spacing:0px"><font face=3D"courier new,monospace" style=
=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:none;border-botto=
m-width:0px;border-left-color:rgb(34,34,34);border-left-style:none;border-l=
eft-width:0px;border-right-color:rgb(34,34,34);border-right-style:none;bord=
er-right-width:0px;border-top-color:rgb(34,34,34);border-top-style:none;bor=
der-top-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin=
-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:=
0px">auto child(name mother: mom, name dad);=C2=A0</font></span></div><div>=
<span style=3D"background-color:transparent;border-bottom-color:rgb(34,34,3=
4);border-bottom-style:none;border-bottom-width:0px;border-left-color:rgb(3=
4,34,34);border-left-style:none;border-left-width:0px;border-right-color:rg=
b(34,34,34);border-right-style:none;border-right-width:0px;border-top-color=
:rgb(34,34,34);border-top-style:none;border-top-width:0px;color:rgb(34,34,3=
4);display:inline;float:none;font-size:13px;font-style:normal;font-variant:=
normal;font-weight:400;letter-spacing:normal;margin-bottom:0px;margin-left:=
0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;pad=
ding-right:0px;padding-top:0px;text-align:left;text-decoration:none;text-in=
dent:0px;text-transform:none;white-space:normal;word-spacing:0px"><font fac=
e=3D"courier new,monospace" style=3D"border-bottom-color:rgb(34,34,34);bord=
er-bottom-style:none;border-bottom-width:0px;border-left-color:rgb(34,34,34=
);border-left-style:none;border-left-width:0px;border-right-color:rgb(34,34=
,34);border-right-style:none;border-right-width:0px;border-top-color:rgb(34=
,34,34);border-top-style:none;border-top-width:0px;margin-bottom:0px;margin=
-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0=
px;padding-right:0px;padding-top:0px"><br></font></span></div><div><font fa=
ce=3D"courier new,monospace">// <span style=3D"border-bottom-color:rgb(34,3=
4,34);border-bottom-style:none;border-bottom-width:0px;border-left-color:rg=
b(34,34,34);border-left-style:none;border-left-width:0px;border-right-color=
:rgb(34,34,34);border-right-style:none;border-right-width:0px;border-top-co=
lor:rgb(34,34,34);border-top-style:none;border-top-width:0px;margin-bottom:=
0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padd=
ing-left:0px;padding-right:0px;padding-top:0px"><font style=3D"border-botto=
m-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;bord=
er-left-color:rgb(34,34,34);border-left-style:none;border-left-width:0px;bo=
rder-right-color:rgb(34,34,34);border-right-style:none;border-right-width:0=
px;border-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0p=
x;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding=
-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px">auto child(=
name mother: mom, name dad); <i>//&lt; error</i></font></span></font></div>=
<div><span style=3D"background-color:transparent;border-bottom-color:rgb(34=
,34,34);border-bottom-style:none;border-bottom-width:0px;border-left-color:=
rgb(34,34,34);border-left-style:none;border-left-width:0px;border-right-col=
or:rgb(34,34,34);border-right-style:none;border-right-width:0px;border-top-=
color:rgb(34,34,34);border-top-style:none;border-top-width:0px;color:rgb(34=
,34,34);display:inline;float:none;font-size:13px;font-variant:normal;letter=
-spacing:normal;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-t=
op:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0p=
x;text-align:left;text-indent:0px;text-transform:none;white-space:normal;wo=
rd-spacing:0px"><font style=3D"border-bottom-color:rgb(34,34,34);border-bot=
tom-style:none;border-bottom-width:0px;border-left-color:rgb(34,34,34);bord=
er-left-style:none;border-left-width:0px;border-right-color:rgb(34,34,34);b=
order-right-style:none;border-right-width:0px;border-top-color:rgb(34,34,34=
);border-top-style:none;border-top-width:0px;margin-bottom:0px;margin-left:=
0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;pad=
ding-right:0px;padding-top:0px"><font face=3D"courier new,monospace"><span>=
// </span><span style=3D"border-bottom-color:rgb(34,34,34);border-bottom-st=
yle:none;border-bottom-width:0px;border-left-color:rgb(34,34,34);border-lef=
t-style:none;border-left-width:0px;border-right-color:rgb(34,34,34);border-=
right-style:none;border-right-width:0px;border-top-color:rgb(34,34,34);bord=
er-top-style:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;ma=
rgin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-r=
ight:0px;padding-top:0px"><font style=3D"border-bottom-color:rgb(34,34,34);=
border-bottom-style:none;border-bottom-width:0px;border-left-color:rgb(34,3=
4,34);border-left-style:none;border-left-width:0px;border-right-color:rgb(3=
4,34,34);border-right-style:none;border-right-width:0px;border-top-color:rg=
b(34,34,34);border-top-style:none;border-top-width:0px;margin-bottom:0px;ma=
rgin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-le=
ft:0px;padding-right:0px;padding-top:0px">auto child(name mom, name father:=
 dad); <i>//&lt; error</i></font></span></font><b style=3D"border-bottom-co=
lor:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;border-l=
eft-color:rgb(34,34,34);border-left-style:none;border-left-width:0px;border=
-right-color:rgb(34,34,34);border-right-style:none;border-right-width:0px;b=
order-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0px;ma=
rgin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bot=
tom:0px;padding-left:0px;padding-right:0px;padding-top:0px"></b><u style=3D=
"border-bottom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-w=
idth:0px;border-left-color:rgb(34,34,34);border-left-style:none;border-left=
-width:0px;border-right-color:rgb(34,34,34);border-right-style:none;border-=
right-width:0px;border-top-color:rgb(34,34,34);border-top-style:none;border=
-top-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-to=
p:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px=
"></u><sub style=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:n=
one;border-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-sty=
le:none;border-left-width:0px;border-right-color:rgb(34,34,34);border-right=
-style:none;border-right-width:0px;border-top-color:rgb(34,34,34);border-to=
p-style:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin-=
right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:=
0px;padding-top:0px"></sub><sup style=3D"border-bottom-color:rgb(34,34,34);=
border-bottom-style:none;border-bottom-width:0px;border-left-color:rgb(34,3=
4,34);border-left-style:none;border-left-width:0px;border-right-color:rgb(3=
4,34,34);border-right-style:none;border-right-width:0px;border-top-color:rg=
b(34,34,34);border-top-style:none;border-top-width:0px;margin-bottom:0px;ma=
rgin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-le=
ft:0px;padding-right:0px;padding-top:0px"></sup><strike style=3D"border-bot=
tom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;bo=
rder-left-color:rgb(34,34,34);border-left-style:none;border-left-width:0px;=
border-right-color:rgb(34,34,34);border-right-style:none;border-right-width=
:0px;border-top-color:rgb(34,34,34);border-top-style:none;border-top-width:=
0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;paddi=
ng-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px"></strike>=
<br style=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:none;bor=
der-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-style:none=
;border-left-width:0px;border-right-color:rgb(34,34,34);border-right-style:=
none;border-right-width:0px;border-top-color:rgb(34,34,34);border-top-style=
:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0=
px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;pad=
ding-top:0px"></font></span></div><div><span style=3D"background-color:tran=
sparent;border-bottom-color:rgb(34,34,34);border-bottom-style:none;border-b=
ottom-width:0px;border-left-color:rgb(34,34,34);border-left-style:none;bord=
er-left-width:0px;border-right-color:rgb(34,34,34);border-right-style:none;=
border-right-width:0px;border-top-color:rgb(34,34,34);border-top-style:none=
;border-top-width:0px;color:rgb(34,34,34);display:inline;float:none;font-si=
ze:13px;font-style:normal;font-variant:normal;font-weight:400;letter-spacin=
g:normal;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;=
padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px;text-=
align:left;text-decoration:none;text-indent:0px;text-transform:none;white-s=
pace:normal;word-spacing:0px"><font face=3D"courier new,monospace" style=3D=
"border-bottom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-w=
idth:0px;border-left-color:rgb(34,34,34);border-left-style:none;border-left=
-width:0px;border-right-color:rgb(34,34,34);border-right-style:none;border-=
right-width:0px;border-top-color:rgb(34,34,34);border-top-style:none;border=
-top-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-to=
p:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px=
">auto child(name mutter, vater); <i>//&lt; OK</i></font></span><b style=3D=
"border-bottom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-w=
idth:0px;border-left-color:rgb(34,34,34);border-left-style:none;border-left=
-width:0px;border-right-color:rgb(34,34,34);border-right-style:none;border-=
right-width:0px;border-top-color:rgb(34,34,34);border-top-style:none;border=
-top-width:0px;color:rgb(34,34,34);line-height:normal;margin-bottom:0px;mar=
gin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-lef=
t:0px;padding-right:0px;padding-top:0px"></b><u style=3D"border-bottom-colo=
r:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;border-lef=
t-color:rgb(34,34,34);border-left-style:none;border-left-width:0px;border-r=
ight-color:rgb(34,34,34);border-right-style:none;border-right-width:0px;bor=
der-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0px;colo=
r:rgb(34,34,34);line-height:normal;margin-bottom:0px;margin-left:0px;margin=
-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right=
:0px;padding-top:0px"></u><sub style=3D"border-bottom-color:rgb(34,34,34);b=
order-bottom-style:none;border-bottom-width:0px;border-left-color:rgb(34,34=
,34);border-left-style:none;border-left-width:0px;border-right-color:rgb(34=
,34,34);border-right-style:none;border-right-width:0px;border-top-color:rgb=
(34,34,34);border-top-style:none;border-top-width:0px;margin-bottom:0px;mar=
gin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-lef=
t:0px;padding-right:0px;padding-top:0px"></sub><sup style=3D"border-bottom-=
color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;border=
-left-color:rgb(34,34,34);border-left-style:none;border-left-width:0px;bord=
er-right-color:rgb(34,34,34);border-right-style:none;border-right-width:0px=
;border-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0px;=
margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-b=
ottom:0px;padding-left:0px;padding-right:0px;padding-top:0px"></sup><strike=
 style=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:none;border=
-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-style:none;bo=
rder-left-width:0px;border-right-color:rgb(34,34,34);border-right-style:non=
e;border-right-width:0px;border-top-color:rgb(34,34,34);border-top-style:no=
ne;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;=
margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;paddin=
g-top:0px"></strike></div><div><span style=3D"margin:0px;padding:0px;border=
:0px rgb(34,34,34);text-align:left;color:rgb(34,34,34);text-transform:none;=
text-indent:0px;letter-spacing:normal;font-size:13px;font-style:normal;font=
-variant:normal;font-weight:400;text-decoration:none;word-spacing:0px;displ=
ay:inline;white-space:normal;float:none;background-color:transparent"><font=
 face=3D"courier new,monospace">auto child(name mother, name father) <i>//&=
lt; OK</i></font></span></div><b></b><i></i><u></u><sub></sub><sup></sup><s=
trike></strike><font face=3D"courier new,monospace">{=C2=A0</font></div><di=
v><font face=3D"courier new,monospace">=C2=A0 // implementation</font></div=
><div><font face=3D"courier new,monospace">}</font><br></div><div>=C2=A0</d=
iv><div>This seems the be the most consistent approach as (weak) named argu=
ments ultimately inhabit <i>exactly</i> the same design space as default ar=
guments - a compiler helper.</div></div></blockquote><div><br></div><div>De=
fault arguments generate code (conditionally or not). Weak named arguments =
do not. I have some difficulty considering those to be &quot;exactly the sa=
me design space&quot;. Or even similar design spaces.<br></div><div><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div=
>With default arguments the compiler is only obligated to copy-paste the de=
fault expression if we don&#39;t pass a value.</div><div><br></div><div>Wit=
h names it is a matter of what features we want to have:</div><ul><li>to on=
ly name-check</li><li>to paste in place of name-only</li><li>to paste on om=
ission<br></li><li>to rearrange<br></li></ul><div><br></div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><di=
v></div><div>If names can be inconsistent and still affect syntax, bad thin=
gs result.</div><div></div><div><br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div>Should it be done is a different matter, this =
is a debate as heated as the one about signature - some people consider nam=
es useless if they don&#39;t rearrange/skip defaults, some are happy with j=
ust checking alone.=C2=A0 <br></div></div></blockquote></div></blockquote><=
/div></blockquote></div></blockquote></div>

<p></p>

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

------=_Part_2719_84395079.1535013440446--

------=_Part_2718_906235636.1535013440445--

.

On 2018-08-19 07:23, David Brown wrote:
> here I am talking about the optional use of parameter names to improve
> readability, help write correct code, help spot incorrect code, and -
> optionally - to allow re-arranging of parameter order and skipping
> defaults using names.

If we *don't* get the optional parts (skipping, reordering)... then
what's the point?

If we don't get the optional parts, you might as well modify your
compiler to warn you about:

  void foo(int x);
  foo(/*y=3D*/5); // warning: 'y' !=3D 'x'

....and no language change is required.

> There are two other use-cases where there could be debate about the best
> solution:
>=20
> If the call has the right parameter names, but the wrong order, should
> that be a warning, or error, or should the compiler "magically" correct
> the order?=C2=A0 If strong naming is used, the compiler should certainly =
be
> able to re-order the parameters without giving any complaints.

Honestly, this is a good question. There are arguments on both sides
whether or not to allow reordering, and I am somewhat avoiding taking a
stance.

That said, FWIW I think I'm less okay with reordering weak names than
strong names.

> The other case is for skipping arguments.=C2=A0 Again, with strong naming
> this should be supported.=C2=A0 I believe it /could/ be supported fine wi=
th
> weak naming, but would again be okay with the safer solution of not
> allowing it without strong naming.

Agreed. (Skipping is sort of a "weak" form of reordering.)

--=20
Matthew

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

.

On 23/08/18 18:44, Matthew Woehlke wrote:
> On 2018-08-19 07:23, David Brown wrote:
>> here I am talking about the optional use of parameter names to improve
>> readability, help write correct code, help spot incorrect code, and -
>> optionally - to allow re-arranging of parameter order and skipping
>> defaults using names.
>=20
> If we *don't* get the optional parts (skipping, reordering)... then
> what's the point?
>=20
> If we don't get the optional parts, you might as well modify your
> compiler to warn you about:
>=20
>    void foo(int x);
>    foo(/*y=3D*/5); // warning: 'y' !=3D 'x'
>=20
> ...and no language change is required.

I see two disadvantages of that.  One is that it is seriously ugly=20
having comments in the middle of a function call - "foo(.y =3D 5)" is very=
=20
much nicer and neater syntax.  The other is that because there is no=20
standard, and neither limits nor requirements in what you might have in=20
these comments (maybe someone wants to write "foo( /* was 4 in last=20
version */ 5);", it would be hard to get it in common use.

But as far as I see it, it is this checking that is the most important=20
feature.  It covers the two most vital points - it aids readability and=20
clarity of the code, and it means mistakes are more likely to be caught=20
at compile-time.  These are both /good/ things - and IMHO they are worth=20
allowing the syntax "foo(.y =3D 5);" even if you don't get anything else.

(I'd like to see that same syntax in C as well, including calling C=20
functions from C++ - and I think re-ordering and overloading would not=20
be a consideration for C.)

>=20
>> There are two other use-cases where there could be debate about the best
>> solution:
>>
>> If the call has the right parameter names, but the wrong order, should
>> that be a warning, or error, or should the compiler "magically" correct
>> the order?=C2=A0 If strong naming is used, the compiler should certainly=
 be
>> able to re-order the parameters without giving any complaints.
>=20
> Honestly, this is a good question. There are arguments on both sides
> whether or not to allow reordering, and I am somewhat avoiding taking a
> stance.
>=20

I have some rough preferences here - but I freely admit that I don't=20
have the experience at guessing what the complications might be, and I=20
leave it to the experts to see if the stance is forced by issues that I=20
have not thought about.

> That said, FWIW I think I'm less okay with reordering weak names than
> strong names.
>=20
>> The other case is for skipping arguments.=C2=A0 Again, with strong namin=
g
>> this should be supported.=C2=A0 I believe it /could/ be supported fine w=
ith
>> weak naming, but would again be okay with the safer solution of not
>> allowing it without strong naming.
>=20
> Agreed. (Skipping is sort of a "weak" form of reordering.)
>=20

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/35f836e7-f7af-e36f-e5f4-2be447d65576%40westcontr=
ol.com.

.

On 2018-08-19 17:53, Nicol Bolas wrote:
> Lastly, it should be noted that tagged dispatch doesn't help with what I
> will refer to as "mega-functions": functions that take stupidly large
> numbers of relatively independent parameters, but for some reason don't
> want to take them as a convenient aggregate. This is a use case that some
> people want to support, to avoid conceptual two-stage construction.

A good exercise in "why do we want named parameters" (at least for this
use case) would be to try to implement the API of Python's argparse in
C++17.

--
Matthew

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

.

On 2018-08-19 19:09, Nicol Bolas wrote:
> On Sunday, August 19, 2018 at 6:32:17 PM UTC-4, Jeremy Maitin-Shepard wrote:
>> We already have a form of weak named parameters readily available in the
>> form of /*parameter_name=*/value comments in combination with the
>> clang-tidy bugprone-argument-comment check or similar functionality in
>> other tools.
>>
>> A mechanism that only warns and doesn't support forwarding/metaprogramming
>> does not seem to me to provide much value over what we already have.
>
> And how would you propose to make "forwarding/metaprogramming" work with
> weak parameters? You can draw up a couple of simplistic cases that a
> compiler can peek through, but you can't come up with a coherent set of
> rules that work everywhere. And when I say "rules", I don't mean English
> text or "something like this"; I mean something approaching standards
> wording.

I don't know about "something approaching standards wording", but where
I was headed, this:

  void foo(int y);
  std::invoke(foo, .x=5);

....would turn into something like:

  invoke(Func *foo, arg<int, "x"> a1 = 5)
  {
    (*foo)(a1);
  }

....which could warn about decomposing the named argument "x" into a call
that names its argument "y".

So, basically, I implement "weak" names by allowing the caller to pass a
strongly named argument to a function that takes only weak names.
Delaying the decay from strongly-named to weakly-named allows most of
the forwarding cases to work.

> The fundamental issue with forwarding is about the transmission of
> information from source to destination. Strong parameter proposals transmit
> information in some explicit way: maybe it's a struct with known parameters
> or the names are themselves parameters or something else. Most strong
> parameter proposals handle parameter names in in ways C++ already
> understands.

Right. In the example above, the *caller* passes a strongly-named
argument, which is forwarded as a strongly named argument. It only
"loses" the naming information when it hits a function taking a
non-template parameter that is not strongly named. At that point, the
compiler has the opportunity to issue a warning.

> With strong parameters, `emplace(val: 2)` compiles when `emplace(2)` does
> not because of normal C++ reasons. You're instantiating two different
> functions, with different sets of parameters, which therefore can have
> different behaviors.

....except that in my thinking, `emplace(2)` will auto-promote to a
strongly named argument, if that's what `emplace` wants. You only get an
error if the caller provides a strongly-named argument that the callee
does not accept.

  void foo(int .x);
  foo(5); // okay
  foo(.x=5); // okay
  foo(.y=5); // error

> Weak named parameters are intended to be purely notation information.
> Therefore, `emplace(val: 2)` must instantiate and execute the same template
> as `emplace(2)` does. Since the information is not passed in a channel that
> C++ currently understands, you now have to create an entirely new channel
> of information, which is somehow attached to a parameter yet otherwise is
> undetectable by anything that isn't the compiler. One which allows such
> intermediary functions to pass such named parameters to logging or other
> functions without causing a compile error.

It's not "undetectable". OTOH, if you have:

  void foo(int x);
  foo(5); // okay
  foo(.x=5); // okay

....by the time you're in `foo`, you've lost the name information.
Forwarding works if you accept a template type. If you accept a concrete
type, the name is lost.

--
Matthew

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

.

On 2018-08-23 13:17, David Brown wrote:
> On 23/08/18 18:44, Matthew Woehlke wrote:
>> If we don't get the optional parts, you might as well modify your
>> compiler to warn you about:
>>
>> =C2=A0=C2=A0 void foo(int x);
>> =C2=A0=C2=A0 foo(/*y=3D*/5); // warning: 'y' !=3D 'x'
>>
>> ...and no language change is required.
>=20
> I see two disadvantages of that.=C2=A0 One is that it is seriously ugly
> having comments in the middle of a function call - "foo(.y =3D 5)" is ver=
y
> much nicer and neater syntax.=C2=A0 The other is that because there is no
> standard, and neither limits nor requirements in what you might have in
> these comments (maybe someone wants to write "foo( /* was 4 in last
> version */ 5);", it would be hard to get it in common use.
>=20
> But as far as I see it, it is this checking that is the most important
> feature.=C2=A0 It covers the two most vital points - it aids readability =
and
> clarity of the code, and it means mistakes are more likely to be caught
> at compile-time.=C2=A0 These are both /good/ things - and IMHO they are w=
orth
> allowing the syntax "foo(.y =3D 5);" even if you don't get anything else.

I understand what you're saying. I just happen to strongly disagree :-).
(That is, I would agree with the above if you replace "most" with
"least"...)

That said, my current vision would give you what you're asking for...
but also overloading and skipping.

Also, as has been elsewhere discussed, I'm not sure how forwarding would
work without at least some degree of "strong" naming, and I don't see
any proposal getting much traction if it doesn't "solve" forwarding.

--=20
Matthew

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/d3a82498-693b-e586-86a2-0af9364a7baf%40gmail.com=
..

.

On 2018-08-20 11:37, Nicol Bolas wrote:
> The only way you can get the "ideal" case is if order for parameters is *completely
> removed* for such functions. You can specify the arguments in any order
> when you call them, and the caller can default any parameter with a default
> value simply by not specifying it.

Um... why? Why is it a problem to enforce that, if you specify a font,
that has to be specified before a palette?

You need to be able to *skip* parameters. I don't see why you need to be
able to *reorder* parameters...

--
Matthew

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

.

(Sorry, I'm only just now reading the original post...)

On 2018-08-16 01:10, Justin Bassett wrote:
> However, I believe that the name should be part of the function type and
> should be mangled into the name for the function. It should not be allowed
> for the following two declarations to coexist:
>
> int foo(int .x, int .y);
> int foo(int .a, int .b);
>
> If the name of the parameters are not part of the function, then if those
> declarations are in separate translation units, there's little way to
> enforce that this should fail to compile / link.

If the name is part of the ABI, *why* should the above be forbidden? For
that matter, *how* would you forbid it? They have different mangled names...

If the two exist only in separate TU's and are never seen in the same
TU, you would be requiring the *linker*, not the compiler, to reject this.

> This does bring in the issue that it becomes harder to change existing APIs
> to accept named parameters in an ABI compatible manner.

FWIW, my current thought is to solve this by means of an explicitly
inline trampoline function. (Actually, I would ideally make it an
*alias*, not a "real" trampoline at all.)

For example:

  void foo(int);
  using foo(int .x) = foo(int);

Basically, it is a mechanism to add a function prototype to the overload
set, such that the added overload actually resolves to a different ABI
function. Thus, you can write code *as if* `foo(int .x)` existed, but
when the compiler resolves a call to the named argument version, it will
*actually* call `foo(int)`. This allows the ABI to be unchanged.

> Now for templates. In order to have higher-order functions which work on
> named parameters, I believe it is necessary to have a new kind of template
> parameter, something like this:
>
> // I separated the name completely from the type.
> // This would severely complicate generic code, however, so maybe there's
> // a way to keep both together
> template <typename F, .typename Name, typename Arg>
> void call(F fn, Arg&& .Name arg) {
>     // Some syntax to expand the name is needed. I'm not sure what
>     // a reasonable choice is. There should also probably be a way
>     // to generate a name from a compile time string.
>     fn(.(Name) = std::forward<Arg>(arg));
> }

....which suggests that e.g. std::invoke can't use named parameters. I
don't think that will work.

> Reflection could possibly allow us to inspect the actual name supplied
> (useful for libraries such as fmt: fmt::format("({x}, {y})", .x = 10, .y =
> 20); ), and it would probably be useful to be able to generate a name from
> a compile-time string.

I've been thinking along the lines of named parameters being syntax
sugar for something like `std::arg<T, name>`, where `name` is a string
literal type. So reflection would just see the std::arg, and we don't
have to think about this too hard (or about ABI).

(Not *just* syntax sugar; they affect overload resolution also. But for
e.g. reflection, they'd just be sugar.)

I *think* this makes your above example possible, though it may require
something like building a dictionary by converting the compile-time
literals into (possibly) run-time keys.

> Further ideas: I don't want to propose this yet, but I would also like to
> see named parameters in template parameters. For example, it would be nice
> to be easily able to specify the allocator of an unordered_map:
> std::unordered_map<Key,
> Value, .allocator = MyAllocator> . I believe this would break ABI
> compatibility, though.

I think this is an orthogonal space, much closer actually to designated
initializers. (Yes, it *looks* very much the same to users, but
implementation-wise I don't think it has anything like the same sorts of
problems as genuine named *function arguments*.)

This would be a good space for an independent proposal to explore.

--
Matthew

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

.

On 23/08/2018 19:37, Matthew Woehlke wrote:
> On 2018-08-23 13:17, David Brown wrote:
>> On 23/08/18 18:44, Matthew Woehlke wrote:
>>> If we don't get the optional parts, you might as well modify your
>>> compiler to warn you about:
>>>
>>>  =C2=A0=C2=A0 void foo(int x);
>>>  =C2=A0=C2=A0 foo(/*y=3D*/5); // warning: 'y' !=3D 'x'
>>>
>>> ...and no language change is required.
>>
>> I see two disadvantages of that.=C2=A0 One is that it is seriously ugly
>> having comments in the middle of a function call - "foo(.y =3D 5)" is ve=
ry
>> much nicer and neater syntax.=C2=A0 The other is that because there is n=
o
>> standard, and neither limits nor requirements in what you might have in
>> these comments (maybe someone wants to write "foo( /* was 4 in last
>> version */ 5);", it would be hard to get it in common use.
>>
>> But as far as I see it, it is this checking that is the most important
>> feature.=C2=A0 It covers the two most vital points - it aids readability=
 and
>> clarity of the code, and it means mistakes are more likely to be caught
>> at compile-time.=C2=A0 These are both /good/ things - and IMHO they are =
worth
>> allowing the syntax "foo(.y =3D 5);" even if you don't get anything else=
..
>=20
> I understand what you're saying. I just happen to strongly disagree :-).
> (That is, I would agree with the above if you replace "most" with
> "least"...)

I think we just have a little difference in perspective.  You want=20
powerful new features, and increased checking and readability is a free=20
bonus from that.  I want increased checking and readability, and new=20
features might be a bonus from the way they are implemented.

>=20
> That said, my current vision would give you what you're asking for...
> but also overloading and skipping.
>=20
> Also, as has been elsewhere discussed, I'm not sure how forwarding would
> work without at least some degree of "strong" naming, and I don't see
> any proposal getting much traction if it doesn't "solve" forwarding.
>=20

We could get /my/ part done without worrying about forwarding...

But I agree it is unlikely that the standards would support a named=20
parameter system that doesn't cover a wider range of new functions.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/90defe78-0849-1cbd-3835-bc73160ee829%40westcontr=
ol.com.

.

On 23/08/18 19:37, Matthew Woehlke wrote:
> On 2018-08-23 13:17, David Brown wrote:
>> On 23/08/18 18:44, Matthew Woehlke wrote:
>>> If we don't get the optional parts, you might as well modify your
>>> compiler to warn you about:
>>>
>>>    void foo(int x);
>>>    foo(/*y=*/5); // warning: 'y' != 'x'
>>>
>>> ...and no language change is required.
>>
>> I see two disadvantages of that.  One is that it is seriously ugly
>> having comments in the middle of a function call - "foo(.y = 5)" is very
>> much nicer and neater syntax.  The other is that because there is no
>> standard, and neither limits nor requirements in what you might have in
>> these comments (maybe someone wants to write "foo( /* was 4 in last
>> version */ 5);", it would be hard to get it in common use.
>>
>> But as far as I see it, it is this checking that is the most important
>> feature.  It covers the two most vital points - it aids readability and
>> clarity of the code, and it means mistakes are more likely to be caught
>> at compile-time.  These are both /good/ things - and IMHO they are worth
>> allowing the syntax "foo(.y = 5);" even if you don't get anything else.
>
> I understand what you're saying. I just happen to strongly disagree :-).
> (That is, I would agree with the above if you replace "most" with
> "least"...)
>
> That said, my current vision would give you what you're asking for...
> but also overloading and skipping.
>
> Also, as has been elsewhere discussed, I'm not sure how forwarding would
> work without at least some degree of "strong" naming, and I don't see
> any proposal getting much traction if it doesn't "solve" forwarding.
>

It has just occurred to me that if you allow skipping of overloaded
defaults - which can be done without "strong" naming or changes to
declaration syntax - it is quite easy to implement name-based
overloading in the same way as it is done in Python.  For example,
Python has a built-in type "complex":

>>> c = complex(1, 2)
>>> type(c)
<type 'complex'>
>>> print c
(1+2j)
>>>

You might want a function "Complex" that could be used with either polar
or rectangular parameters.  In Python, you would define that as
something like:

def Complex(x = None, y = None, r = None, phi = None) :
 if (x != None) and (y != None) :
  return complex(x, y)
 if (r != None) and (phi != None) :
  return cmath.rect(r, phi)
 raise NotImplementedError

This lets you write:

>>> Complex(1, 2)
(1+2j)
>>> Complex(x = 1, y = 2)
(1+2j)
>>> Complex(r = 1, phi = math.pi / 4)
(0.7071067811865476+0.7071067811865475j)

That is simple, name-based overloading.

C++ can express the same thing, using optional:


#include <stdint.h>
#include <complex>
#include <optional>
#include <exception>

using namespace std;

inline complex<double>
Complex(optional<double> x = nullopt, optional<double> y = nullopt,
        optional<double> r = nullopt, optional<double> phi = nullopt)
{
    if (x && y) return complex<double>(x.value(), y.value());
    if (r && phi) return polar(r.value(), phi.value());
    throw invalid_argument("Complex requires either x, y /or/ r, phi");
}


complex<double> rect_test1(double a, double b) {
    return complex<double>(a, b);
}

complex<double> rect_test2(double a, double b) {
    return Complex(a, b);
}

complex<double> polar_test1(double a, double b) {
    return polar(a, b);
}

complex<double> polar_test2(double a, double b) {
    return Complex(nullopt, nullopt, a, b);
}


Functions rect_test1 and rect_test2 generate the same code in gcc, as do
functions polar_test1 and polar_test2, from a quick test.

If you allow parameter names to skip default values, then using this
function definition for "Complex", without any changes to the code or
language as it is today, you could write:

complex<double> rect_test3(double a, double b) {
    return Complex(.x = a, .y = b);
}

complex<double> polar_test3(double a, double b) {
    return Complex(.r = a, .phi = b);
}


That gives you parameter name based function overloading without having
to change the language at the definition side, and without more than a
small syntax change on the caller side.  (C++ compilers might want to
put some effort into making sure they optimise std::optional well - but
that would be nice anyway!)








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

.

On 2018-08-24 02:31, David Brown wrote:
> We could get /my/ part done without worrying about forwarding...

As others have noted, if we don't even worry about forwarding, I just
can't see where what you are proposing is a sufficient improvement over
what clang-tidy *already does* to be worth committee time...

--
Matthew

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

.

This is a multi-part message in MIME format.
--------------61334D979CAEE3FDC1A4553B
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 24/08/2018 =C3=A0 17:28, Matthew Woehlke a =C3=A9crit=C2=A0:
> On 2018-08-24 02:31, David Brown wrote:
>> We could get /my/ part done without worrying about forwarding...
> As others have noted, if we don't even worry about forwarding, I just
> can't see where what you are proposing is a sufficient improvement over
> what clang-tidy *already does* to be worth committee time...
>
How would you ensure that any developer uses the same syntax so that=20
clang-tidy takes in account those comments as weak named parameters ? :(

Having weak named parameters in the standard will ensure that everybody=20
uses the same syntax :)


Vicente


--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/dc396379-2e4b-4758-5f1f-51e2561acfa2%40wanadoo.f=
r.

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

<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 24/08/2018 =C3=A0 17:28, Matthew Woeh=
lke
      a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"
      cite=3D"mid:defb4327-c818-a439-ff58-7838d3a046de@gmail.com">
      <pre wrap=3D"">On 2018-08-24 02:31, David Brown wrote:
</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">We could get /my/ part done without worrying about f=
orwarding...
</pre>
      </blockquote>
      <pre wrap=3D"">
As others have noted, if we don't even worry about forwarding, I just
can't see where what you are proposing is a sufficient improvement over
what clang-tidy *already does* to be worth committee time...

</pre>
    </blockquote>
    <p><font size=3D"+1">How would you ensure that any developer uses the
        same syntax so that clang-tidy takes in account those comments
        as weak named parameters ? :(</font></p>
    <p><font size=3D"+1">Having weak named parameters in the standard will
        ensure that everybody uses the same syntax :)</font></p>
    <p><font size=3D"+1"><br>
      </font></p>
    <p><font size=3D"+1">Vicente<br>
      </font></p>
    <p><font size=3D"+1"></font><br>
    </p>
  </body>
</html>

<p></p>

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

--------------61334D979CAEE3FDC1A4553B--

.

On 2018-08-24 13:26, Vicente J. Botet Escriba wrote:
> Le 24/08/2018 =C3=A0 17:28, Matthew Woehlke a =C3=A9crit=C2=A0:
>> On 2018-08-24 02:31, David Brown wrote:
>>> We could get /my/ part done without worrying about forwarding...
>> As others have noted, if we don't even worry about forwarding, I just
>> can't see where what you are proposing is a sufficient improvement over
>> what clang-tidy *already does* to be worth committee time...
>>
> How would you ensure that any developer uses the same syntax so that
> clang-tidy takes in account those comments as weak named parameters ? :(

....because for this purpose, clang-tidy is the *de facto* standard.

> Having weak named parameters in the standard will ensure that everybody
> uses the same syntax :)

Why do you think that a de jure standard will be more closely followed
than a de facto standard? In fact, considering that I can use the de
facto standard "weak arguments" *in C++98*, whereas the hypothetical de
jure standard I can only follow if all my compilers support C++20 or
C++2x, I would rather expect the opposite...

--=20
Matthew

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

.

This is a multi-part message in MIME format.
--------------2476FBD6A5B4D7B581ACFE8F
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 24/08/2018 =C3=A0 19:39, Matthew Woehlke a =C3=A9crit=C2=A0:
> On 2018-08-24 13:26, Vicente J. Botet Escriba wrote:
>> Le 24/08/2018 =C3=A0 17:28, Matthew Woehlke a =C3=A9crit=C2=A0:
>>> On 2018-08-24 02:31, David Brown wrote:
>>>> We could get /my/ part done without worrying about forwarding...
>>> As others have noted, if we don't even worry about forwarding, I just
>>> can't see where what you are proposing is a sufficient improvement over
>>> what clang-tidy *already does* to be worth committee time...
>>>
>> How would you ensure that any developer uses the same syntax so that
>> clang-tidy takes in account those comments as weak named parameters ? :(
> ...because for this purpose, clang-tidy is the *de facto* standard.
weak named parameters allow reorder and omission of named parameters=20
having a default value.
AFAIK clang-tidy cannot do that.

For me weak named parameters are parameter that have a specific name=20
that is part of the public interface of the function (the current ones=20
are not weak named parameters) and that can be used by the caller to=20
name the argument but that doesn't change his signature, nor the ABI.=20
These functions can be called without the use of the names, following=20
the current rules. parameter names could be used to select the good=20
overload, but are not part of the signature and so we can not forward=20
weak parameter names, but it can forward named parameters when we don't=20
use his name (as we do now).

Maybe you want forwarding, but then the name of the named parameter need=20
to be part of the signature. IMO, this is solved with tag dispatching=20
and weak named parameters.
>
>> Having weak named parameters in the standard will ensure that everybody
>> uses the same syntax :)
> Why do you think that a de jure standard will be more closely followed
> than a de facto standard? In fact, considering that I can use the de
> facto standard "weak arguments" *in C++98*, whereas the hypothetical de
> jure standard I can only follow if all my compilers support C++20 or
> C++2x, I would rather expect the opposite...
>
Sorry, but we are not talking here about C++98, but a possible feature=20
for the future standard.

And yes, I'm sure that having them in the standard would make them used=20
a lot (as they are currently in other languages) than what we can get=20
with C comments and clang-tidy.


Vicente

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7d1be349-0a22-e22e-f0e7-e578f7b1c919%40wanadoo.f=
r.

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

<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 24/08/2018 =C3=A0 19:39, Matthew Woeh=
lke
      a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"
      cite=3D"mid:4c686121-fd2e-18b0-1480-e2f528c085ef@gmail.com">
      <pre wrap=3D"">On 2018-08-24 13:26, Vicente J. Botet Escriba wrote:
</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">Le 24/08/2018 =C3=A0 17:28, Matthew Woehlke a =C3=A9=
crit=C2=A0:
</pre>
        <blockquote type=3D"cite">
          <pre wrap=3D"">On 2018-08-24 02:31, David Brown wrote:
</pre>
          <blockquote type=3D"cite">
            <pre wrap=3D"">We could get /my/ part done without worrying abo=
ut forwarding...
</pre>
          </blockquote>
          <pre wrap=3D"">As others have noted, if we don't even worry about=
 forwarding, I just
can't see where what you are proposing is a sufficient improvement over
what clang-tidy *already does* to be worth committee time...

</pre>
        </blockquote>
        <pre wrap=3D"">How would you ensure that any developer uses the sam=
e syntax so that
clang-tidy takes in account those comments as weak named parameters ? :(
</pre>
      </blockquote>
      <pre wrap=3D"">
....because for this purpose, clang-tidy is the *de facto* standard.</pre>
    </blockquote>
    weak named parameters allow reorder and omission of named parameters
    having a default value.<br>
    AFAIK clang-tidy cannot do that.<br>
    <br>
    For me weak named parameters are parameter that have a specific name
    that is part of the public interface of the function (the current
    ones are not weak named parameters) and that can be used by the
    caller to name the argument but that doesn't change his signature,
    nor the ABI. These functions can be called without the use of the
    names, following the current rules. parameter names could be used to
    select the good overload, but are not part of the signature and so
    we can not forward weak parameter names, but it can forward named
    parameters when we don't use his name (as we do now).<br>
    <br>
    Maybe you want forwarding, but then the name of the named parameter
    need to be part of the signature. IMO, this is solved with tag
    dispatching and weak named parameters.<br>
    <blockquote type=3D"cite"
      cite=3D"mid:4c686121-fd2e-18b0-1480-e2f528c085ef@gmail.com">
      <pre wrap=3D"">

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">Having weak named parameters in the standard will en=
sure that everybody
uses the same syntax :)
</pre>
      </blockquote>
      <pre wrap=3D"">
Why do you think that a de jure standard will be more closely followed
than a de facto standard? In fact, considering that I can use the de
facto standard "weak arguments" *in C++98*, whereas the hypothetical de
jure standard I can only follow if all my compilers support C++20 or
C++2x, I would rather expect the opposite...

</pre>
    </blockquote>
    <p><font size=3D"+1">Sorry, but we are not talking here about C++98,
        but a possible feature for the future standard.</font></p>
    <p><font size=3D"+1">And yes, I'm sure that having them in the
        standard would make them used a lot (as they are currently in
        other languages) than what we can get with C comments and
        clang-tidy.<br>
      </font></p>
    <p><font size=3D"+1"><br>
      </font></p>
    <p><font size=3D"+1">Vicente</font><br>
    </p>
  </body>
</html>

<p></p>

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

--------------2476FBD6A5B4D7B581ACFE8F--

.

------=_Part_526_1500327205.1535174632248
Content-Type: multipart/alternative;
 boundary="----=_Part_527_859370224.1535174632248"

------=_Part_527_859370224.1535174632248
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Saturday, August 25, 2018 at 2:11:04 AM UTC+3, Vicente J. Botet Escriba=
=20
wrote:
>
> Le 24/08/2018 =C3=A0 19:39, Matthew Woehlke a =C3=A9crit :
>
> On 2018-08-24 13:26, Vicente J. Botet Escriba wrote:
>
> Le 24/08/2018 =C3=A0 17:28, Matthew Woehlke a =C3=A9crit :
>
> On 2018-08-24 02:31, David Brown wrote:
>
> We could get /my/ part done without worrying about forwarding...
>
> As others have noted, if we don't even worry about forwarding, I just
> can't see where what you are proposing is a sufficient improvement over
> what clang-tidy *already does* to be worth committee time...
>
>
> How would you ensure that any developer uses the same syntax so that
> clang-tidy takes in account those comments as weak named parameters ? :(
>
> ...because for this purpose, clang-tidy is the *de facto* standard.
>
> =20

> weak named parameters allow reorder and omission of named parameters=20
> having a default value.
> AFAIK clang-tidy cannot do that.
>
> For me weak named parameters are parameter that have a specific name that=
=20
> is part of the public interface of the function (the current ones are not=
=20
> weak named parameters) and that can be used by the caller to name the=20
> argument but that doesn't change his signature, nor the ABI. These=20
> functions can be called without the use of the names, following the curre=
nt=20
> rules. parameter names could be used to select the good overload, but are=
=20
> not part of the signature and so we can not forward weak parameter names,=
=20
> but it can forward named parameters when we don't use his name (as we do=
=20
> now).
>


> Maybe you want forwarding, but then the name of the named parameter need=
=20
> to be part of the signature. IMO, this is solved with tag dispatching and=
=20
> weak named parameters.
>

Forwarding is 100% doable as forwarding references are inline and the=20
compiler can see-through.=20
What is not possible is forward-as-tuple and async type of forwarding,=20
where forwarding references are not used all the way down.

Having weak named parameters in the standard will ensure that everybody
> uses the same syntax :)
>
> Why do you think that a de jure standard will be more closely followed
> than a de facto standard? In fact, considering that I can use the de
> facto standard "weak arguments" *in C++98*, whereas the hypothetical de
> jure standard I can only follow if all my compilers support C++20 or
> C++2x, I would rather expect the opposite...
>
>
> Sorry, but we are not talking here about C++98, but a possible feature fo=
r=20
> the future standard.
>
> And yes, I'm sure that having them in the standard would make them used a=
=20
> lot (as they are currently in other languages) than what we can get with =
C=20
> comments and clang-tidy.
>
>
> Vicente
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/293fe1d0-2692-4998-b7d2-f699522c2dec%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Saturday, August 25, 2018 at 2:11:04 AM UTC+3, =
Vicente J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>Le 24/08/2018 =C3=A0 19:39, Matthew Woehlke
      a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
      <pre>On 2018-08-24 13:26, Vicente J. Botet Escriba wrote:
</pre>
      <blockquote type=3D"cite">
        <pre>Le 24/08/2018 =C3=A0 17:28, Matthew Woehlke a =C3=A9crit=C2=A0=
:
</pre>
        <blockquote type=3D"cite">
          <pre>On 2018-08-24 02:31, David Brown wrote:
</pre>
          <blockquote type=3D"cite">
            <pre>We could get /my/ part done without worrying about forward=
ing...
</pre>
          </blockquote>
          <pre>As others have noted, if we don&#39;t even worry about forwa=
rding, I just
can&#39;t see where what you are proposing is a sufficient improvement over
what clang-tidy *already does* to be worth committee time...

</pre>
        </blockquote>
        <pre>How would you ensure that any developer uses the same syntax s=
o that
clang-tidy takes in account those comments as weak named parameters ? :(
</pre>
      </blockquote>
      <pre>...because for this purpose, clang-tidy is the *de facto* standa=
rd.</pre></blockquote></div></blockquote><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><bloc=
kquote type=3D"cite">
    </blockquote>
    weak named parameters allow reorder and omission of named parameters
    having a default value.<br>
    AFAIK clang-tidy cannot do that.<br>
    <br>
    For me weak named parameters are parameter that have a specific name
    that is part of the public interface of the function (the current
    ones are not weak named parameters) and that can be used by the
    caller to name the argument but that doesn&#39;t change his signature,
    nor the ABI. These functions can be called without the use of the
    names, following the current rules. parameter names could be used to
    select the good overload, but are not part of the signature and so
    we can not forward weak parameter names, but it can forward named
    parameters when we don&#39;t use his name (as we do now).<br></div></bl=
ockquote><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div b=
gcolor=3D"#FFFFFF" text=3D"#000000">
    <br>
    Maybe you want forwarding, but then the name of the named parameter
    need to be part of the signature. IMO, this is solved with tag
    dispatching and weak named parameters.<br></div></blockquote><div><br><=
/div><div>Forwarding is 100% doable as forwarding references are inline and=
 the compiler can see-through.=C2=A0</div><div>What is not possible is forw=
ard-as-tuple and async type of forwarding, where forwarding references are =
not used all the way down.</div><div><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <blockquote type=3D"cite">
      <pre></pre>
      <blockquote type=3D"cite">
        <pre>Having weak named parameters in the standard will ensure that =
everybody
uses the same syntax :)
</pre>
      </blockquote>
      <pre>Why do you think that a de jure standard will be more closely fo=
llowed
than a de facto standard? In fact, considering that I can use the de
facto standard &quot;weak arguments&quot; *in C++98*, whereas the hypotheti=
cal de
jure standard I can only follow if all my compilers support C++20 or
C++2x, I would rather expect the opposite...

</pre>
    </blockquote>
    <p><font size=3D"+1">Sorry, but we are not talking here about C++98,
        but a possible feature for the future standard.</font></p>
    <p><font size=3D"+1">And yes, I&#39;m sure that having them in the
        standard would make them used a lot (as they are currently in
        other languages) than what we can get with C comments and
        clang-tidy.<br>
      </font></p>
    <p><font size=3D"+1"><br>
      </font></p>
    <p><font size=3D"+1">Vicente</font><br>
    </p>
  </div>

</blockquote></div>

<p></p>

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

------=_Part_527_859370224.1535174632248--

------=_Part_526_1500327205.1535174632248--

.

This is a multi-part message in MIME format.
--------------0A950561046D356B524C2C52
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 25/08/2018 =C3=A0 07:23, mihailnajdenov@gmail.com a =C3=A9crit=C2=A0:
>
>
> On Saturday, August 25, 2018 at 2:11:04 AM UTC+3, Vicente J. Botet=20
> Escriba wrote:
>
>     Le 24/08/2018 =C3=A0 19:39, Matthew Woehlke a =C3=A9crit=C2=A0:
>>     On 2018-08-24 13:26, Vicente J. Botet Escriba wrote:
>>>     Le 24/08/2018 =C3=A0 17:28, Matthew Woehlke a =C3=A9crit=C2=A0:
>>>>     On 2018-08-24 02:31, David Brown wrote:
>>>>>     We could get /my/ part done without worrying about forwarding...
>>>>     As others have noted, if we don't even worry about forwarding, I j=
ust
>>>>     can't see where what you are proposing is a sufficient improvement=
 over
>>>>     what clang-tidy *already does* to be worth committee time...
>>>>
>>>     How would you ensure that any developer uses the same syntax so tha=
t
>>>     clang-tidy takes in account those comments as weak named parameters=
 ? :(
>>     ...because for this purpose, clang-tidy is the *de facto* standard.
>
BTW, I have not see a clang tidy checker that manage with this; Do you=20
have a pointer?
>
>     weak named parameters allow reorder and omission of named
>     parameters having a default value.
>     AFAIK clang-tidy cannot do that.
>
>     For me weak named parameters are parameter that have a specific
>     name that is part of the public interface of the function (the
>     current ones are not weak named parameters) and that can be used
>     by the caller to name the argument but that doesn't change his
>     signature, nor the ABI. These functions can be called without the
>     use of the names, following the current rules. parameter names
>     could be used to select the good overload, but are not part of the
>     signature and so we can not forward weak parameter names, but it
>     can forward named parameters when we don't use his name (as we do
>     now).
>
>
>
>     Maybe you want forwarding, but then the name of the named
>     parameter need to be part of the signature. IMO, this is solved
>     with tag dispatching and weak named parameters.
>
>
> Forwarding is 100% doable as forwarding references are inline and the=20
> compiler can see-through.
> What is not possible is forward-as-tuple and async type of forwarding,=20
> where forwarding references are not used all the way down.
>
It is not important if compilers (the language) could manage with=20
forwarding weak named parameters if the asynchronous case can not be=20
managed, isn't it?

Vicente

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/979be82f-a6e6-17f4-f0f8-732b6791ffec%40wanadoo.f=
r.

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

<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 25/08/2018 =C3=A0 07:23,
      <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:mihailnajdenov@g=
mail.com">mihailnajdenov@gmail.com</a> a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"
      cite=3D"mid:293fe1d0-2692-4998-b7d2-f699522c2dec@isocpp.org">
      <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf=
-8">
      <div dir=3D"ltr"><br>
        <br>
        On Saturday, August 25, 2018 at 2:11:04 AM UTC+3, Vicente J.
        Botet Escriba wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
            <div>Le 24/08/2018 =C3=A0 19:39, Matthew Woehlke a =C3=A9crit=
=C2=A0:<br>
            </div>
            <blockquote type=3D"cite">
              <pre>On 2018-08-24 13:26, Vicente J. Botet Escriba wrote:
</pre>
              <blockquote type=3D"cite">
                <pre>Le 24/08/2018 =C3=A0 17:28, Matthew Woehlke a =C3=A9cr=
it=C2=A0:
</pre>
                <blockquote type=3D"cite">
                  <pre>On 2018-08-24 02:31, David Brown wrote:
</pre>
                  <blockquote type=3D"cite">
                    <pre>We could get /my/ part done without worrying about=
 forwarding...
</pre>
                  </blockquote>
                  <pre>As others have noted, if we don't even worry about f=
orwarding, I just
can't see where what you are proposing is a sufficient improvement over
what clang-tidy *already does* to be worth committee time...

</pre>
                </blockquote>
                <pre>How would you ensure that any developer uses the same =
syntax so that
clang-tidy takes in account those comments as weak named parameters ? :(
</pre>
              </blockquote>
              <pre>...because for this purpose, clang-tidy is the *de facto=
* standard.</pre>
            </blockquote>
          </div>
        </blockquote>
        <div>=C2=A0</div>
      </div>
    </blockquote>
    BTW, I have not see a clang tidy checker that manage with this; Do
    you have a pointer?<br>
    <blockquote type=3D"cite"
      cite=3D"mid:293fe1d0-2692-4998-b7d2-f699522c2dec@isocpp.org">
      <div dir=3D"ltr">
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
            <blockquote type=3D"cite"> </blockquote>
            weak named parameters allow reorder and omission of named
            parameters having a default value.<br>
            AFAIK clang-tidy cannot do that.<br>
            <br>
            For me weak named parameters are parameter that have a
            specific name that is part of the public interface of the
            function (the current ones are not weak named parameters)
            and that can be used by the caller to name the argument but
            that doesn't change his signature, nor the ABI. These
            functions can be called without the use of the names,
            following the current rules. parameter names could be used
            to select the good overload, but are not part of the
            signature and so we can not forward weak parameter names,
            but it can forward named parameters when we don't use his
            name (as we do now).<br>
          </div>
        </blockquote>
        <div><br>
        </div>
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000"> <br>
            Maybe you want forwarding, but then the name of the named
            parameter need to be part of the signature. IMO, this is
            solved with tag dispatching and weak named parameters.<br>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>Forwarding is 100% doable as forwarding references are
          inline and the compiler can see-through.=C2=A0</div>
        <div>What is not possible is forward-as-tuple and async type of
          forwarding, where forwarding references are not used all the
          way down.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    It is not important if compilers (the language) could manage with
    forwarding weak named parameters if the asynchronous case can not be
    managed, isn't it?<br>
    <br>
    Vicente<br>
  </body>
</html>

<p></p>

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

--------------0A950561046D356B524C2C52--

.

On 16/08/18 19:25, Matthew Woehlke wrote:
> While I don't disagree with that, exactly, I also don't see it as a
> compelling benefit. For me, named arguments are *primarily* about fixing
> the problem of needing extremely flexible functions (read: large number
> of parameters and/or large number of overloads) of which any *one* user
> is only going to care about a small slice of the total surface area.

These functions are extremely dubious and I doubt it is a Good Thing to
support them further. In these cases, configuration structures with
default values and named constructor idioms make much more sense IMHO.

> I
> only care about argument order to the extent it is useful in solving
> that problem. Thus, for me, *the* killer features are being able to
> specify one parameter in the middle of a list of defaulted parameters,
> and/or to overload on parameter names.

This is a useful feature even with 3 or 4 parameters, and no overloads.

However, that it is at least partially achievable using std::optional's
and having the function set the nullopt's to default values.

Eyal

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/19cc8816-ee6d-1f1b-c493-f424d39ddc3e%40technion.ac.il.

.

Given your described use of designated initializers, how would you feel
about something like following proposal:

1. Functions with named parameter support must be marked with a
[[named-param]] attribute.
2. Such marked functions get an anonymous struct defined for their
parameters, just like FooParams in your example, and what actually gets
compiled is

void foo(int, int);
void foo(_some_autogenerated_foo_params_struct_identifier);

3. Tie thing up syntax-wise so that you can write foo(.x = 5, .y = 12),
and also have some sort of syntactic solution for using &foo .


Not that I had a dog in this fight, I'm just trying to help map out some
possibilities.


On 16/08/18 18:42, Nicol Bolas wrote:
> This even works through forwarding, but it does require you to
> explicitly name the `FoosParams` type at the call site:
>
> std::function<void(FoosParams)> foofunctor = &foo;
> foofunctor(FoosParams{.x = 5, .y = 12});
>
> Now of course, this way of handling named parameters causes a bunch of
> warts. Anytime you want to create such a function, you have to
> explicitly create a type for it. Forwarding, or any usage of the
> signature, requires using that typename. And while you can forward them,
> the forwarding function only sees it as a single struct, not a set of
> values. This makes doing things like transforming parameters impossible
> (well, without reflection, and even then, your code would have to assume
> that the single struct is a set of "parameters" to be transformed). And
> so forth.
>
> But overall, it gets the job done without language changes. It's not
> clean, so it won't be used universally or anything, but it works well
> enough that it can be used in places where the ambiguity of a call is
> worse than having to pass a struct

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/60449422-b543-4949-557a-96435c1c2926%40technion.ac.il.

.

------=_Part_732_1500839161.1535325697642
Content-Type: multipart/alternative;
 boundary="----=_Part_733_1312985192.1535325697642"

------=_Part_733_1312985192.1535325697642
Content-Type: text/plain; charset="UTF-8"



On Sunday, August 26, 2018 at 10:35:25 PM UTC+2, Eyal Rozenberg wrote:
>
> Given your described use of designated initializers, how would you feel
> about something like following proposal:
>
> 1. Functions with named parameter support must be marked with a
> [[named-param]] attribute.
>

Attribute should be ignorable, then you should use keyword to change
behavior of program. Otherwise `f(.x = 5)` can't compile when attribute is
not recognized.

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

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

<div dir=3D"ltr"><br><br>On Sunday, August 26, 2018 at 10:35:25 PM UTC+2, E=
yal Rozenberg wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Given your=
 described use of designated initializers, how would you feel=20
<br>about something like following proposal:
<br>
<br>1. Functions with named parameter support must be marked with a=20
<br>[[named-param]] attribute.
<br></blockquote><div>=C2=A0</div><div>Attribute should be ignorable, then =
you should use keyword to change behavior of program. Otherwise `f(.x =3D 5=
)` can&#39;t compile when attribute is not recognized.<br></div></div>

<p></p>

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

------=_Part_733_1312985192.1535325697642--

------=_Part_732_1500839161.1535325697642--

.

On 2018-08-25 01:23, mihailnajdenov@gmail.com wrote:
> On Saturday, August 25, 2018 at 2:11:04 AM UTC+3, Vicente J. Botet Escrib=
a=20
> wrote:
>> Maybe you want forwarding, but then the name of the named parameter need=
=20
>> to be part of the signature.
>=20
> Forwarding is 100% doable as forwarding references are inline and the
> compiler can see-through. What is not possible is forward-as-tuple
> and async type of forwarding, where forwarding references are not
> used all the way down.
So, you want this feature to include magic that *rewrites* inline
functions to do something other than what their definition *says* they
do? Yike...

Making names part of the signature solves this much more cleanly, *and*
it solves forwarding-as-tuple and asynchronous dispatch. (Well, I
*think* it solves the latter; it depends on how that dispatch is coded,
e.g. if it is pure template. If it has run-time argument resolution,
that might need to be made aware of named parameters to work,
*especially* if it needs to support skipping and reordering. But it
*can* be made to work, because all the information is available.)

>> IMO, this is solved with tag dispatching and weak named
>> parameters.
How?

  void complicated(int .a=3D1, int .b=3D42, int .c=3D10,
                   double .x=3D0.25, string .s=3D"bar");

  std::invoke(complicated, .b=3D7);

How do you express this with tag dispatching? How do you support
argument skipping (and maybe reordering) in the presence of forwarding
with tag dispatching?

>> Le 24/08/2018 =C3=A0 19:39, Matthew Woehlke a =C3=A9crit :
>>> Why do you think that a de jure standard will be more closely followed
>>> than a de facto standard? In fact, considering that I can use the de
>>> facto standard "weak arguments" *in C++98*, whereas the hypothetical de
>>> jure standard I can only follow if all my compilers support C++20 or
>>> C++2x, I would rather expect the opposite...
>>
>> Sorry, but we are not talking here about C++98, but a possible feature f=
or=20
>> the future standard.

You miss the point. What makes this *hypothetical* feature, which can't
be practically adopted for many years, more likely to be useful than one
that *already exists* and can be used even in C++98 code?

--=20
Matthew

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/260de1d5-b1c3-ab4c-11c1-121eec377a22%40gmail.com=
..

.

------=_Part_1041_269740472.1535382768027
Content-Type: text/plain; charset="UTF-8"

See https://clang.llvm.org/extra/clang-tidy/checks/bugprone-argument-comment.html for the clang-tidy 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fe78a713-1333-4b2c-900f-0e7ffed9c6f1%40isocpp.org.

------=_Part_1041_269740472.1535382768027--

.

On 2018-08-26 16:35, Eyal Rozenberg wrote:
> Given your described use of designated initializers, how would you feel
> about something like following proposal:
>
> 1. Functions with named parameter support must be marked with a
> [[named-param]] attribute.
> 2. Such marked functions get an anonymous struct defined for their
> parameters, just like FooParams in your example, and what actually gets
> compiled is
>
> void foo(int, int);
> void foo(_some_autogenerated_foo_params_struct_identifier);
>
> 3. Tie thing up syntax-wise so that you can write foo(.x = 5, .y = 12),
> and also have some sort of syntactic solution for using &foo .

Besides that the attribute changes the meaning of the code (and we've
generally frowned on that), I don't see how it could possibly work with
forwarding.

I think the names need to be part of the type of *individual* arguments,
not the argument list as a whole. (Plus, this allows mixing named and
positional arguments, which designated initializers don't, but is
probably a feature we want here...)

--
Matthew

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

.

--000000000000520cae05746cfd5f
Content-Type: text/plain; charset="UTF-8"

On Mon, Aug 27, 2018 at 6:14 PM Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2018-08-26 16:35, Eyal Rozenberg wrote:
> > Given your described use of designated initializers, how would you feel
> > about something like following proposal:
> >
> > 1. Functions with named parameter support must be marked with a
> > [[named-param]] attribute.
> > 2. Such marked functions get an anonymous struct defined for their
> > parameters, just like FooParams in your example, and what actually gets
> > compiled is
> >
> > void foo(int, int);
> > void foo(_some_autogenerated_foo_params_struct_identifier);
> >
> > 3. Tie thing up syntax-wise so that you can write foo(.x = 5, .y = 12),
> > and also have some sort of syntactic solution for using &foo .
>
> Besides that the attribute changes the meaning of the code (and we've
> generally frowned on that), I don't see how it could possibly work with
> forwarding.
>
> I think the names need to be part of the type of *individual* arguments,
> not the argument list as a whole. (Plus, this allows mixing named and
> positional arguments, which designated initializers don't, but is
> probably a feature we want here...)
>

How do you envision optional argument would work if we have only
named-arguments-part-of-the-type?
It's an honest question, because I am curious to know all options. I
personally have one raw idea, but I wonder if you have figured it out
already.

If you don't have an idea how to make overloading names optional as well,
then you will also need weak names to make the other half of the community
happy
(more like, not making them mad because of mandatory names).


> --
> Matthew
>
> --
> 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/MbDT0vsA2j0/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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ecd10435-ac8d-1f59-8c73-cd3426eb0c47%40gmail.com
> .
>

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

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

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon=
, Aug 27, 2018 at 6:14 PM Matthew Woehlke &lt;<a href=3D"mailto:mwoehlke.fl=
oss@gmail.com">mwoehlke.floss@gmail.com</a>&gt; wrote:<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;b=
order-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:s=
olid">On 2018-08-26 16:35, Eyal Rozenberg wrote:<br>
&gt; Given your described use of designated initializers, how would you fee=
l<br>
&gt; about something like following proposal:<br>
&gt; <br>
&gt; 1. Functions with named parameter support must be marked with a<br>
&gt; [[named-param]] attribute.<br>
&gt; 2. Such marked functions get an anonymous struct defined for their<br>
&gt; parameters, just like FooParams in your example, and what actually get=
s<br>
&gt; compiled is<br>
&gt; <br>
&gt; void foo(int, int);<br>
&gt; void foo(_some_autogenerated_foo_params_struct_identifier);<br>
&gt; <br>
&gt; 3. Tie thing up syntax-wise so that you can write foo(.x =3D 5, .y =3D=
 12),<br>
&gt; and also have some sort of syntactic solution for using &amp;foo .<br>
<br>
Besides that the attribute changes the meaning of the code (and we&#39;ve<b=
r>
generally frowned on that), I don&#39;t see how it could possibly work with=
<br>
forwarding.<br>
<br>
I think the names need to be part of the type of *individual* arguments,<br=
>
not the argument list as a whole. (Plus, this allows mixing named and<br>
positional arguments, which designated initializers don&#39;t, but is<br>
probably a feature we want here...)<br></blockquote><div><br></div><div>How=
 do you envision optional argument would work if we have only named-argumen=
ts-part-of-the-type?=C2=A0</div><div>It&#39;s an honest question, because I=
 am curious to know all options.=C2=A0<span style=3D"font:400 13.33px/19.99=
px Arial,Helvetica,sans-serif;text-align:left;color:rgb(34,34,34);text-tran=
sform:none;text-indent:0px;letter-spacing:normal;text-decoration:none;word-=
spacing:0px;display:inline;white-space:normal;font-size-adjust:none;font-st=
retch:100%;float:none;background-color:transparent">I personally have one r=
aw idea, but I wonder if you have figured it out already.=C2=A0</span></div=
><div><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><br></div=
><div>If you don&#39;t have an idea how to make overloading names optional =
as well, then you will also need weak names to make the other half of the c=
ommunity happy=C2=A0</div><div>(more like, not making them mad because of m=
andatory names).</div><div><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,20=
4,204);border-left-width:1px;border-left-style:solid">
<br>
-- <br>
Matthew<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/MbDT0vsA2j0/unsubscribe" target=3D"_blan=
k" rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/MbDT0vsA2j0/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ecd10435-ac8d-1f59-8c73-cd3426eb0c47%=
40gmail.com" target=3D"_blank" rel=3D"noreferrer">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/ecd10435-ac8d-1f59-8c73-cd3426eb0c47%40=
gmail.com</a>.<br>
</blockquote></div></div>

<p></p>

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

--000000000000520cae05746cfd5f--

.

On 2018-08-27 12:12, =D0=9C=D0=B8=D1=85=D0=B0=D0=B8=D0=BB =D0=9D=D0=B0=D0=
=B9=D0=B4=D0=B5=D0=BD=D0=BE=D0=B2 wrote:
> How do you envision optional argument would work if we have only
> named-arguments-part-of-the-type?

....because named arguments are a special, "magic" type. Basically, when
the compiler sees that a function call has a named argument, it alters
the overload rules, so that the named argument doesn't have to match the
*current* argument, but *any* argument (excluding already matched
arguments).

I think the "only" in your question may be a faulty assumption.

I've started writing up my thoughts as a formal proposal (though a
preliminary one, i.e. a long way from actual wording). Hopefully one of
these days I'll get it in a state that I feel ready to post...

--=20
Matthew

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

.

FWIW=20

IMHO Named Parameters are curing a symptom of primitive obsession where str=
ongly typed Whole Value Pattern application would be the better solution.=
=20

Peter

sent from a mobile device.
Prof. Peter Sommerlad
peter.Sommerlad@hsr.ch
+41-79-432 23 32

> On 27 Aug 2018, at 18:22, Matthew Woehlke <mwoehlke.floss@gmail.com> wrot=
e:
>=20
>> On 2018-08-27 12:12, =D0=9C=D0=B8=D1=85=D0=B0=D0=B8=D0=BB =D0=9D=D0=B0=
=D0=B9=D0=B4=D0=B5=D0=BD=D0=BE=D0=B2 wrote:
>> How do you envision optional argument would work if we have only
>> named-arguments-part-of-the-type?
>=20
> ...because named arguments are a special, "magic" type. Basically, when
> the compiler sees that a function call has a named argument, it alters
> the overload rules, so that the named argument doesn't have to match the
> *current* argument, but *any* argument (excluding already matched
> arguments).
>=20
> I think the "only" in your question may be a faulty assumption.
>=20
> I've started writing up my thoughts as a formal proposal (though a
> preliminary one, i.e. a long way from actual wording). Hopefully one of
> these days I'll get it in a state that I feel ready to post...
>=20
> --=20
> Matthew
>=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=
 email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/3e50834d-2e56-392f-fe30-8c24769d7647%40gmail.c=
om.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/0C3F5A99-57A2-450B-8FBC-8F1F514EF7B8%40hsr.ch.

.

------=_Part_1072_563073624.1535388985389
Content-Type: multipart/alternative;
 boundary="----=_Part_1073_816653957.1535388985389"

------=_Part_1073_816653957.1535388985389
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

This is repost, the message did not show up

On Monday, August 27, 2018 at 7:22:44 PM UTC+3, Matthew Woehlke wrote:
>
> On 2018-08-27 12:12, =D0=9C=D0=B8=D1=85=D0=B0=D0=B8=D0=BB =D0=9D=D0=B0=D0=
=B9=D0=B4=D0=B5=D0=BD=D0=BE=D0=B2 wrote:=20
> > How do you envision optional argument would work if we have only=20
> > named-arguments-part-of-the-type?=20
>
> ...because named arguments are a special, "magic" type. Basically, when=
=20
> the compiler sees that a function call has a named argument, it alters=20
> the overload rules, so that the named argument doesn't have to match the=
=20
> *current* argument, but *any* argument (excluding already matched=20
> arguments).=20
>

Will the arguments you envision be able to be marked as optional or not?

Because this "optionality" must travel through the type system as well, to=
=20
be able to work with async/forward_as_typle
This is not the case of "simple" strong names, which are "simply" mandatory=
=20
and "are just a different type".=20

=20

>
> I think the "only" in your question may be a faulty assumption.=20
>
> I've started writing up my thoughts as a formal proposal (though a=20
> preliminary one, i.e. a long way from actual wording). Hopefully one of=
=20
> these days I'll get it in a state that I feel ready to post...=20
>
> --=20
> Matthew=20
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/44b180b7-9c2f-48fe-9cf5-5b803b45f460%40isocpp.or=
g.

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

<div dir=3D"ltr">This is repost, the message did not show up<br><br>On Mond=
ay, August 27, 2018 at 7:22:44 PM UTC+3, Matthew Woehlke wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;">On 2018-08-27 12:12, =D0=9C=D0=B8=D1=85=D0=
=B0=D0=B8=D0=BB =D0=9D=D0=B0=D0=B9=D0=B4=D0=B5=D0=BD=D0=BE=D0=B2 wrote:
<br>&gt; How do you envision optional argument would work if we have only
<br>&gt; named-arguments-part-of-the-<wbr>type?
<br>
<br>...because named arguments are a special, &quot;magic&quot; type. Basic=
ally, when
<br>the compiler sees that a function call has a named argument, it alters
<br>the overload rules, so that the named argument doesn&#39;t have to matc=
h the
<br>*current* argument, but *any* argument (excluding already matched
<br>arguments).
<br></blockquote><div><br></div><div><div style=3D"background-color: transp=
arent; color: rgb(34, 34, 34); font-family: Arial,Helvetica,sans-serif; fon=
t-size: 13.33px; font-size-adjust: none; font-stretch: 100%; font-style: no=
rmal; font-variant: normal; font-weight: 400; letter-spacing: normal; line-=
height: 19.99px; orphans: 2; overflow: visible; text-align: left; text-deco=
ration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-w=
idth: 0px; white-space: normal; word-spacing: 0px;">Will the arguments you =
envision be able to be marked as optional or not?</div><div style=3D"backgr=
ound-color: transparent; color: rgb(34, 34, 34); font-family: Arial,Helveti=
ca,sans-serif; font-size: 13.33px; font-size-adjust: none; font-stretch: 10=
0%; font-style: normal; font-variant: normal; font-weight: 400; letter-spac=
ing: normal; line-height: 19.99px; orphans: 2; overflow: visible; text-alig=
n: left; text-decoration: none; text-indent: 0px; text-transform: none; -we=
bkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"><br s=
tyle=3D"font-family: Arial,Helvetica,sans-serif; font-size: 13.33px; font-s=
ize-adjust: none; font-stretch: 100%; font-style: normal; font-variant: nor=
mal; font-weight: 400; line-height: 19.99px; overflow: visible;"></div><div=
 style=3D"background-color: transparent; color: rgb(34, 34, 34); font-famil=
y: Arial,Helvetica,sans-serif; font-size: 13.33px; font-size-adjust: none; =
font-stretch: 100%; font-style: normal; font-variant: normal; font-weight: =
400; letter-spacing: normal; line-height: 19.99px; orphans: 2; overflow: vi=
sible; text-align: left; text-decoration: none; text-indent: 0px; text-tran=
sform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spac=
ing: 0px;">Because this &quot;optionality&quot; must travel through the typ=
e system as well, to be able to work with async/forward_as_typle</div><div =
style=3D"background-color: transparent; color: rgb(34, 34, 34); font-family=
: Arial,Helvetica,sans-serif; font-size: 13.33px; font-size-adjust: none; f=
ont-stretch: 100%; font-style: normal; font-variant: normal; font-weight: 4=
00; letter-spacing: normal; line-height: 19.99px; orphans: 2; overflow: vis=
ible; text-align: left; text-decoration: none; text-indent: 0px; text-trans=
form: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spaci=
ng: 0px;">This is not the case of &quot;simple&quot; strong names, which ar=
e &quot;simply&quot; mandatory and &quot;are just a different type&quot;.=
=C2=A0</div><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><br=
></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>I think the &quot;only&quot; in your question may be a faulty assumptio=
n.
<br>
<br>I&#39;ve started writing up my thoughts as a formal proposal (though a
<br>preliminary one, i.e. a long way from actual wording). Hopefully one of
<br>these days I&#39;ll get it in a state that I feel ready to post...
<br>
<br>--=20
<br>Matthew
<br></blockquote></div>

<p></p>

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

------=_Part_1073_816653957.1535388985389--

------=_Part_1072_563073624.1535388985389--

.

On 2018-08-27 12:56, mihailnajdenov@gmail.com wrote:
> On Monday, August 27, 2018 at 7:22:44 PM UTC+3, Matthew Woehlke wrote:
>> On 2018-08-27 12:12, =D0=9C=D0=B8=D1=85=D0=B0=D0=B8=D0=BB =D0=9D=D0=B0=
=D0=B9=D0=B4=D0=B5=D0=BD=D0=BE=D0=B2 wrote:=20
>>> How do you envision optional argument would work if we have only=20
>>> named-arguments-part-of-the-type?=20
>>
>> ...because named arguments are a special, "magic" type. Basically, when=
=20
>> the compiler sees that a function call has a named argument, it alters=
=20
>> the overload rules, so that the named argument doesn't have to match the=
=20
>> *current* argument, but *any* argument (excluding already matched=20
>> arguments).=20
>=20
> Will the arguments you envision be able to be marked as optional or not?

They can be defaulted:

  void foo(int .x, int .y=3D5, int .z=3D12);
  foo(2, .z=3D7); // okay, calls foo(2, 5, 7)

> Because this "optionality" must travel through the type system as well, t=
o=20
> be able to work with async/forward_as_typle
> This is not the case of "simple" strong names, which are "simply" mandato=
ry=20
> and "are just a different type".=20

I don't think that's the case:

  void invoke(Func f, tuple<int, named<int, "z">> args)
  {
    f(get<0>(args), get<1>(args));
  }
  invoke(foo, make_tuple(2, .z=3D7)); // okay, calls foo(2, 5, 7)

(Obviously, `invoke` is really a template, but I have shown the
instantiation that is called in the example.)

This will work with reordering also (if we allow it). I don't need to
know anything about optionality when I am forwarding arguments, just so
long as when I try to call the actual function, that succeeds with the
arguments I actually provided. Basically, by tying the name to each
argument, it passes through forwarding transparently, so that when I try
to call the "actual" function, the arguments the compiler sees look the
same as if the forwarding layer(s) weren't there.

....unless you're talking about something totally different when you talk
about "optionality"?

--=20
Matthew

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/fd3cd9e2-26fc-7770-0f82-182abd75134d%40gmail.com=
..

.

------=_Part_1105_994958673.1535394127977
Content-Type: multipart/alternative;
 boundary="----=_Part_1106_139929233.1535394127978"

------=_Part_1106_139929233.1535394127978
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Monday, August 27, 2018 at 8:29:49 PM UTC+3, Matthew Woehlke wrote:
>
> On 2018-08-27 12:56, mihailn...@gmail.com <javascript:> wrote:=20
> > On Monday, August 27, 2018 at 7:22:44 PM UTC+3, Matthew Woehlke wrote:=
=20
> >> On 2018-08-27 12:12, =D0=9C=D0=B8=D1=85=D0=B0=D0=B8=D0=BB =D0=9D=D0=B0=
=D0=B9=D0=B4=D0=B5=D0=BD=D0=BE=D0=B2 wrote:=20
> >>> How do you envision optional argument would work if we have only=20
> >>> named-arguments-part-of-the-type?=20
> >>=20
> >> ...because named arguments are a special, "magic" type. Basically, whe=
n=20
> >> the compiler sees that a function call has a named argument, it alters=
=20
> >> the overload rules, so that the named argument doesn't have to match=
=20
> the=20
> >> *current* argument, but *any* argument (excluding already matched=20
> >> arguments).=20
> >=20
> > Will the arguments you envision be able to be marked as optional or not=
?=20
>
> They can be defaulted:=20
>
>   void foo(int .x, int .y=3D5, int .z=3D12);=20
>   foo(2, .z=3D7); // okay, calls foo(2, 5, 7)=20
>

If foo(2, .z=3D7) =3D=3D foo(2, 5, 7) then how can it overload based on nam=
e?=20
Where is the name in the final call?

Or you mean foo(2, .y=3D5, .z=3D7) a.k.a. something like foo(2, named<5, 'y=
'>,=20
named<7, 'z'>) ?


By optionality I meant that after all template transformation and behind a=
=20
TU boundary and whatever the call must work with both non-named-types AND=
=20
with named ones IFF a name is optional .

Strong and weak names are split at that boundary for a reason - either=20
named-type (different type, period, like magic_pair<7, 'x'>, if you don't=
=20
supply an magic_pair<7, 'x'> you fail),
 *or* standard type 7 for the weak ones and names are just compiler-only=20
handshakes.

Your magic type, if is it to be aware the type system, must have a type=20
that accepts *either* magic_pair<7, 'x'> *or* naked type int.
The type system must be able to create tuples (or members or whatnot) of=20
that type as well for delayed invocation.=20

On the declaration such arguments, must be marked as well, so the user can=
=20
now, which names are optional and can be omitted (not "skipped" but be=20
either "positional" or "named").=20


> > Because this "optionality" must travel through the type system as well,=
=20
> to=20
> > be able to work with async/forward_as_typle=20
> > This is not the case of "simple" strong names, which are "simply"=20
> mandatory=20
> > and "are just a different type".=20
>
> I don't think that's the case:=20
>
>   void invoke(Func f, tuple<int, named<int, "z">> args)=20
>   {=20
>     f(get<0>(args), get<1>(args));=20
>   }=20
>   invoke(foo, make_tuple(2, .z=3D7)); // okay, calls foo(2, 5, 7)=20
>
> (Obviously, `invoke` is really a template, but I have shown the=20
> instantiation that is called in the example.)=20
>
> This will work with reordering also (if we allow it). I don't need to=20
> know anything about optionality when I am forwarding arguments, just so=
=20
> long as when I try to call the actual function, that succeeds with the=20
> arguments I actually provided. Basically, by tying the name to each=20
> argument, it passes through forwarding transparently, so that when I try=
=20
> to call the "actual" function, the arguments the compiler sees look the=
=20
> same as if the forwarding layer(s) weren't there.=20
>
> ...unless you're talking about something totally different when you talk=
=20
> about "optionality"?=20
>
> --=20
> Matthew=20
>

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

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

<div dir=3D"ltr"><br><br>On Monday, August 27, 2018 at 8:29:49 PM UTC+3, Ma=
tthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2018-08=
-27 12:56, <a onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;=
" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"javasc=
ript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"Yi22O9EB=
AgAJ">mihailn...@gmail.com</a> wrote:
<br>&gt; On Monday, August 27, 2018 at 7:22:44 PM UTC+3, Matthew Woehlke wr=
ote:
<br>&gt;&gt; On 2018-08-27 12:12, =D0=9C=D0=B8=D1=85=D0=B0=D0=B8=D0=BB =D0=
=9D=D0=B0=D0=B9=D0=B4=D0=B5=D0=BD=D0=BE=D0=B2 wrote:=20
<br>&gt;&gt;&gt; How do you envision optional argument would work if we hav=
e only=20
<br>&gt;&gt;&gt; named-arguments-part-of-the-<wbr>type?=20
<br>&gt;&gt;
<br>&gt;&gt; ...because named arguments are a special, &quot;magic&quot; ty=
pe. Basically, when=20
<br>&gt;&gt; the compiler sees that a function call has a named argument, i=
t alters=20
<br>&gt;&gt; the overload rules, so that the named argument doesn&#39;t hav=
e to match the=20
<br>&gt;&gt; *current* argument, but *any* argument (excluding already matc=
hed=20
<br>&gt;&gt; arguments).=20
<br>&gt;=20
<br>&gt; Will the arguments you envision be able to be marked as optional o=
r not?
<br>
<br>They can be defaulted:
<br>
<br>=C2=A0 void foo(int .x, int .y=3D5, int .z=3D12);
<br>=C2=A0 foo(2, .z=3D7); // okay, calls foo(2, 5, 7)
<br></blockquote><div><br></div><div>If=C2=A0<span style=3D"display: inline=
 !important; float: none; background-color: transparent; color: rgb(34, 34,=
 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font=
-size: 13px; font-style: normal; font-variant: normal; font-weight: 400; le=
tter-spacing: normal; orphans: 2; text-align: left; text-decoration: none; =
text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; whi=
te-space: normal; word-spacing: 0px;">foo(2, .z=3D7) =3D=3D=C2=A0<span styl=
e=3D"display: inline !important; float: none; background-color: transparent=
; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&qu=
ot;,sans-serif; font-size: 13px; font-style: normal; font-variant: normal; =
font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; tex=
t-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-st=
roke-width: 0px; white-space: normal; word-spacing: 0px;">foo(2, 5, 7) then=
 how can it overload based on name? Where is the name in the final call?</s=
pan></span></div><div><span style=3D"display: inline !important; float: non=
e; background-color: transparent; color: rgb(34, 34, 34); font-family: &quo=
t;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style=
: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; o=
rphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-=
transform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-=
spacing: 0px;"><span style=3D"display: inline !important; float: none; back=
ground-color: transparent; color: rgb(34, 34, 34); font-family: &quot;Arial=
&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: norma=
l; font-variant: normal; font-weight: 400; letter-spacing: normal; orphans:=
 2; text-align: left; text-decoration: none; text-indent: 0px; text-transfo=
rm: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing=
: 0px;"><br></span></span></div><div><span style=3D"display: inline !import=
ant; float: none; background-color: transparent; color: rgb(34, 34, 34); fo=
nt-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 1=
3px; font-style: normal; font-variant: normal; font-weight: 400; letter-spa=
cing: normal; orphans: 2; text-align: left; text-decoration: none; text-ind=
ent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space=
: normal; word-spacing: 0px;"><span style=3D"display: inline !important; fl=
oat: none; background-color: transparent; color: rgb(34, 34, 34); font-fami=
ly: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; fo=
nt-style: normal; font-variant: normal; font-weight: 400; letter-spacing: n=
ormal; orphans: 2; text-align: left; text-decoration: none; text-indent: 0p=
x; text-transform: none; -webkit-text-stroke-width: 0px; white-space: norma=
l; word-spacing: 0px;">Or you mean=C2=A0<span style=3D"background-color: tr=
ansparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none;=
 border-bottom-width: 0px; border-image-outset: 0; border-image-repeat: str=
etch; border-image-slice: 100%; border-image-source: none; border-image-wid=
th: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; border-=
left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: n=
one; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top=
-style: none; border-top-width: 0px; color: rgb(34, 34, 34); display: inlin=
e; float: none; font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&=
amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: no=
rmal; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-=
left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: =
0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: l=
eft; text-decoration: none; text-indent: 0px; text-transform: none; -webkit=
-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">foo(2, .y=
=3D5, .z=3D7) a.k.a. something like <span style=3D"background-color: transp=
arent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; bor=
der-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stretch=
; border-image-slice: 100%; border-image-source: none; border-image-width: =
1; border-left-color: rgb(34, 34, 34); border-left-style: none; border-left=
-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: none;=
 border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-sty=
le: none; border-top-width: 0px; color: rgb(34, 34, 34); display: inline; f=
loat: none; font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;=
quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: normal=
; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-left=
: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px;=
 padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left;=
 text-decoration: none; text-indent: 0px; text-transform: none; -webkit-tex=
t-stroke-width: 0px; white-space: normal; word-spacing: 0px;">foo(2, <span =
style=3D"display: inline !important; float: none; background-color: transpa=
rent; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetic=
a&quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: norm=
al; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left;=
 text-decoration: none; text-indent: 0px; text-transform: none; -webkit-tex=
t-stroke-width: 0px; white-space: normal; word-spacing: 0px;">named&lt;5, &=
#39;y&#39;&gt;</span>, named&lt;7, &#39;z&#39;&gt;) </span>?</span></span><=
/span></div><div><span style=3D"display: inline !important; float: none; ba=
ckground-color: transparent; color: rgb(34, 34, 34); font-family: &quot;Ari=
al&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: nor=
mal; font-variant: normal; font-weight: 400; letter-spacing: normal; orphan=
s: 2; text-align: left; text-decoration: none; text-indent: 0px; text-trans=
form: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spaci=
ng: 0px;"><span style=3D"display: inline !important; float: none; backgroun=
d-color: transparent; color: rgb(34, 34, 34); font-family: &quot;Arial&quot=
;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: normal; fo=
nt-variant: normal; font-weight: 400; letter-spacing: normal; orphans: 2; t=
ext-align: left; text-decoration: none; text-indent: 0px; text-transform: n=
one; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px=
;"><span style=3D"background-color: transparent; border-bottom-color: rgb(3=
4, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-ima=
ge-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; borde=
r-image-source: none; border-image-width: 1; border-left-color: rgb(34, 34,=
 34); border-left-style: none; border-left-width: 0px; border-right-color: =
rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; border-=
top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; =
color: rgb(34, 34, 34); display: inline; float: none; font-family: &amp;quo=
t;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px=
; font-style: normal; font-variant: normal; font-weight: 400; letter-spacin=
g: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-=
top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right=
: 0px; padding-top: 0px; text-align: left; text-decoration: none; text-inde=
nt: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space:=
 normal; word-spacing: 0px;"><br></span></span></span></div><div><span styl=
e=3D"display: inline !important; float: none; background-color: transparent=
; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&qu=
ot;,sans-serif; font-size: 13px; font-style: normal; font-variant: normal; =
font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; tex=
t-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-st=
roke-width: 0px; white-space: normal; word-spacing: 0px;"><span style=3D"di=
splay: inline !important; float: none; background-color: transparent; color=
: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,san=
s-serif; font-size: 13px; font-style: normal; font-variant: normal; font-we=
ight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decor=
ation: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-wi=
dth: 0px; white-space: normal; word-spacing: 0px;"><span style=3D"backgroun=
d-color: transparent; border-bottom-color: rgb(34, 34, 34); border-bottom-s=
tyle: none; border-bottom-width: 0px; border-image-outset: 0; border-image-=
repeat: stretch; border-image-slice: 100%; border-image-source: none; borde=
r-image-width: 1; border-left-color: rgb(34, 34, 34); border-left-style: no=
ne; border-left-width: 0px; border-right-color: rgb(34, 34, 34); border-rig=
ht-style: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34);=
 border-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34); dis=
play: inline; float: none; font-family: &amp;quot;Arial&amp;quot;,&amp;quot=
;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-=
variant: normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0=
px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; paddi=
ng-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; te=
xt-align: left; text-decoration: none; text-indent: 0px; text-transform: no=
ne; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;=
"><br></span></span></span></div><div><span style=3D"display: inline !impor=
tant; float: none; background-color: transparent; color: rgb(34, 34, 34); f=
ont-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: =
13px; font-style: normal; font-variant: normal; font-weight: 400; letter-sp=
acing: normal; orphans: 2; text-align: left; text-decoration: none; text-in=
dent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-spac=
e: normal; word-spacing: 0px;"><span style=3D"display: inline !important; f=
loat: none; background-color: transparent; color: rgb(34, 34, 34); font-fam=
ily: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; f=
ont-style: normal; font-variant: normal; font-weight: 400; letter-spacing: =
normal; orphans: 2; text-align: left; text-decoration: none; text-indent: 0=
px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: norm=
al; word-spacing: 0px;"><span style=3D"background-color: transparent; borde=
r-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-w=
idth: 0px; border-image-outset: 0; border-image-repeat: stretch; border-ima=
ge-slice: 100%; border-image-source: none; border-image-width: 1; border-le=
ft-color: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px;=
 border-right-color: rgb(34, 34, 34); border-right-style: none; border-righ=
t-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; bo=
rder-top-width: 0px; color: rgb(34, 34, 34); display: inline; float: none; =
font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-s=
erif; font-size: 13px; font-style: normal; font-variant: normal; font-weigh=
t: 400; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px; margi=
n-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-lef=
t: 0px; padding-right: 0px; padding-top: 0px; text-align: left; text-decora=
tion: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-wid=
th: 0px; white-space: normal; word-spacing: 0px;">By optionality I meant th=
at after all template transformation and behind a TU boundary and whatever =
the call must work with both non-named-types AND with named ones IFF a name=
 is optional .</span></span></span></div><div><span style=3D"display: inlin=
e !important; float: none; background-color: transparent; color: rgb(34, 34=
, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; fon=
t-size: 13px; font-style: normal; font-variant: normal; font-weight: 400; l=
etter-spacing: normal; orphans: 2; text-align: left; text-decoration: none;=
 text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; wh=
ite-space: normal; word-spacing: 0px;"><span style=3D"display: inline !impo=
rtant; float: none; background-color: transparent; color: rgb(34, 34, 34); =
font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size:=
 13px; font-style: normal; font-variant: normal; font-weight: 400; letter-s=
pacing: normal; orphans: 2; text-align: left; text-decoration: none; text-i=
ndent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-spa=
ce: normal; word-spacing: 0px;"><span style=3D"background-color: transparen=
t; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-=
bottom-width: 0px; border-image-outset: 0; border-image-repeat: stretch; bo=
rder-image-slice: 100%; border-image-source: none; border-image-width: 1; b=
order-left-color: rgb(34, 34, 34); border-left-style: none; border-left-wid=
th: 0px; border-right-color: rgb(34, 34, 34); border-right-style: none; bor=
der-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: =
none; border-top-width: 0px; color: rgb(34, 34, 34); display: inline; float=
: none; font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot=
;,sans-serif; font-size: 13px; font-style: normal; font-variant: normal; fo=
nt-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-left: 0p=
x; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; pad=
ding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; tex=
t-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-st=
roke-width: 0px; white-space: normal; word-spacing: 0px;"><br></span></span=
></span></div><div><span style=3D"display: inline !important; float: none; =
background-color: transparent; color: rgb(34, 34, 34); font-family: &quot;A=
rial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: n=
ormal; font-variant: normal; font-weight: 400; letter-spacing: normal; orph=
ans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-tra=
nsform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spa=
cing: 0px;"><span style=3D"display: inline !important; float: none; backgro=
und-color: transparent; color: rgb(34, 34, 34); font-family: &quot;Arial&qu=
ot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: normal; =
font-variant: normal; font-weight: 400; letter-spacing: normal; orphans: 2;=
 text-align: left; text-decoration: none; text-indent: 0px; text-transform:=
 none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0=
px;"><span style=3D"background-color: transparent; border-bottom-color: rgb=
(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-i=
mage-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; bor=
der-image-source: none; border-image-width: 1; border-left-color: rgb(34, 3=
4, 34); border-left-style: none; border-left-width: 0px; border-right-color=
: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; borde=
r-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px=
; color: rgb(34, 34, 34); display: inline; float: none; font-family: &amp;q=
uot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13=
px; font-style: normal; font-variant: normal; font-weight: 400; letter-spac=
ing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margi=
n-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-rig=
ht: 0px; padding-top: 0px; text-align: left; text-decoration: none; text-in=
dent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-spac=
e: normal; word-spacing: 0px;">Strong and weak names are split at that boun=
dary for a reason - either named-type (different type, period, like magic_p=
air&lt;7, &#39;x&#39;&gt;, if you don&#39;t supply an <span style=3D"displa=
y: inline !important; float: none; background-color: transparent; color: rg=
b(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-se=
rif; font-size: 13px; font-style: normal; font-variant: normal; font-weight=
: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decoratio=
n: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width:=
 0px; white-space: normal; word-spacing: 0px;">magic_pair&lt;7, &#39;x&#39;=
&gt; you fail</span>),</span></span></span></div><div><span style=3D"displa=
y: inline !important; float: none; background-color: transparent; color: rg=
b(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-se=
rif; font-size: 13px; font-style: normal; font-variant: normal; font-weight=
: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decoratio=
n: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width:=
 0px; white-space: normal; word-spacing: 0px;"><span style=3D"display: inli=
ne !important; float: none; background-color: transparent; color: rgb(34, 3=
4, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; fo=
nt-size: 13px; font-style: normal; font-variant: normal; font-weight: 400; =
letter-spacing: normal; orphans: 2; text-align: left; text-decoration: none=
; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; w=
hite-space: normal; word-spacing: 0px;"><span style=3D"background-color: tr=
ansparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none;=
 border-bottom-width: 0px; border-image-outset: 0; border-image-repeat: str=
etch; border-image-slice: 100%; border-image-source: none; border-image-wid=
th: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; border-=
left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: n=
one; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top=
-style: none; border-top-width: 0px; color: rgb(34, 34, 34); display: inlin=
e; float: none; font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&=
amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: no=
rmal; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-=
left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: =
0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: l=
eft; text-decoration: none; text-indent: 0px; text-transform: none; -webkit=
-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">=C2=A0<i>=
or</i> standard type 7 for the weak ones and names are just compiler-only h=
andshakes.</span></span></span></div><div><span style=3D"display: inline !i=
mportant; float: none; background-color: transparent; color: rgb(34, 34, 34=
); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-si=
ze: 13px; font-style: normal; font-variant: normal; font-weight: 400; lette=
r-spacing: normal; orphans: 2; text-align: left; text-decoration: none; tex=
t-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-=
space: normal; word-spacing: 0px;"><span style=3D"display: inline !importan=
t; float: none; background-color: transparent; color: rgb(34, 34, 34); font=
-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13p=
x; font-style: normal; font-variant: normal; font-weight: 400; letter-spaci=
ng: normal; orphans: 2; text-align: left; text-decoration: none; text-inden=
t: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: =
normal; word-spacing: 0px;"><span style=3D"background-color: transparent; b=
order-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bott=
om-width: 0px; border-image-outset: 0; border-image-repeat: stretch; border=
-image-slice: 100%; border-image-source: none; border-image-width: 1; borde=
r-left-color: rgb(34, 34, 34); border-left-style: none; border-left-width: =
0px; border-right-color: rgb(34, 34, 34); border-right-style: none; border-=
right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none=
; border-top-width: 0px; color: rgb(34, 34, 34); display: inline; float: no=
ne; font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sa=
ns-serif; font-size: 13px; font-style: normal; font-variant: normal; font-w=
eight: 400; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px; m=
argin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; padding=
-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; text-de=
coration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke=
-width: 0px; white-space: normal; word-spacing: 0px;"><br></span></span></s=
pan></div><div><span style=3D"display: inline !important; float: none; back=
ground-color: transparent; color: rgb(34, 34, 34); font-family: &quot;Arial=
&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: norma=
l; font-variant: normal; font-weight: 400; letter-spacing: normal; orphans:=
 2; text-align: left; text-decoration: none; text-indent: 0px; text-transfo=
rm: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing=
: 0px;"><span style=3D"display: inline !important; float: none; background-=
color: transparent; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,=
&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: normal; font=
-variant: normal; font-weight: 400; letter-spacing: normal; orphans: 2; tex=
t-align: left; text-decoration: none; text-indent: 0px; text-transform: non=
e; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"=
><span style=3D"background-color: transparent; border-bottom-color: rgb(34,=
 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-image=
-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; border-=
image-source: none; border-image-width: 1; border-left-color: rgb(34, 34, 3=
4); border-left-style: none; border-left-width: 0px; border-right-color: rg=
b(34, 34, 34); border-right-style: none; border-right-width: 0px; border-to=
p-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; co=
lor: rgb(34, 34, 34); display: inline; float: none; font-family: &amp;quot;=
Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; =
font-style: normal; font-variant: normal; font-weight: 400; letter-spacing:=
 normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-to=
p: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: =
0px; padding-top: 0px; text-align: left; text-decoration: none; text-indent=
: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: n=
ormal; word-spacing: 0px;">Your magic type, if is it to be aware the type s=
ystem, must have a type that accepts <i>either</i>=C2=A0<span style=3D"disp=
lay: inline !important; float: none; background-color: transparent; color: =
rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-=
serif; font-size: 13px; font-style: normal; font-variant: normal; font-weig=
ht: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decorat=
ion: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-widt=
h: 0px; white-space: normal; word-spacing: 0px;">magic_pair&lt;7, &#39;x&#3=
9;&gt; <i>or</i> naked type int.</span></span></span></span></div><div><spa=
n style=3D"display: inline !important; float: none; background-color: trans=
parent; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvet=
ica&quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: no=
rmal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: lef=
t; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-t=
ext-stroke-width: 0px; white-space: normal; word-spacing: 0px;"><span style=
=3D"display: inline !important; float: none; background-color: transparent;=
 color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quo=
t;,sans-serif; font-size: 13px; font-style: normal; font-variant: normal; f=
ont-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text=
-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-str=
oke-width: 0px; white-space: normal; word-spacing: 0px;"><span style=3D"bac=
kground-color: transparent; border-bottom-color: rgb(34, 34, 34); border-bo=
ttom-style: none; border-bottom-width: 0px; border-image-outset: 0; border-=
image-repeat: stretch; border-image-slice: 100%; border-image-source: none;=
 border-image-width: 1; border-left-color: rgb(34, 34, 34); border-left-sty=
le: none; border-left-width: 0px; border-right-color: rgb(34, 34, 34); bord=
er-right-style: none; border-right-width: 0px; border-top-color: rgb(34, 34=
, 34); border-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34=
); display: inline; float: none; font-family: &amp;quot;Arial&amp;quot;,&am=
p;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal;=
 font-variant: normal; font-weight: 400; letter-spacing: normal; margin-bot=
tom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2;=
 padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0=
px; text-align: left; text-decoration: none; text-indent: 0px; text-transfo=
rm: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing=
: 0px;"><span style=3D"display: inline !important; float: none; background-=
color: transparent; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,=
&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: normal; font=
-variant: normal; font-weight: 400; letter-spacing: normal; orphans: 2; tex=
t-align: left; text-decoration: none; text-indent: 0px; text-transform: non=
e; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"=
>The type system must be able to create tuples (or members or whatnot) of t=
hat type as well for delayed invocation.=C2=A0</span></span></span></span><=
/div><div><span style=3D"display: inline !important; float: none; backgroun=
d-color: transparent; color: rgb(34, 34, 34); font-family: &quot;Arial&quot=
;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: normal; fo=
nt-variant: normal; font-weight: 400; letter-spacing: normal; orphans: 2; t=
ext-align: left; text-decoration: none; text-indent: 0px; text-transform: n=
one; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px=
;"><span style=3D"display: inline !important; float: none; background-color=
: transparent; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot=
;Helvetica&quot;,sans-serif; font-size: 13px; font-style: normal; font-vari=
ant: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-ali=
gn: left; text-decoration: none; text-indent: 0px; text-transform: none; -w=
ebkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"><spa=
n style=3D"background-color: transparent; border-bottom-color: rgb(34, 34, =
34); border-bottom-style: none; border-bottom-width: 0px; border-image-outs=
et: 0; border-image-repeat: stretch; border-image-slice: 100%; border-image=
-source: none; border-image-width: 1; border-left-color: rgb(34, 34, 34); b=
order-left-style: none; border-left-width: 0px; border-right-color: rgb(34,=
 34, 34); border-right-style: none; border-right-width: 0px; border-top-col=
or: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; color: =
rgb(34, 34, 34); display: inline; float: none; font-family: &amp;quot;Arial=
&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-=
style: normal; font-variant: normal; font-weight: 400; letter-spacing: norm=
al; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0p=
x; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; =
padding-top: 0px; text-align: left; text-decoration: none; text-indent: 0px=
; text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal=
; word-spacing: 0px;"><span style=3D"display: inline !important; float: non=
e; background-color: transparent; color: rgb(34, 34, 34); font-family: &quo=
t;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style=
: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; o=
rphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-=
transform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-=
spacing: 0px;"><br></span></span></span></span></div><div><span style=3D"di=
splay: inline !important; float: none; background-color: transparent; color=
: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,san=
s-serif; font-size: 13px; font-style: normal; font-variant: normal; font-we=
ight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decor=
ation: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-wi=
dth: 0px; white-space: normal; word-spacing: 0px;"><span style=3D"display: =
inline !important; float: none; background-color: transparent; color: rgb(3=
4, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif=
; font-size: 13px; font-style: normal; font-variant: normal; font-weight: 4=
00; letter-spacing: normal; orphans: 2; text-align: left; text-decoration: =
none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0p=
x; white-space: normal; word-spacing: 0px;"><span style=3D"background-color=
: transparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: n=
one; border-bottom-width: 0px; border-image-outset: 0; border-image-repeat:=
 stretch; border-image-slice: 100%; border-image-source: none; border-image=
-width: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; bor=
der-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-styl=
e: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border=
-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34); display: i=
nline; float: none; font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvet=
ica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-variant=
: normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; mar=
gin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bott=
om: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-alig=
n: left; text-decoration: none; text-indent: 0px; text-transform: none; -we=
bkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"><span=
 style=3D"display: inline !important; float: none; background-color: transp=
arent; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helveti=
ca&quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: nor=
mal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left=
; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-te=
xt-stroke-width: 0px; white-space: normal; word-spacing: 0px;">On the decla=
ration such arguments, must be marked as well, so the user can now, which n=
ames are optional and can be omitted (not &quot;skipped&quot; but be either=
 &quot;positional&quot; or &quot;named&quot;).=C2=A0</span></span></span></=
span></div><div><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike=
><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><b></b><i></i>=
<u></u><sub></sub><sup></sup><strike></strike><b></b><i></i><u></u><sub></s=
ub><sup></sup><strike></strike><b></b><i></i><u></u><sub></sub><sup></sup><=
strike></strike><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; Because this &quot;optionality&quot; must travel through the type =
system as well, to=20
<br>&gt; be able to work with async/forward_as_typle
<br>&gt; This is not the case of &quot;simple&quot; strong names, which are=
 &quot;simply&quot; mandatory=20
<br>&gt; and &quot;are just a different type&quot;.=20
<br>
<br>I don&#39;t think that&#39;s the case:
<br>
<br>=C2=A0 void invoke(Func f, tuple&lt;int, named&lt;int, &quot;z&quot;&gt=
;&gt; args)
<br>=C2=A0 {
<br>=C2=A0 =C2=A0 f(get&lt;0&gt;(args), get&lt;1&gt;(args));
<br>=C2=A0 }
<br>=C2=A0 invoke(foo, make_tuple(2, .z=3D7)); // okay, calls foo(2, 5, 7)
<br>
<br>(Obviously, `invoke` is really a template, but I have shown the
<br>instantiation that is called in the example.)
<br>
<br>This will work with reordering also (if we allow it). I don&#39;t need =
to
<br>know anything about optionality when I am forwarding arguments, just so
<br>long as when I try to call the actual function, that succeeds with the
<br>arguments I actually provided. Basically, by tying the name to each
<br>argument, it passes through forwarding transparently, so that when I tr=
y
<br>to call the &quot;actual&quot; function, the arguments the compiler see=
s look the
<br>same as if the forwarding layer(s) weren&#39;t there.
<br>
<br>...unless you&#39;re talking about something totally different when you=
 talk
<br>about &quot;optionality&quot;?
<br>
<br>--=20
<br>Matthew
<br></blockquote></div>

<p></p>

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

------=_Part_1106_139929233.1535394127978--

------=_Part_1105_994958673.1535394127977--

.

On 2018-08-27 14:22, mihailnajdenov@gmail.com wrote:
> On Monday, August 27, 2018 at 8:29:49 PM UTC+3, Matthew Woehlke wrote:
>>   void foo(int .x, int .y=5, int .z=12);
>>   foo(2, .z=7); // okay, calls foo(2, 5, 7)
>
> If foo(2, .z=7) == foo(2, 5, 7) then how can it overload based on name?
> Where is the name in the final call?
>
> Or you mean foo(2, .y=5, .z=7) a.k.a. something like foo(2, named<5, 'y'>,
> named<7, 'z'>) ?

Heh... yeah, sorry for being unclear. `foo(2, .z=7)` is the input to
overload resolution, which resolves to `foo(int .x, int .y, int .z)`
and, due to skipping, invokes that overload with the arguments `(2, 5,
7)`... or, yes, more pedantically, `(.x=2, .y=5, .z=7)`. Above, I was
only trying to show that the skipped argument got "filled in".

> Your magic type, if is it to be aware the type system, must have a type
> that accepts *either* magic_pair<7, 'x'> *or* naked type int.

Yes; they are convertible. (I also require that "conversion" is
effectively reinterpret_cast.)

> The type system must be able to create tuples (or members or whatnot) of
> that type as well for delayed invocation.

That's the idea:

  template <typename T> void delayed(T);
  delayed(.x=5); // resolves to delayed<named<int, "x">>

> On the declaration such arguments, must be marked as well, so the user can
> now, which names are optional and can be omitted (not "skipped" but be
> either "positional" or "named").

A named argument may *always* be given as a positional argument, *if*
overload resolution succeeds (or is irrelevant, e.g. because you are
invoking a function pointer). Names are required only to skip, reorder,
or disambiguate (name-based overloading).

--
Matthew

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

.

--0000000000009c24e605746f7205
Content-Type: text/plain; charset="UTF-8"

On Mon, Aug 27, 2018 at 2:22 PM <mihailnajdenov@gmail.com> wrote:

> > Will the arguments you envision be able to be marked as optional or not?
>>
>> They can be defaulted:
>>
>>   void foo(int .x, int .y=5, int .z=12);
>>   foo(2, .z=7); // okay, calls foo(2, 5, 7)
>>
>
> If foo(2, .z=7) == foo(2, 5, 7) then how can it overload based on name?
> Where is the name in the final call?
>

The overload set is chosen such that an int can be the first argument,
and that there is another parameter named 'z' for which an int can be
an argument, and other parameters, if any, have default values.

For example, given
    void foo(int a, int b = 2);
    void foo(int c);
then
    foo(3);
is ambiguous but
    foo(.c = 3);
call the second version.

(By the Ada rules, two functions cannot differ only in parameter names.)

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

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Aug 27=
, 2018 at 2:22 PM &lt;<a href=3D"mailto:mihailnajdenov@gmail.com">mihailnaj=
denov@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"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; Will the arguments yo=
u envision be able to be marked as optional or not?
<br>
<br>They can be defaulted:
<br>
<br>=C2=A0 void foo(int .x, int .y=3D5, int .z=3D12);
<br>=C2=A0 foo(2, .z=3D7); // okay, calls foo(2, 5, 7)
<br></blockquote><div><br></div><div>If=C2=A0<span style=3D"display:inline!=
important;float:none;background-color:transparent;color:rgb(34,34,34);font-=
family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:13px;fo=
nt-style:normal;font-variant:normal;font-weight:400;letter-spacing:normal;t=
ext-align:left;text-decoration:none;text-indent:0px;text-transform:none;whi=
te-space:normal;word-spacing:0px">foo(2, .z=3D7) =3D=3D=C2=A0<span style=3D=
"display:inline!important;float:none;background-color:transparent;color:rgb=
(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;f=
ont-size:13px;font-style:normal;font-variant:normal;font-weight:400;letter-=
spacing:normal;text-align:left;text-decoration:none;text-indent:0px;text-tr=
ansform:none;white-space:normal;word-spacing:0px">foo(2, 5, 7) then how can=
 it overload based on name? Where is the name in the final call?</span></sp=
an></div></div></blockquote><div><br>The overload set is chosen such that a=
n int can be the first argument,<br>and that there is another parameter nam=
ed &#39;z&#39; for which an int can be<br>an argument, and other parameters=
, if any, have default values.<br><br>For example, given<br><font face=3D"m=
onospace, monospace">=C2=A0 =C2=A0 void foo(int a, int b =3D 2);<br>=C2=A0 =
=C2=A0 void foo(int c);</font><br>then<br><font face=3D"monospace, monospac=
e">=C2=A0 =C2=A0 foo(3);</font><br>is ambiguous but<br><font face=3D"monosp=
ace, monospace">=C2=A0 =C2=A0 foo(.c =3D 3);</font><br>call the second vers=
ion.<br><br>(By the Ada rules, two functions cannot differ only in paramete=
r names.)</div></div></div>

<p></p>

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

--0000000000009c24e605746f7205--

.

------=_Part_1175_1800676600.1535402322800
Content-Type: multipart/alternative;
 boundary="----=_Part_1176_1923329106.1535402322801"

------=_Part_1176_1923329106.1535402322801
Content-Type: text/plain; charset="UTF-8"



On Monday, August 27, 2018 at 9:47:26 PM UTC+3, Matthew Woehlke wrote:
>
> On 2018-08-27 14:22, mihailn...@gmail.com <javascript:> wrote:
> > On Monday, August 27, 2018 at 8:29:49 PM UTC+3, Matthew Woehlke wrote:
> >>   void foo(int .x, int .y=5, int .z=12);
> >>   foo(2, .z=7); // okay, calls foo(2, 5, 7)
> >
> > If foo(2, .z=7) == foo(2, 5, 7) then how can it overload based on name?
> > Where is the name in the final call?
> >
> > Or you mean foo(2, .y=5, .z=7) a.k.a. something like foo(2, named<5,
> 'y'>,
> > named<7, 'z'>) ?
>
> Heh... yeah, sorry for being unclear. `foo(2, .z=7)` is the input to
> overload resolution, which resolves to `foo(int .x, int .y, int .z)`
> and, due to skipping, invokes that overload with the arguments `(2, 5,
> 7)`... or, yes, more pedantically, `(.x=2, .y=5, .z=7)`. Above, I was
> only trying to show that the skipped argument got "filled in".
>
> > Your magic type, if is it to be aware the type system, must have a type
> > that accepts *either* magic_pair<7, 'x'> *or* naked type int.
>
> Yes; they are convertible. (I also require that "conversion" is
> effectively reinterpret_cast.)
>
> > The type system must be able to create tuples (or members or whatnot) of
> > that type as well for delayed invocation.
>
> That's the idea:
>
>   template <typename T> void delayed(T);
>   delayed(.x=5); // resolves to delayed<named<int, "x">>
>
> > On the declaration such arguments, must be marked as well, so the user
> can
> > now, which names are optional and can be omitted (not "skipped" but be
> > either "positional" or "named").
>
>

> A named argument may *always* be given as a positional argument, *if*
> overload resolution succeeds (or is irrelevant, e.g. because you are
> invoking a function pointer). Names are required only to skip, reorder,
> or disambiguate (name-based overloading).
>

So, *all* arguments are optional, basically strong names with implicit
conversion from the type.

struct a
{
  a(int) {}
};

struct b
{
  b(int) {}
};

void func(a) {}
void func(b) {}
void func(b, int) {}

int main()
{
  func(5); //< fails
  func(a(5)); //< ok
  func(5,5); //< ok
}

Something like that

I don't know, I guess it is the most complete solution, but people will
consider it too close to types, not to mention how *eagerly *changes the
signature.

A simple function like legendre ( unsigned l, unsigned x ); will turn to legendre
( named<unsigned, 'l'> l, named<unsigned, 'x'> x);

Some people will still prefer the zero-overhead compiler-only C#-like names
(accepting their limitations), and use a tags from time to time or
something else or have also have some strong names (or better tags), as
precision strike to fight overloading issues, but only when required.

As I said, I don't know, there are tradeoffs in every solution clearly.
Both the community and the committee should be sampled, I guess, to have
real needs.


> --
> Matthew
>

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

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

<div dir=3D"ltr"><br><br>On Monday, August 27, 2018 at 9:47:26 PM UTC+3, Ma=
tthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2018-08=
-27 14:22, <a onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;=
" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"javasc=
ript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"w_WDrQ0G=
AgAJ">mihailn...@gmail.com</a> wrote:
<br>&gt; On Monday, August 27, 2018 at 8:29:49 PM UTC+3, Matthew Woehlke wr=
ote:
<br>&gt;&gt; =C2=A0 void foo(int .x, int .y=3D5, int .z=3D12);=20
<br>&gt;&gt; =C2=A0 foo(2, .z=3D7); // okay, calls foo(2, 5, 7)=20
<br>&gt;=20
<br>&gt; If foo(2, .z=3D7) =3D=3D foo(2, 5, 7) then how can it overload bas=
ed on name?=20
<br>&gt; Where is the name in the final call?
<br>&gt;=20
<br>&gt; Or you mean foo(2, .y=3D5, .z=3D7) a.k.a. something like foo(2, na=
med&lt;5, &#39;y&#39;&gt;,=20
<br>&gt; named&lt;7, &#39;z&#39;&gt;) ?
<br>
<br>Heh... yeah, sorry for being unclear. `foo(2, .z=3D7)` is the input to
<br>overload resolution, which resolves to `foo(int .x, int .y, int .z)`
<br>and, due to skipping, invokes that overload with the arguments `(2, 5,
<br>7)`... or, yes, more pedantically, `(.x=3D2, .y=3D5, .z=3D7)`. Above, I=
 was
<br>only trying to show that the skipped argument got &quot;filled in&quot;=
..
<br>
<br>&gt; Your magic type, if is it to be aware the type system, must have a=
 type=20
<br>&gt; that accepts *either* magic_pair&lt;7, &#39;x&#39;&gt; *or* naked =
type int.
<br>
<br>Yes; they are convertible. (I also require that &quot;conversion&quot; =
is
<br>effectively reinterpret_cast.)
<br>
<br>&gt; The type system must be able to create tuples (or members or whatn=
ot) of=20
<br>&gt; that type as well for delayed invocation.=20
<br>
<br>That&#39;s the idea:
<br>
<br>=C2=A0 template &lt;typename T&gt; void delayed(T);
<br>=C2=A0 delayed(.x=3D5); // resolves to delayed&lt;named&lt;int, &quot;x=
&quot;&gt;&gt;
<br>
<br>&gt; On the declaration such arguments, must be marked as well, so the =
user can=20
<br>&gt; now, which names are optional and can be omitted (not &quot;skippe=
d&quot; but be=20
<br>&gt; either &quot;positional&quot; or &quot;named&quot;).
<br>
<br></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">A named argument may *always* be given as a positional argument, *if*
<br>overload resolution succeeds (or is irrelevant, e.g. because you are
<br>invoking a function pointer). Names are required only to skip, reorder,
<br>or disambiguate (name-based overloading).
<br></blockquote><div><br></div><div>So, <i>all</i> arguments are optional,=
 basically strong names with implicit conversion from the type.=C2=A0</div>=
<div><span style=3D"text-align: left; color: rgb(34, 34, 34); text-transfor=
m: none; text-indent: 0px; letter-spacing: normal; font-size: 13px; font-st=
yle: normal; font-variant: normal; font-weight: 400; text-decoration: none;=
 word-spacing: 0px; display: inline !important; white-space: normal; orphan=
s: 2; float: none; -webkit-text-stroke-width: 0px; background-color: transp=
arent;"><font face=3D"courier new,monospace"><br></font></span></div><span =
style=3D"text-align: left; color: rgb(34, 34, 34); text-transform: none; te=
xt-indent: 0px; letter-spacing: normal; font-size: 13px; font-style: normal=
; font-variant: normal; font-weight: 400; text-decoration: none; word-spaci=
ng: 0px; display: inline !important; white-space: normal; orphans: 2; float=
: none; -webkit-text-stroke-width: 0px; background-color: transparent;"><di=
v><font face=3D"courier new,monospace">struct a<br>{<br>=C2=A0 a(int) {}<br=
>};</font></div><div><font face=3D"courier new,monospace"></font><br></div>=
<div><font face=3D"courier new,monospace">struct b<br>{<br>=C2=A0 b(int) {}=
<br>};</font></div><div><font face=3D"courier new,monospace"></font><br></d=
iv><div><font face=3D"courier new,monospace">void <span style=3D"text-align=
: left; color: rgb(34, 34, 34); text-transform: none; text-indent: 0px; let=
ter-spacing: normal; font-size: 13px; font-style: normal; font-variant: nor=
mal; font-weight: 400; text-decoration: none; word-spacing: 0px; display: i=
nline !important; white-space: normal; orphans: 2; float: none; -webkit-tex=
t-stroke-width: 0px; background-color: transparent;">func</span>(a) {}</fon=
t></div><div><font face=3D"courier new,monospace">void <span style=3D"text-=
align: left; color: rgb(34, 34, 34); text-transform: none; text-indent: 0px=
; letter-spacing: normal; font-size: 13px; font-style: normal; font-variant=
: normal; font-weight: 400; text-decoration: none; word-spacing: 0px; displ=
ay: inline !important; white-space: normal; orphans: 2; float: none; -webki=
t-text-stroke-width: 0px; background-color: transparent;">func</span>(b) {}=
</font></div><div><font face=3D"courier new,monospace"><span style=3D"text-=
align: left; color: rgb(34, 34, 34); text-transform: none; text-indent: 0px=
; letter-spacing: normal; font-size: 13px; font-style: normal; font-variant=
: normal; font-weight: 400; text-decoration: none; word-spacing: 0px; displ=
ay: inline !important; white-space: normal; orphans: 2; float: none; -webki=
t-text-stroke-width: 0px; background-color: transparent;">void <span style=
=3D"text-align: left; color: rgb(34, 34, 34); text-transform: none; text-in=
dent: 0px; letter-spacing: normal; font-size: 13px; font-style: normal; fon=
t-variant: normal; font-weight: 400; text-decoration: none; word-spacing: 0=
px; display: inline !important; white-space: normal; orphans: 2; float: non=
e; -webkit-text-stroke-width: 0px; background-color: transparent;">func</sp=
an>(b, int) </span><span style=3D"text-align: left; color: rgb(34, 34, 34);=
 text-transform: none; text-indent: 0px; letter-spacing: normal; font-size:=
 13px; font-style: normal; font-variant: normal; font-weight: 400; text-dec=
oration: none; word-spacing: 0px; display: inline !important; white-space: =
normal; orphans: 2; float: none; -webkit-text-stroke-width: 0px; background=
-color: transparent;">{</span><span style=3D"text-align: left; color: rgb(3=
4, 34, 34); text-transform: none; text-indent: 0px; letter-spacing: normal;=
 font-size: 13px; font-style: normal; font-variant: normal; font-weight: 40=
0; text-decoration: none; word-spacing: 0px; display: inline !important; wh=
ite-space: normal; orphans: 2; float: none; -webkit-text-stroke-width: 0px;=
 background-color: transparent;">}</span></font></div><div><b></b><i></i><u=
></u><sub></sub><sup></sup><strike></strike><font face=3D"courier new,monos=
pace"></font><br></div><div><font face=3D"courier new,monospace">int main()=
<br>{<br>=C2=A0 <span style=3D"text-align: left; color: rgb(34, 34, 34); te=
xt-transform: none; text-indent: 0px; letter-spacing: normal; font-size: 13=
px; font-style: normal; font-variant: normal; font-weight: 400; text-decora=
tion: none; word-spacing: 0px; display: inline !important; white-space: nor=
mal; orphans: 2; float: none; -webkit-text-stroke-width: 0px; background-co=
lor: transparent;">func</span>(5); //&lt; fails</font></div><div><font face=
=3D"courier new,monospace">=C2=A0 func(a(5)); //&lt; ok</font></div><div><f=
ont face=3D"courier new,monospace">=C2=A0 func(5,5); //&lt; ok</font></div>=
<div><font face=3D"courier new,monospace">}</font><br></div></span><div><b>=
</b><i></i><u></u><sub></sub><sup></sup><strike></strike><b></b><i></i><u><=
/u><sub></sub><sup></sup><strike></strike><b></b><i></i><u></u><sub></sub><=
sup></sup><strike></strike><font face=3D"courier new,monospace"></font><br>=
</div><div>Something like that</div><div><br></div><div>I don&#39;t know, I=
 guess it is the most complete solution, but people will consider it too cl=
ose to types, not to mention how <i><b>eagerly</b> </i>changes the signatur=
e.</div><div><br></div><div>A simple function like <font face=3D"courier ne=
w,monospace">legendre ( unsigned l, unsigned x );</font> <font face=3D"aria=
l,sans-serif">will turn to </font><font face=3D"courier new,monospace"><spa=
n style=3D"text-align: left; color: rgb(34, 34, 34); text-transform: none; =
text-indent: 0px; letter-spacing: normal; font-size: 13px; font-style: norm=
al; font-variant: normal; font-weight: 400; text-decoration: none; word-spa=
cing: 0px; display: inline !important; white-space: normal; orphans: 2; flo=
at: none; -webkit-text-stroke-width: 0px; background-color: transparent;">l=
egendre ( named&lt;unsigned, &#39;l&#39;&gt; l, <span style=3D"text-align: =
left; color: rgb(34, 34, 34); text-transform: none; text-indent: 0px; lette=
r-spacing: normal; font-size: 13px; font-style: normal; font-variant: norma=
l; font-weight: 400; text-decoration: none; word-spacing: 0px; display: inl=
ine !important; white-space: normal; orphans: 2; float: none; -webkit-text-=
stroke-width: 0px; background-color: transparent;">named&lt;unsigned, &#39;=
x&#39;&gt; x</span>);</span></font></div><div><b></b><i></i><u></u><sub></s=
ub><sup></sup><strike></strike><font face=3D"courier new,monospace"></font>=
<br></div><div>Some people will still prefer the zero-overhead compiler-onl=
y C#-like names (accepting their limitations), and use a tags from time to =
time or something else or have also have some strong names (or better tags)=
, as precision strike to fight overloading issues, but only when required.<=
/div><div><br></div><div>As I said, I don&#39;t know, there are tradeoffs i=
n every solution clearly. Both the community and the committee should be sa=
mpled, I guess, to have real needs.=C2=A0</div><div><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;">
<br>--=20
<br>Matthew
<br></blockquote></div>

<p></p>

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

------=_Part_1176_1923329106.1535402322801--

------=_Part_1175_1800676600.1535402322800--

.

--0000000000000ec625057470feac
Content-Type: text/plain; charset="UTF-8"

On Mon, Aug 27, 2018 at 4:38 PM <mihailnajdenov@gmail.com> wrote:

> A simple function like legendre ( unsigned l, unsigned x ); will turn to legendre
> ( named<unsigned, 'l'> l, named<unsigned, 'x'> x);
>

Ugh.  If I were voting that would be a strong "no".

Some people will still prefer the zero-overhead compiler-only C#-like names
> (accepting their limitations), and use a tags from time to time or
> something else or have also have some strong names (or better tags), as
> precision strike to fight overloading issues, but only when required.
>

Named parameters can be zero-overhead-compiler-only and still affect
overload resolution.
When there's a call that uses a parameter name, you find the functions that
have a parameter
with that name that are callable with that argument type, and they form the
overload set.

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

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Aug 27=
, 2018 at 4:38 PM &lt;<a href=3D"mailto:mihailnajdenov@gmail.com">mihailnaj=
denov@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"><div>A simple function like <font face=3D"courier new,monospace">l=
egendre ( unsigned l, unsigned x );</font> <font face=3D"arial,sans-serif">=
will turn to </font><font face=3D"courier new,monospace"><span style=3D"tex=
t-align:left;color:rgb(34,34,34);text-transform:none;text-indent:0px;letter=
-spacing:normal;font-size:13px;font-style:normal;font-variant:normal;font-w=
eight:400;text-decoration:none;word-spacing:0px;display:inline!important;wh=
ite-space:normal;float:none;background-color:transparent">legendre ( named&=
lt;unsigned, &#39;l&#39;&gt; l, <span style=3D"text-align:left;color:rgb(34=
,34,34);text-transform:none;text-indent:0px;letter-spacing:normal;font-size=
:13px;font-style:normal;font-variant:normal;font-weight:400;text-decoration=
:none;word-spacing:0px;display:inline!important;white-space:normal;float:no=
ne;background-color:transparent">named&lt;unsigned, &#39;x&#39;&gt; x</span=
>);</span></font></div></div></blockquote><div><br>Ugh.=C2=A0 If I were vot=
ing that would be a strong &quot;no&quot;.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div>Some people will still prefer the zero-=
overhead compiler-only C#-like names (accepting their limitations), and use=
 a tags from time to time or something else or have also have some strong n=
ames (or better tags), as precision strike to fight overloading issues, but=
 only when required.</div></div></blockquote><div><br>Named parameters can =
be zero-overhead-compiler-only and still affect overload resolution.<br>Whe=
n there&#39;s a call that uses a parameter name, you find the functions tha=
t have a parameter<br>with that name that are callable with that argument t=
ype, and they form the overload set.</div></div></div>

<p></p>

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

--0000000000000ec625057470feac--

.

On 2018-08-27 16:38, mihailnajdenov@gmail.com wrote:
> So, *all* arguments are optional, basically strong names with implicit
> conversion from the type.

Right.

> struct a
> {
>   a(int) {}
> };
>
> struct b
> {
>   b(int) {}
> };
>
> void func(a) {}
> void func(b) {}
> void func(b, int) {}
>
> int main()
> {
>   func(5); //< fails
>   func(a(5)); //< ok
>   func(5,5); //< ok
> }
>
> Something like that

Right.

> Some people will still prefer the zero-overhead compiler-only C#-like names
> (accepting their limitations), and use a tags from time to time or
> something else or have also have some strong names (or better tags), as
> precision strike to fight overloading issues, but only when required.

Changing the signature is required for name-based overloading to work.
If we *don't* do that, we basically close ourselves off from *ever*
having name-based overloading.

That said, one of the "co-features" I am looking at is the ability to
*alias* functions, differing only by argument names. IOW:

  void foo(int);
  using foo(int .x) = foo(int);

....says to pretend that `foo(int .x)` exists, but that any call that
resolves to that shall actually call `foo(int)`. Also, `foo(1)` would
not be ambiguous, because even though both `foo(int)` and `foo(int .x)`
are viable, they are actually the same function and therefore are not
considered ambiguous.

(Note: `using foo(int .a) = foo(int .x)` is also legal. You just can't
mix parameter *types*, i.e. no `using foo(int) = foo(short)`.)

I wouldn't recommend this for *new* development, but it provides a way
to get all the goodies of named arguments with "legacy" ABI's.

--
Matthew

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

.

------=_Part_1188_1104817741.1535404476461
Content-Type: multipart/alternative;
 boundary="----=_Part_1189_1059962420.1535404476461"

------=_Part_1189_1059962420.1535404476461
Content-Type: text/plain; charset="UTF-8"



On Monday, August 27, 2018 at 11:58:53 PM UTC+3, Hyman Rosen wrote:
>
> On Mon, Aug 27, 2018 at 4:38 PM <mihailn...@gmail.com <javascript:>>
> wrote:
>
>> A simple function like legendre ( unsigned l, unsigned x ); will turn to legendre
>> ( named<unsigned, 'l'> l, named<unsigned, 'x'> x);
>>
>
> Ugh.  If I were voting that would be a strong "no".
>
> Some people will still prefer the zero-overhead compiler-only C#-like
>> names (accepting their limitations), and use a tags from time to time or
>> something else or have also have some strong names (or better tags), as
>> precision strike to fight overloading issues, but only when required.
>>
>
> Named parameters can be zero-overhead-compiler-only and still affect
> overload resolution.
> When there's a call that uses a parameter name, you find the functions
> that have a parameter
> with that name that are callable with that argument type, and they form
> the overload set.
>

Yeah, I am aware. The point was overloading *on* names and the fact names
can travel the typesystem. Matthew clearly wants these.


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

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

<div dir=3D"ltr"><br><br>On Monday, August 27, 2018 at 11:58:53 PM UTC+3, H=
yman Rosen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Aug 27, 2018 at 4:3=
8 PM &lt;<a onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" =
onclick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"javascri=
pt:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"tIbBDDoNAg=
AJ">mihailn...@gmail.com</a>&gt; wrote:</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div>A simple function like <font face=3D"courier new,mon=
ospace">legendre ( unsigned l, unsigned x );</font> <font face=3D"arial,san=
s-serif">will turn to </font><font face=3D"courier new,monospace"><span sty=
le=3D"text-align:left;color:rgb(34,34,34);text-transform:none;text-indent:0=
px;letter-spacing:normal;font-size:13px;font-style:normal;font-variant:norm=
al;font-weight:400;text-decoration:none;word-spacing:0px;display:inline!imp=
ortant;white-space:normal;float:none;background-color:transparent">legendre=
 ( named&lt;unsigned, &#39;l&#39;&gt; l, <span style=3D"text-align:left;col=
or:rgb(34,34,34);text-transform:none;text-indent:0px;letter-spacing:normal;=
font-size:13px;font-style:normal;font-variant:normal;font-weight:400;text-d=
ecoration:none;word-spacing:0px;display:inline!important;white-space:normal=
;float:none;background-color:transparent">named&lt;unsigned, &#39;x&#39;&gt=
; x</span>);</span></font></div></div></blockquote><div><br>Ugh.=C2=A0 If I=
 were voting that would be a strong &quot;no&quot;.<br><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><div>Some people will still prefer th=
e zero-overhead compiler-only C#-like names (accepting their limitations), =
and use a tags from time to time or something else or have also have some s=
trong names (or better tags), as precision strike to fight overloading issu=
es, but only when required.</div></div></blockquote><div><br>Named paramete=
rs can be zero-overhead-compiler-only and still affect overload resolution.=
<br>When there&#39;s a call that uses a parameter name, you find the functi=
ons that have a parameter<br>with that name that are callable with that arg=
ument type, and they form the overload set.</div></div></div></blockquote><=
div><br></div><div>Yeah, I am aware. The point was overloading <i>on</i> na=
mes and the fact names can travel the typesystem. Matthew clearly wants the=
se.=C2=A0</div><div><br></div><div><br></div></div>

<p></p>

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

------=_Part_1189_1059962420.1535404476461--

------=_Part_1188_1104817741.1535404476461--

.

On 2018-08-27 16:58, Hyman Rosen wrote:
> On Mon, Aug 27, 2018 at 4:38 PM wrote:
>> A simple function like legendre ( unsigned l, unsigned x ); will turn to legendre
>> ( named<unsigned, 'l'> l, named<unsigned, 'x'> x);
>
> Ugh.  If I were voting that would be a strong "no".

Are you just opposed to *writing* that? (Because you won't.) Or are you
opposed to being able to overload on names (which requires that the name
be part of the ABI)?

Yes, what Mihail wrote is the *unmangled ABI*. But your *code* will look
like `legendre(unsigned .l, unsigned .x)`. (I'm not even sure the 'named
argument' type will be utterable. I'm leaning towards "no", unless
someone can show a reason why you would need to name it.)

> Named parameters can be zero-overhead-compiler-only and still affect
> overload resolution. When there's a call that uses a parameter name,
> you find the functions that have a parameter with that name that are
> callable with that argument type, and they form the overload set.
Assuming that "compiler only" means "does not change the ABI", how would
you implement name-based overloading?

(The only overhead in my present thinking is that the ABI mangled name
is a little longer. There is no *instruction* overhead. Incidentally,
I'm not sure this is true for 'argument structs'. We probably *hope* it
is, but...)

--
Matthew

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

.

--0000000000008be7b40574719e22
Content-Type: text/plain; charset="UTF-8"

On Mon, Aug 27, 2018 at 5:14 PM Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> Assuming that "compiler only" means "does not change the ABI", how would
> you implement name-based overloading?
>

Haven't I been saying it?  Given a call
    foo(p1, p2, p3, .n1 = v1, .n2 = v2, .n3 = v3);
the overload set consists of those functions that can be called with the
first three
parameters p1, p2, and p3, and that have subsequent named parameters n1, n2,
and n3 (in any order) that can be initialized with v1, v2, and v3, and have
default
values for any other parameters if present.  The names are just the
parameter
names that appear in the function declaration.

Functions are not permitted to differ only in parameter names - that is,
    void f(int a);
    void f(int b);
is not legal.

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

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Aug 27=
, 2018 at 5:14 PM Matthew Woehlke &lt;<a href=3D"mailto:mwoehlke.floss@gmai=
l.com">mwoehlke.floss@gmail.com</a>&gt; wrote:</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
Assuming that &quot;compiler only&quot; means &quot;does not change the ABI=
&quot;, how would<br>
you implement name-based overloading?<br></blockquote><div><br>Haven&#39;t =
I been saying it?=C2=A0 Given a call<br><font face=3D"monospace, monospace"=
>=C2=A0 =C2=A0 foo(p1, p2, p3, .n1 =3D v1, .n2 =3D v2, .n3 =3D v3);</font><=
br>the overload set consists of those functions that can be called with the=
 first three<br>parameters=C2=A0<font face=3D"monospace, monospace">p1</fon=
t>,=C2=A0<font face=3D"monospace, monospace">p2</font>, and=C2=A0<font face=
=3D"monospace, monospace">p3</font>, and that have subsequent named paramet=
ers=C2=A0<font face=3D"monospace, monospace">n1</font>,=C2=A0<font face=3D"=
monospace, monospace">n2</font>,<br>and=C2=A0<font face=3D"monospace, monos=
pace">n3</font>=C2=A0(in any order) that can be initialized with=C2=A0<font=
 face=3D"monospace, monospace">v1</font>,=C2=A0<font face=3D"monospace, mon=
ospace">v2</font>, and=C2=A0<font face=3D"monospace, monospace">v3</font>, =
and have default<br>values for any other parameters if present.=C2=A0 The n=
ames are just the parameter<br>names that appear in the function declaratio=
n.<br><br>Functions are not permitted to differ only in parameter names - t=
hat is,<br><font face=3D"monospace, monospace">=C2=A0 =C2=A0 void f(int a);=
<br>=C2=A0 =C2=A0 void f(int b);</font><br>is not legal.=C2=A0=C2=A0=C2=A0<=
/div></div></div>

<p></p>

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

--0000000000008be7b40574719e22--

.

------=_Part_1135_2077566935.1535406327106
Content-Type: multipart/alternative;
 boundary="----=_Part_1136_1293118794.1535406327106"

------=_Part_1136_1293118794.1535406327106
Content-Type: text/plain; charset="UTF-8"



On Monday, August 27, 2018 at 11:59:44 PM UTC+3, Matthew Woehlke wrote:
>
> On 2018-08-27 16:38, mihailn...@gmail.com <javascript:> wrote:
> > So, *all* arguments are optional, basically strong names with implicit
> > conversion from the type.
>
> Right.
>
> > struct a
> > {
> >   a(int) {}
> > };
> >
> > struct b
> > {
> >   b(int) {}
> > };
> >
> > void func(a) {}
> > void func(b) {}
> > void func(b, int) {}
> >
> > int main()
> > {
> >   func(5); //< fails
> >   func(a(5)); //< ok
> >   func(5,5); //< ok
> > }
> >
> > Something like that
>
> Right.
>
> > Some people will still prefer the zero-overhead compiler-only C#-like
> names
> > (accepting their limitations), and use a tags from time to time or
> > something else or have also have some strong names (or better tags), as
> > precision strike to fight overloading issues, but only when required.
>
> Changing the signature is required for name-based overloading to work.
> If we *don't* do that, we basically close ourselves off from *ever*
> having name-based overloading.
>

Well, not without a spin on the declaration.


I am worried, your suggestion is dangerously close to P0671R0
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0671r0.html> that
"introduces a new function type", where here every single named argument is
changed,
which might as well mean *every argument, *which in turn is essentially a
new function "type" altogether.

Am I also worried, it will be seen an easy way around the need of types.
This will be used against it* for sure*.
It will probably be somewhat valid argument if we examine current practice
in the face of Swift/ObjectiveC - the typing is *laughable* - "dictionary",
"data", "string" all over the place.

It is the most (the only?) complete solution but it is also the most
aggressive one.


>
> That said, one of the "co-features" I am looking at is the ability to
> *alias* functions, differing only by argument names. IOW:
>
>   void foo(int);
>   using foo(int .x) = foo(int);
>
> ...says to pretend that `foo(int .x)` exists, but that any call that
> resolves to that shall actually call `foo(int)`. Also, `foo(1)` would
> not be ambiguous, because even though both `foo(int)` and `foo(int .x)`
> are viable, they are actually the same function and therefore are not
> considered ambiguous.
>
> (Note: `using foo(int .a) = foo(int .x)` is also legal. You just can't
> mix parameter *types*, i.e. no `using foo(int) = foo(short)`.)
>
> I wouldn't recommend this for *new* development, but it provides a way
> to get all the goodies of named arguments with "legacy" ABI's.
>
> --
> Matthew
>

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

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

<div dir=3D"ltr"><br><br>On Monday, August 27, 2018 at 11:59:44 PM UTC+3, M=
atthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2018-0=
8-27 16:38, <a onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true=
;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"javas=
cript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"j72nzUU=
NAgAJ">mihailn...@gmail.com</a> wrote:
<br>&gt; So, *all* arguments are optional, basically strong names with impl=
icit=20
<br>&gt; conversion from the type.=20
<br>
<br>Right.
<br>
<br>&gt; struct a
<br>&gt; {
<br>&gt; =C2=A0 a(int) {}
<br>&gt; };
<br>&gt;=20
<br>&gt; struct b
<br>&gt; {
<br>&gt; =C2=A0 b(int) {}
<br>&gt; };
<br>&gt;=20
<br>&gt; void func(a) {}
<br>&gt; void func(b) {}
<br>&gt; void func(b, int) {}
<br>&gt;=20
<br>&gt; int main()
<br>&gt; {
<br>&gt; =C2=A0 func(5); //&lt; fails
<br>&gt; =C2=A0 func(a(5)); //&lt; ok
<br>&gt; =C2=A0 func(5,5); //&lt; ok
<br>&gt; }
<br>&gt;=20
<br>&gt; Something like that
<br>
<br>Right.
<br>
<br>&gt; Some people will still prefer the zero-overhead compiler-only C#-l=
ike names=20
<br>&gt; (accepting their limitations), and use a tags from time to time or=
=20
<br>&gt; something else or have also have some strong names (or better tags=
), as=20
<br>&gt; precision strike to fight overloading issues, but only when requir=
ed.
<br>
<br>Changing the signature is required for name-based overloading to work.
<br>If we *don&#39;t* do that, we basically close ourselves off from *ever*
<br>having name-based overloading.
<br></blockquote><div><br></div><div>Well, not without a spin on the declar=
ation.</div><div><br></div><div><br></div><div>I am worried, your suggestio=
n is dangerously close to=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc22=
/wg21/docs/papers/2017/p0671r0.html">P0671R0</a><font color=3D"#b06400"> </=
font>that &quot;introduces a new function type&quot;, where here every sing=
le named argument is changed,=C2=A0</div><div>which might as well mean <i>e=
very argument, </i>which in turn is essentially a new function &quot;type&q=
uot; altogether.</div><div><br></div><div>Am I also worried, it will be see=
n an easy way around the need of types. This will be used against it<i> for=
 sure</i>.=C2=A0</div><div>It will probably be somewhat valid argument if w=
e examine current practice in the face of Swift/ObjectiveC - the typing is =
<i>laughable</i> - &quot;dictionary&quot;, &quot;data&quot;, &quot;string&q=
uot; all over the place.</div><div><br></div><div>It is the most (the only?=
) complete solution but it is also the most aggressive one.=C2=A0</div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>That said, one of the &quot;co-features&quot; I am looking at is the ab=
ility to
<br>*alias* functions, differing only by argument names. IOW:
<br>
<br>=C2=A0 void foo(int);
<br>=C2=A0 using foo(int .x) =3D foo(int);
<br>
<br>...says to pretend that `foo(int .x)` exists, but that any call that
<br>resolves to that shall actually call `foo(int)`. Also, `foo(1)` would
<br>not be ambiguous, because even though both `foo(int)` and `foo(int .x)`
<br>are viable, they are actually the same function and therefore are not
<br>considered ambiguous.
<br>
<br>(Note: `using foo(int .a) =3D foo(int .x)` is also legal. You just can&=
#39;t
<br>mix parameter *types*, i.e. no `using foo(int) =3D foo(short)`.)
<br>
<br>I wouldn&#39;t recommend this for *new* development, but it provides a =
way
<br>to get all the goodies of named arguments with &quot;legacy&quot; ABI&#=
39;s.
<br>
<br>--=20
<br>Matthew
<br></blockquote></div>

<p></p>

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

------=_Part_1136_1293118794.1535406327106--

------=_Part_1135_2077566935.1535406327106--

.

On 2018-08-27 17:43, Hyman Rosen wrote:
> On Mon, Aug 27, 2018 at 5:14 PM Matthew Woehlke wrote:
>> Assuming that "compiler only" means "does not change the ABI", how would
>> you implement name-based overloading?
>
> Haven't I been saying it?
> [...]
>
> Functions are not permitted to differ only in parameter names - that is,
>     void f(int a);
>     void f(int b);
> is not legal.

So... you wouldn't; you'd make it illegal. Which is exactly what *I*
have been saying. AFAICT (feel free to prove me wrong, but so far no one
has) any solution that does *not* involve changing the ABI *permanently
precludes* name-based overloads (that is, overloads that differ *only*
by name).

I, personally, am not in favor of any such approach.

I also don't understand why some folks seem so violently opposed to
names being part of the ABI. I'm not talking about compatibility (I
showed an option for how to accomplish that), I'm talking about *for new
functions*. That is, if we were designing the language *from scratch*,
with no legacy code to consider, *why* would having the name be part of
the ABI be a bad thing? AFAIK no one has answered that.

--
Matthew

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

.

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

On Tue, Aug 28, 2018 at 10:17 AM Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2018-08-27 17:43, Hyman Rosen wrote:
> > On Mon, Aug 27, 2018 at 5:14 PM Matthew Woehlke wrote:
> >> Assuming that "compiler only" means "does not change the ABI", how would
> >> you implement name-based overloading?
> >
> > Haven't I been saying it?
> > [...]
> >
> > Functions are not permitted to differ only in parameter names - that is,
> >     void f(int a);
> >     void f(int b);
> > is not legal.
>
> So... you wouldn't; you'd make it illegal. Which is exactly what *I*
> have been saying. AFAICT (feel free to prove me wrong, but so far no one
> has) any solution that does *not* involve changing the ABI *permanently
> precludes* name-based overloads (that is, overloads that differ *only*
> by name).
>

"Overloading by parameter name" doesn't just mean what you want it to mean.
My version still causes functions to be added to the overload set based on
parameter names, so I feel completely justified in saying that my version
also
overloads by parameter name.

I also don't understand why some folks seem so violently opposed to
> names being part of the ABI.


Speaking just for myself, I see named parameters as syntactic sugar for
making
a function call more convenient and self-documenting.  That means that it's
not
changing the functions themselves at all, so there is no reason to change
the ABI.

We do not now allow two functions to have the same name and parameter
profile,
and I don't see any need to change that either.

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

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Aug 28=
, 2018 at 10:17 AM Matthew Woehlke &lt;<a href=3D"mailto:mwoehlke.floss@gma=
il.com">mwoehlke.floss@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">On 2018-08-27 17:43, Hyman Rosen wrote:<br>
&gt; On Mon, Aug 27, 2018 at 5:14 PM Matthew Woehlke wrote:<br>
&gt;&gt; Assuming that &quot;compiler only&quot; means &quot;does not chang=
e the ABI&quot;, how would<br>
&gt;&gt; you implement name-based overloading?<br>
&gt; <br>
&gt; Haven&#39;t I been saying it?<br>
&gt; [...]<br>
&gt; <br>
&gt; Functions are not permitted to differ only in parameter names - that i=
s,<br>
&gt;=C2=A0 =C2=A0 =C2=A0void f(int a);<br>
&gt;=C2=A0 =C2=A0 =C2=A0void f(int b);<br>
&gt; is not legal.<br>
<br>
So... you wouldn&#39;t; you&#39;d make it illegal. Which is exactly what *I=
*<br>
have been saying. AFAICT (feel free to prove me wrong, but so far no one<br=
>
has) any solution that does *not* involve changing the ABI *permanently<br>
precludes* name-based overloads (that is, overloads that differ *only*<br>
by name).<br></blockquote><div><br>&quot;Overloading by parameter name&quot=
; doesn&#39;t just mean what you want it to mean.<br>My version still cause=
s functions to be added to the overload set based on<br>parameter names, so=
 I feel completely justified in saying that my version also<br>overloads by=
 parameter name.<br><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I also don&#39;t understand why some folks seem so violently opposed to<br>
names being part of the ABI.</blockquote><div><br>Speaking just for myself,=
 I see named parameters as syntactic sugar for making<br>a function call mo=
re convenient and self-documenting.=C2=A0 That means that it&#39;s not<br>c=
hanging the functions themselves at all, so there is no reason to change th=
e ABI.<br><br>We do not now allow two functions to have the same name and p=
arameter profile,<br>and I don&#39;t see any need to change that either.</d=
iv></div></div>

<p></p>

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

--0000000000005fc16c05747fcc38--

.

On 2018-08-27 17:45, mihailnajdenov@gmail.com wrote:
> On Monday, August 27, 2018 at 11:59:44 PM UTC+3, Matthew Woehlke wrote:
>> Changing the signature is required for name-based overloading to work.
>> If we *don't* do that, we basically close ourselves off from *ever*
>> having name-based overloading.
>
> Well, not without a spin on the declaration.
>
> I am worried, your suggestion is dangerously close to P0671R0
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0671r0.html> that
> "introduces a new function type", where here every single named argument is
> changed,
> which might as well mean *every argument, *which in turn is essentially a
> new function "type" altogether.

Well, we seem to be about split down the middle, between people for whom
having to make *any change at all* to declarations of existing functions
constitutes an "over my dead body" objection, and people for whom having
named arguments *not* be opt-in is an "over my dead body" objection.

Since these two are diametrically opposed, we seem to be at an impasse.

FWIW, my idea is definitely *not* "a new function type". It is a new
*argument* type, and can most definitely be used in combination with
unnamed arguments:

  foo(int, int, double .x); // perfectly legal

> Am I also worried, it will be seen an easy way around the need of types.
> This will be used against it* for sure*.

Types are *really hard*, and even if we had them, it's hard to imagine
people wanting to make a new type for every single function argument
everywhere.

Besides, types *won't* allow argument skipping (or reordering). At best,
they'd help with overload disambiguation, which is about the *least*
important feature to just about everyone. (Note: named arguments as
types makes this a shoe-in, but more importantly, they *solve
forwarding*, so it's not like name-based overloads is the only reason
for my approach.)

--
Matthew

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

.

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

On Tue, Aug 28, 2018 at 10:44 AM Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> Well, we seem to be about split down the middle, between people for whom
> having to make *any change at all* to declarations of existing functions
> constitutes an "over my dead body" objection, and people for whom having
> named arguments *not* be opt-in is an "over my dead body" objection.
>
> Since these two are diametrically opposed, we seem to be at an impasse.
>

That's not true.  The version I (and others, I assume) are talking about
requires
no change to functions, existing or future, and is optional at the call
site.
The example again:
    void f(int a, int b = 1);
    void f(int c);
    f(5);       // ambiguous
    f(3, 4);    // calls first function
    f(.c = 6);  // calls second function

The impasse, such as it is, exists for people who want to be able to
declare functions
that differ only in parameter names.  I think that feature is unnecessary
and confusing.
If the parameter names are the only way to distinguish between two
functions, you
should change the function name to incorporate those names.

I really do not want people writing this:
    void set_weight(double pounds);
    void set_weight(double stone);
    void set_weight(double kilograms);

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

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Aug 28=
, 2018 at 10:44 AM Matthew Woehlke &lt;<a href=3D"mailto:mwoehlke.floss@gma=
il.com">mwoehlke.floss@gmail.com</a>&gt; wrote:</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
Well, we seem to be about split down the middle, between people for whom<br=
>
having to make *any change at all* to declarations of existing functions<br=
>
constitutes an &quot;over my dead body&quot; objection, and people for whom=
 having<br>
named arguments *not* be opt-in is an &quot;over my dead body&quot; objecti=
on.<br>
<br>
Since these two are diametrically opposed, we seem to be at an impasse.<br>=
</blockquote><div><br></div><div>That&#39;s not true.=C2=A0 The version I (=
and others, I assume) are talking about requires<br>no change to functions,=
 existing or future, and is optional at the call site.=C2=A0<br>The example=
 again:<br><font face=3D"monospace, monospace">=C2=A0 =C2=A0 void f(int a, =
int b =3D 1);<br>=C2=A0 =C2=A0 void f(int c);<br>=C2=A0 =C2=A0 f(5);=C2=A0 =
=C2=A0 =C2=A0 =C2=A0// ambiguous<br>=C2=A0 =C2=A0 f(3, 4);=C2=A0 =C2=A0 // =
calls first function<br>=C2=A0 =C2=A0 f(.c =3D 6);=C2=A0 // calls second fu=
nction</font></div><div><br></div>The impasse, such as it is, exists for pe=
ople who want to be able to declare functions<br>that differ only in parame=
ter names.=C2=A0 I think that feature is unnecessary and confusing.<br>If t=
he parameter names are the only way to distinguish between two functions, y=
ou<br>should change the function name to incorporate those names.<br><br>I =
really do not want people writing this:<br><font face=3D"monospace, monospa=
ce">=C2=A0 =C2=A0 void set_weight(double pounds);</font></div><span style=
=3D"font-family:monospace,monospace">=C2=A0 =C2=A0 void set_weight(double s=
tone);</span>

<br style=3D"font-family:monospace,monospace"><span style=3D"font-family:mo=
nospace,monospace">=C2=A0 =C2=A0 void set_weight(double kilograms);</span><=
/div>

<p></p>

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

--000000000000b00e050574805296--

.

On 2018-08-28 11:16, Hyman Rosen wrote:
> On Tue, Aug 28, 2018 at 10:44 AM Matthew Woehlke wrote:
>> Well, we seem to be about split down the middle, between people for whom
>> having to make *any change at all* to declarations of existing functions
>> constitutes an "over my dead body" objection, and people for whom having
>> named arguments *not* be opt-in is an "over my dead body" objection.
>>
>> Since these two are diametrically opposed, we seem to be at an impasse.
>
> That's not true.

Really? Maybe I didn't express myself clearly...

> The version I (and others, I assume) are talking about requires no
> change to functions, existing or future, and is optional at the call
> site.
Right. And as has been stated *many times*, there are people that are
*strongly opposed* to this approach.

> The impasse, such as it is, exists for people who want to be able to
> declare functions that differ only in parameter names.
No. It exists for people that are *strongly opposed* to making something
that has never been API suddenly be API. That's what I meant by "not
opt-in". I'm not talking about whether or not *call sites* use named
arguments, I'm talking about whether or not the names that appear in
(existing) declarations are *allowed* to have meaning. Some people are
*adamant* that existing argument names are *not* given meaning without
some form of opt-in.

--
Matthew

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

.

--0000000000003b0cbf057480b64c
Content-Type: text/plain; charset="UTF-8"

On Tue, Aug 28, 2018 at 11:31 AM Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2018-08-28 11:16, Hyman Rosen wrote:
> > The version I (and others, I assume) are talking about requires no
> > change to functions, existing or future, and is optional at the call
> > site.
> Right. And as has been stated *many times*, there are people that are
> *strongly opposed* to this approach.


> The impasse, such as it is, exists for people who want to be able to
> > declare functions that differ only in parameter names.
> No. It exists for people that are *strongly opposed* to making something
> that has never been API suddenly be API. That's what I meant by "not
> opt-in". I'm not talking about whether or not *call sites* use named
> arguments, I'm talking about whether or not the names that appear in
> (existing) declarations are *allowed* to have meaning. Some people are
> *adamant* that existing argument names are *not* given meaning without
> some form of opt-in.
>

I don't know why using parameter names at the call site isn't opt-in enough,
but I guess control freaks will control.  To me, the argument that "nothing
has changed in my code, but you can't do what you want unless I let you"
is specious.  And it's only an impasse if there are enough of those people
to
actually block the feature (assuming it ever gets proposed again).

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

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Aug 28=
, 2018 at 11:31 AM Matthew Woehlke &lt;<a href=3D"mailto:mwoehlke.floss@gma=
il.com">mwoehlke.floss@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">On 2018-08-28 11:16, Hyman Rosen wrote:<br>
&gt; The version I (and others, I assume) are talking about requires no<br>
&gt; change to functions, existing or future, and is optional at the call <=
br>
&gt; site.<br>
Right. And as has been stated *many times*, there are people that are<br>
*strongly opposed* to this approach.</blockquote><div><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
&gt; The impasse, such as it is, exists for people who want to be able to <=
br>
&gt; declare functions that differ only in parameter names.<br>
No. It exists for people that are *strongly opposed* to making something<br=
>
that has never been API suddenly be API. That&#39;s what I meant by &quot;n=
ot<br>
opt-in&quot;. I&#39;m not talking about whether or not *call sites* use nam=
ed<br>
arguments, I&#39;m talking about whether or not the names that appear in<br=
>
(existing) declarations are *allowed* to have meaning. Some people are<br>
*adamant* that existing argument names are *not* given meaning without<br>
some form of opt-in.<br></blockquote><div><br>I don&#39;t know why using pa=
rameter names at the call site isn&#39;t opt-in enough,<br>but I guess cont=
rol freaks will control.=C2=A0 To me, the argument that &quot;nothing<br>ha=
s changed in my code, but you can&#39;t do what you want unless I let you&q=
uot;<br>is specious.=C2=A0 And it&#39;s only an impasse if there are enough=
 of those people to<br>actually block the feature (assuming it ever gets pr=
oposed again).</div></div></div>

<p></p>

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

--0000000000003b0cbf057480b64c--

.

On 2018-08-28 11:43, Hyman Rosen wrote:
> I don't know why using parameter names at the call site isn't opt-in enough,

....because right now, I, as a library author, can change or remove
argument names without breaking anything. If a non-opt-in proposal is
accepted, suddenly changing something that I used to be able to change
freely becomes a source-incompatible change.

That's not opt in in *any* way. That's "your proposal just *forced* me
to maintain a form of compatibility that didn't used to matter".

> And it's only an impasse if there are enough of those people
> to actually block the feature

I'm not about to bet against that.

I, personally, would *not* vote in favor of any proposal that does not
make named arguments opt-in (and I don't mean "at the call site"), no
matter how awesome it is otherwise. *At best* I would vote neutral.

> To me, the argument [...] is specious.

....which is exactly why we're at an impasse. There are multiple points
on which different parties hold conflicting views and, to all
appearances, are not willing to budge from those positions.

--
Matthew

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

.

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

On Tue, Aug 28, 2018 at 11:59 AM Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> That's not opt in in *any* way. That's "your proposal just *forced* me
> to maintain a form of compatibility that didn't used to matter".
>

In any case, even that sort of opt-in doesn't require an ABI change.  All
that is
needed is a marker on the parameter declarators that callers can use the
names.

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

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Aug 28=
, 2018 at 11:59 AM Matthew Woehlke &lt;<a href=3D"mailto:mwoehlke.floss@gma=
il.com">mwoehlke.floss@gmail.com</a>&gt; wrote:</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
That&#39;s not opt in in *any* way. That&#39;s &quot;your proposal just *fo=
rced* me<br>
to maintain a form of compatibility that didn&#39;t used to matter&quot;.<b=
r></blockquote><div><br>In any case, even that sort of opt-in doesn&#39;t r=
equire an ABI change.=C2=A0 All that is</div><div>needed is a marker on the=
 parameter declarators that callers can use the names.<br></div></div></div=
>

<p></p>

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

--000000000000cc5977057481091f--

.

--0000000000007632f40574810eb9
Content-Type: text/plain; charset="UTF-8"

On Tue, 28 Aug 2018, 16:59 Matthew Woehlke, <mwoehlke.floss@gmail.com>
wrote:

>  There are multiple points
> on which different parties hold conflicting views and, to all
> appearances, are not willing to budge from those positions.


This is exactly why this proposal is so controversial. I don't imagine that
the committee will be any less resistant.

That's why I suggested that we just allow named-member initialization of
structs and allow library devs to accept structs - ones that could in
future be automagically created by adding a keyword to a function - when
they want this functionality. I don't imagine that we will ever make any
progress by introducing something at the function level, and named-member
struct initialization solves reordering without butchering the language.

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

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

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, =
28 Aug 2018, 16:59 Matthew Woehlke, &lt;<a href=3D"mailto:mwoehlke.floss@gm=
ail.com">mwoehlke.floss@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">=C2=A0There are multiple points<br>
on which different parties hold conflicting views and, to all<br>
appearances, are not willing to budge from those positions.</blockquote></d=
iv></div><div dir=3D"auto"><br></div><div dir=3D"auto">This is exactly why =
this proposal is so controversial. I don&#39;t imagine that the committee w=
ill be any less resistant.</div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">That&#39;s why I suggested that we just allow named-member initializatio=
n of structs and allow library devs to accept structs - ones that could in =
future be automagically created by adding a keyword to a function - when th=
ey want this functionality. I don&#39;t imagine that we will ever make any =
progress by introducing something at the function level, and named-member s=
truct initialization solves reordering without butchering the language.</di=
v><div dir=3D"auto"></div></div>

<p></p>

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

--0000000000007632f40574810eb9--

.

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

On Tue, Aug 28, 2018 at 12:08 PM Jake Arkinstall <jake.arkinstall@gmail.com>
wrote:

> On Tue, 28 Aug 2018, 16:59 Matthew Woehlke, <mwoehlke.floss@gmail.com>
> wrote:
>
>>  There are multiple points on which different parties hold conflicting
>> views and, to all
>> appearances, are not willing to budge from those positions.
>
>
> This is exactly why this proposal is so controversial.
>
I don't imagine that the committee will be any less resistant.
>

Language design by consensus and committee seems kind of a bust.
We seem to get into these "this is why we can't have nice things"
situations a lot, where everyone wants some version of a feature,
people fight about details, and everyone gets nothing.

I we wish we could resurrect Jean Ichbiah and have him to work on C++.

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

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Aug 28=
, 2018 at 12:08 PM Jake Arkinstall &lt;<a href=3D"mailto:jake.arkinstall@gm=
ail.com">jake.arkinstall@gmail.com</a>&gt; wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=
=3D"ltr">On Tue, 28 Aug 2018, 16:59 Matthew Woehlke, &lt;<a href=3D"mailto:=
mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail.com</a>&gt=
; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">=C2=A0There are multiple p=
oints on which different parties hold conflicting views and, to all<br>
appearances, are not willing to budge from those positions.</blockquote></d=
iv></div><div dir=3D"auto"><br></div><div dir=3D"auto">This is exactly why =
this proposal is so controversial.=C2=A0</div></div></blockquote><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto"> I don&#39;t imagi=
ne that the committee will be any less resistant.</div></div></blockquote><=
div><br>Language design by consensus and committee seems kind of a bust.<br=
>We seem to get into these &quot;this is why we can&#39;t have nice things&=
quot;<br>situations a lot, where everyone wants some version of a feature,<=
br>people fight about details, and everyone gets nothing.<br><br>I we wish =
we could resurrect Jean Ichbiah and have him to work on C++.</div></div></d=
iv>

<p></p>

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

--000000000000d6cde5057482c779--

.

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

On Tue, 28 Aug 2018, 19:12 Hyman Rosen, <hyman.rosen@gmail.com> wrote:

> On Tue, Aug 28, 2018 at 12:08 PM Jake Arkinstall <
> jake.arkinstall@gmail.com> wrote:
>
>> On Tue, 28 Aug 2018, 16:59 Matthew Woehlke, <mwoehlke.floss@gmail.com>
>> wrote:
>>
>>>  There are multiple points on which different parties hold conflicting
>>> views and, to all
>>> appearances, are not willing to budge from those positions.
>>
>>
>> This is exactly why this proposal is so controversial.
>>
> I don't imagine that the committee will be any less resistant.
>>
>
> Language design by consensus and committee seems kind of a bust.
> We seem to get into these "this is why we can't have nice things"
> situations a lot, where everyone wants some version of a feature,
> people fight about details, and everyone gets nothing.
>

I'm not so sure. Not everyone wants this feature, and not everyone wants it
enough to justify the changes the implementation would require. The
committee is very good at preventing downsides that we didn't foresee.

What we *can* have is a small step towards a solution, and if it takes off
make another small step.

I'm convinced a named-member struct initialiser would suffice as this
midstep. The ability to have a function accepting parameters through a
struct constructed inline at the call site is a side effect, and that
ability is in the hands of the library developer rather than the user
(which is one thing I'm strongly for). The next step is stripping the
braces and making the struct implicit. No ABI breaks, no extreme language
changes in a single proposal, and I cant imagine step 1 would be remotely
controversial.

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

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

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, =
28 Aug 2018, 19:12 Hyman Rosen, &lt;<a href=3D"mailto:hyman.rosen@gmail.com=
">hyman.rosen@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Au=
g 28, 2018 at 12:08 PM Jake Arkinstall &lt;<a href=3D"mailto:jake.arkinstal=
l@gmail.com" target=3D"_blank" rel=3D"noreferrer">jake.arkinstall@gmail.com=
</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><=
div><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, 28 Aug 2018, 16:59 =
Matthew Woehlke, &lt;<a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"=
_blank" rel=3D"noreferrer">mwoehlke.floss@gmail.com</a>&gt; wrote:<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">=C2=A0There are multiple points on which di=
fferent parties hold conflicting views and, to all<br>
appearances, are not willing to budge from those positions.</blockquote></d=
iv></div><div dir=3D"auto"><br></div><div dir=3D"auto">This is exactly why =
this proposal is so controversial.=C2=A0</div></div></blockquote><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto"> I don&#39;t imagi=
ne that the committee will be any less resistant.</div></div></blockquote><=
div><br>Language design by consensus and committee seems kind of a bust.<br=
>We seem to get into these &quot;this is why we can&#39;t have nice things&=
quot;<br>situations a lot, where everyone wants some version of a feature,<=
br>people fight about details, and everyone gets nothing.<br></div></div></=
div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">=
I&#39;m not so sure. Not everyone wants this feature, and not everyone want=
s it enough to justify the changes the implementation would require. The co=
mmittee is very good at preventing downsides that we didn&#39;t foresee.</d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto">What we <i>can</i> have is=
 a small step towards a solution, and if it takes off make another small st=
ep.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I&#39;m convinced a =
named-member struct initialiser would suffice as this midstep. The ability =
to have a function accepting parameters through a struct constructed inline=
 at the call site is a side effect, and that ability is in the hands of the=
 library developer rather than the user (which is one thing I&#39;m strongl=
y for). The next step is stripping the braces and making the struct implici=
t. No ABI breaks, no extreme language changes in a single proposal, and I c=
ant imagine step 1 would be remotely controversial.</div></div>

<p></p>

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

--000000000000deb0a20574831086--

.

--000000000000561e51057483699e
Content-Type: text/plain; charset="UTF-8"

On Tue, Aug 28, 2018 at 2:32 PM Jake Arkinstall <jake.arkinstall@gmail.com>
wrote:

> I'm convinced a named-member struct initialiser would suffice as this
> midstep.
>

And I passionately hate this, so there you go.  Named arguments are named
arguments.
All you need is the compiler matching up names at the call with names in
the declaration,
not changing (even behind the scenes) what kind of parameters the function
accepts.

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

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Aug 28=
, 2018 at 2:32 PM Jake Arkinstall &lt;<a href=3D"mailto:jake.arkinstall@gma=
il.com">jake.arkinstall@gmail.com</a>&gt; wrote:</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"auto"><div dir=3D"auto">I&#39;m convinced a named-mem=
ber struct initialiser would suffice as this midstep.</div></div></blockquo=
te><div><br>And I passionately hate this, so there you go.=C2=A0 Named argu=
ments are named arguments.<br>All you need is the compiler matching up name=
s at the call with names in the declaration,<br>not changing (even behind t=
he scenes) what kind of parameters the function accepts.<br></div></div></d=
iv>

<p></p>

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

--000000000000561e51057483699e--

.

Le 27/08/2018 =C3=A0 17:10, Matthew Woehlke a =C3=A9crit=C2=A0:
> On 2018-08-25 01:23, mihailnajdenov@gmail.com wrote:
>> On Saturday, August 25, 2018 at 2:11:04 AM UTC+3, Vicente J. Botet Escri=
ba
>> wrote:
>>> Maybe you want forwarding, but then the name of the named parameter nee=
d
>>> to be part of the signature.
>> <snip>
>>> IMO, this is solved with tag dispatching and weak named
>>> parameters.
> How?
>
>    void complicated(int .a=3D1, int .b=3D42, int .c=3D10,
>                     double .x=3D0.25, string .s=3D"bar");
>
>    std::invoke(complicated, .b=3D7);
>
> How do you express this with tag dispatching? How do you support
> argument skipping (and maybe reordering) in the presence of forwarding
> with tag dispatching?
Well, this case don't needs tag dispatching

   complicated(.b=3D7);

If what you want is to call to some function that calls invoke,you can alwa=
ys use a lambda.

   std::invoke([]() { complicated(.b=3D7); });


Am I missing something?

>>> Le 24/08/2018 =C3=A0 19:39, Matthew Woehlke a =C3=A9crit :
>>>> Why do you think that a de jure standard will be more closely followed
>>>> than a de facto standard? In fact, considering that I can use the de
>>>> facto standard "weak arguments" *in C++98*, whereas the hypothetical d=
e
>>>> jure standard I can only follow if all my compilers support C++20 or
>>>> C++2x, I would rather expect the opposite...
>>> Sorry, but we are not talking here about C++98, but a possible feature =
for
>>> the future standard.
> You miss the point. What makes this *hypothetical* feature, which can't
> be practically adopted for many years, more likely to be useful than one
> that *already exists* and can be used even in C++98 code?
>
But, the fact that you can use something that is not satisfactory enough=20
already doesn't mean that we can not change to something better.

BTW, I have not see clang-tidy to do that yet. Give me a pointer if I'm=20
wrong.

Vicente

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a3848c3a-99f2-8c91-e03c-3c9d69d3eeb1%40wanadoo.f=
r.

.

This is a multi-part message in MIME format.
--------------A997B17A1F2171AB98A7339D
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 27/08/2018 =C3=A0 17:12, Jeremy Maitin-Shepard a =C3=A9crit=C2=A0:
> See https://clang.llvm.org/extra/clang-tidy/checks/bugprone-argument-comm=
ent.html for the clang-tidy check.
>
Thanks,

Vicente

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/d6c93eba-720f-735f-ff4c-bb21de9c1eff%40wanadoo.f=
r.

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

<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 27/08/2018 =C3=A0 17:12, Jeremy
      Maitin-Shepard a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"
      cite=3D"mid:fe78a713-1333-4b2c-900f-0e7ffed9c6f1@isocpp.org">
      <pre wrap=3D"">See <a class=3D"moz-txt-link-freetext" href=3D"https:/=
/clang.llvm.org/extra/clang-tidy/checks/bugprone-argument-comment.html">htt=
ps://clang.llvm.org/extra/clang-tidy/checks/bugprone-argument-comment.html<=
/a> for the clang-tidy check.

</pre>
    </blockquote>
    <p><font size=3D"+1">Thanks,</font></p>
    <p><font size=3D"+1">Vicente</font><br>
    </p>
  </body>
</html>

<p></p>

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

--------------A997B17A1F2171AB98A7339D--

.

--0000000000004dbc7c057491c447
Content-Type: text/plain; charset="UTF-8"

On Tue, 28 Aug 2018, 19:57 Hyman Rosen, <hyman.rosen@gmail.com> wrote:

> On Tue, Aug 28, 2018 at 2:32 PM Jake Arkinstall <jake.arkinstall@gmail.com>
> wrote:
>
>> I'm convinced a named-member struct initialiser would suffice as this
>> midstep.
>>
>
> And I passionately hate this, so there you go.  Named arguments are named
> arguments.
> All you need is the compiler matching up names at the call with names in
> the declaration,
> not changing (even behind the scenes) what kind of parameters the function
> accepts.
>

And that's why we have the committee and not one or two people making
decisions that impacts over a million developers.

But this still needs to be opt-in from the library developer. It has to.
Otherwise we risk permitting code that would never have compiled before
(giving a value to optional parameter N+1 without giving a value to
optional parameter N) and locking developers into naming schemes that they
didn't count on having to keep permanent.

So if we need to provide a way of users doing this explicitly, the
underlying implementation need not act as a function as we know it. If the
curly braces are too much to demand, we only need to provide a way of
implicitly converting a parameter list into a struct which can be
constructed in a name-based manner.

Why a struct? Because a struct's members already have names that are
externally relevant. Function parameters do not. Using a struct means that
we don't have to screw around with the language.

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

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

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
On Tue, 28 Aug 2018, 19:57 Hyman Rosen, &lt;<a href=3D"mailto:hyman.rosen@g=
mail.com">hyman.rosen@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">=
On Tue, Aug 28, 2018 at 2:32 PM Jake Arkinstall &lt;<a href=3D"mailto:jake.=
arkinstall@gmail.com" target=3D"_blank" rel=3D"noreferrer">jake.arkinstall@=
gmail.com</a>&gt; wrote:</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"au=
to"><div dir=3D"auto">I&#39;m convinced a named-member struct initialiser w=
ould suffice as this midstep.</div></div></blockquote><div><br>And I passio=
nately hate this, so there you go.=C2=A0 Named arguments are named argument=
s.<br>All you need is the compiler matching up names at the call with names=
 in the declaration,<br>not changing (even behind the scenes) what kind of =
parameters the function accepts.<br></div></div></div></blockquote></div></=
div><div dir=3D"auto"><br></div><div dir=3D"auto">And that&#39;s why we hav=
e the committee and not one or two people making decisions that impacts ove=
r a million developers.</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
But this still needs to be opt-in from the library developer. It has to. Ot=
herwise we risk permitting code that would never have compiled before (givi=
ng a value to optional parameter N+1 without giving a value to optional par=
ameter N) and locking developers into naming schemes that they didn&#39;t c=
ount on having to keep permanent.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">So if we need to provide a way of users doing this explicitly, th=
e underlying implementation need not act as a function as we know it. If th=
e curly braces are too much to demand, we only need to provide a way of imp=
licitly converting a parameter list into a struct which can be constructed =
in a name-based manner.</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
Why a struct? Because a struct&#39;s members already have names that are ex=
ternally relevant. Function parameters do not. Using a struct means that we=
 don&#39;t have to screw around with the language.</div></div>

<p></p>

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

--0000000000004dbc7c057491c447--

.

--00000000000044b453057492d0a5
Content-Type: text/plain; charset="UTF-8"

On Wed, Aug 29, 2018, 8:04 AM Jake Arkinstall <jake.arkinstall@gmail.com>
wrote:

>
>
> On Tue, 28 Aug 2018, 19:57 Hyman Rosen, <hyman.rosen@gmail.com> wrote:
>
>> On Tue, Aug 28, 2018 at 2:32 PM Jake Arkinstall <
>> jake.arkinstall@gmail.com> wrote:
>>
>>> I'm convinced a named-member struct initialiser would suffice as this
>>> midstep.
>>>
>>
>> And I passionately hate this, so there you go.  Named arguments are named
>> arguments.
>> All you need is the compiler matching up names at the call with names in
>> the declaration,
>> not changing (even behind the scenes) what kind of parameters the
>> function accepts.
>>
>
> And that's why we have the committee and not one or two people making
> decisions that impacts over a million developers.
>

I would still rather have that decision made by one person with a singular
and coherent vision.  Something like this recently happened in Python, over
assignment expressions.  Guido van Rossum, the singular vision guy, got an
extension into the language, but the fight was so acrimonious that he
subsequently resigned as dictator.

But this still needs to be opt-in from the library developer. It has to.
> Otherwise we risk permitting code that would never have compiled before
> (giving a value to optional parameter N+1 without giving a value to
> optional parameter N) and locking developers into naming schemes that they
> didn't count on having to keep permanent.
>

Again, I disagree.  Optional parameters have default values that callers
can duplicate, so your first obiection is irrelevant - people can always
have done that.  As for the second, there will be plenty of time for
library writers to adapt.  If the library is under maintenance, they'll
change the parameter names if they care.  If it isn't, the names will be
whatever they are.  Library writers hellbent on denying users the feature
can leave out parameter names in their declarations altogether.

So if we need to provide a way of users doing this explicitly, the
> underlying implementation need not act as a function as we know it. If the
> curly braces are too much to demand, we only need to provide a way of
> implicitly converting a parameter list into a struct which can be
> constructed in a name-based manner.
>

Since I don't think we need that, I think everything should stay the same
and leave named parameters purely as an internal compiler thing.

Why a struct? Because a struct's members already have names that are
> externally relevant. Function parameters do not. Using a struct means that
> we don't have to screw around with the language.
>

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

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

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, =
Aug 29, 2018, 8:04 AM Jake Arkinstall &lt;<a href=3D"mailto:jake.arkinstall=
@gmail.com">jake.arkinstall@gmail.com</a>&gt; wrote:<br></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"auto"><div><br><br><div class=3D"gmail_quote"=
><div dir=3D"ltr">On Tue, 28 Aug 2018, 19:57 Hyman Rosen, &lt;<a href=3D"ma=
ilto:hyman.rosen@gmail.com" target=3D"_blank" rel=3D"noreferrer">hyman.rose=
n@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Aug 28, 2018 a=
t 2:32 PM Jake Arkinstall &lt;<a href=3D"mailto:jake.arkinstall@gmail.com" =
rel=3D"noreferrer noreferrer" target=3D"_blank">jake.arkinstall@gmail.com</=
a>&gt; wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div di=
r=3D"auto">I&#39;m convinced a named-member struct initialiser would suffic=
e as this midstep.</div></div></blockquote><div><br>And I passionately hate=
 this, so there you go.=C2=A0 Named arguments are named arguments.<br>All y=
ou need is the compiler matching up names at the call with names in the dec=
laration,<br>not changing (even behind the scenes) what kind of parameters =
the function accepts.<br></div></div></div></blockquote></div></div><div di=
r=3D"auto"><br></div><div dir=3D"auto">And that&#39;s why we have the commi=
ttee and not one or two people making decisions that impacts over a million=
 developers.</div></div></blockquote></div></div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">I would still rather have that decision made by one per=
son with a singular and coherent vision.=C2=A0 Something like this recently=
 happened in Python, over assignment expressions.=C2=A0 Guido van Rossum, t=
he singular vision guy, got an extension into the language, but the fight w=
as so acrimonious that he subsequently resigned as dictator.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto">But this still nee=
ds to be opt-in from the library developer. It has to. Otherwise we risk pe=
rmitting code that would never have compiled before (giving a value to opti=
onal parameter N+1 without giving a value to optional parameter N) and lock=
ing developers into naming schemes that they didn&#39;t count on having to =
keep permanent.</div></div></blockquote></div></div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">Again, I disagree.=C2=A0 Optional parameters have de=
fault values that callers can duplicate, so your first obiection is irrelev=
ant - people can always have done that.=C2=A0 As for the second, there will=
 be plenty of time for library writers to adapt.=C2=A0 If the library is un=
der maintenance, they&#39;ll change the parameter names if they care.=C2=A0=
 If it isn&#39;t, the names will be whatever they are.=C2=A0 Library writer=
s hellbent on denying users the feature can leave out parameter names in th=
eir declarations altogether.</div><div dir=3D"auto"><br></div><div dir=3D"a=
uto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
auto"><div dir=3D"auto">So if we need to provide a way of users doing this =
explicitly, the underlying implementation need not act as a function as we =
know it. If the curly braces are too much to demand, we only need to provid=
e a way of implicitly converting a parameter list into a struct which can b=
e constructed in a name-based manner.</div></div></blockquote></div></div><=
div dir=3D"auto"><br></div><div dir=3D"auto">Since I don&#39;t think we nee=
d that, I think everything should stay the same and leave named parameters =
purely as an internal compiler thing.</div><div dir=3D"auto"><br></div><div=
 dir=3D"auto"><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"><di=
v dir=3D"auto"><div dir=3D"auto">Why a struct? Because a struct&#39;s membe=
rs already have names that are externally relevant. Function parameters do =
not. Using a struct means that we don&#39;t have to screw around with the l=
anguage.</div></div>
</blockquote></div></div></div>

<p></p>

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

--00000000000044b453057492d0a5--

.

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

On Wed, 29 Aug 2018, 14:19 Hyman Rosen, <hyman.rosen@gmail.com> wrote:

> Again, I disagree.  Optional parameters have default values that callers
> can duplicate, so your first obiection is irrelevant - people can always
> have done that.
>

It's possible to, but it then becomes a conscious effort, and the user has
presumably read the documentation and may know of unwanted behaviour. It's
possible and reasonable to assume that there exist functions which branch
off of each successive parameter - not good design, but it works. It's
reasonable because the existence of prior parameters is an established
fact, and users knowingly entering an error value for a previous parameter
do so intentionally. With named parameters, they may do so
*unintentionally.*

Sure, that's not a breaking change in the traditional sense. But changing
the way parameters are injected will mean that a trusty old API can turn
into a confusing mess. That's why I'd rather the control remain in the
hands of the library writers - adding a new way of interacting with their
code means they have something new to worry about inside unchanged code.

In any other language that would be something I wouldn't care so much
about. But C++ code in the wild has the tendency to move forward at the
rate of treacle, and adding a new potential site for bugs concerns me.
That's the reason I'd want this to be opt-in.

As for the second, there will be plenty of time for library writers to
> adapt.  If the library is under maintenance, they'll change the parameter
> names if they care.  If it isn't, the names will be whatever they are.
> Library writers hellbent on denying users the feature can leave out
> parameter names in their declarations altogether.
>

That they can. But they still have to change it. We have never functioned
based off of "there will be plenty of time for library writers to adapt"
and I don't see why we should start now.


> So if we need to provide a way of users doing this explicitly, the
>> underlying implementation need not act as a function as we know it. If the
>> curly braces are too much to demand, we only need to provide a way of
>> implicitly converting a parameter list into a struct which can be
>> constructed in a name-based manner.
>>
>
> Since I don't think we need that, I think everything should stay the same
> and leave named parameters purely as an internal compiler thing.
>

Though we still have to force them to work in a certain way because
instruction ordering needs to be consistent.

void f(int a, int b);

int x = 0;
f(.b = ++x, .a = ++x);

Does 'a' get given the value 1 or 2? The approach used by compilers will
need to do this consistently, and thus we are pinning them to an
implementation. While we're doing that, being able to call

f(.a=some_expensive_function(), .b=.a);

Might be useful to someone out there.

>

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

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

<div dir=3D"auto"><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr">=
On Wed, 29 Aug 2018, 14:19 Hyman Rosen, &lt;<a href=3D"mailto:hyman.rosen@g=
mail.com">hyman.rosen@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D=
"ltr">Again, I disagree.=C2=A0 Optional parameters have default values that=
 callers can duplicate, so your first obiection is irrelevant - people can =
always have done that.</div></div></div></div></blockquote></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">It&#39;s possible to, but it then bec=
omes a conscious effort, and the user has presumably read the documentation=
 and may know of unwanted behaviour. It&#39;s possible and reasonable to as=
sume that there exist functions which branch off of each successive paramet=
er - not good design, but it works. It&#39;s reasonable because the existen=
ce of prior parameters is an established fact, and users knowingly entering=
 an error value for a previous parameter do so intentionally. With named pa=
rameters, they may do so <i>unintentionally.</i></div><div dir=3D"auto"><br=
></div><div dir=3D"auto">Sure, that&#39;s not a breaking change in the trad=
itional sense. But changing the way parameters are injected will mean that =
a trusty old API can turn into a confusing mess. That&#39;s why I&#39;d rat=
her the control remain in the hands of the library writers - adding a new w=
ay of interacting with their code means they have something new to worry ab=
out inside unchanged code.</div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">In any other language that would be something I wouldn&#39;t care so muc=
h about. But C++ code in the wild has the tendency to move forward at the r=
ate of treacle, and adding a new potential site for bugs concerns me. That&=
#39;s the reason I&#39;d want this to be opt-in.</div><div dir=3D"auto"><br=
></div><div class=3D"gmail_quote" dir=3D"auto"><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"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr"> As f=
or the second, there will be plenty of time for library writers to adapt.=
=C2=A0 If the library is under maintenance, they&#39;ll change the paramete=
r names if they care.=C2=A0 If it isn&#39;t, the names will be whatever the=
y are.=C2=A0 Library writers hellbent on denying users the feature can leav=
e out parameter names in their declarations altogether.<br></div></div></di=
v></div></blockquote></div><div dir=3D"auto"><br></div><div dir=3D"auto">Th=
at they can. But they still have to change it. We have never functioned bas=
ed off of &quot;there will be plenty of time for library writers to adapt&q=
uot; and I don&#39;t see why we should start now.</div><div dir=3D"auto"><b=
r></div><div class=3D"gmail_quote" dir=3D"auto"><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr"></di=
v></div></div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div dir=3D"au=
to">So if we need to provide a way of users doing this explicitly, the unde=
rlying implementation need not act as a function as we know it. If the curl=
y braces are too much to demand, we only need to provide a way of implicitl=
y converting a parameter list into a struct which can be constructed in a n=
ame-based manner.</div></div></blockquote></div></div><div dir=3D"auto"><br=
></div><div dir=3D"auto">Since I don&#39;t think we need that, I think ever=
ything should stay the same and leave named parameters purely as an interna=
l compiler thing.</div></div></blockquote></div><div dir=3D"auto"><br></div=
><div dir=3D"auto">Though we still have to force them to work in a certain =
way because instruction ordering needs to be consistent.</div><div class=3D=
"gmail_quote" dir=3D"auto"></div><div dir=3D"auto"><br></div><div dir=3D"au=
to"><div dir=3D"auto" style=3D"font-family:sans-serif">void f(int a, int b)=
;</div><div dir=3D"auto" style=3D"font-family:sans-serif"><br></div><div di=
r=3D"auto" style=3D"font-family:sans-serif">int x =3D 0;</div><div dir=3D"a=
uto" style=3D"font-family:sans-serif">f(.b =3D ++x, .a =3D ++x);</div><div =
dir=3D"auto" style=3D"font-family:sans-serif"><br></div><div dir=3D"auto" s=
tyle=3D"font-family:sans-serif">Does &#39;a&#39; get given the value 1 or 2=
? The approach used by compilers will need to do this consistently, and thu=
s we are pinning them to an implementation. While we&#39;re doing that, bei=
ng able to call</div><div dir=3D"auto" style=3D"font-family:sans-serif"><br=
></div><div dir=3D"auto" style=3D"font-family:sans-serif">f(.a=3Dsome_expen=
sive_function(), .b=3D.a);</div><div dir=3D"auto" style=3D"font-family:sans=
-serif"><br></div><div dir=3D"auto" style=3D"font-family:sans-serif">Might =
be useful to someone out there.</div></div><div class=3D"gmail_quote" dir=
=3D"auto"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div>

<p></p>

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

--000000000000b84ab4057493d5b1--

.

On 2018-08-29 10:32, Jake Arkinstall wrote:
> Though we still have to force them to work in a certain way because
> instruction ordering needs to be consistent.
>
> void f(int a, int b);
>
> int x = 0;
> f(.b = ++x, .a = ++x);
>
> Does 'a' get given the value 1 or 2?

AFAIUI, this is unspecified.

Let me clarify:

  void f(int a, int b);

  int x = 0;
  f(++x, ++x);

*This is (still) unspecified* (again, AIUI). We guarantee that the
arguments to `f` will be 1 and 2 (not 1 and 1, or 2 and 2, which was
*not* true before C++17), but not whether you will get a=1, b=2 or a=2, b=1.

Reordering won't make this any worse.

> f(.a=some_expensive_function(), .b=.a);
>
> Might be useful to someone out there.

Right now, even with any of the named arguments ideas, that's a syntax
error. It *might* be useful, but I think it needs its own, separate
proposal, if we ever get to the point where it would be feasible to
consider it.

--
Matthew

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

.

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

On Wed, Aug 29, 2018 at 3:04 PM Jake Arkinstall <jake.arkinstall@gmail.com>
wrote:

>
>
> On Tue, 28 Aug 2018, 19:57 Hyman Rosen, <hyman.rosen@gmail.com> wrote:
>
>> On Tue, Aug 28, 2018 at 2:32 PM Jake Arkinstall <
>> jake.arkinstall@gmail.com> wrote:
>>
>>> I'm convinced a named-member struct initialiser would suffice as this
>>> midstep.
>>>
>>
>> And I passionately hate this, so there you go.  Named arguments are named
>> arguments.
>> All you need is the compiler matching up names at the call with names in
>> the declaration,
>> not changing (even behind the scenes) what kind of parameters the
>> function accepts.
>>
>
> And that's why we have the committee and not one or two people making
> decisions that impacts over a million developers.
>
> But this still needs to be opt-in from the library developer. It has to.
> Otherwise we risk permitting code that would never have compiled before
> (giving a value to optional parameter N+1 without giving a value to
> optional parameter N) and locking developers into naming schemes that they
> didn't count on having to keep permanent.
>
> So if we need to provide a way of users doing this explicitly, the
> underlying implementation need not act as a function as we know it. If the
> curly braces are too much to demand, we only need to provide a way of
> implicitly converting a parameter list into a struct which can be
> constructed in a name-based manner.
>
> Why a struct? Because a struct's members already have names that are
> externally relevant. Function parameters do not. Using a struct means that
> we don't have to screw around with the language.
>

I can't see a struct working as an official solution. It will radically
change both the declaration (one param vs N) and the implementation
(structured bindings to the rescue?).
It will also have both code size and performance effect.

Named arguments are well established machinery, both language level type
and compiler-only type.

I think we need a paper which presents all options, without much details,
let alone syntax, and ask the committee for direction.
They will vote pro or contra names as part of the typesystem, compiler
based, some hybrid (compiler based + better tags/ strong typedef/ inline
structs or something)

The details will come easily afterwards. In any case there will be happy
people and unhappy, that is for sure, but any names are better then none
and after all it is not for the community to make a decision.


--
> 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/MbDT0vsA2j0/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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPpyfJEj_kHyNFGG0Q17BfGPyAtL23PrujdmKe5y-3vJA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPpyfJEj_kHyNFGG0Q17BfGPyAtL23PrujdmKe5y-3vJA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

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

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

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed=
, Aug 29, 2018 at 3:04 PM Jake Arkinstall &lt;<a href=3D"mailto:jake.arkins=
tall@gmail.com">jake.arkinstall@gmail.com</a>&gt; wrote:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"auto"><div><br><br><div class=3D"gmail_qu=
ote"><div dir=3D"ltr">On Tue, 28 Aug 2018, 19:57 Hyman Rosen, &lt;<a href=
=3D"mailto:hyman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
 class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Aug 28, 2018 at 2:32 PM Jak=
e Arkinstall &lt;<a href=3D"mailto:jake.arkinstall@gmail.com" target=3D"_bl=
ank" rel=3D"noreferrer">jake.arkinstall@gmail.com</a>&gt; wrote:</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto">I&#39;m convi=
nced a named-member struct initialiser would suffice as this midstep.</div>=
</div></blockquote><div><br>And I passionately hate this, so there you go.=
=C2=A0 Named arguments are named arguments.<br>All you need is the compiler=
 matching up names at the call with names in the declaration,<br>not changi=
ng (even behind the scenes) what kind of parameters the function accepts.<b=
r></div></div></div></blockquote></div></div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">And that&#39;s why we have the committee and not one or two=
 people making decisions that impacts over a million developers.</div><div =
dir=3D"auto"><br></div><div dir=3D"auto">But this still needs to be opt-in =
from the library developer. It has to. Otherwise we risk permitting code th=
at would never have compiled before (giving a value to optional parameter N=
+1 without giving a value to optional parameter N) and locking developers i=
nto naming schemes that they didn&#39;t count on having to keep permanent.<=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">So if we need to provide=
 a way of users doing this explicitly, the underlying implementation need n=
ot act as a function as we know it. If the curly braces are too much to dem=
and, we only need to provide a way of implicitly converting a parameter lis=
t into a struct which can be constructed in a name-based manner.</div><div =
dir=3D"auto"><br></div><div dir=3D"auto">Why a struct? Because a struct&#39=
;s members already have names that are externally relevant. Function parame=
ters do not. Using a struct means that we don&#39;t have to screw around wi=
th the language.</div></div></blockquote><div><br></div><div>I can&#39;t se=
e a struct working as an official solution. It will radically change both t=
he declaration (one param vs N) and the implementation (structured bindings=
 to the rescue?).</div><div>It will also have both code size and performanc=
e effect.<br></div><div><br></div><div>Named arguments are well established=
 machinery, both language level type and compiler-only type.</div><div><br>=
</div><div>I think we need a paper which presents all options, without much=
 details, let alone syntax, and ask the committee for direction.=C2=A0</div=
><div>They will vote pro or contra names as part of the typesystem, compile=
r based, some hybrid (compiler based + better tags/ strong typedef/ inline =
structs or something)</div><div><br></div><div>The details will come easily=
 afterwards. In any case there will be happy people and unhappy, that is fo=
r sure, but any names are better then none and after all it is not for the =
community to make a decision.</div><div><br></div><div><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">

<p></p>

-- <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/MbDT0vsA2j0/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/MbDT0vsA2j0=
/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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPpyfJEj_kHyNFGG0Q17BfGPyAtL2=
3PrujdmKe5y-3vJA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAC%2B0CCPpyfJEj_kHyNFGG0Q17BfGPyAtL23PrujdmKe5y-3vJA%40mail.gmail.c=
om</a>.<br>
</blockquote></div></div>

<p></p>

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

--000000000000cbf38805749706f3--

.

------=_Part_2063_2130184375.1535567019939
Content-Type: multipart/alternative;
 boundary="----=_Part_2064_1997835791.1535567019939"

------=_Part_2064_1997835791.1535567019939
Content-Type: text/plain; charset="UTF-8"



On Wednesday, August 29, 2018 at 3:04:58 PM UTC+3, Jake Arkinstall wrote:
>
>
>
> On Tue, 28 Aug 2018, 19:57 Hyman Rosen, <hyman...@gmail.com <javascript:>>
> wrote:
>
>> On Tue, Aug 28, 2018 at 2:32 PM Jake Arkinstall <jake.ar...@gmail.com
>> <javascript:>> wrote:
>>
>>> I'm convinced a named-member struct initialiser would suffice as this
>>> midstep.
>>>
>>
>> And I passionately hate this, so there you go.  Named arguments are named
>> arguments.
>> All you need is the compiler matching up names at the call with names in
>> the declaration,
>> not changing (even behind the scenes) what kind of parameters the
>> function accepts.
>>
>
> And that's why we have the committee and not one or two people making
> decisions that impacts over a million developers.
>
> But this still needs to be opt-in from the library developer. It has to.
> Otherwise we risk permitting code that would never have compiled before
> (giving a value to optional parameter N+1 without giving a value to
> optional parameter N) and locking developers into naming schemes that they
> didn't count on having to keep permanent.
>
> So if we need to provide a way of users doing this explicitly, the
> underlying implementation need not act as a function as we know it. If the
> curly braces are too much to demand, we only need to provide a way of
> implicitly converting a parameter list into a struct which can be
> constructed in a name-based manner.
>
> Why a struct? Because a struct's members already have names that are
> externally relevant. Function parameters do not. Using a struct means that
> we don't have to screw around with the language.
>

I can't see a struct working as an official solution. It will radically
change both the declaration (one param vs N) and the implementation
(structured bindings to the rescue?).
It will also have both code size and performance effect.

Named arguments are well established machinery, both language level type
and compiler-only type.

I think we need a paper which presents all options, without much details,
let alone syntax, and ask the committee for direction.
They will vote pro or contra names as part of the typesystem, compiler
based, some hybrid (compiler based + better tags/ strong typedef/ inline
structs or something)

The details will come easily afterwards. In any case there will be happy
people and unhappy, that is for sure, but any names are better then none
and after all it is not for the community to make a decision.


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/735cf8f8-41e8-49b3-9dec-1ff47e2a47f8%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Wednesday, August 29, 2018 at 3:04:58 PM UTC+3,=
 Jake Arkinstall wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue,=
 28 Aug 2018, 19:57 Hyman Rosen, &lt;<a onmousedown=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;re=
turn true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obf=
uscated-mailto=3D"_5A_PKMPCAAJ">hyman...@gmail.com</a>&gt; wrote:<br></div>=
<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_quote">=
<div dir=3D"ltr">On Tue, Aug 28, 2018 at 2:32 PM Jake Arkinstall &lt;<a onm=
ousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this=
..href=3D&#39;javascript:&#39;;return true;" href=3D"javascript:" target=3D"=
_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"_5A_PKMPCAAJ">jake.ar...@=
gmail.com</a>&gt; wrote:</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"au=
to"><div dir=3D"auto">I&#39;m convinced a named-member struct initialiser w=
ould suffice as this midstep.</div></div></blockquote><div><br>And I passio=
nately hate this, so there you go.=C2=A0 Named arguments are named argument=
s.<br>All you need is the compiler matching up names at the call with names=
 in the declaration,<br>not changing (even behind the scenes) what kind of =
parameters the function accepts.<br></div></div></div></blockquote></div></=
div><div dir=3D"auto"><br></div><div dir=3D"auto">And that&#39;s why we hav=
e the committee and not one or two people making decisions that impacts ove=
r a million developers.</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
But this still needs to be opt-in from the library developer. It has to. Ot=
herwise we risk permitting code that would never have compiled before (givi=
ng a value to optional parameter N+1 without giving a value to optional par=
ameter N) and locking developers into naming schemes that they didn&#39;t c=
ount on having to keep permanent.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">So if we need to provide a way of users doing this explicitly, th=
e underlying implementation need not act as a function as we know it. If th=
e curly braces are too much to demand, we only need to provide a way of imp=
licitly converting a parameter list into a struct which can be constructed =
in a name-based manner.</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
Why a struct? Because a struct&#39;s members already have names that are ex=
ternally relevant. Function parameters do not. Using a struct means that we=
 don&#39;t have to screw around with the language.</div></div></blockquote>=
<div><br></div><div><div style=3D"background-color: transparent; color: rgb=
(34, 34, 34); font-family: Arial,Helvetica,sans-serif; font-size: 13.33px; =
font-size-adjust: none; font-stretch: 100%; font-style: normal; font-varian=
t: normal; font-weight: 400; letter-spacing: normal; line-height: 19.99px; =
orphans: 2; overflow: visible; text-align: left; text-decoration: none; tex=
t-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-=
space: normal; word-spacing: 0px;">I can&#39;t see a struct working as an o=
fficial solution. It will radically change both the declaration (one param =
vs N) and the implementation (structured bindings to the rescue?).</div><di=
v style=3D"background-color: transparent; color: rgb(34, 34, 34); font-fami=
ly: Arial,Helvetica,sans-serif; font-size: 13.33px; font-size-adjust: none;=
 font-stretch: 100%; font-style: normal; font-variant: normal; font-weight:=
 400; letter-spacing: normal; line-height: 19.99px; orphans: 2; overflow: v=
isible; text-align: left; text-decoration: none; text-indent: 0px; text-tra=
nsform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spa=
cing: 0px;">It will also have both code size and performance effect.<br sty=
le=3D"font-family: Arial,Helvetica,sans-serif; font-size: 13.33px; font-siz=
e-adjust: none; font-stretch: 100%; font-style: normal; font-variant: norma=
l; font-weight: 400; line-height: 19.99px; overflow: visible;"></div><div s=
tyle=3D"background-color: transparent; color: rgb(34, 34, 34); font-family:=
 Arial,Helvetica,sans-serif; font-size: 13.33px; font-size-adjust: none; fo=
nt-stretch: 100%; font-style: normal; font-variant: normal; font-weight: 40=
0; letter-spacing: normal; line-height: 19.99px; orphans: 2; overflow: visi=
ble; text-align: left; text-decoration: none; text-indent: 0px; text-transf=
orm: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacin=
g: 0px;"><br style=3D"font-family: Arial,Helvetica,sans-serif; font-size: 1=
3.33px; font-size-adjust: none; font-stretch: 100%; font-style: normal; fon=
t-variant: normal; font-weight: 400; line-height: 19.99px; overflow: visibl=
e;"></div><div style=3D"background-color: transparent; color: rgb(34, 34, 3=
4); font-family: Arial,Helvetica,sans-serif; font-size: 13.33px; font-size-=
adjust: none; font-stretch: 100%; font-style: normal; font-variant: normal;=
 font-weight: 400; letter-spacing: normal; line-height: 19.99px; orphans: 2=
; overflow: visible; text-align: left; text-decoration: none; text-indent: =
0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: nor=
mal; word-spacing: 0px;">Named arguments are well established machinery, bo=
th language level type and compiler-only type.</div><div style=3D"backgroun=
d-color: transparent; color: rgb(34, 34, 34); font-family: Arial,Helvetica,=
sans-serif; font-size: 13.33px; font-size-adjust: none; font-stretch: 100%;=
 font-style: normal; font-variant: normal; font-weight: 400; letter-spacing=
: normal; line-height: 19.99px; orphans: 2; overflow: visible; text-align: =
left; text-decoration: none; text-indent: 0px; text-transform: none; -webki=
t-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"><br styl=
e=3D"font-family: Arial,Helvetica,sans-serif; font-size: 13.33px; font-size=
-adjust: none; font-stretch: 100%; font-style: normal; font-variant: normal=
; font-weight: 400; line-height: 19.99px; overflow: visible;"></div><div st=
yle=3D"background-color: transparent; color: rgb(34, 34, 34); font-family: =
Arial,Helvetica,sans-serif; font-size: 13.33px; font-size-adjust: none; fon=
t-stretch: 100%; font-style: normal; font-variant: normal; font-weight: 400=
; letter-spacing: normal; line-height: 19.99px; orphans: 2; overflow: visib=
le; text-align: left; text-decoration: none; text-indent: 0px; text-transfo=
rm: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing=
: 0px;">I think we need a paper which presents all options, without much de=
tails, let alone syntax, and ask the committee for direction.=C2=A0</div><d=
iv style=3D"background-color: transparent; color: rgb(34, 34, 34); font-fam=
ily: Arial,Helvetica,sans-serif; font-size: 13.33px; font-size-adjust: none=
; font-stretch: 100%; font-style: normal; font-variant: normal; font-weight=
: 400; letter-spacing: normal; line-height: 19.99px; orphans: 2; overflow: =
visible; text-align: left; text-decoration: none; text-indent: 0px; text-tr=
ansform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-sp=
acing: 0px;">They will vote pro or contra names as part of the typesystem, =
compiler based, some hybrid (compiler based + better tags/ strong typedef/ =
inline structs or something)</div><div style=3D"background-color: transpare=
nt; color: rgb(34, 34, 34); font-family: Arial,Helvetica,sans-serif; font-s=
ize: 13.33px; font-size-adjust: none; font-stretch: 100%; font-style: norma=
l; font-variant: normal; font-weight: 400; letter-spacing: normal; line-hei=
ght: 19.99px; orphans: 2; overflow: visible; text-align: left; text-decorat=
ion: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-widt=
h: 0px; white-space: normal; word-spacing: 0px;"><br style=3D"font-family: =
Arial,Helvetica,sans-serif; font-size: 13.33px; font-size-adjust: none; fon=
t-stretch: 100%; font-style: normal; font-variant: normal; font-weight: 400=
; line-height: 19.99px; overflow: visible;"></div><div style=3D"background-=
color: transparent; color: rgb(34, 34, 34); font-family: Arial,Helvetica,sa=
ns-serif; font-size: 13.33px; font-size-adjust: none; font-stretch: 100%; f=
ont-style: normal; font-variant: normal; font-weight: 400; letter-spacing: =
normal; line-height: 19.99px; orphans: 2; overflow: visible; text-align: le=
ft; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-=
text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">The detail=
s will come easily afterwards. In any case there will be happy people and u=
nhappy, that is for sure, but any names are better then none and after all =
it is not for the community to make a decision.</div>=C2=A0</div></div>

<p></p>

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

------=_Part_2064_1997835791.1535567019939--

------=_Part_2063_2130184375.1535567019939--

.

--00000000000012be7a05749886f2
Content-Type: text/plain; charset="UTF-8"

On Wed, 29 Aug 2018, 19:23 , <mihailnajdenov@gmail.com> wrote:

>
> I can't see a struct working as an official solution. It will radically
> change both the declaration (one param vs N) and the implementation
> (structured bindings to the rescue?).
> It will also have both code size and performance effect.
>

In terms of the declaration, I'm thinking of a keyword that automatically
creates a parameter struct overload for a function. This is thus a strictly
opt-in approach (so won't suit everyone).

void f(int a, int b, int c = 0) named;
void f(int a, int b, int c = 0) named_only;

Produces:

void f(int a, int b, int c = 0);
struct f_params{
    int a;
    int b;
    int c = 0;
};
void f(f_params p){
    f(p.a, p.b, p.c);
}

struct g_params{
    int a;
    int b;
    int c = 0;
};
void g(g_params); // internals rewritten to swap a, b, c to g_params.a,
g_params.b, g_params.c.


And on the call site:

f({.a = 4, .b = 5, .c = 1 }); // already valid

Same with g. We can try to get the removal of braces for these calls (but
not for general calls with structs as parameters) into a proposal:

g(.a=4, .b=5, .c=1);

In terms of getting reorderable parameters, that requires a change to
designated initializers, which don't currently accept arguments in an order
other than the declaration (I don't see why not. C allows it.)

Performance wise, no noticeable change that I can think of (why would there
be?). Code size impact is dependant on the use of named vs named_only.


> Named arguments are well established machinery, both language level type
> and compiler-only type.
>
> I think we need a paper which presents all options, without much details,
> let alone syntax, and ask the committee for direction.
> They will vote pro or contra names as part of the typesystem, compiler
> based, some hybrid (compiler based + better tags/ strong typedef/ inline
> structs or something)
>
> The details will come easily afterwards. In any case there will be happy
> people and unhappy, that is for sure, but any names are better then none
> and after all it is not for the community to make a decision.
>
>

Very good point. Agreed.

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

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

<div dir=3D"auto"><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr">=
On Wed, 29 Aug 2018, 19:23 , &lt;<a href=3D"mailto:mihailnajdenov@gmail.com=
">mihailnajdenov@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"><div><br></div><div><div style=3D"background-color:tran=
sparent;color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-siz=
e:13.33px;font-size-adjust:none;font-stretch:100%;font-style:normal;font-va=
riant:normal;font-weight:400;letter-spacing:normal;line-height:19.99px;over=
flow:visible;text-align:left;text-decoration:none;text-indent:0px;text-tran=
sform:none;white-space:normal;word-spacing:0px">I can&#39;t see a struct wo=
rking as an official solution. It will radically change both the declaratio=
n (one param vs N) and the implementation (structured bindings to the rescu=
e?).</div><div style=3D"background-color:transparent;color:rgb(34,34,34);fo=
nt-family:Arial,Helvetica,sans-serif;font-size:13.33px;font-size-adjust:non=
e;font-stretch:100%;font-style:normal;font-variant:normal;font-weight:400;l=
etter-spacing:normal;line-height:19.99px;overflow:visible;text-align:left;t=
ext-decoration:none;text-indent:0px;text-transform:none;white-space:normal;=
word-spacing:0px">It will also have both code size and performance effect.<=
br style=3D"font-family:Arial,Helvetica,sans-serif;font-size:13.33px;font-s=
ize-adjust:none;font-stretch:100%;font-style:normal;font-variant:normal;fon=
t-weight:400;line-height:19.99px;overflow:visible"></div></div></div></bloc=
kquote></div><div dir=3D"auto"><br></div><div dir=3D"auto">In terms of the =
declaration, I&#39;m thinking of a keyword that automatically creates a par=
ameter struct overload for a function. This is thus a strictly opt-in appro=
ach (so won&#39;t suit everyone).</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">void f(int a, int b, int c =3D 0) named;</div><div dir=3D"auto"><=
span style=3D"font-family:sans-serif">void f(int a, int b, int c =3D 0) nam=
ed_only;</span><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Prod=
uces:</div><div dir=3D"auto"><br></div><div dir=3D"auto">void f(int a, int =
b, int c =3D 0);</div><div dir=3D"auto">struct f_params{</div><div dir=3D"a=
uto">=C2=A0 =C2=A0 int a;</div><div dir=3D"auto">=C2=A0 =C2=A0 int b;</div>=
<div dir=3D"auto">=C2=A0 =C2=A0 int c =3D 0;</div><div dir=3D"auto">};</div=
><div dir=3D"auto">void f(f_params p){</div><div dir=3D"auto">=C2=A0 =C2=A0=
 f(p.a, p.b, p.c);</div><div dir=3D"auto">}</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">struct g_params{</div><div dir=3D"auto">=C2=A0 =C2=A0 i=
nt a;</div><div dir=3D"auto">=C2=A0 =C2=A0 int b;</div><div dir=3D"auto">=
=C2=A0 =C2=A0 int c =3D 0;</div><div dir=3D"auto">};</div><div dir=3D"auto"=
>void g(g_params); // internals rewritten to swap a, b, c to g_params.a, g_=
params.b, g_params.c.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">And on the call site:</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">f({.a =3D 4, .b =3D 5, .c =3D 1 }); // already vali=
d</div><div dir=3D"auto"><br></div><div dir=3D"auto">Same with g. We can tr=
y to get the removal of braces for these calls (but not for general calls w=
ith structs as parameters) into a proposal:</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">g(.a=3D4, .b=3D5, .c=3D1);</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">In terms of getting reorderable parameters, that req=
uires a change to designated initializers, which don&#39;t currently accept=
 arguments in an order other than the declaration (I don&#39;t see why not.=
 C allows it.)</div><div dir=3D"auto"><br></div><div dir=3D"auto">Performan=
ce wise, no noticeable change that I can think of (why would there be?). Co=
de size impact is dependant on the use of named vs named_only.</div><div di=
r=3D"auto"><br></div><div class=3D"gmail_quote" dir=3D"auto"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div><div style=3D"background-color:trans=
parent;color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size=
:13.33px;font-size-adjust:none;font-stretch:100%;font-style:normal;font-var=
iant:normal;font-weight:400;letter-spacing:normal;line-height:19.99px;overf=
low:visible;text-align:left;text-decoration:none;text-indent:0px;text-trans=
form:none;white-space:normal;word-spacing:0px"></div><div style=3D"backgrou=
nd-color:transparent;color:rgb(34,34,34);font-family:Arial,Helvetica,sans-s=
erif;font-size:13.33px;font-size-adjust:none;font-stretch:100%;font-style:n=
ormal;font-variant:normal;font-weight:400;letter-spacing:normal;line-height=
:19.99px;overflow:visible;text-align:left;text-decoration:none;text-indent:=
0px;text-transform:none;white-space:normal;word-spacing:0px"><br style=3D"f=
ont-family:Arial,Helvetica,sans-serif;font-size:13.33px;font-size-adjust:no=
ne;font-stretch:100%;font-style:normal;font-variant:normal;font-weight:400;=
line-height:19.99px;overflow:visible"></div><div style=3D"background-color:=
transparent;color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font=
-size:13.33px;font-size-adjust:none;font-stretch:100%;font-style:normal;fon=
t-variant:normal;font-weight:400;letter-spacing:normal;line-height:19.99px;=
overflow:visible;text-align:left;text-decoration:none;text-indent:0px;text-=
transform:none;white-space:normal;word-spacing:0px">Named arguments are wel=
l established machinery, both language level type and compiler-only type.</=
div><div style=3D"background-color:transparent;color:rgb(34,34,34);font-fam=
ily:Arial,Helvetica,sans-serif;font-size:13.33px;font-size-adjust:none;font=
-stretch:100%;font-style:normal;font-variant:normal;font-weight:400;letter-=
spacing:normal;line-height:19.99px;overflow:visible;text-align:left;text-de=
coration:none;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px"><br style=3D"font-family:Arial,Helvetica,sans-serif;font-size:1=
3.33px;font-size-adjust:none;font-stretch:100%;font-style:normal;font-varia=
nt:normal;font-weight:400;line-height:19.99px;overflow:visible"></div><div =
style=3D"background-color:transparent;color:rgb(34,34,34);font-family:Arial=
,Helvetica,sans-serif;font-size:13.33px;font-size-adjust:none;font-stretch:=
100%;font-style:normal;font-variant:normal;font-weight:400;letter-spacing:n=
ormal;line-height:19.99px;overflow:visible;text-align:left;text-decoration:=
none;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0p=
x">I think we need a paper which presents all options, without much details=
, let alone syntax, and ask the committee for direction.=C2=A0</div><div st=
yle=3D"background-color:transparent;color:rgb(34,34,34);font-family:Arial,H=
elvetica,sans-serif;font-size:13.33px;font-size-adjust:none;font-stretch:10=
0%;font-style:normal;font-variant:normal;font-weight:400;letter-spacing:nor=
mal;line-height:19.99px;overflow:visible;text-align:left;text-decoration:no=
ne;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"=
>They will vote pro or contra names as part of the typesystem, compiler bas=
ed, some hybrid (compiler based + better tags/ strong typedef/ inline struc=
ts or something)</div><div style=3D"background-color:transparent;color:rgb(=
34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:13.33px;font-siz=
e-adjust:none;font-stretch:100%;font-style:normal;font-variant:normal;font-=
weight:400;letter-spacing:normal;line-height:19.99px;overflow:visible;text-=
align:left;text-decoration:none;text-indent:0px;text-transform:none;white-s=
pace:normal;word-spacing:0px"><br style=3D"font-family:Arial,Helvetica,sans=
-serif;font-size:13.33px;font-size-adjust:none;font-stretch:100%;font-style=
:normal;font-variant:normal;font-weight:400;line-height:19.99px;overflow:vi=
sible"></div><div style=3D"background-color:transparent;color:rgb(34,34,34)=
;font-family:Arial,Helvetica,sans-serif;font-size:13.33px;font-size-adjust:=
none;font-stretch:100%;font-style:normal;font-variant:normal;font-weight:40=
0;letter-spacing:normal;line-height:19.99px;overflow:visible;text-align:lef=
t;text-decoration:none;text-indent:0px;text-transform:none;white-space:norm=
al;word-spacing:0px">The details will come easily afterwards. In any case t=
here will be happy people and unhappy, that is for sure, but any names are =
better then none and after all it is not for the community to make a decisi=
on.</div>=C2=A0</div></div></blockquote></div><div dir=3D"auto"><br></div><=
div dir=3D"auto">Very good point. Agreed.</div></div>

<p></p>

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

--00000000000012be7a05749886f2--

.

On 29 August 2018 at 23:08, Jake Arkinstall <jake.arkinstall@gmail.com> wrote:
> On Wed, 29 Aug 2018, 19:23 , <mihailnajdenov@gmail.com> wrote:
>>
>>
>> I can't see a struct working as an official solution. It will radically
>> change both the declaration (one param vs N) and the implementation
>> (structured bindings to the rescue?).
>> It will also have both code size and performance effect.
>
>
> In terms of the declaration, I'm thinking of a keyword that automatically
> creates a parameter struct overload for a function. This is thus a strictly
> opt-in approach (so won't suit everyone).
>
> void f(int a, int b, int c = 0) named;
> void f(int a, int b, int c = 0) named_only;
>
> Produces:
>
> void f(int a, int b, int c = 0);
> struct f_params{
>     int a;
>     int b;
>     int c = 0;
> };
> void f(f_params p){
>     f(p.a, p.b, p.c);
> }
>
> struct g_params{
>     int a;
>     int b;
>     int c = 0;
> };
> void g(g_params); // internals rewritten to swap a, b, c to g_params.a,
> g_params.b, g_params.c.
>
>
> And on the call site:
>
> f({.a = 4, .b = 5, .c = 1 }); // already valid

The problem with conjuring up a struct is that it requires more magic to forward
the parameters as ints.
>
> Same with g. We can try to get the removal of braces for these calls (but
> not for general calls with structs as parameters) into a proposal:
>
> g(.a=4, .b=5, .c=1);
>
> In terms of getting reorderable parameters, that requires a change to
> designated initializers, which don't currently accept arguments in an order
> other than the declaration (I don't see why not. C allows it.)

You don't see why not? In C, EVERY TYPE IS TRIVIAL. In C++, that's not the case,
so initialization and destruction order matters.

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

.

On 2018-08-29 16:08, Jake Arkinstall wrote:
> In terms of getting reorderable parameters, that requires a change to
> designated initializers, which don't currently accept arguments in an order
> other than the declaration (I don't see why not. C allows it.)

  struct foo { int a, b; }
  int x = 1;
  auto y = foo{.b = ++x, .a = ++y};

Is y.a 2 or 3? Keep in mind that y.a was initialized before y.b. (Hmm,
actually considering that we allow reordering parameters, it is sort of
interesting that we don't allow the compiler to rewrite the above as
`{.a = ++x, .b = ++x}`.)

--
Matthew

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

.

--0000000000008ca9e7057498e9a2
Content-Type: text/plain; charset="UTF-8"

On Wed, 29 Aug 2018, 21:15 Ville Voutilainen, <ville.voutilainen@gmail.com>
wrote:

> You don't see why not? In C, EVERY TYPE IS TRIVIAL. In C++, that's not the
> case,
> so initialization and destruction order matters.
>

That hasn't stopped us before. What I don't understand is why we would
rather make it an error than define an order of evaluation, make it UB, or
only cause an error when non-trivial types are used.

>

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

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

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, =
29 Aug 2018, 21:15 Ville Voutilainen, &lt;<a href=3D"mailto:ville.voutilain=
en@gmail.com" target=3D"_blank" rel=3D"noreferrer">ville.voutilainen@gmail.=
com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You don&#39;t se=
e why not? In C, EVERY TYPE IS TRIVIAL. In C++, that&#39;s not the case,<br=
>
so initialization and destruction order matters.<br></blockquote></div></di=
v><div dir=3D"auto"><br></div><div dir=3D"auto">That hasn&#39;t stopped us =
before. What I don&#39;t understand is why we would rather make it an error=
 than define an order of evaluation, make it UB, or only cause an error whe=
n non-trivial types are used.</div><div dir=3D"auto"><div class=3D"gmail_qu=
ote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>

<p></p>

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

--0000000000008ca9e7057498e9a2--

.

On 29 August 2018 at 23:36, Jake Arkinstall <jake.arkinstall@gmail.com> wrote:
> On Wed, 29 Aug 2018, 21:15 Ville Voutilainen, <ville.voutilainen@gmail.com>
> wrote:
>>
>> You don't see why not? In C, EVERY TYPE IS TRIVIAL. In C++, that's not the
>> case,
>> so initialization and destruction order matters.
>
>
> That hasn't stopped us before. What I don't understand is why we would
> rather make it an error than define an order of evaluation, make it UB, or
> only cause an error when non-trivial types are used.

Fair enough. I don't recommend going towards the UB route, but
defining the order of evaluation
seems perfectly palatable to me, because that's what we do for
ctor-initializers, and I don't suppose
it's all that hard implementation-wise either. Same goes for making it
an error only for non-trivial types,
although that seems like an inferior choice to me.

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

.

On 2018-08-29 16:36, Jake Arkinstall wrote:
> What I don't understand is why we would rather make [designated
> initializers that don't match declaration order] an error than define
> an order of evaluation, make it UB, or only cause an error when
> non-trivial types are used.
I suppose the folks that wanted it to be an error probably felt that
allowing ctor initializers to be reordered (i.e. written in other than
declaration order) never should have been allowed either?

OTOH, given that ctor initializers can (safely!) refer to earlier
members, there may be a larger scope for insidious errors, there.

OTGH, there are folks that don't like that order of function parameter
evaluation is unspecified...

--
Matthew

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

.

------=_Part_2118_943650749.1535577490730
Content-Type: multipart/alternative;
 boundary="----=_Part_2119_1215456492.1535577490730"

------=_Part_2119_1215456492.1535577490730
Content-Type: text/plain; charset="UTF-8"



On Wednesday, August 29, 2018 at 11:08:38 PM UTC+3, Jake Arkinstall wrote:
>
> On Wed, 29 Aug 2018, 19:23 , <mihailn...@gmail.com <javascript:>> wrote:
>
>>
>> I can't see a struct working as an official solution. It will radically
>> change both the declaration (one param vs N) and the implementation
>> (structured bindings to the rescue?).
>> It will also have both code size and performance effect.
>>
>
> In terms of the declaration, I'm thinking of a keyword that automatically
> creates a parameter struct overload for a function. This is thus a strictly
> opt-in approach (so won't suit everyone).
>
> void f(int a, int b, int c = 0) named;
> void f(int a, int b, int c = 0) named_only;
>
> Produces:
>
> void f(int a, int b, int c = 0);
> struct f_params{
>     int a;
>     int b;
>     int c = 0;
> };
> void f(f_params p){
>     f(p.a, p.b, p.c);
> }
>
> struct g_params{
>     int a;
>     int b;
>     int c = 0;
> };
> void g(g_params); // internals rewritten to swap a, b, c to g_params.a,
> g_params.b, g_params.c.
>
>
> And on the call site:
>
> f({.a = 4, .b = 5, .c = 1 }); // already valid
>
> Same with g. We can try to get the removal of braces for these calls (but
> not for general calls with structs as parameters) into a proposal:
>
> g(.a=4, .b=5, .c=1);
>
> In terms of getting reorderable parameters, that requires a change to
> designated initializers, which don't currently accept arguments in an order
> other than the declaration (I don't see why not. C allows it.)
>
> Performance wise, no noticeable change that I can think of (why would
> there be?). Code size impact is dependant on the use of named vs named_only.
>

But what will reflection report about such a function and its parameters?
And I doubt the boilerplate can completely disappear from the runtime (and
at what cost in terms of compilation/optimization time).


>
>
>> Named arguments are well established machinery, both language level type
>> and compiler-only type.
>>
>> I think we need a paper which presents all options, without much details,
>> let alone syntax, and ask the committee for direction.
>> They will vote pro or contra names as part of the typesystem, compiler
>> based, some hybrid (compiler based + better tags/ strong typedef/ inline
>> structs or something)
>>
>> The details will come easily afterwards. In any case there will be happy
>> people and unhappy, that is for sure, but any names are better then none
>> and after all it is not for the community to make a decision.
>>
>>
>
> Very good point. Agreed.
>

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

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

<div dir=3D"ltr"><br><br>On Wednesday, August 29, 2018 at 11:08:38 PM UTC+3=
, Jake Arkinstall wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"auto"><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr">On Wed=
, 29 Aug 2018, 19:23 , &lt;<a onmousedown=3D"this.href=3D&#39;javascript:&#=
39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;=
" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-ma=
ilto=3D"jLfhGQgqCAAJ">mihailn...@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"><div><br></div><div><div style=3D"backg=
round-color:transparent;color:rgb(34,34,34);font-family:Arial,Helvetica,san=
s-serif;font-size:13.33px;font-size-adjust:none;font-stretch:100%;font-styl=
e:normal;font-variant:normal;font-weight:400;letter-spacing:normal;line-hei=
ght:19.99px;overflow:visible;text-align:left;text-decoration:none;text-inde=
nt:0px;text-transform:none;white-space:normal;word-spacing:0px">I can&#39;t=
 see a struct working as an official solution. It will radically change bot=
h the declaration (one param vs N) and the implementation (structured bindi=
ngs to the rescue?).</div><div style=3D"background-color:transparent;color:=
rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:13.33px;font=
-size-adjust:none;font-stretch:100%;font-style:normal;font-variant:normal;f=
ont-weight:400;letter-spacing:normal;line-height:19.99px;overflow:visible;t=
ext-align:left;text-decoration:none;text-indent:0px;text-transform:none;whi=
te-space:normal;word-spacing:0px">It will also have both code size and perf=
ormance effect.<br style=3D"font-family:Arial,Helvetica,sans-serif;font-siz=
e:13.33px;font-size-adjust:none;font-stretch:100%;font-style:normal;font-va=
riant:normal;font-weight:400;line-height:19.99px;overflow:visible"></div></=
div></div></blockquote></div><div dir=3D"auto"><br></div><div dir=3D"auto">=
In terms of the declaration, I&#39;m thinking of a keyword that automatical=
ly creates a parameter struct overload for a function. This is thus a stric=
tly opt-in approach (so won&#39;t suit everyone).</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">void f(int a, int b, int c =3D 0) named;</div><di=
v dir=3D"auto"><span style=3D"font-family:sans-serif">void f(int a, int b, =
int c =3D 0) named_only;</span><br></div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">Produces:</div><div dir=3D"auto"><br></div><div dir=3D"auto">vo=
id f(int a, int b, int c =3D 0);</div><div dir=3D"auto">struct f_params{</d=
iv><div dir=3D"auto">=C2=A0 =C2=A0 int a;</div><div dir=3D"auto">=C2=A0 =C2=
=A0 int b;</div><div dir=3D"auto">=C2=A0 =C2=A0 int c =3D 0;</div><div dir=
=3D"auto">};</div><div dir=3D"auto">void f(f_params p){</div><div dir=3D"au=
to">=C2=A0 =C2=A0 f(p.a, p.b, p.c);</div><div dir=3D"auto">}</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">struct g_params{</div><div dir=3D"aut=
o">=C2=A0 =C2=A0 int a;</div><div dir=3D"auto">=C2=A0 =C2=A0 int b;</div><d=
iv dir=3D"auto">=C2=A0 =C2=A0 int c =3D 0;</div><div dir=3D"auto">};</div><=
div dir=3D"auto">void g(g_params); // internals rewritten to swap a, b, c t=
o g_params.a, g_params.b, g_params.c.</div><div dir=3D"auto"><br></div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">And on the call site:</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">f({.a =3D 4, .b =3D 5, .c =3D 1 });=
 // already valid</div><div dir=3D"auto"><br></div><div dir=3D"auto">Same w=
ith g. We can try to get the removal of braces for these calls (but not for=
 general calls with structs as parameters) into a proposal:</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">g(.a=3D4, .b=3D5, .c=3D1);</div><div =
dir=3D"auto"><br></div><div dir=3D"auto">In terms of getting reorderable pa=
rameters, that requires a change to designated initializers, which don&#39;=
t currently accept arguments in an order other than the declaration (I don&=
#39;t see why not. C allows it.)</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Performance wise, no noticeable change that I can think of (why w=
ould there be?). Code size impact is dependant on the use of named vs named=
_only.</div></div></blockquote><div><br></div><div>But what will reflection=
 report about such a function and its parameters?=C2=A0</div><div>And I dou=
bt the boilerplate can completely disappear from the runtime (and at what c=
ost in terms of compilation/optimization time).=C2=A0<br></div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto"><div di=
r=3D"auto"><br></div><div class=3D"gmail_quote" dir=3D"auto"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div><div style=3D"background-color:trans=
parent;color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size=
:13.33px;font-size-adjust:none;font-stretch:100%;font-style:normal;font-var=
iant:normal;font-weight:400;letter-spacing:normal;line-height:19.99px;overf=
low:visible;text-align:left;text-decoration:none;text-indent:0px;text-trans=
form:none;white-space:normal;word-spacing:0px"></div><div style=3D"backgrou=
nd-color:transparent;color:rgb(34,34,34);font-family:Arial,Helvetica,sans-s=
erif;font-size:13.33px;font-size-adjust:none;font-stretch:100%;font-style:n=
ormal;font-variant:normal;font-weight:400;letter-spacing:normal;line-height=
:19.99px;overflow:visible;text-align:left;text-decoration:none;text-indent:=
0px;text-transform:none;white-space:normal;word-spacing:0px"><br style=3D"f=
ont-family:Arial,Helvetica,sans-serif;font-size:13.33px;font-size-adjust:no=
ne;font-stretch:100%;font-style:normal;font-variant:normal;font-weight:400;=
line-height:19.99px;overflow:visible"></div><div style=3D"background-color:=
transparent;color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font=
-size:13.33px;font-size-adjust:none;font-stretch:100%;font-style:normal;fon=
t-variant:normal;font-weight:400;letter-spacing:normal;line-height:19.99px;=
overflow:visible;text-align:left;text-decoration:none;text-indent:0px;text-=
transform:none;white-space:normal;word-spacing:0px">Named arguments are wel=
l established machinery, both language level type and compiler-only type.</=
div><div style=3D"background-color:transparent;color:rgb(34,34,34);font-fam=
ily:Arial,Helvetica,sans-serif;font-size:13.33px;font-size-adjust:none;font=
-stretch:100%;font-style:normal;font-variant:normal;font-weight:400;letter-=
spacing:normal;line-height:19.99px;overflow:visible;text-align:left;text-de=
coration:none;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px"><br style=3D"font-family:Arial,Helvetica,sans-serif;font-size:1=
3.33px;font-size-adjust:none;font-stretch:100%;font-style:normal;font-varia=
nt:normal;font-weight:400;line-height:19.99px;overflow:visible"></div><div =
style=3D"background-color:transparent;color:rgb(34,34,34);font-family:Arial=
,Helvetica,sans-serif;font-size:13.33px;font-size-adjust:none;font-stretch:=
100%;font-style:normal;font-variant:normal;font-weight:400;letter-spacing:n=
ormal;line-height:19.99px;overflow:visible;text-align:left;text-decoration:=
none;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0p=
x">I think we need a paper which presents all options, without much details=
, let alone syntax, and ask the committee for direction.=C2=A0</div><div st=
yle=3D"background-color:transparent;color:rgb(34,34,34);font-family:Arial,H=
elvetica,sans-serif;font-size:13.33px;font-size-adjust:none;font-stretch:10=
0%;font-style:normal;font-variant:normal;font-weight:400;letter-spacing:nor=
mal;line-height:19.99px;overflow:visible;text-align:left;text-decoration:no=
ne;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"=
>They will vote pro or contra names as part of the typesystem, compiler bas=
ed, some hybrid (compiler based + better tags/ strong typedef/ inline struc=
ts or something)</div><div style=3D"background-color:transparent;color:rgb(=
34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:13.33px;font-siz=
e-adjust:none;font-stretch:100%;font-style:normal;font-variant:normal;font-=
weight:400;letter-spacing:normal;line-height:19.99px;overflow:visible;text-=
align:left;text-decoration:none;text-indent:0px;text-transform:none;white-s=
pace:normal;word-spacing:0px"><br style=3D"font-family:Arial,Helvetica,sans=
-serif;font-size:13.33px;font-size-adjust:none;font-stretch:100%;font-style=
:normal;font-variant:normal;font-weight:400;line-height:19.99px;overflow:vi=
sible"></div><div style=3D"background-color:transparent;color:rgb(34,34,34)=
;font-family:Arial,Helvetica,sans-serif;font-size:13.33px;font-size-adjust:=
none;font-stretch:100%;font-style:normal;font-variant:normal;font-weight:40=
0;letter-spacing:normal;line-height:19.99px;overflow:visible;text-align:lef=
t;text-decoration:none;text-indent:0px;text-transform:none;white-space:norm=
al;word-spacing:0px">The details will come easily afterwards. In any case t=
here will be happy people and unhappy, that is for sure, but any names are =
better then none and after all it is not for the community to make a decisi=
on.</div>=C2=A0</div></div></blockquote></div><div dir=3D"auto"><br></div><=
div dir=3D"auto">Very good point. Agreed.</div></div>
</blockquote></div>

<p></p>

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

------=_Part_2119_1215456492.1535577490730--

------=_Part_2118_943650749.1535577490730--

.

> From: Ville Voutilainen <ville.voutilainen@gmail.com>
> Sent: Wednesday, August 29, 2018 3:42 PM
>
> defining the order of evaluation
> seems perfectly palatable to me, because that's what we do for
> ctor-initializers, and I don't suppose
> it's all that hard implementation-wise either.

The authors had extensive discussions on this topic
and copying what ctor-initializers did was certainly
considered, until we realized that the ctor-initializers
and the data members are both controlled by the class
authors, while only the data members are controlled by
the aggregate author since the uses of the designated
initializers are controlled by the aggregate users.  This
difference can cause some code to legitimately and
silently fails at runtime if the aggregate changes the
member orders, making a library less sustainable.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________



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

.

On 30 August 2018 at 00:43, Zhihao Yuan <zy@miator.net> wrote:
>> From: Ville Voutilainen <ville.voutilainen@gmail.com>
>> Sent: Wednesday, August 29, 2018 3:42 PM
>>
>> defining the order of evaluation
>> seems perfectly palatable to me, because that's what we do for
>> ctor-initializers, and I don't suppose
>> it's all that hard implementation-wise either.
>
> The authors had extensive discussions on this topic
> and copying what ctor-initializers did was certainly
> considered, until we realized that the ctor-initializers
> and the data members are both controlled by the class
> authors, while only the data members are controlled by
> the aggregate author since the uses of the designated
> initializers are controlled by the aggregate users.  This
> difference can cause some code to legitimately and
> silently fails at runtime if the aggregate changes the
> member orders, making a library less sustainable.

Ah, heh, there's indeed a UB component in it, because we can't
statically guarantee
that the members and their initializers wouldn't end up dependent. And
we get into
that UB-land even with trivial types.

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

.