In the past couple months I've seen several proposals for names parameters.=
  Each with a list of pros and cons, and because there are cons arguments a=
gainst them.  I think we need a discussion on what we want assuming some st=
rawman acceptable syntax, and some thought of how many limitations in corne=
r cases we are willing to accept.=20

I can think of 4 uses for names parameters. (If you don't understand these =
I have simple code examples)
1 . a function with more than one parameter of the same type is called with=
 the parameters in the wrong order
      *  Some people want this to be a compilation error, some want the com=
piler to correct the problem and continue
2. a function wants to take the same type to mean different things in diffe=
rent contexts
3. it isn't obvious from the type alone what a parameter means
4. A function has a bunch of defaulted arguments and you want to change one=
 of the latter ones without specifying all the others

First question: is this complete?
Second, which problems are worth solving?
Third, for problems worth solving, which is the better solution, and how st=
rongly attached to it are you?

For the first the motivating code is something like:

class myMatrix {
     T GetCell(int row, int column);
     ...
};

in code:
   cell =3D matrix.GetCell(column, row);

This will compile just fine in C++17, but the code is undoubtedly wrong.  I=
n C++2n do you want this to be a compiler error, or correct code?


Second:
class point {
    point(double x, double y);=20
    point(double distance, double angle);
....
};

This code does not compile in C++17.  Do we want to make this case work?


Third:
class myString {
    int compare(myString, bool CaseSensitive);
....
};

in code
    if(str.compare(otherString, false) =3D=3D 0) ...   // what does this me=
an, why would you call compare and not compare?

This code is legal C++17, but it is user hostile. False in the context of r=
eading the function makes no intuitive sense.  Qt has created an enum for t=
his, but it can be argued that this is too heavy.  (you may or may not agre=
e with the argument)


Fourth:
// warning, marketing regularly changes the default value of this function
void foo(double a =3D 1234.5, int b =3D 6789);

foo(b:=3D1234);

This won't compile in C++17. However it seems like it would be useful to no=
t clutter function calls with default parameters that you don't care about.=
 In the case I gave it is a maintenance problem to update all uses of foo e=
very time the defaults change, though I'm not sure if this is actually a co=
mmon problem.

--=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/1534441498.3721109.1476442920.71D445BF%40webmail=
..messagingengine.com.

.

------=_Part_448_1595985164.1534446138125
Content-Type: multipart/alternative;
 boundary="----=_Part_449_210939992.1534446138125"

------=_Part_449_210939992.1534446138125
Content-Type: text/plain; charset="UTF-8"

On Thursday, August 16, 2018 at 1:45:01 PM UTC-4, Henry Miller wrote:
>
>
> In the past couple months I've seen several proposals for names
> parameters.  Each with a list of pros and cons, and because there are cons
> arguments against them.  I think we need a discussion on what we want
> assuming some strawman acceptable syntax, and some thought of how many
> limitations in corner cases we are willing to accept.
>
> I can think of 4 uses for names parameters. (If you don't understand these
> I have simple code examples)
> 1 . a function with more than one parameter of the same type is called
> with the parameters in the wrong order
>       *  Some people want this to be a compilation error, some want the
> compiler to correct the problem and continue
> 2. a function wants to take the same type to mean different things in
> different contexts
> 3. it isn't obvious from the type alone what a parameter means
> 4. A function has a bunch of defaulted arguments and you want to change
> one of the latter ones without specifying all the others
>
> First question: is this complete?
> Second, which problems are worth solving?
> Third, for problems worth solving, which is the better solution, and how
> strongly attached to it are you?
>

I think that there should be a discussion of existing solutions to all of
the problems of interest, so that we can enumerate why those solutions are
not good enough. It would also allow us to perhaps find a better way to
handle this than with named parameters. For example, if tagged dispatch
solves a lot of these problems, then perhaps we can incorporate tags into
the language in some more formal way rather than going to full named
parameters.

For the first the motivating code is something like:
>
> class myMatrix {
>      T GetCell(int row, int column);
>      ...
> };
>
> in code:
>    cell = matrix.GetCell(column, row);
>
> This will compile just fine in C++17, but the code is undoubtedly wrong.
>  In C++2n do you want this to be a compiler error, or correct code?
>

Note that making this "not correct code" would require that the mechanism
*require* that the user provide named arguments. That is, you cannot use
positional arguments at all.

Tagged dispatch can handle such cases.

Second:
> class point {
>     point(double x, double y);
>     point(double distance, double angle);
> ...
> };
>
> This code does not compile in C++17.  Do we want to make this case work?
>

Tagged dispatch can work here. So can a properly named struct:
`point(Polar(dist, angle))`. Plus, by giving the type a full name, we allow
`Polar` coordinates to be passed around and used for other purposes.

Third:
> class myString {
>     int compare(myString, bool CaseSensitive);
> ...
> };
>
> in code
>     if(str.compare(otherString, false) == 0) ...   // what does this mean,
> why would you call compare and not compare?
>
> This code is legal C++17, but it is user hostile. False in the context of
> reading the function makes no intuitive sense.  Qt has created an enum for
> this, but it can be argued that this is too heavy.  (you may or may not
> agree with the argument)
>

The alternatives should be considered and discussed. Enumerators and tagged
dispatch both are good solutions.

Fourth:
> // warning, marketing regularly changes the default value of this function
> void foo(double a = 1234.5, int b = 6789);
>
> foo(b:=1234);
>
> This won't compile in C++17. However it seems like it would be useful to
> not clutter function calls with default parameters that you don't care
> about. In the case I gave it is a maintenance problem to update all uses of
> foo every time the defaults change, though I'm not sure if this is actually
> a common problem.
>

There are several alternative solutions. A named struct works well enough,
thanks to designated initializers. Plus, it puts the default values in a
more accessible location, rather than the signature of a function. It's not
like users can get changes to such default values without recompiling
anyway.

There is also the option of using `optional<double>`. So you'd call it with
`foo(nullopt, 1234)`, and allow the internal code to fill in the default.
This alternative also has the advantage that, if the default changes, you *don't
have to recompile* to get the changed value. Named parameters could take
advantage of that too by using `optional`.


--
You received this message because you are 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/12ca0430-f790-4dee-b491-266435bae170%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, August 16, 2018 at 1:45:01 PM UTC-4, Henry Mi=
ller wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>In the past couple months I&#39;ve seen several proposals for names par=
ameters. =C2=A0Each with a list of pros and cons, and because there are con=
s arguments against them. =C2=A0I think we need a discussion on what we wan=
t assuming some strawman acceptable syntax, and some thought of how many li=
mitations in corner cases we are willing to accept.=20
<br>
<br>I can think of 4 uses for names parameters. (If you don&#39;t understan=
d these I have simple code examples)
<br>1 . a function with more than one parameter of the same type is called =
with the parameters in the wrong order
<br>=C2=A0 =C2=A0 =C2=A0 * =C2=A0Some people want this to be a compilation =
error, some want the compiler to correct the problem and continue
<br>2. a function wants to take the same type to mean different things in d=
ifferent contexts
<br>3. it isn&#39;t obvious from the type alone what a parameter means
<br>4. A function has a bunch of defaulted arguments and you want to change=
 one of the latter ones without specifying all the others
<br>
<br>First question: is this complete?
<br>Second, which problems are worth solving?
<br>Third, for problems worth solving, which is the better solution, and ho=
w strongly attached to it are you?
<br></blockquote><div><br></div><div>I think that there should be a discuss=
ion of existing solutions to all of the problems of interest, so that we ca=
n enumerate why those solutions are not good enough. It would also allow us=
 to perhaps find a better way to handle this than with named parameters. Fo=
r example, if tagged dispatch solves a lot of these problems, then perhaps =
we can incorporate tags into the language in some more formal way rather th=
an going to full named parameters.<br></div><div><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;">
For the first the motivating code is something like:
<br>
<br>class myMatrix {
<br>=C2=A0 =C2=A0 =C2=A0T GetCell(int row, int column);
<br>=C2=A0 =C2=A0 =C2=A0...
<br>};
<br>
<br>in code:
<br>=C2=A0 =C2=A0cell =3D matrix.GetCell(column, row);
<br>
<br>This will compile just fine in C++17, but the code is undoubtedly wrong=
.. =C2=A0In C++2n do you want this to be a compiler error, or correct code?<=
br></blockquote><div><br></div><div>Note that making this &quot;not correct=
 code&quot; would require that the mechanism <i>require</i> that the user p=
rovide named arguments. That is, you cannot use positional arguments at all=
..</div><div><br></div><div>Tagged dispatch can handle such cases.<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;">
Second:
<br>class point {
<br>=C2=A0 =C2=A0 point(double x, double y);=20
<br>=C2=A0 =C2=A0 point(double distance, double angle);
<br>...
<br>};
<br>
<br>This code does not compile in C++17. =C2=A0Do we want to make this case=
 work?<br></blockquote><div><br></div><div>Tagged dispatch can work here. S=
o can a properly named struct: `point(Polar(dist, angle))`. Plus, by giving=
 the type a full name, we allow `Polar` coordinates to be passed around and=
 used for other purposes.<br></div><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;">
Third:
<br>class myString {
<br>=C2=A0 =C2=A0 int compare(myString, bool CaseSensitive);
<br>...
<br>};
<br>
<br>in code
<br>=C2=A0 =C2=A0 if(str.compare(otherString, false) =3D=3D 0) ... =C2=A0 /=
/ what does this mean, why would you call compare and not compare?
<br>
<br>This code is legal C++17, but it is user hostile. False in the context =
of reading the function makes no intuitive sense. =C2=A0Qt has created an e=
num for this, but it can be argued that this is too heavy. =C2=A0(you may o=
r may not agree with the argument)
<br></blockquote><div><br></div><div>The alternatives should be considered =
and discussed. Enumerators and tagged dispatch both are good solutions.<br>=
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
Fourth:
<br>// warning, marketing regularly changes the default value of this funct=
ion
<br>void foo(double a =3D 1234.5, int b =3D 6789);
<br>
<br>foo(b:=3D1234);
<br>
<br>This won&#39;t compile in C++17. However it seems like it would be usef=
ul to not clutter function calls with default parameters that you don&#39;t=
 care about. In the case I gave it is a maintenance problem to update all u=
ses of foo every time the defaults change, though I&#39;m not sure if this =
is actually a common problem.<br></blockquote><div><br></div><div>There are=
 several alternative solutions. A named struct works well enough, thanks to=
 designated initializers. Plus, it puts the default values in a more access=
ible location, rather than the signature of a function. It&#39;s not like u=
sers can get changes to such default values without recompiling anyway.</di=
v><div><br></div><div>There is also the option of using `optional&lt;double=
&gt;`. So you&#39;d call it with `foo(nullopt, 1234)`, and allow the intern=
al code to fill in the default. This alternative also has the advantage tha=
t, if the default changes, you <i>don&#39;t have to recompile</i> to get th=
e changed value. Named parameters could take advantage of that too by using=
 `optional`.<br></div><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/12ca0430-f790-4dee-b491-266435bae170%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/12ca0430-f790-4dee-b491-266435bae170=
%40isocpp.org</a>.<br />

------=_Part_449_210939992.1534446138125--

------=_Part_448_1595985164.1534446138125--

.

This is a multi-part message in MIME format.

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

On Thu, Aug 16, 2018, at 2:02 PM, Nicol Bolas wrote:
> On Thursday, August 16, 2018 at 1:45:01 PM UTC-4, Henry Miller wrote:>>=
=20
>> In the past couple months I've seen several proposals for names
>> parameters.  Each with a list of pros and cons, and because there are
>> cons arguments against them.  I think we need a discussion on what we
>> want assuming some strawman acceptable syntax, and some thought of
>> how many limitations in corner cases we are willing to accept.>>=20
>> I can think of 4 uses for names parameters. (If you don't understand
>> these I have simple code examples)>> 1 . a function with more than one p=
arameter of the same type is
>>     called with the parameters in the wrong order>>       *  Some people=
 want this to be a compilation error, some want
>>          the compiler to correct the problem and continue>> 2. a functio=
n wants to take the same type to mean different things in
>>    different contexts>> 3. it isn't obvious from the type alone what a p=
arameter means=20
>> 4. A function has a bunch of defaulted arguments and you want to
>>    change one of the latter ones without specifying all the others>>=20
>> First question: is this complete?=20
>> Second, which problems are worth solving?=20
>> Third, for problems worth solving, which is the better solution, and
>> how strongly attached to it are you?>=20
> I think that there should be a discussion of existing solutions to all
> of the problems of interest, so that we can enumerate why those
> solutions are not good enough. It would also allow us to perhaps find
> a better way to handle this than with named parameters. For example,
> if tagged dispatch solves a lot of these problems, then perhaps we can
> incorporate tags into the language in some more formal way rather than
> going to full named parameters.
That comes next. First I want to brainstorm in a world where we are not
constrained by possible to say what we want.
After that we look at the other solutions, decide which are useful, and
if any are good enough.  Note in particular P0707 - metaclasses has
using...as notation which make strong types easier to declare and might
give everyone what they wanted.
>=20
>> For the first the motivating code is something like:=20
>>=20
>> class myMatrix {=20
>>      T GetCell(int row, int column);=20
>>      ...=20
>> };=20
>>=20
>> in code:=20
>>    cell =3D matrix.GetCell(column, row);=20
>>=20
>> This will compile just fine in C++17, but the code is undoubtedly
>> wrong.  In C++2n do you want this to be a compiler error, or
>> correct code?>=20
> Note that making this "not correct code" would require that the
> mechanism *require* that the user provide named arguments. That is,
> you cannot use positional arguments at all.
Right, the question is WHAT mechanism?  When I write that I thought of 4
different ways to change C++ to accomplish this, and as it happens
taging wasn't one.  My 4 plus taging isn't a complete list either, it
isn't even close.
The point isn't to discuss how we want to do this, it is to discuss to
we want to do it at all, and if so is it a compiler error or does the
compiler just do what the user wanted.
>=20
> Tagged dispatch can handle such cases.
>=20
>> Second:=20
>> class point {=20
>>     point(double x, double y);=20
>>     point(double distance, double angle);=20
>> ...=20
>> };=20
>>=20
>> This code does not compile in C++17.  Do we want to make this
>> case work?>=20
> Tagged dispatch can work here. So can a properly named struct:
> `point(Polar(dist, angle))`. Plus, by giving the type a full name, we
> allow `Polar` coordinates to be passed around and used for other
> purposes.>=20
>> Third:=20
>> class myString {=20
>>     int compare(myString, bool CaseSensitive);=20
>> ...=20
>> };=20
>>=20
>> in code=20
>>     if(str.compare(otherString, false) =3D=3D 0) ...   // what does this
>>     mean, why would you call compare and not compare?>>=20
>> This code is legal C++17, but it is user hostile. False in the
>> context of reading the function makes no intuitive sense.  Qt has
>> created an enum for this, but it can be argued that this is too
>> heavy.  (you may or may not agree with the argument)>=20
> The alternatives should be considered and discussed. Enumerators and
> tagged dispatch both are good solutions.
The argument against both is they are "ugly"  This is of course
subjective, but sometimes that is compelling anyway.
>> Fourth:=20
>> // warning, marketing regularly changes the default value of this
>> function>> void foo(double a =3D 1234.5, int b =3D 6789);=20
>>=20
>> foo(b:=3D1234);=20
>>=20
>> This won't compile in C++17. However it seems like it would be useful
>> to not clutter function calls with default parameters that you don't
>> care about. In the case I gave it is a maintenance problem to update
>> all uses of foo every time the defaults change, though I'm not sure
>> if this is actually a common problem.>=20
> There are several alternative solutions. A named struct works well
> enough, thanks to designated initializers. Plus, it puts the default
> values in a more accessible location, rather than the signature of a
> function. It's not like users can get changes to such default values
> without recompiling anyway.>=20
> There is also the option of using `optional<double>`. So you'd call it
> with `foo(nullopt, 1234)`, and allow the internal code to fill in the
> default. This alternative also has the advantage that, if the default
> changes, you *don't have to recompile* to get the changed value. Named
> parameters could take advantage of that too by using `optional`.
Lots of options are possible.  Do we like them? =20

I considered proposing a syntax llke 'foo(:=3Ddefault, 1234)' for this.=C2=
=A0 I
decided it wasn't worth it yet, but if we are not happy with the options
adding something like this is possible.

--=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/1534452105.3767720.1476682240.226BF14C%40webmail=
..messagingengine.com.

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

<!DOCTYPE html>
<html>
<head>
<title></title>
<style type=3D"text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style>
</head>
<body><div style=3D"font-family:Arial;">On Thu, Aug 16, 2018, at 2:02 PM, N=
icol Bolas wrote:<br></div>
<blockquote type=3D"cite"><div dir=3D"ltr"><div style=3D"font-family:Arial;=
">On Thursday, August 16, 2018 at 1:45:01 PM UTC-4, Henry Miller wrote:<br>=
</div>
<blockquote defang_data-gmailquote=3D"yes" style=3D"margin-top:0px;margin-r=
ight:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-l=
eft-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><di=
v style=3D"font-family:Arial;"><br></div>
<div style=3D"font-family:Arial;">In the past couple months I've seen sever=
al proposals for names parameters. &nbsp;Each with a list of pros and cons,=
 and because there are cons arguments against them. &nbsp;I think we need a=
 discussion on what we want assuming some strawman acceptable syntax, and s=
ome thought of how many limitations in corner cases we are willing to accep=
t. <br></div>
<div style=3D"font-family:Arial;"> <br></div>
<div style=3D"font-family:Arial;">I can think of 4 uses for names parameter=
s. (If you don't understand these I have simple code examples) <br></div>
<div style=3D"font-family:Arial;">1 . a function with more than one paramet=
er of the same type is called with the parameters in the wrong order <br></=
div>
<div style=3D"font-family:Arial;">&nbsp; &nbsp; &nbsp; * &nbsp;Some people =
want this to be a compilation error, some want the compiler to correct the =
problem and continue <br></div>
<div style=3D"font-family:Arial;">2. a function wants to take the same type=
 to mean different things in different contexts <br></div>
<div style=3D"font-family:Arial;">3. it isn't obvious from the type alone w=
hat a parameter means <br></div>
<div style=3D"font-family:Arial;">4. A function has a bunch of defaulted ar=
guments and you want to change one of the latter ones without specifying al=
l the others <br></div>
<div style=3D"font-family:Arial;"> <br></div>
<div style=3D"font-family:Arial;">First question: is this complete? <br></d=
iv>
<div style=3D"font-family:Arial;">Second, which problems are worth solving?=
 <br></div>
<div style=3D"font-family:Arial;">Third, for problems worth solving, which =
is the better solution, and how strongly attached to it are you? <br></div>
</blockquote><div><br></div>
<div>I think that there should be a discussion of existing solutions to all=
 of the problems of interest, so that we can enumerate why those solutions =
are not good enough. It would also allow us to perhaps find a better way to=
 handle this than with named parameters. For example, if tagged dispatch so=
lves a lot of these problems, then perhaps we can incorporate tags into the=
 language in some more formal way rather than going to full named parameter=
s.<br></div>
</div>
</blockquote><div style=3D"font-family:Arial;"><br></div>
<div style=3D"font-family:Arial;">That comes next. First I want to brainsto=
rm in a world where we are not constrained by possible to say what we want.=
<br></div>
<div style=3D"font-family:Arial;"><br></div>
<div style=3D"font-family:Arial;">After that we look at the other solutions=
, decide which are useful, and if any are good enough.&nbsp; Note in partic=
ular P0707 - metaclasses has using...as notation which make strong types ea=
sier to declare and might give everyone what they wanted.<br></div>
<div style=3D"font-family:Arial;"><br></div>
<blockquote type=3D"cite"><div dir=3D"ltr"><div><br></div>
<blockquote defang_data-gmailquote=3D"yes" style=3D"margin-top:0px;margin-r=
ight:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-l=
eft-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><di=
v style=3D"font-family:Arial;">For the first the motivating code is somethi=
ng like: <br></div>
<div style=3D"font-family:Arial;"> <br></div>
<div style=3D"font-family:Arial;">class myMatrix { <br></div>
<div style=3D"font-family:Arial;">&nbsp; &nbsp; &nbsp;T GetCell(int row, in=
t column); <br></div>
<div style=3D"font-family:Arial;">&nbsp; &nbsp; &nbsp;... <br></div>
<div style=3D"font-family:Arial;">}; <br></div>
<div style=3D"font-family:Arial;"> <br></div>
<div style=3D"font-family:Arial;">in code: <br></div>
<div style=3D"font-family:Arial;">&nbsp; &nbsp;cell =3D matrix.GetCell(colu=
mn, row); <br></div>
<div style=3D"font-family:Arial;"> <br></div>
<div style=3D"font-family:Arial;">This will compile just fine in C++17, but=
 the code is undoubtedly wrong. &nbsp;In C++2n do you want this to be a com=
piler error, or correct code?<br></div>
</blockquote><div><br></div>
<div>Note that making this "not correct code" would require that the mechan=
ism <i>require</i> that the user provide named arguments. That is, you cann=
ot use positional arguments at all.<br></div>
</div>
</blockquote><div style=3D"font-family:Arial;"><br></div>
<div style=3D"font-family:Arial;">Right, the question is WHAT mechanism?&nb=
sp; When I write that I thought of 4 different ways to change C++ to accomp=
lish this, and as it happens taging wasn't one.&nbsp; My 4 plus taging isn'=
t a complete list either, it isn't even close.<br></div>
<div style=3D"font-family:Arial;"><br></div>
<div style=3D"font-family:Arial;">The point isn't to discuss how we want to=
 do this, it is to discuss to we want to do it at all, and if so is it a co=
mpiler error or does the compiler just do what the user wanted.</div>
<div style=3D"font-family:Arial;"><br></div>
<blockquote type=3D"cite"><div dir=3D"ltr"><div><br></div>
<div>Tagged dispatch can handle such cases.<br></div>
<div><br></div>
<blockquote defang_data-gmailquote=3D"yes" style=3D"margin-top:0px;margin-r=
ight:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-l=
eft-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><di=
v style=3D"font-family:Arial;">Second: <br></div>
<div style=3D"font-family:Arial;">class point { <br></div>
<div style=3D"font-family:Arial;">&nbsp; &nbsp; point(double x, double y); =
<br></div>
<div style=3D"font-family:Arial;">&nbsp; &nbsp; point(double distance, doub=
le angle); <br></div>
<div style=3D"font-family:Arial;">... <br></div>
<div style=3D"font-family:Arial;">}; <br></div>
<div style=3D"font-family:Arial;"> <br></div>
<div style=3D"font-family:Arial;">This code does not compile in C++17. &nbs=
p;Do we want to make this case work?<br></div>
</blockquote><div><br></div>
<div>Tagged dispatch can work here. So can a properly named struct: `point(=
Polar(dist, angle))`. Plus, by giving the type a full name, we allow `Polar=
` coordinates to be passed around and used for other purposes.<br></div>
<div><br></div>
<blockquote defang_data-gmailquote=3D"yes" style=3D"margin-top:0px;margin-r=
ight:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-l=
eft-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><di=
v style=3D"font-family:Arial;">Third: <br></div>
<div style=3D"font-family:Arial;">class myString { <br></div>
<div style=3D"font-family:Arial;">&nbsp; &nbsp; int compare(myString, bool =
CaseSensitive); <br></div>
<div style=3D"font-family:Arial;">... <br></div>
<div style=3D"font-family:Arial;">}; <br></div>
<div style=3D"font-family:Arial;"> <br></div>
<div style=3D"font-family:Arial;">in code <br></div>
<div style=3D"font-family:Arial;">&nbsp; &nbsp; if(str.compare(otherString,=
 false) =3D=3D 0) ... &nbsp; // what does this mean, why would you call com=
pare and not compare? <br></div>
<div style=3D"font-family:Arial;"> <br></div>
<div style=3D"font-family:Arial;">This code is legal C++17, but it is user =
hostile. False in the context of reading the function makes no intuitive se=
nse. &nbsp;Qt has created an enum for this, but it can be argued that this =
is too heavy. &nbsp;(you may or may not agree with the argument) <br></div>
</blockquote><div><br></div>
<div>The alternatives should be considered and discussed. Enumerators and t=
agged dispatch both are good solutions.<br></div>
</div>
</blockquote><div style=3D"font-family:Arial;"><br></div>
<div style=3D"font-family:Arial;">The argument against both is they are "ug=
ly"&nbsp; This is of course subjective, but sometimes that is compelling an=
yway.</div>
<div style=3D"font-family:Arial;"><br></div>
<blockquote type=3D"cite"><div dir=3D"ltr"><blockquote defang_data-gmailquo=
te=3D"yes" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margi=
n-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-colo=
r:rgb(204, 204, 204);padding-left:1ex;"><div style=3D"font-family:Arial;">F=
ourth: <br></div>
<div style=3D"font-family:Arial;">// warning, marketing regularly changes t=
he default value of this function <br></div>
<div style=3D"font-family:Arial;">void foo(double a =3D 1234.5, int b =3D 6=
789); <br></div>
<div style=3D"font-family:Arial;"> <br></div>
<div style=3D"font-family:Arial;">foo(b:=3D1234); <br></div>
<div style=3D"font-family:Arial;"> <br></div>
<div style=3D"font-family:Arial;">This won't compile in C++17. However it s=
eems like it would be useful to not clutter function calls with default par=
ameters that you don't care about. In the case I gave it is a maintenance p=
roblem to update all uses of foo every time the defaults change, though I'm=
 not sure if this is actually a common problem.<br></div>
</blockquote><div><br></div>
<div>There are several alternative solutions. A named struct works well eno=
ugh, thanks to designated initializers. Plus, it puts the default values in=
 a more accessible location, rather than the signature of a function. It's =
not like users can get changes to such default values without recompiling a=
nyway.<br></div>
<div><br></div>
<div>There is also the option of using `optional&lt;double&gt;`. So you'd c=
all it with `foo(nullopt, 1234)`, and allow the internal code to fill in th=
e default. This alternative also has the advantage that, if the default cha=
nges, you <i>don't have to recompile</i> to get the changed value. Named pa=
rameters could take advantage of that too by using `optional`.&nbsp;<br></d=
iv>
</div>
</blockquote><div style=3D"font-family:Arial;"><br></div>
<div style=3D"font-family:Arial;">Lots of options are possible.&nbsp; Do we=
 like them?&nbsp;&nbsp;<br></div>
<div style=3D"font-family:Arial;"><br></div>
<div style=3D"font-family:Arial;">I considered proposing a syntax llke 'foo=
(:=3Ddefault, 1234)' for this.&nbsp; I decided it wasn't worth it yet, but =
if we are not happy with the options adding something like this is possible=
..</div>
</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/1534452105.3767720.1476682240.226BF14=
C%40webmail.messagingengine.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1534452105.376772=
0.1476682240.226BF14C%40webmail.messagingengine.com</a>.<br />

--_----------=_153445210537677200--


.

------=_Part_575_923338648.1534453268345
Content-Type: multipart/alternative;
 boundary="----=_Part_576_277744023.1534453268346"

------=_Part_576_277744023.1534453268346
Content-Type: text/plain; charset="UTF-8"

I will answer where I need them.

First to freely use constructors with "many" arguments.
I tend to prefer constructors in place of getter/setter and late
initialization.
This way I have tight control over the state of the object and know -
public interface means someone *else* needs to access this, not "I need
this for construction".

Second, which is tied to the first, I need this for non-so-public
interfaces, where things are not so stable and/or not so pretty. You
mention Qt, but even Qt uses bool arg, in the non public interface!
Yea, I also "never" use a bool, yet I have few places for sure, none of
them public interface, but still.

These two define my PoV:
1. Mainly need weak arguments, but stronger then comments and/or just
warnings
2. No alternative will ever help me if it is *more* code and need *more*
maintenance.

But I want to iterate on the second point.
Way, way to often there is the armchair argument "you should do this" or "you
should do that", in pace of named arguments, and these are mostly correct
(mostly),
*if we talk about public interface. *The requirement for private, and/or
semi stable, and/or work in progress code are different, and the code is
different.
With enough time, any interface can be pretty, even in C, but in practice,
day to day, we need quick and practical ways for more correct code.
(This all putting aside code that even pretty is vulnerable to confusion in
general, like math, physics some algorithms)


--
You received this message because you are 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/037bdc3e-6030-41d6-ae70-3849cca0585c%40isocpp.org.

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

<div dir=3D"ltr"><div>I will answer where I need them.</div><div><br></div>=
<div>First to freely use constructors with &quot;many&quot; arguments.=C2=
=A0</div><div>I tend to prefer constructors in place of getter/setter and l=
ate initialization.=C2=A0</div><div>This way I have tight control over the =
state of the object and know - public interface means someone <i>else</i> n=
eeds to access this, not &quot;I need this for construction&quot;.<br></div=
><div><br></div><div>Second, which is tied to the first, I need this for no=
n-so-public interfaces, where things are not so stable and/or not so pretty=
.. You mention Qt, but even Qt uses bool arg, in the non public interface!</=
div><div>Yea, I also &quot;never&quot; use a bool, yet I have few places fo=
r sure, none of them public interface, but still.</div><div><br></div><div>=
These two define my PoV:=C2=A0</div><div>1. Mainly need weak arguments, but=
 stronger then comments and/or just warnings<br></div><div>2. No alternativ=
e will ever help me if it is <i>more</i> code and need <i>more</i> maintena=
nce.=C2=A0</div><div><br></div><div>But I want to iterate on the second poi=
nt.=C2=A0</div><div>Way, way to often there is the armchair argument &quot;=
you should do this&quot; or &quot;<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;">you should do that</span>&quot;, in pace of name=
d arguments, and these are mostly correct (mostly),=C2=A0</div><div><i>if w=
e talk about public interface. </i>The requirement for private, and/or semi=
 stable, and/or work in progress code are different, and the code is differ=
ent.=C2=A0<br></div><div>With enough time, any interface can be pretty, eve=
n in C, but in practice, day to day, we need quick and practical ways for m=
ore correct code.</div><div>(This all putting aside code that even pretty i=
s vulnerable to confusion in general, like math, physics some algorithms)</=
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/037bdc3e-6030-41d6-ae70-3849cca0585c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/037bdc3e-6030-41d6-ae70-3849cca0585c=
%40isocpp.org</a>.<br />

------=_Part_576_277744023.1534453268346--

------=_Part_575_923338648.1534453268345--

.

--00000000000003d6580573940ee6
Content-Type: text/plain; charset="UTF-8"

Something complexly different approach.
Fro both items ignore syntax, ideas/problems are main focus.

1. Strong typedefs.
    Currently there is strong demand for for it.
    But no consensus so far.
    Take a look at next code

    strongdef polar = std::array<double,2>;
    strongdef descartes = std::array<double,2>;
    struct A{
        void f( polar const& p );
        void f( descartes const& p );
    };

    Clearly strong typedef will supersede this proposal.

  2. Another nice proposal is call functions with named parameters:
    Another very niece feature.

    Example:
     void f( int a, int b );
     f( .b=1, .b=2 ); // Highly probable that is one of many proposed
syntax.
     I see here another clash. Syntax must be clearly different. So more
complication.
     Clash aslo will be in the head of programmer. Which one is call
functions with parameter naming and which one is from this proposal.

Combining two of them( strongdef and function call ) is very easy.
No interference to from each other.

Based on previous two item it is not enough to solve current problem.

 It is must to see what is effect on other proposal.




On Thu, Aug 16, 2018 at 11:01 PM, <mihailnajdenov@gmail.com> wrote:

> I will answer where I need them.
>
> First to freely use constructors with "many" arguments.
> I tend to prefer constructors in place of getter/setter and late
> initialization.
> This way I have tight control over the state of the object and know -
> public interface means someone *else* needs to access this, not "I need
> this for construction".
>
> Second, which is tied to the first, I need this for non-so-public
> interfaces, where things are not so stable and/or not so pretty. You
> mention Qt, but even Qt uses bool arg, in the non public interface!
> Yea, I also "never" use a bool, yet I have few places for sure, none of
> them public interface, but still.
>
> These two define my PoV:
> 1. Mainly need weak arguments, but stronger then comments and/or just
> warnings
> 2. No alternative will ever help me if it is *more* code and need *more*
> maintenance.
>
> But I want to iterate on the second point.
> Way, way to often there is the armchair argument "you should do this" or "you
> should do that", in pace of named arguments, and these are mostly correct
> (mostly),
> *if we talk about public interface. *The requirement for private, and/or
> semi stable, and/or work in progress code are different, and the code is
> different.
> With enough time, any interface can be pretty, even in C, but in practice,
> day to day, we need quick and practical ways for more correct code.
> (This all putting aside code that even pretty is vulnerable to confusion
> in general, like math, physics some algorithms)
>
>
> --
> You received this message because you are 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/037bdc3e-6030-41d6-
> ae70-3849cca0585c%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/037bdc3e-6030-41d6-ae70-3849cca0585c%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/CAEfefmwPGsm3uuGCJKDBgd9d0e3mPONAKkHf0Pdfwbad4Y%3D6Dw%40mail.gmail.com.

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

<div dir=3D"ltr"><div>Something complexly different approach.</div><div>Fro=
 both items ignore syntax, ideas/problems are main focus.</div><div><br></d=
iv><div>1.=C2=A0Strong typedefs.<br>=C2=A0=C2=A0=C2=A0 Currently there is s=
trong demand for for it.<br>=C2=A0=C2=A0=C2=A0 But no consensus so far.<br>=
=C2=A0=C2=A0=C2=A0 Take a look at next code</div><p>=C2=A0=C2=A0=C2=A0 stro=
ngdef polar =3D std::array&lt;double,2&gt;;<br>=C2=A0=C2=A0=C2=A0 strongdef=
 descartes =3D std::array&lt;double,2&gt;;</p><div>=C2=A0=C2=A0=C2=A0 struc=
t A{<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 void f( polar const&amp;=
 p );<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 void f( descartes const=
&amp; p );<br>=C2=A0=C2=A0=C2=A0 };</div><div><br>=C2=A0=C2=A0=C2=A0 Clearl=
y strong typedef will supersede this proposal.</div><p>=C2=A0 2. Another ni=
ce proposal is=C2=A0call functions with named parameters:<br>=C2=A0=C2=A0=
=C2=A0 Another very niece feature.</p><p>=C2=A0=C2=A0=C2=A0 Example:<br>=C2=
=A0=C2=A0=C2=A0=C2=A0 void f( int a, int b );<br>=C2=A0=C2=A0=C2=A0=C2=A0 f=
( .b=3D1, .b=3D2 ); // Highly probable that is one of many proposed syntax.=
</p><div>=C2=A0=C2=A0=C2=A0=C2=A0 I see here another clash. Syntax must be =
clearly different. So more complication.<br>=C2=A0=C2=A0=C2=A0=C2=A0 Clash =
aslo will be in the head of programmer. Which one is call functions with pa=
rameter naming and which one is from this proposal.</div><div><br></div><di=
v>Combining two of them( strongdef and function call ) is very easy.</div><=
div>No interference=C2=A0to from each other. </div><p>Based on previous two=
 item it is not enough to solve current problem.</p><p>=C2=A0It is must to =
see what is effect on other proposal.</p><p><br></p><p><br></p></div><div c=
lass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Aug 16, 2018 at=
 11:01 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:mihailnajdenov@gmail.co=
m" target=3D"_blank">mihailnajdenov@gmail.com</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div>I will answer where I need=
 them.</div><div><br></div><div>First to freely use constructors with &quot=
;many&quot; arguments.=C2=A0</div><div>I tend to prefer constructors in pla=
ce of getter/setter and late initialization.=C2=A0</div><div>This way I hav=
e tight control over the state of the object and know - public interface me=
ans someone <i>else</i> needs to access this, not &quot;I need this for con=
struction&quot;.<br></div><div><br></div><div>Second, which is tied to the =
first, I need this for non-so-public interfaces, where things are not so st=
able and/or not so pretty. You mention Qt, but even Qt uses bool arg, in th=
e non public interface!</div><div>Yea, I also &quot;never&quot; use a bool,=
 yet I have few places for sure, none of them public interface, but still.<=
/div><div><br></div><div>These two define my PoV:=C2=A0</div><div>1. Mainly=
 need weak arguments, but stronger then comments and/or just warnings<br></=
div><div>2. No alternative will ever help me if it is <i>more</i> code and =
need <i>more</i> maintenance.=C2=A0</div><div><br></div><div>But I want to =
iterate on the second point.=C2=A0</div><div>Way, way to often there is the=
 armchair argument &quot;you should do this&quot; or &quot;<span style=3D"t=
ext-align:left;color:rgb(34,34,34);text-transform:none;text-indent:0px;lett=
er-spacing:normal;font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-=
serif;font-size:13px;font-style:normal;font-variant:normal;font-weight:400;=
text-decoration:none;word-spacing:0px;float:none;display:inline!important;w=
hite-space:normal;background-color:transparent">you should do that</span>&q=
uot;, in pace of named arguments, and these are mostly correct (mostly),=C2=
=A0</div><div><i>if we talk about public interface. </i>The requirement for=
 private, and/or semi stable, and/or work in progress code are different, a=
nd the code is different.=C2=A0<br></div><div>With enough time, any interfa=
ce can be pretty, even in C, but in practice, day to day, we need quick and=
 practical ways for more correct code.</div><div>(This all putting aside co=
de that even pretty is vulnerable to confusion in general, like math, physi=
cs some algorithms)</div><div><br></div><div><br></div></div><span>

<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@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/037bdc3e-6030-41d6-ae70-3849cca0585c%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/037b=
dc3e-6030-41d6-<wbr>ae70-3849cca0585c%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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/CAEfefmwPGsm3uuGCJKDBgd9d0e3mPONAKkHf=
0Pdfwbad4Y%3D6Dw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmwPGsm3uu=
GCJKDBgd9d0e3mPONAKkHf0Pdfwbad4Y%3D6Dw%40mail.gmail.com</a>.<br />

--00000000000003d6580573940ee6--

.

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

On Thu, 16 Aug 2018, 22:23 Dejan Milosavljevic, <dmilos@gmail.com> wrote:

> Something complexly different approach.
> Fro both items ignore syntax, ideas/problems are main focus.
>
> 1. Strong typedefs.
>     Currently there is strong demand for for it.
>     But no consensus so far.
>     Take a look at next code
>
>     strongdef polar = std::array<double,2>;
>     strongdef descartes = std::array<double,2>;
>     struct A{
>         void f( polar const& p );
>         void f( descartes const& p );
>     };
>
>     Clearly strong typedef will supersede this proposal.
>

This aligns with my viewpoint on this - though it is commonly argued that
we might just end up cluttering up code with artificial types. My take on
it is that it's always worth doing so in order to define strict conversion
rules, but it isn't everyone's cup of tea.

>   2. Another nice proposal is call functions with named parameters:
>     Another very niece feature.
>
>     Example:
>      void f( int a, int b );
>      f( .b=1, .b=2 ); // Highly probable that is one of many proposed
> syntax.
>
I find that syntax ugly, but its something I would get used to after some
time. I'd prefer :name, $name, @name, something with a bit more prominence
than a dot. But that's just me.

     I see here another clash. Syntax must be clearly different. So more
> complication.
>      Clash aslo will be in the head of programmer. Which one is call
> functions with parameter naming and which one is from this proposal.
>
> Combining two of them( strongdef and function call ) is very easy.
> No interference to from each other.
>
> Based on previous two item it is not enough to solve current problem.
>
>  It is must to see what is effect on other proposal.
>
I guess mixing the two approaches would make a lot of sense, and it
certainly goes some way to answer the "what if the signature for two
functions are the same" problem. Forbid it and make the types stronger if
and when you need to. The last thing I want to have is *forced* named
parameters because of a confusing API. It's an immediate way of making your
headers incompatible with older C++ versions, and I see no justification of
such a major language overhall for a feature that won't see any widespread
adoption for a decade.

On the other hand, it's easy enough for a library to provide structs for
strong types for older standard versions, wrapped in preprocessor
conditionals.

--
You received this message because you are 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%2B0CCNmazfF1R35rWui0D73g258Y0X9RT7XPMa638DMmGf%2BEA%40mail.gmail.com.

--0000000000007f4a10057394d812
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 Thu, =
16 Aug 2018, 22:23 Dejan Milosavljevic, &lt;<a href=3D"mailto:dmilos@gmail.=
com" target=3D"_blank" rel=3D"noreferrer">dmilos@gmail.com</a>&gt; wrote:<b=
r></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>Something comp=
lexly different approach.</div><div>Fro both items ignore syntax, ideas/pro=
blems are main focus.</div><div><br></div><div>1.=C2=A0Strong typedefs.<br>=
=C2=A0=C2=A0=C2=A0 Currently there is strong demand for for it.<br>=C2=A0=
=C2=A0=C2=A0 But no consensus so far.<br>=C2=A0=C2=A0=C2=A0 Take a look at =
next code</div><p>=C2=A0=C2=A0=C2=A0 strongdef polar =3D std::array&lt;doub=
le,2&gt;;<br>=C2=A0=C2=A0=C2=A0 strongdef descartes =3D std::array&lt;doubl=
e,2&gt;;</p><div>=C2=A0=C2=A0=C2=A0 struct A{<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 void f( polar const&amp; p );<br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 void f( descartes const&amp; p );<br>=C2=A0=C2=A0=C2=
=A0 };</div><div><br>=C2=A0=C2=A0=C2=A0 Clearly strong typedef will superse=
de this proposal.</div></div></blockquote></div></div><div dir=3D"auto"><br=
></div><div dir=3D"auto">This aligns with my viewpoint on this - though it =
is commonly argued that we might just end up cluttering up code with artifi=
cial types. My take on it is that it&#39;s always worth doing so in order t=
o define strict conversion rules, but it isn&#39;t everyone&#39;s cup of te=
a.</div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><p>=C2=A0 2. Another nice proposal is=C2=A0call f=
unctions with named parameters:<br>=C2=A0=C2=A0=C2=A0 Another very niece fe=
ature.</p><p>=C2=A0=C2=A0=C2=A0 Example:<br>=C2=A0=C2=A0=C2=A0=C2=A0 void f=
( int a, int b );<br>=C2=A0=C2=A0=C2=A0=C2=A0 f( .b=3D1, .b=3D2 ); // Highl=
y probable that is one of many proposed syntax.</p></div></blockquote></div=
></div><div dir=3D"auto">I find that syntax ugly, but its something I would=
 get used to after some time. I&#39;d prefer :name, $name, @name, something=
 with a bit more prominence than a dot. But that&#39;s just me.</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div>=C2=A0=C2=A0=C2=A0=C2=A0 I see=
 here another clash. Syntax must be clearly different. So more complication=
..<br>=C2=A0=C2=A0=C2=A0=C2=A0 Clash aslo will be in the head of programmer.=
 Which one is call functions with parameter naming and which one is from th=
is proposal.</div><div><br></div><div>Combining two of them( strongdef and =
function call ) is very easy.</div><div>No interference=C2=A0to from each o=
ther. </div><p>Based on previous two item it is not enough to solve current=
 problem.</p><p>=C2=A0It is must to see what is effect on other proposal.</=
p></div></blockquote></div></div><div dir=3D"auto">I guess mixing the two a=
pproaches would make a lot of sense, and it certainly goes some way to answ=
er the &quot;what if the signature for two functions are the same&quot; pro=
blem. Forbid it and make the types stronger if and when you need to. The la=
st thing I want to have is <b>forced</b> named parameters because of a conf=
using API. It&#39;s an immediate way of making your headers incompatible wi=
th older C++ versions, and I see no justification of such a major language =
overhall for a feature that won&#39;t see any widespread adoption for a dec=
ade.</div><div dir=3D"auto"><br></div><div dir=3D"auto">On the other hand, =
it&#39;s easy enough for a library to provide structs for strong types for =
older standard versions, wrapped in preprocessor conditionals.</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%2B0CCNmazfF1R35rWui0D73g258Y0X9RT=
7XPMa638DMmGf%2BEA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCNmaz=
fF1R35rWui0D73g258Y0X9RT7XPMa638DMmGf%2BEA%40mail.gmail.com</a>.<br />

--0000000000007f4a10057394d812--

.

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

On Thu, Aug 16, 2018 at 12:02 PM Nicol Bolas <jmckesson@gmail.com> wrote:

> I think that there should be a discussion of existing solutions to all of
> the problems of interest, so that we can enumerate why those solutions are
> not good enough. It would also allow us to perhaps find a better way to
> handle this than with named parameters. For example, if tagged dispatch
> solves a lot of these problems, then perhaps we can incorporate tags into
> the language in some more formal way rather than going to full named
> parameters.
>

A short list of current solutions I know of:

   - "Named Parameters Idiom"
   - Strong types
   - Tag dispatch
   - Operator overloading (writing foo(parameter = value) by overloading
   operator=, sometimes done with other operators instead); I believe Boost
   Parameters does this
   - Boost Graph's named parameters. The named parameters argument is
   always the last and is specified by member functions. Similar to the named
   parameters idiom, but more complex: boost::foo(positional, arguments,
   boost::arg1(val).arg2(val2))
   - Designated Initializers

The named parameters idiom and Boost Graph's named parameters both require
a lot of overhead on the library author's side. There's a lot of code that
needs to be maintained. If you want to prevent
parameters().foo(value).foo(someOtherValue), that's even more work.
Together with designated initializers, I've heard that this can also
produce worse codegen, since we are passing around a struct rather than
individual parameters.

Strong types and designated initializers fall short in parameter
reordering. Sure, you can provide all possible combinations with strong
types, but then it becomes unmaintainable. Strong types also require a type
for each name you wish to use (if you want different types, that works
within C++17's CTAD), which might run into problems if you end up with
collisions with names of actual types rather than psuedo-types made just
for named parameters. Also, it's annoying to use without using declarations
or directives.

Designated initializers fall short if you go more than one layer deep:
std::invoke(something_with_named_parameters,
{ .arg1 = value }). You have to specify the name of the struct, which is
jarring. It's also not nice to decompose elements of each struct to send
them into other named-parameters-designated-structs. I was convinced
designated initializers would be the solution to C++'s lack of named
parameters, but I ran into problems such as this when experimenting with
it. I had some more complex scenarios, but I have since forgotten them.

There is also the option of using `optional<double>`. So you'd call it with
> `foo(nullopt, 1234)`, and allow the internal code to fill in the default.
> This alternative also has the advantage that, if the default changes, you *don't
> have to recompile* to get the changed value. Named parameters could take
> advantage of that too by using `optional`.
>

This isn't named parameters. This is optional parameters. Once you get more
than a few optional parameters, it becomes unreadable fast: foo(123,
nullopt, nullopt, "string", nullopt)

--
You received this message because you are 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/CAPuuy5cHU7OHPAEFJL41gLnknwxS1JQJHGrOsX8bQR7mfkVdxw%40mail.gmail.com.

--0000000000008c884d057399ec53
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:02 PM Nicol Bolas &lt;<a href=3D"mailto:jmckesson@gmai=
l.com" target=3D"_blank">jmckesson@gmail.com</a>&gt; wrote:</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>I think that there should be a d=
iscussion of existing solutions to all of the problems of interest, so that=
 we can enumerate why those solutions are not good enough. It would also al=
low us to perhaps find a better way to handle this than with named paramete=
rs. For example, if tagged dispatch solves a lot of these problems, then pe=
rhaps we can incorporate tags into the language in some more formal way rat=
her than going to full named parameters.</div></div></blockquote><div><br><=
/div><div>A short list of current solutions I know of:</div><div><ul><li>&q=
uot;Named Parameters Idiom&quot;</li><li>Strong types</li><li>Tag dispatch<=
/li><li>Operator overloading (writing <font face=3D"monospace, monospace">f=
oo(parameter =3D value)</font> by overloading <font face=3D"monospace, mono=
space">operator=3D</font>, sometimes done with other operators instead); I =
believe Boost Parameters does this</li><li>Boost Graph&#39;s named paramete=
rs. The named parameters argument is always the last and is specified by me=
mber functions. Similar to the named parameters idiom, but more complex: <f=
ont face=3D"monospace, monospace">boost::foo(positional, arguments, boost::=
arg1(val).arg2(val2))</font></li><li><font face=3D"arial, helvetica, sans-s=
erif">Designated Initializers</font></li></ul><div><font face=3D"arial, hel=
vetica, sans-serif">The named parameters idiom and Boost Graph&#39;s named =
parameters both require a lot of overhead on the library author&#39;s side.=
 There&#39;s a lot of code that needs to be maintained. If you want to prev=
ent </font><font face=3D"monospace, monospace">parameters().foo(value).foo(=
someOtherValue)</font><font face=3D"arial, helvetica, sans-serif">, that&#3=
9;s even more work. Together with designated initializers, I&#39;ve heard t=
hat this can also produce worse codegen, since we are passing around a stru=
ct rather than individual parameters.</font></div></div><div><font face=3D"=
arial, helvetica, sans-serif"><br></font></div><div><font face=3D"arial, he=
lvetica, sans-serif">Strong types and designated initializers fall short in=
 parameter reordering. Sure, you can provide all possible combinations with=
 strong types, but then it becomes unmaintainable. Strong types also requir=
e a type for each name you wish to use (if you want different types, that w=
orks within C++17&#39;s CTAD), which might run into problems if you end up =
with collisions with names of actual types rather than psuedo-types made ju=
st for named parameters. Also, it&#39;s annoying to use without using decla=
rations or directives.</font></div><div><font face=3D"arial, helvetica, san=
s-serif"><br></font></div><div><font face=3D"arial, helvetica, sans-serif">=
Designated initializers fall short if you go more than one layer deep: </fo=
nt><font face=3D"monospace, monospace">std::invoke(something_with_named_par=
ameters, { .arg1 =3D value })</font><font face=3D"arial, helvetica, sans-se=
rif">. You have to specify the name of the struct, which is jarring. It&#39=
;s also not nice to decompose elements of each struct to send them into oth=
er named-parameters-designated-structs. I was convinced designated initiali=
zers would be the solution to C++&#39;s lack of named parameters, but I ran=
 into problems such as this when experimenting with it. I had some more com=
plex scenarios, but I have since forgotten them.</font></div><div><font fac=
e=3D"arial, helvetica, sans-serif"><br></font></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div>There is also the option of using `optional&l=
t;double&gt;`. So you&#39;d call it with `foo(nullopt, 1234)`, and allow th=
e internal code to fill in the default. This alternative also has the advan=
tage that, if the default changes, you <i>don&#39;t have to recompile</i> t=
o get the changed value. Named parameters could take advantage of that too =
by using `optional`.</div></div></blockquote><div><br></div><div>This isn&#=
39;t named parameters. This is optional parameters. Once you get more than =
a few optional parameters, it becomes unreadable fast: <font face=3D"monosp=
ace, monospace">foo(123, nullopt, nullopt, &quot;string&quot;, nullopt)</fo=
nt>=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/CAPuuy5cHU7OHPAEFJL41gLnknwxS1JQJHGrO=
sX8bQR7mfkVdxw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPuuy5cHU7OHPAEF=
JL41gLnknwxS1JQJHGrOsX8bQR7mfkVdxw%40mail.gmail.com</a>.<br />

--0000000000008c884d057399ec53--

.

--000000000000561b1605739a03cf
Content-Type: text/plain; charset="UTF-8"

Clicked send a bit fast.

Strong types and named parameters are not replacements for one another.
They solve different classes of problems. Strong types don't handle the
case of providing a value for a parameter in the middle of a bunch of
defaulted parameters.

Operator overloading is not a good solution. You need to namespace qualify
everything (else using), and it abuses operators in a way that makes it
unclear what's going on, especially when using operator=.

Boost Graph's named parameters are the best calling-side API I've yet seen
for named parameters. It is not nice to maintain code that provides such
nice APIs, though, although one could make a library to make it more
reasonable.

Tag dispatch is orthogonal to named parameters IMO. Using tags such as
std::in_place is just a way of saying, "I know this is an overload set, but
I really need to call this particular overload." That's not naming
parameters, that's naming overloads. Tag dispatch would not work for Boost
Graph's use case, which is approximately option 4 that Henry Miller
mentioned.

On Thu, Aug 16, 2018 at 9:23 PM Justin Bassett <jbassett271@gmail.com>
wrote:

>
>
> On Thu, Aug 16, 2018 at 12:02 PM Nicol Bolas <jmckesson@gmail.com> wrote:
>
>> I think that there should be a discussion of existing solutions to all of
>> the problems of interest, so that we can enumerate why those solutions are
>> not good enough. It would also allow us to perhaps find a better way to
>> handle this than with named parameters. For example, if tagged dispatch
>> solves a lot of these problems, then perhaps we can incorporate tags into
>> the language in some more formal way rather than going to full named
>> parameters.
>>
>
> A short list of current solutions I know of:
>
>    - "Named Parameters Idiom"
>    - Strong types
>    - Tag dispatch
>    - Operator overloading (writing foo(parameter = value) by overloading
>    operator=, sometimes done with other operators instead); I believe
>    Boost Parameters does this
>    - Boost Graph's named parameters. The named parameters argument is
>    always the last and is specified by member functions. Similar to the named
>    parameters idiom, but more complex: boost::foo(positional, arguments,
>    boost::arg1(val).arg2(val2))
>    - Designated Initializers
>
> The named parameters idiom and Boost Graph's named parameters both require
> a lot of overhead on the library author's side. There's a lot of code that
> needs to be maintained. If you want to prevent
> parameters().foo(value).foo(someOtherValue), that's even more work.
> Together with designated initializers, I've heard that this can also
> produce worse codegen, since we are passing around a struct rather than
> individual parameters.
>
> Strong types and designated initializers fall short in parameter
> reordering. Sure, you can provide all possible combinations with strong
> types, but then it becomes unmaintainable. Strong types also require a type
> for each name you wish to use (if you want different types, that works
> within C++17's CTAD), which might run into problems if you end up with
> collisions with names of actual types rather than psuedo-types made just
> for named parameters. Also, it's annoying to use without using declarations
> or directives.
>
> Designated initializers fall short if you go more than one layer deep: std::invoke(something_with_named_parameters,
> { .arg1 = value }). You have to specify the name of the struct, which is
> jarring. It's also not nice to decompose elements of each struct to send
> them into other named-parameters-designated-structs. I was convinced
> designated initializers would be the solution to C++'s lack of named
> parameters, but I ran into problems such as this when experimenting with
> it. I had some more complex scenarios, but I have since forgotten them.
>
> There is also the option of using `optional<double>`. So you'd call it
>> with `foo(nullopt, 1234)`, and allow the internal code to fill in the
>> default. This alternative also has the advantage that, if the default
>> changes, you *don't have to recompile* to get the changed value. Named
>> parameters could take advantage of that too by using `optional`.
>>
>
> This isn't named parameters. This is optional parameters. Once you get
> more than a few optional parameters, it becomes unreadable fast: foo(123,
> nullopt, nullopt, "string", nullopt)
>

--
You received this message because you are 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/CAPuuy5cV03gX4Th%2BLxPAAXjnBEyNatrdinrjVFRLsSiLavj%2BjA%40mail.gmail.com.

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

<div dir=3D"ltr">Clicked send a bit fast.<div><br></div><div>Strong types a=
nd named parameters are not replacements for one another. They solve differ=
ent classes of problems. Strong types don&#39;t handle the case of providin=
g a value for a parameter in the middle of a bunch of defaulted parameters.=
</div><div><br></div><div>Operator overloading is not a good solution. You =
need to namespace qualify everything (else <font face=3D"monospace, monospa=
ce">using</font>), and it abuses operators in a way that makes it unclear w=
hat&#39;s going on, especially when using <font face=3D"monospace, monospac=
e">operator=3D</font>.</div><div><br></div><div>Boost Graph&#39;s named par=
ameters are the best calling-side API I&#39;ve yet seen for named parameter=
s. It is not nice to maintain code that provides such nice APIs, though, al=
though one could make a library to make it more reasonable.</div><div><br><=
/div><div>Tag dispatch is orthogonal to named parameters IMO. Using tags su=
ch as <font face=3D"monospace, monospace">std::in_place</font> is just a wa=
y of saying, &quot;I know this is an overload set, but I really need to cal=
l this particular overload.&quot; That&#39;s not naming parameters, that&#3=
9;s naming overloads. Tag dispatch would not work for Boost Graph&#39;s use=
 case, which is approximately option 4 that Henry Miller mentioned.</div></=
div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Aug 16, 2018 at=
 9:23 PM Justin Bassett &lt;<a href=3D"mailto:jbassett271@gmail.com">jbasse=
tt271@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Au=
g 16, 2018 at 12:02 PM Nicol Bolas &lt;<a href=3D"mailto:jmckesson@gmail.co=
m" target=3D"_blank">jmckesson@gmail.com</a>&gt; wrote:</div><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>I think that there should be a discu=
ssion of existing solutions to all of the problems of interest, so that we =
can enumerate why those solutions are not good enough. It would also allow =
us to perhaps find a better way to handle this than with named parameters. =
For example, if tagged dispatch solves a lot of these problems, then perhap=
s we can incorporate tags into the language in some more formal way rather =
than going to full named parameters.</div></div></blockquote><div><br></div=
><div>A short list of current solutions I know of:</div><div><ul><li>&quot;=
Named Parameters Idiom&quot;</li><li>Strong types</li><li>Tag dispatch</li>=
<li>Operator overloading (writing <font face=3D"monospace, monospace">foo(p=
arameter =3D value)</font> by overloading <font face=3D"monospace, monospac=
e">operator=3D</font>, sometimes done with other operators instead); I beli=
eve Boost Parameters does this</li><li>Boost Graph&#39;s named parameters. =
The named parameters argument is always the last and is specified by member=
 functions. Similar to the named parameters idiom, but more complex: <font =
face=3D"monospace, monospace">boost::foo(positional, arguments, boost::arg1=
(val).arg2(val2))</font></li><li><font face=3D"arial, helvetica, sans-serif=
">Designated Initializers</font></li></ul><div><font face=3D"arial, helveti=
ca, sans-serif">The named parameters idiom and Boost Graph&#39;s named para=
meters both require a lot of overhead on the library author&#39;s side. The=
re&#39;s a lot of code that needs to be maintained. If you want to prevent =
</font><font face=3D"monospace, monospace">parameters().foo(value).foo(some=
OtherValue)</font><font face=3D"arial, helvetica, sans-serif">, that&#39;s =
even more work. Together with designated initializers, I&#39;ve heard that =
this can also produce worse codegen, since we are passing around a struct r=
ather than individual parameters.</font></div></div><div><font face=3D"aria=
l, helvetica, sans-serif"><br></font></div><div><font face=3D"arial, helvet=
ica, sans-serif">Strong types and designated initializers fall short in par=
ameter reordering. Sure, you can provide all possible combinations with str=
ong types, but then it becomes unmaintainable. Strong types also require a =
type for each name you wish to use (if you want different types, that works=
 within C++17&#39;s CTAD), which might run into problems if you end up with=
 collisions with names of actual types rather than psuedo-types made just f=
or named parameters. Also, it&#39;s annoying to use without using declarati=
ons or directives.</font></div><div><font face=3D"arial, helvetica, sans-se=
rif"><br></font></div><div><font face=3D"arial, helvetica, sans-serif">Desi=
gnated initializers fall short if you go more than one layer deep: </font><=
font face=3D"monospace, monospace">std::invoke(something_with_named_paramet=
ers, { .arg1 =3D value })</font><font face=3D"arial, helvetica, sans-serif"=
>. You have to specify the name of the struct, which is jarring. It&#39;s a=
lso not nice to decompose elements of each struct to send them into other n=
amed-parameters-designated-structs. I was convinced designated initializers=
 would be the solution to C++&#39;s lack of named parameters, but I ran int=
o problems such as this when experimenting with it. I had some more complex=
 scenarios, but I have since forgotten them.</font></div><div><font face=3D=
"arial, helvetica, sans-serif"><br></font></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>There is also the option of using `optional&lt;do=
uble&gt;`. So you&#39;d call it with `foo(nullopt, 1234)`, and allow the in=
ternal code to fill in the default. This alternative also has the advantage=
 that, if the default changes, you <i>don&#39;t have to recompile</i> to ge=
t the changed value. Named parameters could take advantage of that too by u=
sing `optional`.</div></div></blockquote><div><br></div><div>This isn&#39;t=
 named parameters. This is optional parameters. Once you get more than a fe=
w optional parameters, it becomes unreadable fast: <font face=3D"monospace,=
 monospace">foo(123, nullopt, nullopt, &quot;string&quot;, nullopt)</font>=
=C2=A0</div></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/CAPuuy5cV03gX4Th%2BLxPAAXjnBEyNatrdin=
rjVFRLsSiLavj%2BjA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPuuy5cV03gX=
4Th%2BLxPAAXjnBEyNatrdinrjVFRLsSiLavj%2BjA%40mail.gmail.com</a>.<br />

--000000000000561b1605739a03cf--

.

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

On Thu, Aug 16, 2018 at 10:45 AM Henry Miller <hank@millerfarm.com> wrote:

>
> In the past couple months I've seen several proposals for names
> parameters.  Each with a list of pros and cons, and because there are cons
> arguments against them.  I think we need a discussion on what we want
> assuming some strawman acceptable syntax, and some thought of how many
> limitations in corner cases we are willing to accept.
>
> I can think of 4 uses for names parameters. (If you don't understand these
> I have simple code examples)
> 1 . a function with more than one parameter of the same type is called
> with the parameters in the wrong order
>       *  Some people want this to be a compilation error, some want the
> compiler to correct the problem and continue
> 2. a function wants to take the same type to mean different things in
> different contexts
> 3. it isn't obvious from the type alone what a parameter means
> 4. A function has a bunch of defaulted arguments and you want to change
> one of the latter ones without specifying all the others
>
> First question: is this complete?
> Second, which problems are worth solving?
> Third, for problems worth solving, which is the better solution, and how
> strongly attached to it are you?
>

Some other use cases:

5. In tandem with reflection, names could be used for their names. A
formatting library could use this in tandem with reflection:
fmt::format("{sign}
{value}", .sign = "$", .value = 1.34_usd); Language bindings to e.g. Python
could use it to specify names for parameters  (e.g. this could expose the
parameter names to the language bindings: m.def([](int .a, int .b) { return
a + b; }) )
6. This is a variation on 4. There may not be a bunch of defaulted
arguments, but rather a few expert settings which you want the users to be
able to tweak on rare occasions.
7. bool arguments have meaning. It's pretty well known that something
like file.open("path/to/file.txt",
true) is bad, because the bool has no meaning. But
file.open("path/to/file.txt",
..append = true) isn't so bad because the meaning is apparent. Enums
currently fill this role.

--
You received this message because you are 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/CAPuuy5dz_N4nwnDrmds%3DROEpnUY2jQU4XGcLytxXscB%3DX36P1g%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Aug 16=
, 2018 at 10:45 AM Henry Miller &lt;<a href=3D"mailto:hank@millerfarm.com">=
hank@millerfarm.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<br>
In the past couple months I&#39;ve seen several proposals for names paramet=
ers.=C2=A0 Each with a list of pros and cons, and because there are cons ar=
guments against them.=C2=A0 I think we need a discussion on what we want as=
suming some strawman acceptable syntax, and some thought of how many limita=
tions in corner cases we are willing to accept. <br>
<br>
I can think of 4 uses for names parameters. (If you don&#39;t understand th=
ese I have simple code examples)<br>
1 . a function with more than one parameter of the same type is called with=
 the parameters in the wrong order<br>
=C2=A0 =C2=A0 =C2=A0 *=C2=A0 Some people want this to be a compilation erro=
r, some want the compiler to correct the problem and continue<br>
2. a function wants to take the same type to mean different things in diffe=
rent contexts<br>
3. it isn&#39;t obvious from the type alone what a parameter means<br>
4. A function has a bunch of defaulted arguments and you want to change one=
 of the latter ones without specifying all the others<br>
<br>
First question: is this complete?<br>
Second, which problems are worth solving?<br>
Third, for problems worth solving, which is the better solution, and how st=
rongly attached to it are you?<br></blockquote><div><br></div><div>Some oth=
er use cases:</div><div><br></div><div>5. In tandem with reflection, names =
could be used for their names. A formatting library could use this in tande=
m with reflection: <font face=3D"monospace, monospace">fmt::format(&quot;{s=
ign} {value}&quot;, .sign =3D &quot;$&quot;, .value =3D 1.34_usd)</font>; L=
anguage bindings to e.g. Python could use it to specify names for parameter=
s=C2=A0=C2=A0(e.g. this could expose the parameter names to the language bi=
ndings: <font face=3D"monospace, monospace">m.def([](int .a, int .b) { retu=
rn a + b; })</font> )</div><div>6. This is a variation on 4. There may not =
be a bunch of defaulted arguments, but rather a few expert settings which y=
ou want the users to be able to tweak on rare occasions.</div><div>7. bool =
arguments have meaning. It&#39;s pretty well known that something like <fon=
t face=3D"monospace, monospace">file.open(&quot;path/to/file.txt&quot;, tru=
e)</font> is bad, because the bool has no meaning. But <font face=3D"monosp=
ace, monospace">file.open(&quot;path/to/file.txt&quot;, .append =3D true)</=
font> isn&#39;t so bad because the meaning is apparent. Enums currently fil=
l this role.</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/CAPuuy5dz_N4nwnDrmds%3DROEpnUY2jQU4XG=
cLytxXscB%3DX36P1g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPuuy5dz_N4n=
wnDrmds%3DROEpnUY2jQU4XGcLytxXscB%3DX36P1g%40mail.gmail.com</a>.<br />

--0000000000007a12a905739a24f2--

.

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

Le 16/08/2018 =C3=A0 22:41, Henry Miller a =C3=A9crit=C2=A0:
> On Thu, Aug 16, 2018, at 2:02 PM, Nicol Bolas wrote:
>> On Thursday, August 16, 2018 at 1:45:01 PM UTC-4, Henry Miller wrote:
>>
>>
>>     In the past couple months I've seen several proposals for names
>>     parameters. =C2=A0Each with a list of pros and cons, and because the=
re
>>     are cons arguments against them. =C2=A0I think we need a discussion =
on
>>     what we want assuming some strawman acceptable syntax, and some
>>     thought of how many limitations in corner cases we are willing to
>>     accept.
>>
>>     I can think of 4 uses for names parameters. (If you don't
>>     understand these I have simple code examples)
>>     1 . a function with more than one parameter of the same type is
>>     called with the parameters in the wrong order
>>     =C2=A0 =C2=A0 =C2=A0 * =C2=A0Some people want this to be a compilati=
on error, some
>>     want the compiler to correct the problem and continue
>>     2. a function wants to take the same type to mean different
>>     things in different contexts
>>     3. it isn't obvious from the type alone what a parameter means
>>     4. A function has a bunch of defaulted arguments and you want to
>>     change one of the latter ones without specifying all the others
>>
>>     First question: is this complete?
>>     Second, which problems are worth solving?
>>     Third, for problems worth solving, which is the better solution,
>>     and how strongly attached to it are you?
>>
>>
>> I think that there should be a discussion of existing solutions to=20
>> all of the problems of interest, so that we can enumerate why those=20
>> solutions are not good enough. It would also allow us to perhaps find=20
>> a better way to handle this than with named parameters. For example,=20
>> if tagged dispatch solves a lot of these problems, then perhaps we=20
>> can incorporate tags into the language in some more formal way rather=20
>> than going to full named parameters.
>
> That comes next. First I want to brainstorm in a world where we are=20
> not constrained by possible to say what we want.
I'm not against a possible named parameter feature, but we need a good=20
proposal as all of them have failed. Why the past proposals failed?

In addition, I believe that what Nicol means is that in order to compare=20
possible solutions to those problems we need to compare them as well to=20
the current solutions we have already using the current standard. The=20
current way is even more important=C2=A0 than the new way to check if it is=
=20
worth changing the language.

One important thing to consider is if we are able to change the existing=20
defining code, if we are able to change the signature (the function=20
type), ...
>
> After that we look at the other solutions, decide which are useful,=20
> and if any are good enough. Note in particular P0707 - metaclasses has=20
> using...as notation which make strong types easier to declare and=20
> might give everyone what they wanted.
>
>>
>>     For the first the motivating code is something like:
>>
>>     class myMatrix {
>>     =C2=A0 =C2=A0 =C2=A0T GetCell(int row, int column);
>>     =C2=A0 =C2=A0 =C2=A0...
>>     };
>>
>>     in code:
>>     =C2=A0 =C2=A0cell =3D matrix.GetCell(column, row);
>>
>>     This will compile just fine in C++17, but the code is undoubtedly
>>     wrong. =C2=A0In C++2n do you want this to be a compiler error, or
>>     correct code?
>>
>>
>> Note that making this "not correct code" would require that the=20
>> mechanism /require/ that the user provide named arguments. That is,=20
>> you cannot use positional arguments at all.
>
> Right, the question is WHAT mechanism?=C2=A0 When I write that I thought =
of=20
> 4 different ways to change C++ to accomplish this, and as it happens=20
> taging wasn't one.=C2=A0 My 4 plus taging isn't a complete list either, i=
t=20
> isn't even close.
>
> The point isn't to discuss how we want to do this, it is to discuss to=20
> we want to do it at all, and if so is it a compiler error or does the=20
> compiler just do what the user wanted.
Hum, how to know what the user wanted?
Having a name parameter could help also partially as you could always=20
use the bad int while associating the row and columns named arguments.
>
>>
>> Tagged dispatch can handle such cases.
When considering tag dispatch, we change the function type, and some=20
times this is not possible.
If we can change the signature, this case can be solved partially using=20
different types for row and column. I say partially because at the end=20
you will need to initialize a row and a column, and you could choose the=20
wrong int for them (as with named parameters)
>>
>>     Second:
>>     class point {
>>     =C2=A0 =C2=A0 point(double x, double y);
>>     =C2=A0 =C2=A0 point(double distance, double angle);
>>     ...
>>     };
>>
>>     This code does not compile in C++17. =C2=A0Do we want to make this
>>     case work?
>>
>>
>> Tagged dispatch can work here. So can a properly named struct:=20
>> `point(Polar(dist, angle))`. Plus, by giving the type a full name, we=20
>> allow `Polar` coordinates to be passed around and used for other=20
>> purposes.
In this case I'm all for strong types and I believe we shouldn't take it=20
into consideration this example while discussing named parameters. Named=20
parameters (as I understand them) couldn't be used to solve this case.
Tag dispatch could be a solution as well.
>>
>>     Third:
>>     class myString {
>>     =C2=A0 =C2=A0 int compare(myString, bool CaseSensitive);
>>     ...
>>     };
>>
>>     in code
>>     if(str.compare(otherString, false) =3D=3D 0) ... =C2=A0 // what does=
 this
>>     mean, why would you call compare and not compare?
>>
>>     This code is legal C++17, but it is user hostile. False in the
>>     context of reading the function makes no intuitive sense. =C2=A0Qt h=
as
>>     created an enum for this, but it can be argued that this is too
>>     heavy. =C2=A0(you may or may not agree with the argument)
>>
>>
>> The alternatives should be considered and discussed. Enumerators and=20
>> tagged dispatch both are good solutions.
>
> The argument against both is they are "ugly"=C2=A0 This is of course=20
> subjective, but sometimes that is compelling anyway.

What is wrong with case_sensitive, non_case_sensitive?

I'm a fan of strong types and I would like to minimize the direct use of=20
non-strong types as much as possible. When I try to solve define a=20
strong flag I have the problem that those flags can not be short circuit=20
the overloaded boolean expressions. This means that those strong types=20
should be convertible to a bool.
>
>>     Fourth:
>>     // warning, marketing regularly changes the default value of this
>>     function
>>     void foo(double a =3D 1234.5, int b =3D 6789);
>>
>>     foo(b:=3D1234);
>>
>>     This won't compile in C++17. However it seems like it would be
>>     useful to not clutter function calls with default parameters that
>>     you don't care about. In the case I gave it is a maintenance
>>     problem to update all uses of foo every time the defaults change,
>>     though I'm not sure if this is actually a common problem.
>>
>>
>> There are several alternative solutions. A named struct works well=20
>> enough, thanks to designated initializers. Plus, it puts the default=20
>> values in a more accessible location, rather than the signature of a=20
>> function. It's not like users can get changes to such default values=20
>> without recompiling anyway.
>>
>> There is also the option of using `optional<double>`. So you'd call=20
>> it with `foo(nullopt, 1234)`, and allow the internal code to fill in=20
>> the default. This alternative also has the advantage that, if the=20
>> default changes, you /don't have to recompile/ to get the changed=20
>> value. Named parameters could take advantage of that too by using=20
>> `optional`.
>
> Lots of options are possible.=C2=A0 Do we like them?

I want to promote interfaces like the previous one. Maybe knowing what=20
foo, a and b mean could help me. Could we please, use concrete examples.
When I have a lot of parameters, I believe I like the named struct=20
approach. It is easy to define the default values today, and the use of=20
named designators help to override them. The compiler shopuld make the=20
code as efficient as if we had several parameters and in some cases it=20
will even make the code more efficient.

And you, do you like them? If not, what you don't like and why?

>
> I considered proposing a syntax llke 'foo(:=3Ddefault, 1234)' for this.=
=C2=A0=20
> I decided it wasn't worth it yet, but if we are not happy with the=20
> options adding something like this is possible.
I want to promote interfaces like the previous one. Maybe knowing what=20
foo, a and b mean could help me.

Note that you can already define to code what the comment says "warning,=20
marketing regularly changes the default value of this function".

 =C2=A0=C2=A0=C2=A0 double foo_a_default =3D ...;
 =C2=A0=C2=A0=C2=A0 void foo(double a =3D foo_a_default, int b =3D foo_b_de=
fault);

 =C2=A0=C2=A0=C2=A0 foo(foo_a_default, 1234);

so the previous solution should be compared to something like this to=20
check if it is worth changing the language to cover this case.

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/2fcb51b2-fefb-b190-aaa5-d884cf6a4ab8%40wanadoo.f=
r.

--------------38781DCFCF90F75D5C82CF34
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 22:41, Henry Miller=
 a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"
cite=3D"mid:1534452105.3767720.1476682240.226BF14C@webmail.messagingengine.=
com">
      <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf=
-8">
      <title></title>
      <style type=3D"text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style>
      <div style=3D"font-family:Arial;">On Thu, Aug 16, 2018, at 2:02 PM,
        Nicol Bolas wrote:<br>
      </div>
      <blockquote type=3D"cite">
        <div dir=3D"ltr">
          <div style=3D"font-family:Arial;">On Thursday, August 16, 2018
            at 1:45:01 PM UTC-4, Henry Miller wrote:<br>
          </div>
          <blockquote defang_data-gmailquote=3D"yes"
style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8e=
x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,
            204, 204);padding-left:1ex;">
            <div style=3D"font-family:Arial;"><br>
            </div>
            <div style=3D"font-family:Arial;">In the past couple months
              I've seen several proposals for names parameters. =C2=A0Each
              with a list of pros and cons, and because there are cons
              arguments against them. =C2=A0I think we need a discussion on
              what we want assuming some strawman acceptable syntax, and
              some thought of how many limitations in corner cases we
              are willing to accept. <br>
            </div>
            <div style=3D"font-family:Arial;"> <br>
            </div>
            <div style=3D"font-family:Arial;">I can think of 4 uses for
              names parameters. (If you don't understand these I have
              simple code examples) <br>
            </div>
            <div style=3D"font-family:Arial;">1 . a function with more
              than one parameter of the same type is called with the
              parameters in the wrong order <br>
            </div>
            <div style=3D"font-family:Arial;">=C2=A0 =C2=A0 =C2=A0 * =C2=A0=
Some people want
              this to be a compilation error, some want the compiler to
              correct the problem and continue <br>
            </div>
            <div style=3D"font-family:Arial;">2. a function wants to take
              the same type to mean different things in different
              contexts <br>
            </div>
            <div style=3D"font-family:Arial;">3. it isn't obvious from the
              type alone what a parameter means <br>
            </div>
            <div style=3D"font-family:Arial;">4. A function has a bunch of
              defaulted arguments and you want to change one of the
              latter ones without specifying all the others <br>
            </div>
            <div style=3D"font-family:Arial;"> <br>
            </div>
            <div style=3D"font-family:Arial;">First question: is this
              complete? <br>
            </div>
            <div style=3D"font-family:Arial;">Second, which problems are
              worth solving? <br>
            </div>
            <div style=3D"font-family:Arial;">Third, for problems worth
              solving, which is the better solution, and how strongly
              attached to it are you? <br>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>I think that there should be a discussion of existing
            solutions to all of the problems of interest, so that we can
            enumerate why those solutions are not good enough. It would
            also allow us to perhaps find a better way to handle this
            than with named parameters. For example, if tagged dispatch
            solves a lot of these problems, then perhaps we can
            incorporate tags into the language in some more formal way
            rather than going to full named parameters.<br>
          </div>
        </div>
      </blockquote>
      <div style=3D"font-family:Arial;"><br>
      </div>
      <div style=3D"font-family:Arial;">That comes next. First I want to
        brainstorm in a world where we are not constrained by possible
        to say what we want.<br>
      </div>
    </blockquote>
    I'm not against a possible named parameter feature, but we need a
    good proposal as all of them have failed. Why the past proposals
    failed?<br>
    <br>
    In addition, I believe that what Nicol means is that in order to
    compare possible solutions to those problems we need to compare them
    as well to the current solutions we have already using the current
    standard. The current way is even more important=C2=A0 than the new way
    to check if it is worth changing the language.<br>
    <br>
    One important thing to consider is if we are able to change the
    existing defining code, if we are able to change the signature (the
    function type), ...<br>
    <blockquote type=3D"cite"
cite=3D"mid:1534452105.3767720.1476682240.226BF14C@webmail.messagingengine.=
com">
      <div style=3D"font-family:Arial;"><br>
      </div>
      <div style=3D"font-family:Arial;">After that we look at the other
        solutions, decide which are useful, and if any are good enough.=C2=
=A0
        Note in particular P0707 - metaclasses has using...as notation
        which make strong types easier to declare and might give
        everyone what they wanted.<br>
      </div>
      <div style=3D"font-family:Arial;"><br>
      </div>
      <blockquote type=3D"cite">
        <div dir=3D"ltr">
          <div><br>
          </div>
          <blockquote defang_data-gmailquote=3D"yes"
style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8e=
x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,
            204, 204);padding-left:1ex;">
            <div style=3D"font-family:Arial;">For the first the motivating
              code is something like: <br>
            </div>
            <div style=3D"font-family:Arial;"> <br>
            </div>
            <div style=3D"font-family:Arial;">class myMatrix { <br>
            </div>
            <div style=3D"font-family:Arial;">=C2=A0 =C2=A0 =C2=A0T GetCell=
(int row, int
              column); <br>
            </div>
            <div style=3D"font-family:Arial;">=C2=A0 =C2=A0 =C2=A0... <br>
            </div>
            <div style=3D"font-family:Arial;">}; <br>
            </div>
            <div style=3D"font-family:Arial;"> <br>
            </div>
            <div style=3D"font-family:Arial;">in code: <br>
            </div>
            <div style=3D"font-family:Arial;">=C2=A0 =C2=A0cell =3D
              matrix.GetCell(column, row); <br>
            </div>
            <div style=3D"font-family:Arial;"> <br>
            </div>
            <div style=3D"font-family:Arial;">This will compile just fine
              in C++17, but the code is undoubtedly wrong. =C2=A0In C++2n d=
o
              you want this to be a compiler error, or correct code?<br>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>Note that making this "not correct code" would require
            that the mechanism <i>require</i> that the user provide
            named arguments. That is, you cannot use positional
            arguments at all.<br>
          </div>
        </div>
      </blockquote>
      <div style=3D"font-family:Arial;"><br>
      </div>
      <div style=3D"font-family:Arial;">Right, the question is WHAT
        mechanism?=C2=A0 When I write that I thought of 4 different ways to
        change C++ to accomplish this, and as it happens taging wasn't
        one.=C2=A0 My 4 plus taging isn't a complete list either, it isn't
        even close.<br>
      </div>
      <div style=3D"font-family:Arial;"><br>
      </div>
      <div style=3D"font-family:Arial;">The point isn't to discuss how we
        want to do this, it is to discuss to we want to do it at all,
        and if so is it a compiler error or does the compiler just do
        what the user wanted.</div>
    </blockquote>
    Hum, how to know what the user wanted?<br>
    Having a name parameter could help also partially as you could
    always use the bad int while associating the row and columns named
    arguments.=C2=A0 <br>
    <blockquote type=3D"cite"
cite=3D"mid:1534452105.3767720.1476682240.226BF14C@webmail.messagingengine.=
com">
      <div style=3D"font-family:Arial;"><br>
      </div>
      <blockquote type=3D"cite">
        <div dir=3D"ltr">
          <div><br>
          </div>
          <div>Tagged dispatch can handle such cases.<br>
          </div>
        </div>
      </blockquote>
    </blockquote>
    When considering tag dispatch, we change the function type, and some
    times this is not possible.<br>
    If we can change the signature, this case can be solved partially
    using different types for row and column. I say partially because at
    the end you will need to initialize a row and a column, and you
    could choose the wrong int for them (as with named parameters)<br>
    <blockquote type=3D"cite"
cite=3D"mid:1534452105.3767720.1476682240.226BF14C@webmail.messagingengine.=
com">
      <blockquote type=3D"cite">
        <div dir=3D"ltr">
          <div><br>
          </div>
          <blockquote defang_data-gmailquote=3D"yes"
style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8e=
x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,
            204, 204);padding-left:1ex;">
            <div style=3D"font-family:Arial;">Second: <br>
            </div>
            <div style=3D"font-family:Arial;">class point { <br>
            </div>
            <div style=3D"font-family:Arial;">=C2=A0 =C2=A0 point(double x,=
 double
              y); <br>
            </div>
            <div style=3D"font-family:Arial;">=C2=A0 =C2=A0 point(double di=
stance,
              double angle); <br>
            </div>
            <div style=3D"font-family:Arial;">... <br>
            </div>
            <div style=3D"font-family:Arial;">}; <br>
            </div>
            <div style=3D"font-family:Arial;"> <br>
            </div>
            <div style=3D"font-family:Arial;">This code does not compile
              in C++17. =C2=A0Do we want to make this case work?<br>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>Tagged dispatch can work here. So can a properly named
            struct: `point(Polar(dist, angle))`. Plus, by giving the
            type a full name, we allow `Polar` coordinates to be passed
            around and used for other purposes.<br>
          </div>
        </div>
      </blockquote>
    </blockquote>
    In this case I'm all for strong types and I believe we shouldn't
    take it into consideration this example while discussing named
    parameters. Named parameters (as I understand them) couldn't be used
    to solve this case.<br>
    Tag dispatch could be a solution as well.<br>
    <blockquote type=3D"cite"
cite=3D"mid:1534452105.3767720.1476682240.226BF14C@webmail.messagingengine.=
com">
      <blockquote type=3D"cite">
        <div dir=3D"ltr">
          <div><br>
          </div>
          <blockquote defang_data-gmailquote=3D"yes"
style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8e=
x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,
            204, 204);padding-left:1ex;">
            <div style=3D"font-family:Arial;">Third: <br>
            </div>
            <div style=3D"font-family:Arial;">class myString { <br>
            </div>
            <div style=3D"font-family:Arial;">=C2=A0 =C2=A0 int compare(myS=
tring,
              bool CaseSensitive); <br>
            </div>
            <div style=3D"font-family:Arial;">... <br>
            </div>
            <div style=3D"font-family:Arial;">}; <br>
            </div>
            <div style=3D"font-family:Arial;"> <br>
            </div>
            <div style=3D"font-family:Arial;">in code <br>
            </div>
            <div style=3D"font-family:Arial;">=C2=A0 =C2=A0
              if(str.compare(otherString, false) =3D=3D 0) ... =C2=A0 // wh=
at
              does this mean, why would you call compare and not
              compare? <br>
            </div>
            <div style=3D"font-family:Arial;"> <br>
            </div>
            <div style=3D"font-family:Arial;">This code is legal C++17,
              but it is user hostile. False in the context of reading
              the function makes no intuitive sense. =C2=A0Qt has created a=
n
              enum for this, but it can be argued that this is too
              heavy. =C2=A0(you may or may not agree with the argument) <br=
>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>The alternatives should be considered and discussed.
            Enumerators and tagged dispatch both are good solutions.<br>
          </div>
        </div>
      </blockquote>
      <div style=3D"font-family:Arial;"><br>
      </div>
      <div style=3D"font-family:Arial;">The argument against both is they
        are "ugly"=C2=A0 This is of course subjective, but sometimes that i=
s
        compelling anyway.</div>
    </blockquote>
    <br>
    What is wrong with case_sensitive, non_case_sensitive?<br>
    <br>
    I'm a fan of strong types and I would like to minimize the direct
    use of non-strong types as much as possible. When I try to solve
    define a strong flag I have the problem that those flags can not be
    short circuit the overloaded boolean expressions. This means that
    those strong types should be convertible to a bool.<br>
    <blockquote type=3D"cite"
cite=3D"mid:1534452105.3767720.1476682240.226BF14C@webmail.messagingengine.=
com">
      <div style=3D"font-family:Arial;"><br>
      </div>
      <blockquote type=3D"cite">
        <div dir=3D"ltr">
          <blockquote defang_data-gmailquote=3D"yes"
style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8e=
x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,
            204, 204);padding-left:1ex;">
            <div style=3D"font-family:Arial;">Fourth: <br>
            </div>
            <div style=3D"font-family:Arial;">// warning, marketing
              regularly changes the default value of this function <br>
            </div>
            <div style=3D"font-family:Arial;">void foo(double a =3D 1234.5,
              int b =3D 6789); <br>
            </div>
            <div style=3D"font-family:Arial;"> <br>
            </div>
            <div style=3D"font-family:Arial;">foo(b:=3D1234); <br>
            </div>
            <div style=3D"font-family:Arial;"> <br>
            </div>
            <div style=3D"font-family:Arial;">This won't compile in C++17.
              However it seems like it would be useful to not clutter
              function calls with default parameters that you don't care
              about. In the case I gave it is a maintenance problem to
              update all uses of foo every time the defaults change,
              though I'm not sure if this is actually a common problem.<br>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>There are several alternative solutions. A named struct
            works well enough, thanks to designated initializers. Plus,
            it puts the default values in a more accessible location,
            rather than the signature of a function. It's not like users
            can get changes to such default values without recompiling
            anyway.<br>
          </div>
          <div><br>
          </div>
          <div>There is also the option of using
            `optional&lt;double&gt;`. So you'd call it with
            `foo(nullopt, 1234)`, and allow the internal code to fill in
            the default. This alternative also has the advantage that,
            if the default changes, you <i>don't have to recompile</i>
            to get the changed value. Named parameters could take
            advantage of that too by using `optional`.=C2=A0<br>
          </div>
        </div>
      </blockquote>
      <div style=3D"font-family:Arial;"><br>
      </div>
      <div style=3D"font-family:Arial;">Lots of options are possible.=C2=A0=
 Do
        we like them?=C2=A0 <br>
      </div>
    </blockquote>
    <br>
    I want to promote interfaces like the previous one. Maybe knowing
    what foo, a and b mean could help me. Could we please, use concrete
    examples.<br>
    When I have a lot of parameters, I believe I like the named struct
    approach. It is easy to define the default values today, and the use
    of named designators help to override them. The compiler shopuld
    make the code as efficient as if we had several parameters and in
    some cases it will even make the code more efficient.<br>
    <br>
    And you, do you like them? If not, what you don't like and why?<br>
    <br>
    <blockquote type=3D"cite"
cite=3D"mid:1534452105.3767720.1476682240.226BF14C@webmail.messagingengine.=
com">
      <div style=3D"font-family:Arial;"><br>
      </div>
      <div style=3D"font-family:Arial;">I considered proposing a syntax
        llke 'foo(:=3Ddefault, 1234)' for this.=C2=A0 I decided it wasn't w=
orth
        it yet, but if we are not happy with the options adding
        something like this is possible.</div>
    </blockquote>
    I want to promote interfaces like the previous one. Maybe knowing
    what foo, a and b mean could help me.<br>
    <br>
    Note that you can already define to code what the comment says
    "warning, marketing regularly changes the default value of this
    function".<br>
    <br>
    =C2=A0=C2=A0=C2=A0 double foo_a_default =3D ...;<br>
    <div style=3D"font-family:Arial;">=C2=A0=C2=A0=C2=A0 void foo(double a =
=3D
      foo_a_default, int b =3D foo_b_default); <br>
    </div>
    <br>
    =C2=A0=C2=A0=C2=A0 foo(foo_a_default, 1234);<br>
    <br>
    so the previous solution should be compared to something like this
    to check if it is worth changing the language to cover this case.<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/2fcb51b2-fefb-b190-aaa5-d884cf6a4ab8%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2fcb51b2-fefb-b190-aaa5-d884cf6a4ab8=
%40wanadoo.fr</a>.<br />

--------------38781DCFCF90F75D5C82CF34--

.

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

Le 17/08/2018 =C3=A0 06:23, Justin Bassett a =C3=A9crit=C2=A0:
>
>
> On Thu, Aug 16, 2018 at 12:02 PM Nicol Bolas <jmckesson@gmail.com=20
> <mailto:jmckesson@gmail.com>> wrote:
>
>     I think that there should be a discussion of existing solutions to
>     all of the problems of interest, so that we can enumerate why
>     those solutions are not good enough. It would also allow us to
>     perhaps find a better way to handle this than with named
>     parameters. For example, if tagged dispatch solves a lot of these
>     problems, then perhaps we can incorporate tags into the language
>     in some more formal way rather than going to full named parameters.
>
>
> A short list of current solutions I know of:
>
>   * "Named Parameters Idiom"
>   * Strong types
>   * Tag dispatch
>   * Operator overloading (writing foo(parameter =3D value) by
>     overloading operator=3D, sometimes done with other operators
>     instead); I believe Boost Parameters does this
>   * Boost Graph's named parameters. The named parameters argument is
>     always the last and is specified by member functions. Similar to
>     the named parameters idiom, but more complex:
>     boost::foo(positional, arguments, boost::arg1(val).arg2(val2))
>   * Designated Initializers
>
> The named parameters idiom and Boost Graph's named parameters both=20
> require a lot of overhead on the library author's side. There's a lot=20
> of code that needs to be maintained. If you want to prevent=20
> parameters().foo(value).foo(someOtherValue), that's even more work.
I guess for you the named parameter idiom is what Boost.Parameter=20
provides, isn't it?
> Together with designated initializers, I've heard that this can also=20
> produce worse codegen, since we are passing around a struct rather=20
> than individual parameters.
I heard the opposite about the performances of designated initializes=20
;-) I suspect that it will depend on the particular case. We need=20
concrete cases and measure.
>
> Strong types and designated initializers fall short in parameter=20
> reordering. Sure, you can provide all possible combinations with=20
> strong types, but then it becomes unmaintainable. Strong types also=20
> require a type for each name you wish to use (if you want different=20
> types, that works within C++17's CTAD), which might run into problems=20
> if you end up with collisions with names of actual types rather than=20
> psuedo-types made just for named parameters. Also, it's annoying to=20
> use without using declarations or directives.
I don't want to use strong types to solve the problems named parameter=20
is intended to solve as I don't want to use named parameter to solve the=20
problems strong type intend to solve.
>
> Designated initializers fall short if you go more than one layer deep:=20
> std::invoke(something_with_named_parameters, { .arg1 =3D value }). You=20
> have to specify the name of the struct, which is jarring. It's also=20
> not nice to decompose elements of each struct to send them into other=20
> named-parameters-designated-structs. I was convinced designated=20
> initializers would be the solution to C++'s lack of named parameters,=20
> but I ran into problems such as this when experimenting with it. I had=20
> some more complex scenarios, but I have since forgotten them.
perfect forwarding will imply to have specific function types or to use=20
overload sets.
For me named parameters don't change the function type (let me know if=20
this is something you want). This implies that named parameters couldn't=20
be used to solve this perfect forwarding issue. You need tag dispatching=20
or something else.
There is a proposal (from Mihail), that associates some named parameters=20
to the function type. I believe that we need to name it differently. I=20
will consider the first named parameter as as syntactic sugar for tag=20
dispatching ,ad the other just named parameters. As the nature is=20
different I would like to have different syntax for the parameters that=20
change the signature and those that don't change it.
>
>     There is also the option of using `optional<double>`. So you'd
>     call it with `foo(nullopt, 1234)`, and allow the internal code to
>     fill in the default. This alternative also has the advantage that,
>     if the default changes, you /don't have to recompile/ to get the
>     changed value. Named parameters could take advantage of that too
>     by using `optional`.
>
>
> This isn't named parameters. This is optional parameters. Once you get=20
> more than a few optional parameters, it becomes unreadable fast:=20
> foo(123, nullopt, nullopt, "string", nullopt)
I agree.

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/81d3b2f3-398f-9ac2-1783-074ac2ad1ef5%40wanadoo.f=
r.

--------------AE29460FE2077455583A711E
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 06:23, Justin Basse=
tt a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"
cite=3D"mid:CAPuuy5cHU7OHPAEFJL41gLnknwxS1JQJHGrOsX8bQR7mfkVdxw@mail.gmail.=
com">
      <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf=
-8">
      <div dir=3D"ltr"><br>
        <br>
        <div class=3D"gmail_quote">
          <div dir=3D"ltr">On Thu, Aug 16, 2018 at 12:02 PM Nicol Bolas
            &lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank"
              moz-do-not-send=3D"true">jmckesson@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>I think that there should be a discussion of existing
                solutions to all of the problems of interest, so that we
                can enumerate why those solutions are not good enough.
                It would also allow us to perhaps find a better way to
                handle this than with named parameters. For example, if
                tagged dispatch solves a lot of these problems, then
                perhaps we can incorporate tags into the language in
                some more formal way rather than going to full named
                parameters.</div>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>A short list of current solutions I know of:</div>
          <div>
            <ul>
              <li>"Named Parameters Idiom"</li>
              <li>Strong types</li>
              <li>Tag dispatch</li>
              <li>Operator overloading (writing <font face=3D"monospace,
                  monospace">foo(parameter =3D value)</font> by
                overloading <font face=3D"monospace, monospace">operator=3D=
</font>,
                sometimes done with other operators instead); I believe
                Boost Parameters does this</li>
              <li>Boost Graph's named parameters. The named parameters
                argument is always the last and is specified by member
                functions. Similar to the named parameters idiom, but
                more complex: <font face=3D"monospace, monospace">boost::fo=
o(positional,
                  arguments, boost::arg1(val).arg2(val2))</font></li>
              <li><font face=3D"arial, helvetica, sans-serif">Designated
                  Initializers</font></li>
            </ul>
            <div><font face=3D"arial, helvetica, sans-serif">The named
                parameters idiom and Boost Graph's named parameters both
                require a lot of overhead on the library author's side.
                There's a lot of code that needs to be maintained. If
                you want to prevent </font><font face=3D"monospace,
                monospace">parameters().foo(value).foo(someOtherValue)</fon=
t><font
                face=3D"arial, helvetica, sans-serif">, that's even more
                work. </font></div>
          </div>
        </div>
      </div>
    </blockquote>
    <font face=3D"arial, helvetica, sans-serif">I guess for you the named
      parameter idiom is what Boost.Parameter provides, isn't it?</font><br=
>
    <blockquote type=3D"cite"
cite=3D"mid:CAPuuy5cHU7OHPAEFJL41gLnknwxS1JQJHGrOsX8bQR7mfkVdxw@mail.gmail.=
com">
      <div dir=3D"ltr">
        <div class=3D"gmail_quote">
          <div>
            <div><font face=3D"arial, helvetica, sans-serif">Together with
                designated initializers, I've heard that this can also
                produce worse codegen, since we are passing around a
                struct rather than individual parameters.</font></div>
          </div>
        </div>
      </div>
    </blockquote>
    <font face=3D"arial, helvetica, sans-serif">I heard the opposite about
      the performances of designated initializes ;-) I suspect that it
      will depend on the particular case. We need concrete cases and
      measure.<br>
    </font>
    <blockquote type=3D"cite"
cite=3D"mid:CAPuuy5cHU7OHPAEFJL41gLnknwxS1JQJHGrOsX8bQR7mfkVdxw@mail.gmail.=
com">
      <div dir=3D"ltr">
        <div class=3D"gmail_quote">
          <div><font face=3D"arial, helvetica, sans-serif"><br>
            </font></div>
          <div><font face=3D"arial, helvetica, sans-serif">Strong types
              and designated initializers fall short in parameter
              reordering. Sure, you can provide all possible
              combinations with strong types, but then it becomes
              unmaintainable. Strong types also require a type for each
              name you wish to use (if you want different types, that
              works within C++17's CTAD), which might run into problems
              if you end up with collisions with names of actual types
              rather than psuedo-types made just for named parameters.
              Also, it's annoying to use without using declarations or
              directives.</font></div>
        </div>
      </div>
    </blockquote>
    <font face=3D"arial, helvetica, sans-serif">I don't want to use strong
      types to solve the problems named parameter is intended to solve
      as I don't want </font>to use named parameter to solve the
    problems strong type intend to solve.<br>
    <blockquote type=3D"cite"
cite=3D"mid:CAPuuy5cHU7OHPAEFJL41gLnknwxS1JQJHGrOsX8bQR7mfkVdxw@mail.gmail.=
com">
      <div dir=3D"ltr">
        <div class=3D"gmail_quote">
          <div><font face=3D"arial, helvetica, sans-serif"><br>
            </font></div>
          <div><font face=3D"arial, helvetica, sans-serif">Designated
              initializers fall short if you go more than one layer
              deep: </font><font face=3D"monospace, monospace">std::invoke(=
something_with_named_parameters,
              { .arg1 =3D value })</font><font face=3D"arial, helvetica,
              sans-serif">. You have to specify the name of the struct,
              which is jarring. It's also not nice to decompose elements
              of each struct to send them into other
              named-parameters-designated-structs. I was convinced
              designated initializers would be the solution to C++'s
              lack of named parameters, but I ran into problems such as
              this when experimenting with it. I had some more complex
              scenarios, but I have since forgotten them.</font></div>
        </div>
      </div>
    </blockquote>
    <font face=3D"arial, helvetica, sans-serif">perfect forwarding will
      imply to have specific function types or to use overload sets. <br>
      For me named parameters don't change the function type (let me
      know if this is something you want). This implies that named paramete=
rs
      couldn't be used to solve this perfect forwarding issue. You need
      tag dispatching or something else.<br>
      There is a proposal (from Mihail), that associates some named
      parameters to the function type. I believe that we need to name it
      differently. I will consider the first named parameter as as
      syntactic sugar for tag dispatching ,ad the other just named paramete=
rs.
      As the nature is different I would like to have different syntax
      for the parameters that change the signature and those that don't
      change it.<br>
    </font>
    <blockquote type=3D"cite"
cite=3D"mid:CAPuuy5cHU7OHPAEFJL41gLnknwxS1JQJHGrOsX8bQR7mfkVdxw@mail.gmail.=
com">
      <div dir=3D"ltr">
        <div class=3D"gmail_quote">
          <div><font face=3D"arial, helvetica, sans-serif"><br>
            </font></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>There is also the option of using
                `optional&lt;double&gt;`. So you'd call it with
                `foo(nullopt, 1234)`, and allow the internal code to
                fill in the default. This alternative also has the
                advantage that, if the default changes, you <i>don't
                  have to recompile</i> to get the changed value. Named
                parameters could take advantage of that too by using
                `optional`.</div>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>This isn't named parameters. This is optional parameters.
            Once you get more than a few optional parameters, it becomes
            unreadable fast: <font face=3D"monospace, monospace">foo(123,
              nullopt, nullopt, "string", nullopt)</font> <br>
          </div>
        </div>
      </div>
    </blockquote>
    I agree.<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/81d3b2f3-398f-9ac2-1783-074ac2ad1ef5%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/81d3b2f3-398f-9ac2-1783-074ac2ad1ef5=
%40wanadoo.fr</a>.<br />

--------------AE29460FE2077455583A711E--

.

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

Le 17/08/2018 =C3=A0 06:39, Justin Bassett a =C3=A9crit=C2=A0:
> On Thu, Aug 16, 2018 at 10:45 AM Henry Miller <hank@millerfarm.com=20
> <mailto:hank@millerfarm.com>> wrote:
>
>
>     In the past couple months I've seen several proposals for names
>     parameters.=C2=A0 Each with a list of pros and cons, and because ther=
e
>     are cons arguments against them.=C2=A0 I think we need a discussion o=
n
>     what we want assuming some strawman acceptable syntax, and some
>     thought of how many limitations in corner cases we are willing to
>     accept.
>
>     I can think of 4 uses for names parameters. (If you don't
>     understand these I have simple code examples)
>     1 . a function with more than one parameter of the same type is
>     called with the parameters in the wrong order
>     =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Some people want this to be a compilatio=
n error, some
>     want the compiler to correct the problem and continue
>     2. a function wants to take the same type to mean different things
>     in different contexts
>     3. it isn't obvious from the type alone what a parameter means
>     4. A function has a bunch of defaulted arguments and you want to
>     change one of the latter ones without specifying all the others
>
>     First question: is this complete?
>     Second, which problems are worth solving?
>     Third, for problems worth solving, which is the better solution,
>     and how strongly attached to it are you?
>
>
> Some other use cases:
>
> 5. In tandem with reflection, names could be used for their names. A=20
> formatting library could use this in tandem with reflection:=20
> fmt::format("{sign} {value}", .sign =3D "$", .value =3D 1.34_usd);=20
> Language bindings to e.g. Python could use it to specify names for=20
> parameters=C2=A0=C2=A0(e.g. this could expose the parameter names to the=
=20
> language bindings: m.def([](int .a, int .b) { return a + b; }) )

I don't think this is a named parameter use case, even if it look like.=20
Note that the name of the arguments is not given by the parameter name=20
of the function, as it -is a variadic function, but for the name inside=20
the formatting string. So even if I want this to be solved, I don't=20
think it belongs to this feature.
> 6. This is a variation on 4. There may not be a bunch of defaulted=20
> arguments, but rather a few expert settings which you want the users=20
> to be able to tweak on rare occasions.
Could you elaborate?
> 7. bool arguments have meaning. It's pretty well known that something=20
> like file.open("path/to/file.txt", true) is bad, because the bool has=20
> no meaning. But file.open("path/to/file.txt", .append =3D true) isn't so=
=20
> bad because the meaning is apparent. Enums currently fill this role.
Well, not only bool arguments. int arguments have also meaning. I=20
believe this fall under case 3.

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/698e2fea-a733-33b5-282b-b033fe8b9167%40wanadoo.f=
r.

--------------48E4F9F6805358635CA35F0A
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 06:39, Justin Basse=
tt a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"
cite=3D"mid:CAPuuy5dz_N4nwnDrmds=3DROEpnUY2jQU4XGcLytxXscB=3DX36P1g@mail.gm=
ail.com">
      <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf=
-8">
      <div dir=3D"ltr">
        <div class=3D"gmail_quote">
          <div dir=3D"ltr">On Thu, Aug 16, 2018 at 10:45 AM Henry Miller
            &lt;<a href=3D"mailto:hank@millerfarm.com"
              moz-do-not-send=3D"true">hank@millerfarm.com</a>&gt; wrote:<b=
r>
          </div>
          <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
            In the past couple months I've seen several proposals for
            names parameters.=C2=A0 Each with a list of pros and cons, and
            because there are cons arguments against them.=C2=A0 I think we
            need a discussion on what we want assuming some strawman
            acceptable syntax, and some thought of how many limitations
            in corner cases we are willing to accept. <br>
            <br>
            I can think of 4 uses for names parameters. (If you don't
            understand these I have simple code examples)<br>
            1 . a function with more than one parameter of the same type
            is called with the parameters in the wrong order<br>
            =C2=A0 =C2=A0 =C2=A0 *=C2=A0 Some people want this to be a comp=
ilation error,
            some want the compiler to correct the problem and continue<br>
            2. a function wants to take the same type to mean different
            things in different contexts<br>
            3. it isn't obvious from the type alone what a parameter
            means<br>
            4. A function has a bunch of defaulted arguments and you
            want to change one of the latter ones without specifying all
            the others<br>
            <br>
            First question: is this complete?<br>
            Second, which problems are worth solving?<br>
            Third, for problems worth solving, which is the better
            solution, and how strongly attached to it are you?<br>
          </blockquote>
          <div><br>
          </div>
          <div>Some other use cases:</div>
          <div><br>
          </div>
          <div>5. In tandem with reflection, names could be used for
            their names. A formatting library could use this in tandem
            with reflection: <font face=3D"monospace, monospace">fmt::forma=
t("{sign}
              {value}", .sign =3D "$", .value =3D 1.34_usd)</font>; Languag=
e
            bindings to e.g. Python could use it to specify names for
            parameters=C2=A0=C2=A0(e.g. this could expose the parameter nam=
es to
            the language bindings: <font face=3D"monospace, monospace">m.de=
f([](int
              .a, int .b) { return a + b; })</font> )</div>
        </div>
      </div>
    </blockquote>
    <br>
    I don't think this is a named parameter use case, even if it look
    like. Note that the name of the arguments is not given by the
    parameter name of the function, as it -is a variadic function, but
    for the name inside the formatting string. So even if I want this to
    be solved, I don't think it belongs to this feature.<br>
    <blockquote type=3D"cite"
cite=3D"mid:CAPuuy5dz_N4nwnDrmds=3DROEpnUY2jQU4XGcLytxXscB=3DX36P1g@mail.gm=
ail.com">
      <div dir=3D"ltr">
        <div class=3D"gmail_quote">
          <div>6. This is a variation on 4. There may not be a bunch of
            defaulted arguments, but rather a few expert settings which
            you want the users to be able to tweak on rare occasions.</div>
        </div>
      </div>
    </blockquote>
    Could you elaborate?<br>
    <blockquote type=3D"cite"
cite=3D"mid:CAPuuy5dz_N4nwnDrmds=3DROEpnUY2jQU4XGcLytxXscB=3DX36P1g@mail.gm=
ail.com">
      <div dir=3D"ltr">
        <div class=3D"gmail_quote">
          <div>7. bool arguments have meaning. It's pretty well known
            that something like <font face=3D"monospace, monospace">file.op=
en("path/to/file.txt",
              true)</font> is bad, because the bool has no meaning. But
            <font face=3D"monospace, monospace">file.open("path/to/file.txt=
",
              .append =3D true)</font> isn't so bad because the meaning is
            apparent. Enums currently fill this role.</div>
        </div>
      </div>
    </blockquote>
    Well, not only bool arguments. int arguments have also meaning. I
    believe this fall under case 3.<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/698e2fea-a733-33b5-282b-b033fe8b9167%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/698e2fea-a733-33b5-282b-b033fe8b9167=
%40wanadoo.fr</a>.<br />

--------------48E4F9F6805358635CA35F0A--

.

On 16/08/18 19:44, Henry Miller wrote:
>
> In the past couple months I've seen several proposals for names
> parameters.  Each with a list of pros and cons, and because there are
> cons arguments against them.  I think we need a discussion on what we
> want assuming some strawman acceptable syntax, and some thought of
> how many limitations in corner cases we are willing to accept.
>
> I can think of 4 uses for names parameters. (If you don't understand
> these I have simple code examples)
>
> 1 . a function with more than one parameter of the same type is
> called with the parameters in the wrong order
> *  Some people want this to be a compilation error, some want the
> compiler to correct the problem and continue

Ideally, I'd want the compiler to correct it (i.e., re-arrange the
parameter order).  But I'd be okay with an error as a second-best
choice.  An error is enough to ensure that the code is more readable and
mistakes in parameter order are caught.  Re-arranging is about
convenience in writing the code, which is a lot less important.


> 2. a function wants to take the same type to mean different things in
> different contexts

You mean function overloads based on parameter names?  They would
occasionally be useful, but not essential IMHO.  I'd like them but I
would not want them to break other important points like compatibility
with existing code and tools (this feature should not cost anything if
it is not used).


> 3. it isn't obvious from the type alone what a parameter means

I have an alternative idea for your example below.

> 4. A function has a bunch of defaulted arguments and you want to
> change one of the latter ones without specifying all the others

This would be convenient for some types of coding, but is not an
essential.  It would rely on being able to re-order parameters using names.

>
> First question: is this complete?

I think so, yes - those are the key uses.  My prime motivation for
wanting named parameters is to be able to be sure the code I write is
clear and correct, rather than allowing new kinds of coding.  #1 above
would be sufficient for that.

But there are a few other requirements I would add.

5. Using named parameters should be optional unless unavoidable (such as
for overloads).  The solution should not affect existing code, it should
be possible to use named parameters with existing functions, it should
not involve any change to generated code, mangled names, ABIs, object
code formats, etc., unless unavoidable (again, we are talking about
overalods).

6. It should be suitable for use in C as well as C++ (excluding
overloads).  I don't expect it to be part of the C standards until
perhaps C38 (when we have all retired early to avoid the year 2038
fallout) as they are very slow to adopt new features.  But I would
expect big C/C++ compilers to support it as an extension in C once it is
part of C++.


> Second, which problems are worth solving?

#1 is definitely worth solving.  The others would be nice as long as
they don't delay a solution to #1.

Parameter name based overloading looks challenging and would involve a
good deal more changes to the language and the tools.  It is worth
considering, but may not be worth solving.  There could be alternative
ways to get this effect.

> Third, for problems worth solving, which is the better solution, and
> how strongly attached to it are you?

My proposal in the other thread is the best solution :-)

>
> For the first the motivating code is something like:
>
> class myMatrix {
> T GetCell(int row, int column);
> ...
> };
>
> in code: cell = matrix.GetCell(column, row);
>
> This will compile just fine in C++17, but the code is undoubtedly
> wrong.  In C++2n do you want this to be a compiler error, or correct
> code?

I don't think it is an appropriate example.  If you have:

 int column = 1;
 int row = 2;
 auto cell = matrix.GetCell(column, row);

then it should compile fine.  It is not using named parameters, but is
existing code.  (A smart compiler could warn about it.)  But /this/
should either be an error, or be re-arranged automatically:

 auto cell = matrix.GetCell(.column = column, .row = row);


>
>
> Second:
> class point {
> point(double x, double y);
> point(double distance, double angle);
>  ...
> };

>
> This code does not compile in C++17.  Do we want to make this case
> work?

I'd be okay with allowing it, but it would involve a lot more changes to
support.  See the next case below.

>
>
> Third:
> class myString {
>  int compare(myString, bool CaseSensitive);
>  ...
> };
>
> in code
> if(str.compare(otherString, false) == 0) ...
>
> // what does this mean, why would you call compare and not compare?
>
> This code is legal C++17, but it is user hostile. False in the
> context of reading the function makes no intuitive sense.  Qt has
> created an enum for this, but it can be argued that this is too
> heavy.  (you may or may not agree with the argument)


The ideal solution, IMHO, involves two parts.  I would like to see
function parameter scope types, and perhaps be able to define them
within a function declaration.  I want to see:

class myString {
 int compare(
  myString,
  enum class CaseSensitivity { insensitive, sensitive }
    sensitivity
 );

Then you could write:

 if (str.compare(otherString, insensitive) == 0) ...

The "insensitive" would automatically be looked up in the scope of types
declared within the scope of the function declaration.

If you need to refer to the enum constants outside of a function call,
you could use myString::compare::CaseSensitivity.

As a convenience, perhaps the name of the type could be omitted and you
could use the parameter name here, and "enum" could automatically be a
strong enumeration (so you can't use booleans or integers instead of
enumeration constants):

class myString {
 int compare(
  myString,
  enum { insensitive, sensitive } sensitivity
 );

Within the function definition, these local types would also be in scope
(possibly qualified as "sensitivity::insensitive" if that is preferred).

The same idea, with a similar convenience, could give you:

class point {
 point(struct double x, struct double y);
 point(struct double distance, struct double angle);
  ...
};

This would be a convenience syntax for:

class point {
 struct point_x { double x };
 struct point_y { double y };
 struct point_distance { double distance };
 struct point_angle { double angle };

 point(point_x x, point_y y);
 point(point_distance distance, point_angle angle);
  ...
};

 auto p = point(.x = 1, .y = 2);

would be

 auto p = point(point_x(1), point_y(2));


This would give you all you need for overloading based on named
parameters, within the existing type system - no changes are needed in
name mangling or anything else.  It's just a little short-cut for using
strong types for parameter names.

(I'm sure the syntax and details, especially scoping, will need more
careful thought than I've given it here.)

>
>
> Fourth: // warning, marketing regularly changes the default value of
> this function void foo(double a = 1234.5, int b = 6789);
>
> foo(b:=1234);
>
> This won't compile in C++17. However it seems like it would be useful
> to not clutter function calls with default parameters that you don't
> care about. In the case I gave it is a maintenance problem to update
> all uses of foo every time the defaults change, though I'm not sure
> if this is actually a common problem.
>


--
You received this message because you are 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/pl6ob7%249k1%241%40blaine.gmane.org.

.

------=_Part_252_654381316.1534519527997
Content-Type: multipart/alternative;
 boundary="----=_Part_253_902795940.1534519527997"

------=_Part_253_902795940.1534519527997
Content-Type: text/plain; charset="UTF-8"

On Friday, August 17, 2018 at 11:09:38 AM UTC-4, David Brown wrote:
>
> On 16/08/18 19:44, Henry Miller wrote:
>
> >
> >
> > Third:
> > class myString {
> >         int compare(myString, bool CaseSensitive);
> >         ...
> > };
> >
> > in code
> >        if(str.compare(otherString, false) == 0) ...
> >
> > // what does this mean, why would you call compare and not compare?
> >
> > This code is legal C++17, but it is user hostile. False in the
> > context of reading the function makes no intuitive sense.  Qt has
> > created an enum for this, but it can be argued that this is too
> > heavy.  (you may or may not agree with the argument)
>
>
> The ideal solution, IMHO, involves two parts.  I would like to see
> function parameter scope types, and perhaps be able to define them
> within a function declaration.  I want to see:
>
> class myString {
>         int compare(
>                 myString,
>                 enum class CaseSensitivity { insensitive, sensitive }
>                                 sensitivity
>         );
>
> Then you could write:
>
>         if (str.compare(otherString, insensitive) == 0) ...
>
> The "insensitive" would automatically be looked up in the scope of types
> declared within the scope of the function declaration.
>

That is an over-designed solution. The problem has nothing to do with where
the enumeration gets declared. Sticking the declaration in the function
signature doesn't really solve the problem.

What solves the problem is the fact that the identifier `insensitive` is
looked up within the domain of how it is used. It's being used as a
function parameter that takes an enumeration which has an enumerator called
`insensitive`; therefore, that enumerator must be what it names.

*That* is the feature we need: the ability to take an identifier and
generate its "path" information based on context at the site of use. This
ability would aid in this problem and many others (enum-classes in
`switch/case`, having to prefix tags in tag dispatching with
`my_namespace::`, etc).

There is no reason to wed context-specific "path" lookup to the location
where the particular thing is declared.

--
You received this message because you are 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/2d91b5c9-da43-478c-b100-eed305f3397c%40isocpp.org.

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

<div dir=3D"ltr">On Friday, August 17, 2018 at 11:09:38 AM UTC-4, David Bro=
wn 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 19:44, He=
nry Miller wrote:
<br><br>&gt;=20
<br>&gt;=20
<br>&gt; Third:=20
<br>&gt; class myString {
<br>&gt; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0int compare(myStri=
ng, bool CaseSensitive);
<br>&gt; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0...
<br>&gt; };
<br>&gt;=20
<br>&gt; in code
<br>&gt;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if(str.compare(<wbr=
>otherString, false) =3D=3D 0) ...
<br>&gt;
<br>&gt; // what does this mean, why would you call compare and not compare=
?
<br>&gt;=20
<br>&gt; This code is legal C++17, but it is user hostile. False in the
<br>&gt; context of reading the function makes no intuitive sense. =C2=A0Qt=
 has
<br>&gt; created an enum for this, but it can be argued that this is too
<br>&gt; heavy. =C2=A0(you may or may not agree with the argument)
<br>
<br>
<br>The ideal solution, IMHO, involves two parts. =C2=A0I would like to see
<br>function parameter scope types, and perhaps be able to define them
<br>within a function declaration. =C2=A0I want to see:
<br>
<br>class myString {
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0int compare(
<br>=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=A0myString,
<br>=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=A0enum class CaseSensitivity { insensitive, sensit=
ive }
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<wbr>=C2=A0=C2=A0sensitivity
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0);
<br>
<br>Then you could write:
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (str.compare(otherSt=
ring, insensitive) =3D=3D 0) ...
<br>
<br>The &quot;insensitive&quot; would automatically be looked up in the sco=
pe of types
<br>declared within the scope of the function declaration.
<br></blockquote><div><br></div><div>That is an over-designed solution. The=
 problem has nothing to do with where the enumeration gets declared. Sticki=
ng the declaration in the function signature doesn&#39;t really solve the p=
roblem.</div><div><br></div><div>What solves the problem is the fact that t=
he identifier `insensitive` is looked up within the domain of how it is use=
d. It&#39;s being used as a function parameter that takes an enumeration wh=
ich has an enumerator called `insensitive`; therefore, that enumerator must=
 be what it names.</div><div><br></div><div><i>That</i> is the feature we n=
eed: the ability to take an identifier and generate its &quot;path&quot; in=
formation based on context at the site of use. This ability would aid in th=
is problem and many others (enum-classes in `switch/case`, having to prefix=
 tags in tag dispatching with `my_namespace::`, etc).</div><div><br></div><=
div>There is no reason to wed context-specific &quot;path&quot; lookup to t=
he location where the particular thing is declared.</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/2d91b5c9-da43-478c-b100-eed305f3397c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2d91b5c9-da43-478c-b100-eed305f3397c=
%40isocpp.org</a>.<br />

------=_Part_253_902795940.1534519527997--

------=_Part_252_654381316.1534519527997--

.

On 17/08/18 17:25, Nicol Bolas wrote:
> On Friday, August 17, 2018 at 11:09:38 AM UTC-4, David Brown wrote:
>
>     On 16/08/18 19:44, Henry Miller wrote:
>
>     >
>     >
>     > Third:
>     > class myString {
>     >         int compare(myString, bool CaseSensitive);
>     >         ...
>     > };
>     >
>     > in code
>     >        if(str.compare(otherString, false) == 0) ...
>     >
>     > // what does this mean, why would you call compare and not compare?
>     >
>     > This code is legal C++17, but it is user hostile. False in the
>     > context of reading the function makes no intuitive sense.  Qt has
>     > created an enum for this, but it can be argued that this is too
>     > heavy.  (you may or may not agree with the argument)
>
>
>     The ideal solution, IMHO, involves two parts.  I would like to see
>     function parameter scope types, and perhaps be able to define them
>     within a function declaration.  I want to see:
>
>     class myString {
>             int compare(
>                     myString,
>                     enum class CaseSensitivity { insensitive, sensitive }
>                                     sensitivity
>             );
>
>     Then you could write:
>
>             if (str.compare(otherString, insensitive) == 0) ...
>
>     The "insensitive" would automatically be looked up in the scope of
>     types
>     declared within the scope of the function declaration.
>
>
> That is an over-designed solution. The problem has nothing to do with
> where the enumeration gets declared. Sticking the declaration in the
> function signature doesn't really solve the problem.
>
> What solves the problem is the fact that the identifier `insensitive` is
> looked up within the domain of how it is used. It's being used as a
> function parameter that takes an enumeration which has an enumerator
> called `insensitive`; therefore, that enumerator must be what it names.
>
> /That/ is the feature we need: the ability to take an identifier and
> generate its "path" information based on context at the site of use.
> This ability would aid in this problem and many others (enum-classes in
> `switch/case`, having to prefix tags in tag dispatching with
> `my_namespace::`, etc).
>
> There is no reason to wed context-specific "path" lookup to the location
> where the particular thing is declared.

Fair enough.  It sounds like you are suggesting a more general solution
that could be used in other places too.  I'm happy with that idea.



--
You received this message because you are 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/pl6vog%246qv%241%40blaine.gmane.org.

.

------=_Part_2581_392928038.1534964292845
Content-Type: multipart/alternative;
 boundary="----=_Part_2582_1107803020.1534964292845"

------=_Part_2582_1107803020.1534964292845
Content-Type: text/plain; charset="UTF-8"

Back to the topic.


Discussions like this one come and go every 2-3 years. And we make ZERO
progress. At least no written progress.

May be we should make poll, what the most wanted types of named parameters
are?
May be we should write a paper to see what direction the committee is
willing to pursue, *if any*? Because right now I am not sure if the
implementation is the problem or the concept.

But above all, we should start agreeing on *something*.

Otherwise, after the dust settles, we will have nothing. As always.


We should start agreeing we are split, lets say 50/50 to opponents and
proponents, and no need to "convince" the other side they are "wrong".

We should start agreeing, there are different "types" of named parameters,
needed for different people. There is not "best", solution if it does one
type only.

Hell, even if we agree on one of these points, it will be progress.


--
You received this message because you are 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/73b10960-8c70-419a-b317-2d78ec46a1d7%40isocpp.org.

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

<div dir=3D"ltr"><div>Back to the topic.</div><div><br></div><div><br></div=
><div>Discussions like this one come and go every 2-3 years. And we make ZE=
RO progress. At least no written progress.=C2=A0</div><div><br></div><div>M=
ay be we should make poll, what the most wanted types of named parameters a=
re?=C2=A0</div><div>May be we should write a paper to see what direction th=
e committee is willing to pursue, <i>if any</i>? Because right now I am not=
 sure if the implementation is the problem or the concept. =C2=A0=C2=A0</di=
v><div><br></div><div>But above all, w<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;">e should start agreeing on </span><i 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%; background-repeat: r=
epeat; background-size: auto; 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: italic; font-variant: normal; font-=
weight: 400; height: auto; letter-spacing: normal; margin-bottom: 0px; marg=
in-left: 0px; margin-right: 0px; margin-top: 0px; min-width: 0px; orphans: =
2; overflow: visible; overflow-x: visible; overflow-y: visible; padding-bot=
tom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; 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;">some=
thing</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; 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;=
">.=C2=A0</span></div><div><b></b><i></i><u></u><sub></sub><sup></sup><stri=
ke></strike><br></div><div>Otherwise, after the dust settles, we will have =
nothing. As always.</div><div><br></div><div><br></div><div>We should start=
 agreeing we are split, lets say 50/50 to opponents and proponents, and no =
need to &quot;convince&quot; the other side they are &quot;wrong&quot;.</di=
v><div><br></div><div>We should start agreeing, there are different &quot;t=
ypes&quot; of named parameters, needed for different people. There is not &=
quot;best&quot;, solution if it does one type only.</div><div><br></div><di=
v>Hell, even if we agree on one of these points, it will be progress.=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/73b10960-8c70-419a-b317-2d78ec46a1d7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/73b10960-8c70-419a-b317-2d78ec46a1d7=
%40isocpp.org</a>.<br />

------=_Part_2582_1107803020.1534964292845--

------=_Part_2581_392928038.1534964292845--

.

------=_Part_2494_1736594082.1534971896603
Content-Type: multipart/alternative;
 boundary="----=_Part_2495_1170457739.1534971896604"

------=_Part_2495_1170457739.1534971896604
Content-Type: text/plain; charset="UTF-8"

On Wednesday, August 22, 2018 at 2:58:12 PM UTC-4, mihailn...@gmail.com
wrote:
>
> Back to the topic.
>
> Discussions like this one come and go every 2-3 years. And we make ZERO
> progress. At least no written progress.
>
> May be we should make poll, what the most wanted types of named parameters
> are?
> May be we should write a paper to see what direction the committee is
> willing to pursue, *if any*? Because right now I am not sure if the
> implementation is the problem or the concept.
>
> But above all, we should start agreeing on *something*.
>

> Otherwise, after the dust settles, we will have nothing. As always.
>

That's what this thread was trying to accomplish. The reason all that
arguing happens is that everyone is focused on the *solutions*, rather than
the problems.

Consider your explanation of "weak named arguments" from the other thread.
Your definition allows "optional" names to determine which function in an
overload set gets called. And in so doing, actually allows users to
*require* that you use names to call the function with a certain default
parameters.

But if the problem you're trying to solve with the proposal is to make
meaning apparent at the call site in a way the compiler can verify, then
you don't *need* names to factor into overload resolution or default
arguments at all. That would therefore be an extraneous bit of
functionality that isn't helping the feature solve the actual problem being
solved.

The only way to move forward is to localize the problem space into a
specific set of problems to be solved. If you can get broad agreement on
what problems need to be solved, or at least some series of problems with
various ratings of how much of a problem they are compared to existing
solutions, *then* you can move towards a design.

Having a small, well-defined set of problems to be solved focuses
discussions of the eventual proposal. It keeps people from saying, "well,
it doesn't do this" because... it's not *supposed* to do that.

We should start agreeing we are split, lets say 50/50 to opponents and
> proponents, and no need to "convince" the other side they are "wrong".
>

You're not factoring in one group (to which I am a member): the group of
people who have yet to be convinced that C++ needs named parameters *of any
form*. People have provided examples of where they might be useful, sure.
But compared to the wealth of other, more useful features that C++ lacks,
the existing solutions seem more-or-less "good enough".

These are the ones who need the most convincing. And they're more likely to
be convinced by good *problems* than how you go about solving them.

We should start agreeing, there are different "types" of named parameters,
> needed for different people. There is not "best", solution if it does one
> type only.
>

The problem there is, as I've mentioned before, you're working in the same
space. However much different people may need different kinds of named
parameters, C++ as a whole will be dis-served by having different syntax's
for what is essentially a minor variation of the same thing.

Again, I hate using principles as bludgeons, but Remember the Vasa! It's
important to look back on what you're proposing from a high level and see
if it actually leads to good, easily understood code. And if not, maybe we
don't need it so badly.

Hell, even if we agree on one of these points, it will be progress.
>

--
You received this message because you are 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/8e2b5a47-f22b-4cd6-ba68-9802bfff7bc1%40isocpp.org.

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

<div dir=3D"ltr">On Wednesday, August 22, 2018 at 2:58:12 PM UTC-4, mihailn=
....@gmail.com 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"><div>Back to the topic.</div><div><br></div><div>Discussions like =
this one come and go every 2-3 years. And we make ZERO progress. At least n=
o written progress.=C2=A0</div><div><br></div><div>May be we should make po=
ll, what the most wanted types of named parameters are?=C2=A0</div><div>May=
 be we should write a paper to see what direction the committee is willing =
to pursue, <i>if any</i>? Because right now I am not sure if the implementa=
tion is the problem or the concept. =C2=A0=C2=A0</div><div><br></div><div>B=
ut above all, w<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;font-variant:n=
ormal;font-weight:400;letter-spacing:normal;text-align:left;text-decoration=
:none;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0=
px">e should start agreeing on </span><i>something</i><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">.</span></div></div></blockquote=
><div></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><br></div><=
div>Otherwise, after the dust settles, we will have nothing. As always.</di=
v></div></blockquote><div><br></div><div>That&#39;s what this thread was tr=
ying to accomplish. The reason all that arguing happens is that everyone is=
 focused on the <i>solutions</i>, rather than the problems.</div><div><br><=
/div><div>Consider your explanation of &quot;weak named arguments&quot; fro=
m the other thread. Your definition allows &quot;optional&quot; names to de=
termine which function in an overload set gets called. And in so doing, act=
ually allows users to <i>require</i> that you use names to call the functio=
n with a certain default parameters.</div><div><br></div><div></div><div>Bu=
t if the problem you&#39;re trying to solve with the proposal is to make me=
aning apparent at the call site in a way the compiler can verify, then you =
don&#39;t <i>need</i> names to factor into overload resolution or default a=
rguments at all. That would therefore be an extraneous bit of functionality=
 that isn&#39;t helping the feature solve the actual problem being solved.<=
/div><div><br></div><div>The only way to move forward is to localize the pr=
oblem space into a specific set of problems to be solved. If you can get br=
oad agreement on what problems need to be solved, or at least some series o=
f problems with various ratings of how much of a problem they are compared =
to existing solutions, <i>then</i> you can move towards a design.</div><div=
><br></div><div>Having a small, well-defined set of problems to be solved f=
ocuses discussions of the eventual proposal. It keeps people from saying, &=
quot;well, it doesn&#39;t do this&quot; because... it&#39;s not <i>supposed=
</i> to do that.<br></div><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><div></div><div>We should start agreeing we are=
 split, lets say 50/50 to opponents and proponents, and no need to &quot;co=
nvince&quot; the other side they are &quot;wrong&quot;.</div></div></blockq=
uote><div><br></div><div>You&#39;re not factoring in one group (to which I =
am a member): the group of people who have yet to be convinced that C++ nee=
ds named parameters <i>of any form</i>. People have provided examples of wh=
ere they might be useful, sure. But compared to the wealth of other, more u=
seful features that C++ lacks, the existing solutions seem more-or-less &qu=
ot;good enough&quot;.</div><div><br></div><div>These are the ones who need =
the most convincing. And they&#39;re more likely to be convinced by good <i=
>problems</i> than how you go about solving them.<br></div><div><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><di=
v>We should start agreeing, there are different &quot;types&quot; of named =
parameters, needed for different people. There is not &quot;best&quot;, sol=
ution if it does one type only.</div></div></blockquote><div><br></div><div=
>The problem there is, as I&#39;ve mentioned before, you&#39;re working in =
the same space. However much different people may need different kinds of n=
amed parameters, C++ as a whole will be dis-served by having different synt=
ax&#39;s for what is essentially a minor variation of the same thing.</div>=
<div><br></div><div>Again, I hate using principles as bludgeons, but Rememb=
er the Vasa! It&#39;s important to look back on what you&#39;re proposing f=
rom a high level and see if it actually leads to good, easily understood co=
de. And if not, maybe we don&#39;t need it so badly.<br></div><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div>=
<div>Hell, even if we agree on one of these points, it will be progress. <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/8e2b5a47-f22b-4cd6-ba68-9802bfff7bc1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8e2b5a47-f22b-4cd6-ba68-9802bfff7bc1=
%40isocpp.org</a>.<br />

------=_Part_2495_1170457739.1534971896604--

------=_Part_2494_1736594082.1534971896603--

.

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

Lets start wit very small list.

1. Declaration
1.1 No changes. Remain as is.
1.X Add Your preferences here
1.Y and here ...

2. Call
2.1 Dot style
   Declaration: void f( int a, int b );
   Call:       f( .a=1, .b=2 );
2.X Add Your preferences here
2.Y and here ...
My opinion is: 1.1 and 2.1.

Extend this list with one line examples.
Do not explain why is something wrong and another is right.


On Wed, Aug 22, 2018 at 11:04 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Wednesday, August 22, 2018 at 2:58:12 PM UTC-4, mihailn...@gmail.com
> wrote:
>>
>> Back to the topic.
>>
>> Discussions like this one come and go every 2-3 years. And we make ZERO
>> progress. At least no written progress.
>>
>> May be we should make poll, what the most wanted types of named
>> parameters are?
>> May be we should write a paper to see what direction the committee is
>> willing to pursue, *if any*? Because right now I am not sure if the
>> implementation is the problem or the concept.
>>
>> But above all, we should start agreeing on *something*.
>>
>
>> Otherwise, after the dust settles, we will have nothing. As always.
>>
>
> That's what this thread was trying to accomplish. The reason all that
> arguing happens is that everyone is focused on the *solutions*, rather
> than the problems.
>
> Consider your explanation of "weak named arguments" from the other thread.
> Your definition allows "optional" names to determine which function in an
> overload set gets called. And in so doing, actually allows users to
> *require* that you use names to call the function with a certain default
> parameters.
>
> But if the problem you're trying to solve with the proposal is to make
> meaning apparent at the call site in a way the compiler can verify, then
> you don't *need* names to factor into overload resolution or default
> arguments at all. That would therefore be an extraneous bit of
> functionality that isn't helping the feature solve the actual problem being
> solved.
>
> The only way to move forward is to localize the problem space into a
> specific set of problems to be solved. If you can get broad agreement on
> what problems need to be solved, or at least some series of problems with
> various ratings of how much of a problem they are compared to existing
> solutions, *then* you can move towards a design.
>
> Having a small, well-defined set of problems to be solved focuses
> discussions of the eventual proposal. It keeps people from saying, "well,
> it doesn't do this" because... it's not *supposed* to do that.
>
> We should start agreeing we are split, lets say 50/50 to opponents and
>> proponents, and no need to "convince" the other side they are "wrong".
>>
>
> You're not factoring in one group (to which I am a member): the group of
> people who have yet to be convinced that C++ needs named parameters *of
> any form*. People have provided examples of where they might be useful,
> sure. But compared to the wealth of other, more useful features that C++
> lacks, the existing solutions seem more-or-less "good enough".
>
> These are the ones who need the most convincing. And they're more likely
> to be convinced by good *problems* than how you go about solving them.
>
> We should start agreeing, there are different "types" of named parameters,
>> needed for different people. There is not "best", solution if it does one
>> type only.
>>
>
> The problem there is, as I've mentioned before, you're working in the same
> space. However much different people may need different kinds of named
> parameters, C++ as a whole will be dis-served by having different syntax's
> for what is essentially a minor variation of the same thing.
>
> Again, I hate using principles as bludgeons, but Remember the Vasa! It's
> important to look back on what you're proposing from a high level and see
> if it actually leads to good, easily understood code. And if not, maybe we
> don't need it so badly.
>
> Hell, even if we agree on one of these points, it will be progress.
>>
> --
> You received this message because you are 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/8e2b5a47-f22b-4cd6-
> ba68-9802bfff7bc1%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8e2b5a47-f22b-4cd6-ba68-9802bfff7bc1%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/CAEfefmyFhMGM2UbPmCmKd%2B%3D1LgimaZ0-QkJDhov3E_0oqhQzkg%40mail.gmail.com.

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

<div dir=3D"ltr"><div>Lets start wit very small list.</div><div><br></div><=
div>1. Declaration<br>1.1 No changes. Remain as is.<br>1.X Add Your prefere=
nces here<br>1.Y and here ...</div><p>2. Call<br>2.1 Dot style<br>=C2=A0=C2=
=A0 Declaration: void f( int a, int b );<br>=C2=A0=C2=A0 Call:=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 f( .a=3D1, .b=3D2 );<br>2.X Add Your preferences h=
ere<br>2.Y and here ...</p><div>My opinion is: 1.1 and 2.1.</div><div><br><=
/div><div>Extend this list with one line examples.</div><div>Do not explain=
 why is something wrong and another is right.</div><div><span><br></span></=
div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed,=
 Aug 22, 2018 at 11:04 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>On Wedne=
sday, August 22, 2018 at 2:58:12 PM UTC-4, <a href=3D"mailto:mihailn...@gma=
il.com" target=3D"_blank">mihailn...@gmail.com</a> wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-=
left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">=
<div dir=3D"ltr"><div>Back to the topic.</div><div><br></div><div>Discussio=
ns like this one come and go every 2-3 years. And we make ZERO progress. At=
 least no written progress.=C2=A0</div><div><br></div><div>May be we should=
 make poll, what the most wanted types of named parameters are?=C2=A0</div>=
<div>May be we should write a paper to see what direction the committee is =
willing to pursue, <i>if any</i>? Because right now I am not sure if the im=
plementation is the problem or the concept. =C2=A0=C2=A0</div><div><br></di=
v><div>But above all, w<span style=3D"text-align:left;color:rgb(34,34,34);t=
ext-transform:none;text-indent:0px;letter-spacing:normal;font-family:&quot;=
Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-style:norm=
al;font-variant:normal;font-weight:400;text-decoration:none;word-spacing:0p=
x;float:none;display:inline!important;white-space:normal;background-color:t=
ransparent">e should start agreeing on </span><i>something</i><span style=
=3D"text-align:left;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-style:normal;font-variant:normal;font-weight=
:400;text-decoration:none;word-spacing:0px;float:none;display:inline!import=
ant;white-space:normal;background-color:transparent">.</span></div></div></=
blockquote><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-l=
eft-width:1px;border-left-style:solid"><div dir=3D"ltr"><div><b></b><i></i>=
<u></u><sub></sub><sup></sup><strike></strike><br></div><div>Otherwise, aft=
er the dust settles, we will have nothing. As always.</div></div></blockquo=
te><div><br></div></span><div>That&#39;s what this thread was trying to acc=
omplish. The reason all that arguing happens is that everyone is focused on=
 the <i>solutions</i>, rather than the problems.</div><div><br></div><div>C=
onsider your explanation of &quot;weak named arguments&quot; from the other=
 thread. Your definition allows &quot;optional&quot; names to determine whi=
ch function in an overload set gets called. And in so doing, actually allow=
s users to <i>require</i> that you use names to call the function with a ce=
rtain default parameters.</div><div><br></div><div></div><div>But if the pr=
oblem you&#39;re trying to solve with the proposal is to make meaning appar=
ent at the call site in a way the compiler can verify, then you don&#39;t <=
i>need</i> names to factor into overload resolution or default arguments at=
 all. That would therefore be an extraneous bit of functionality that isn&#=
39;t helping the feature solve the actual problem being solved.</div><div><=
br></div><div>The only way to move forward is to localize the problem space=
 into a specific set of problems to be solved. If you can get broad agreeme=
nt on what problems need to be solved, or at least some series of problems =
with various ratings of how much of a problem they are compared to existing=
 solutions, <i>then</i> you can move towards a design.</div><div><br></div>=
<div>Having a small, well-defined set of problems to be solved focuses disc=
ussions of the eventual proposal. It keeps people from saying, &quot;well, =
it doesn&#39;t do this&quot; because... it&#39;s not <i>supposed</i> to do =
that.<br></div><span><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div>=
</div><div>We should start agreeing we are split, lets say 50/50 to opponen=
ts and proponents, and no need to &quot;convince&quot; the other side they =
are &quot;wrong&quot;.</div></div></blockquote><div><br></div></span><div>Y=
ou&#39;re not factoring in one group (to which I am a member): the group of=
 people who have yet to be convinced that C++ needs named parameters <i>of =
any form</i>. People have provided examples of where they might be useful, =
sure. But compared to the wealth of other, more useful features that C++ la=
cks, the existing solutions seem more-or-less &quot;good enough&quot;.</div=
><div><br></div><div>These are the ones who need the most convincing. And t=
hey&#39;re more likely to be convinced by good <i>problems</i> than how you=
 go about solving them.<br></div><span><div><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left=
-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div=
 dir=3D"ltr"><div></div><div>We should start agreeing, there are different =
&quot;types&quot; of named parameters, needed for different people. There i=
s not &quot;best&quot;, solution if it does one type only.</div></div></blo=
ckquote><div><br></div></span><div>The problem there is, as I&#39;ve mentio=
ned before, you&#39;re working in the same space. However much different pe=
ople may need different kinds of named parameters, C++ as a whole will be d=
is-served by having different syntax&#39;s for what is essentially a minor =
variation of the same thing.</div><div><br></div><div>Again, I hate using p=
rinciples as bludgeons, but Remember the Vasa! It&#39;s important to look b=
ack on what you&#39;re proposing from a high level and see if it actually l=
eads to good, easily understood code. And if not, maybe we don&#39;t need i=
t so badly.<br></div><span><div><br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(2=
04,204,204);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"=
><div></div><div>Hell, even if we agree on one of these points, it will be =
progress. <br></div></div></blockquote></span></div><span>

<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@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8e2b5a47-f22b-4cd6-ba68-9802bfff7bc1%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/8e2b=
5a47-f22b-4cd6-<wbr>ba68-9802bfff7bc1%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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/CAEfefmyFhMGM2UbPmCmKd%2B%3D1LgimaZ0-=
QkJDhov3E_0oqhQzkg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmyFhMGM=
2UbPmCmKd%2B%3D1LgimaZ0-QkJDhov3E_0oqhQzkg%40mail.gmail.com</a>.<br />

--000000000000e0315405742d6656--

.

------=_Part_176_1063268695.1535116061321
Content-Type: multipart/alternative;
 boundary="----=_Part_177_2041738651.1535116061322"

------=_Part_177_2041738651.1535116061322
Content-Type: text/plain; charset="UTF-8"



On Friday, August 24, 2018 at 2:20:34 PM UTC+2, Dejan Milosavljevic wrote:
>
> Lets start wit very small list.
>
> 1. Declaration
> 1.1 No changes. Remain as is.
> 1.X Add Your preferences here
> 1.Y and here ...
>
> 2. Call
> 2.1 Dot style
>    Declaration: void f( int a, int b );
>    Call:       f( .a=1, .b=2 );
> 2.X Add Your preferences here
> 2.Y and here ...
> My opinion is: 1.1 and 2.1.
>
> Extend this list with one line examples.
> Do not explain why is something wrong and another is right.
>
>
>
1. Declaration
1.1 No changes. Remain as is.
1.2 Struct: `struct f_P{ int a; int b; }; void f(f_P);` (no change to
language)

2. Call
2.1 `f( .a=1, .b=2 );`
2.2 `f({ .a = 1, .b = 2 });` (no change to language)

My preferred is 1.2 and 2.2

--
You received this message because you are 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/ba2da34e-98f3-4d42-9a2a-5b35cffe51d4%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, August 24, 2018 at 2:20:34 PM UTC+2, De=
jan Milosavljevic 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"ltr"><div>Lets start wit very small list.</div><div><br></div><div>1.=
 Declaration<br>1.1 No changes. Remain as is.<br>1.X Add Your preferences h=
ere<br>1.Y and here ...</div><p>2. Call<br>2.1 Dot style<br>=C2=A0=C2=A0 De=
claration: void f( int a, int b );<br>=C2=A0=C2=A0 Call:=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 f( .a=3D1, .b=3D2 );<br>2.X Add Your preferences here<br=
>2.Y and here ...</p><div>My opinion is: 1.1 and 2.1.</div><div><br></div><=
div>Extend this list with one line examples.</div><div>Do not explain why i=
s something wrong and another is right.</div><div><span><br></span></div></=
div><div><br></div></blockquote><div><br></div><div>1. Declaration</div><di=
v>1.1 No changes. Remain as is.</div><div>1.2 Struct: `struct f_P{ int a; i=
nt b; }; void f(f_P);` (no change to language)<br></div><div><br></div><div=
>2. Call</div><div>2.1 `f( .a=3D1, .b=3D2 );`</div><div>2.2 `f({ .a =3D 1, =
..b =3D 2 });` (no change to language)</div><div><br></div><div>My preferred=
 is 1.2 and 2.2<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/ba2da34e-98f3-4d42-9a2a-5b35cffe51d4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ba2da34e-98f3-4d42-9a2a-5b35cffe51d4=
%40isocpp.org</a>.<br />

------=_Part_177_2041738651.1535116061322--

------=_Part_176_1063268695.1535116061321--

.

On 24/08/18 15:07, inkwizytoryankes@gmail.com wrote:
>
>
> On Friday, August 24, 2018 at 2:20:34 PM UTC+2, Dejan Milosavljevic wrote:
>
>     Lets start wit very small list.
>
>     1. Declaration
>     1.1 No changes. Remain as is.
>     1.X Add Your preferences here
>     1.Y and here ...
>
>     2. Call
>     2.1 Dot style
>        Declaration: void f( int a, int b );
>        Call:       f( .a=1, .b=2 );
>     2.X Add Your preferences here
>     2.Y and here ...
>
>     My opinion is: 1.1 and 2.1.
>
>     Extend this list with one line examples.
>     Do not explain why is something wrong and another is right.
>
>
>
> 1. Declaration
> 1.1 No changes. Remain as is.
> 1.2 Struct: `struct f_P{ int a; int b; }; void f(f_P);` (no change to
> language)
>
> 2. Call
> 2.1 `f( .a=1, .b=2 );`
> 2.2 `f({ .a = 1, .b = 2 });` (no change to language)
>
> My preferred is 1.2 and 2.2
>

(Extending the list means copying it, then adding more - don't remove
parts of it as it makes other changes more difficult.)

1. Declaration
1.1 No changes. Remain as is.
1.2 Struct: `struct f_P{ int a; int b; }; void f(f_P);` (no change to
 language)

2. Call
2.1 Dot style
    Declaration: void f( int a, int b );
    Call: f( .a=1, .b=2 );
2.1b Mixed dot style
    Call: f( 1, .b=2 );  (Positional arguments allowed before named
        ones, but not after named arguments)
2.1c Dot style with re-arrangements
    Call: f(.b = 2, .a = 1);
2.1d Dot style with override of default parameters
    Declaration: void g(int a = 10, int b = 20, int c = 30)
    Call: g(.b = 2); (Same as g(10, 2) would be today)

2.2 f({ .a = 1, .b = 2 }); (no change to language)


My preference is 1.1 and at least 2.1b but ideally 2.1c or 2.1d.


--
You received this message because you are 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/plp2jt%2491c%241%40blaine.gmane.org.

.

--00000000000087bb18057430ceb1
Content-Type: text/plain; charset="UTF-8"

On Fri, Aug 24, 2018 at 9:55 AM David Brown <david@westcontrol.com> wrote:

> (Extending the list means copying it, then adding more - don't remove
> parts of it as it makes other changes more difficult.)
>
> 1. Declaration
> 1.1 No changes. Remain as is.
> 1.2 Struct: `struct f_P{ int a; int b; }; void f(f_P);` (no change to
>         language)
>
> 2. Call
> 2.1 Dot style
>     Declaration: void f( int a, int b );
>     Call: f( .a=1, .b=2 );
> 2.1b Mixed dot style
>     Call: f( 1, .b=2 );  (Positional arguments allowed before named
>         ones, but not after named arguments)
> 2.1c Dot style with re-arrangements
>     Call: f(.b = 2, .a = 1);

2.1d Dot style with override of default parameters
>     Declaration: void g(int a = 10, int b = 20, int c = 30)
>     Call: g(.b = 2);    (Same as g(10, 2) would be today)

2.1e Mixed dot style with positional arguments and rearrangements after
postionals
    f(1, .c = 2, .b = 3);  (Same as f(1, 3, 2) would be today.)

>
> 2.2 f({ .a = 1, .b = 2 }); (no change to language)
>

My preference is 1.1 and all of 2.1, 2.1b, 2.1c, 2.1d, 2.1e.

--
You received this message because you are 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/CAHSYqdYubze5qVAhCd1dPRxvgGBnAqU%2BCLuAQwFpEMY4dWq2jA%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Aug 24=
, 2018 at 9:55 AM David Brown &lt;<a href=3D"mailto:david@westcontrol.com">=
david@westcontrol.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">
(Extending the list means copying it, then adding more - don&#39;t remove<b=
r>
parts of it as it makes other changes more difficult.)<br>
<br>
1. Declaration<br>
1.1 No changes. Remain as is.<br>
1.2 Struct: `struct f_P{ int a; int b; }; void f(f_P);` (no change to<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 language)<br>
<br>
2. Call<br>
2.1 Dot style<br>
=C2=A0 =C2=A0 Declaration: void f( int a, int b );<br>
=C2=A0 =C2=A0 Call: f( .a=3D1, .b=3D2 );<br>
2.1b Mixed dot style<br>
=C2=A0 =C2=A0 Call: f( 1, .b=3D2 );=C2=A0 (Positional arguments allowed bef=
ore named<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ones, but not after named arguments)<br>
2.1c Dot style with re-arrangements<br>
=C2=A0 =C2=A0 Call: f(.b =3D 2, .a =3D 1);</blockquote><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">
2.1d Dot style with override of default parameters<br>
=C2=A0 =C2=A0 Declaration: void g(int a =3D 10, int b =3D 20, int c =3D 30)=
<br>
=C2=A0 =C2=A0 Call: g(.b =3D 2);=C2=A0 =C2=A0 (Same as g(10, 2) would be to=
day)</blockquote><div>2.1e Mixed dot style with positional arguments and re=
arrangements after postionals<br>=C2=A0 =C2=A0 f(1, .c =3D 2, .b =3D 3);=C2=
=A0 (Same as f(1, 3, 2) would be today.)</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
<br>
2.2 f({ .a =3D 1, .b =3D 2 }); (no change to language)<br></blockquote><div=
><br>My preference is 1.1 and all of 2.1, 2.1b, 2.1c, 2.1d, 2.1e.</div></di=
v></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/CAHSYqdYubze5qVAhCd1dPRxvgGBnAqU%2BCL=
uAQwFpEMY4dWq2jA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYubze5qV=
AhCd1dPRxvgGBnAqU%2BCLuAQwFpEMY4dWq2jA%40mail.gmail.com</a>.<br />

--00000000000087bb18057430ceb1--

.

------=_Part_375_1830773375.1535137436023
Content-Type: multipart/alternative;
 boundary="----=_Part_376_1333868902.1535137436023"

------=_Part_376_1333868902.1535137436023
Content-Type: text/plain; charset="UTF-8"



On Friday, August 24, 2018 at 3:20:34 PM UTC+3, Dejan Milosavljevic wrote:
>
> Lets start wit very small list.
>
> 1. Declaration
> 1.1 No changes. Remain as is.
> 1.X Add Your preferences here
> 1.Y and here ...
>
> 2. Call
> 2.1 Dot style
>    Declaration: void f( int a, int b );
>    Call:       f( .a=1, .b=2 );
> 2.X Add Your preferences here
> 2.Y and here ...
> My opinion is: 1.1 and 2.1.
>
> Extend this list with one line examples.
> Do not explain why is something wrong and another is right.
>

We should move away from "no changes to the declaration" if we are to make
any progress:

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


That aside, it seems so far the weak names are the only ones desired.

>

--
You received this message because you are 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/b3fd1d1d-2637-4ce3-8ad2-01b81e17b189%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, August 24, 2018 at 3:20:34 PM UTC+3, De=
jan Milosavljevic 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"ltr"><div>Lets start wit very small list.</div><div><br></div><div>1.=
 Declaration<br>1.1 No changes. Remain as is.<br>1.X Add Your preferences h=
ere<br>1.Y and here ...</div><p>2. Call<br>2.1 Dot style<br>=C2=A0=C2=A0 De=
claration: void f( int a, int b );<br>=C2=A0=C2=A0 Call:=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 f( .a=3D1, .b=3D2 );<br>2.X Add Your preferences here<br=
>2.Y and here ...</p><div>My opinion is: 1.1 and 2.1.</div><div><br></div><=
div>Extend this list with one line examples.</div><div>Do not explain why i=
s something wrong and another is right.</div></div></blockquote><div><br></=
div><div>We should move away from &quot;no changes to the declaration&quot;=
 if we are to make any progress:</div><div><br></div><div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;"><div>What I have established, having had discussions about name=
d arguments <br>on multiple occasions, <br>is that the following pain point=
s are important: </div><div>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 t=
o rely <br>on, in order to avoid breakage that wasn&#39;t considered before=
hand. <br></div></blockquote></div><div><br></div><div><br></div><div>That =
aside, it seems so far the weak names are the only ones desired.=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">
</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/b3fd1d1d-2637-4ce3-8ad2-01b81e17b189%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b3fd1d1d-2637-4ce3-8ad2-01b81e17b189=
%40isocpp.org</a>.<br />

------=_Part_376_1333868902.1535137436023--

------=_Part_375_1830773375.1535137436023--

.

On 2018-08-24 15:03, mihailnajdenov@gmail.com wrote:
> That aside, it seems so far the weak names are the only ones desired.

Really?

Granted, I'm not sure at this point what "weak names" means, but I'm not
sure I agree with that statement.

--
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/d0a6e276-8bbe-e65c-1e9f-09cc9c28b7ef%40gmail.com.

.

------=_Part_405_1724105549.1535142135322
Content-Type: multipart/alternative;
 boundary="----=_Part_406_1995608560.1535142135322"

------=_Part_406_1995608560.1535142135322
Content-Type: text/plain; charset="UTF-8"



On Friday, August 24, 2018 at 10:22:11 PM UTC+3, Matthew Woehlke wrote:
>
> On 2018-08-24 15:03, mihailn...@gmail.com <javascript:> wrote:
> > That aside, it seems so far the weak names are the only ones desired.
>
> Really?
>
> Granted, I'm not sure at this point what "weak names" means, but I'm not
> sure I agree with that statement.
>

As far as the votes so far are concerned. As you know, I believe we need
both.


>
> --
> 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/e630d4f6-1156-4149-90be-d45733f7d0b5%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, August 24, 2018 at 10:22:11 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-24 15:03, <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"ucXYbjU=
cAQAJ">mihailn...@gmail.com</a> wrote:
<br>&gt; That aside, it seems so far the weak names are the only ones desir=
ed.=20
<br>
<br>Really?
<br>
<br>Granted, I&#39;m not sure at this point what &quot;weak names&quot; mea=
ns, but I&#39;m not
<br>sure I agree with that statement.
<br></blockquote><div><br></div><div>As far as the votes so far are concern=
ed. As you know, I believe we need both.</div><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;">
<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/e630d4f6-1156-4149-90be-d45733f7d0b5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e630d4f6-1156-4149-90be-d45733f7d0b5=
%40isocpp.org</a>.<br />

------=_Part_406_1995608560.1535142135322--

------=_Part_405_1724105549.1535142135322--

.

On 2018-08-16 17:23, Dejan Milosavljevic wrote:
> 1. Strong typedefs.
>     Currently there is strong demand for for it.
>     But no consensus so far.
>     Take a look at next code
>
>     strongdef polar = std::array<double,2>;
>     strongdef descartes = std::array<double,2>;
>     struct A{
>         void f( polar const& p );
>         void f( descartes const& p );
>     };
>
>     Clearly strong typedef will supersede this proposal.

Hardly. That *might* solve the desire for name-based overloads, but it
doesn't solve the 'many defaulted parameters' problem. (Not, at least,
without way, way too many overloads.)

--
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/c35ef267-f885-32d2-421e-8449f87621b5%40gmail.com.

.

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

On Fri, Aug 24, 2018 at 4:22 PM <mihailnajdenov@gmail.com> wrote:

> On Friday, August 24, 2018 at 10:22:11 PM UTC+3, Matthew Woehlke wrote:
>>
>> On 2018-08-24 15:03, mihailn...@gmail.com wrote:
>> > That aside, it seems so far the weak names are the only ones desired.
>> Really?
>> Granted, I'm not sure at this point what "weak names" means, but I'm not
>> sure I agree with that statement.
>
> As far as the votes so far are concerned. As you know, I believe we need
> both.
>

I don't see why leaving declarations alone affects using parameter names to
specify 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/CAHSYqdakfiBVYNKQdu4mzCQZuyVQdUHrxp6%3Dq2s3oG7UasyxQw%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Aug 24=
, 2018 at 4: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">On Friday, August 24, 2018 at 10:22:11 PM UTC+3, Matthew Woehlke w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex">On 2018-08-24 15:03, <a rel=3D=
"nofollow">mihailn...@gmail.com</a> wrote:
<br>&gt; That aside, it seems so far the weak names are the only ones desir=
ed. <br>Really?
<br>Granted, I&#39;m not sure at this point what &quot;weak names&quot; mea=
ns, but I&#39;m not
<br>sure I agree with that statement.=C2=A0</blockquote><div>As far as the =
votes so far are concerned. As you know, I believe we need both.</div></div=
></blockquote><div><br>I don&#39;t see why leaving declarations alone affec=
ts using parameter names to specify arguments.=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/CAHSYqdakfiBVYNKQdu4mzCQZuyVQdUHrxp6%=
3Dq2s3oG7UasyxQw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdakfiBVYN=
KQdu4mzCQZuyVQdUHrxp6%3Dq2s3oG7UasyxQw%40mail.gmail.com</a>.<br />

--0000000000007f9458057434e251--

.

------=_Part_422_1958045273.1535148037449
Content-Type: multipart/alternative;
 boundary="----=_Part_423_1274674186.1535148037449"

------=_Part_423_1274674186.1535148037449
Content-Type: text/plain; charset="UTF-8"



On Saturday, August 25, 2018 at 12:16:12 AM UTC+3, Hyman Rosen wrote:
>
> On Fri, Aug 24, 2018 at 4:22 PM <mihailn...@gmail.com <javascript:>>
> wrote:
>
>> On Friday, August 24, 2018 at 10:22:11 PM UTC+3, Matthew Woehlke wrote:
>>>
>>> On 2018-08-24 15:03, mihailn...@gmail.com wrote:
>>> > That aside, it seems so far the weak names are the only ones desired.
>>> Really?
>>> Granted, I'm not sure at this point what "weak names" means, but I'm not
>>> sure I agree with that statement.
>>
>> As far as the votes so far are concerned. As you know, I believe we need
>> both.
>>
>
>

> I don't see why leaving declarations alone affects using parameter names
> to specify arguments.
>

Because the user code starts depending on things, the library author might
not want it to depend on.
Much like "don't reopen std", "don't take the address of a std function",
library authors want the arguments to remain outside the interface to their
code.

From a practical standpoint, the author might want to introduce naming
partially either because the code is in flux,
 or simply because he considers only few argument important and worthy of
standardizing - after all it is his interface, he should be able to design
it how he wants it.
Also, with a separate syntax the author *should* be able to use any word,
including keywords like for, if, default.


--
You received this message because you are 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/9b26b74c-41c6-46c1-974e-1cd39f036a96%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Saturday, August 25, 2018 at 12:16:12 AM UTC+3,=
 Hyman Rosen 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"><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Aug 24, 2018 at 4=
:22 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"javasc=
ript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"f74fRm4i=
AQAJ">mihailn...@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">On Friday, August 24, 2018 at 10:22:11 PM UTC+3, Matthe=
w 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-24 15:03=
, <a rel=3D"nofollow">mihailn...@gmail.com</a> wrote:
<br>&gt; That aside, it seems so far the weak names are the only ones desir=
ed. <br>Really?
<br>Granted, I&#39;m not sure at this point what &quot;weak names&quot; mea=
ns, but I&#39;m not
<br>sure I agree with that statement.=C2=A0</blockquote><div>As far as the =
votes so far are concerned. As you know, I believe we need both.</div></div=
></blockquote><div><br></div></div></div></blockquote><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div class=3D"gma=
il_quote"><div>I don&#39;t see why leaving declarations alone affects using=
 parameter names to specify arguments.=C2=A0</div></div></div></blockquote>=
<div>=C2=A0</div><div>Because the user code starts depending on things, the=
 library author might not want it to depend on.=C2=A0</div><div>Much like &=
quot;don&#39;t reopen std&quot;, &quot;don&#39;t take the address of a std =
function&quot;, library authors want the arguments to remain outside the in=
terface to their code.</div><div><br></div><div>From a practical standpoint=
, the author might want to introduce naming partially either because the co=
de is in flux,</div><div>=C2=A0or simply because he considers only few argu=
ment important and worthy of standardizing - after all it is his interface,=
 he should be able to design it how he wants it.</div><div>Also, with a sep=
arate syntax the author <i>should</i> be able to use any word, including ke=
ywords like <font face=3D"courier new,monospace">for, if, default</font>.</=
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/9b26b74c-41c6-46c1-974e-1cd39f036a96%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9b26b74c-41c6-46c1-974e-1cd39f036a96=
%40isocpp.org</a>.<br />

------=_Part_423_1274674186.1535148037449--

------=_Part_422_1958045273.1535148037449--

.

--00000000000093bd0b05744efab2
Content-Type: text/plain; charset="UTF-8"

On Fri, Aug 24, 2018, 6:00 PM <mihailnajdenov@gmail.com> wrote:

> On Saturday, August 25, 2018 at 12:16:12 AM UTC+3, Hyman Rosen wrote:
>>
>> On Fri, Aug 24, 2018 at 4:22 PM <mihailn...@gmail.com> wrote:
>>
>>> On Friday, August 24, 2018 at 10:22:11 PM UTC+3, Matthew Woehlke wrote:
>>>>
>>>> On 2018-08-24 15:03, mihailn...@gmail.com wrote:
>>>> > That aside, it seems so far the weak names are the only ones desired.
>>>> Really?
>>>> Granted, I'm not sure at this point what "weak names" means, but I'm
>>>> not
>>>> sure I agree with that statement.
>>>
>>> As far as the votes so far are concerned. As you know, I believe we need
>>> both.
>>>
>>
>>
>
>> I don't see why leaving declarations alone affects using parameter names
>> to specify arguments.
>>
>
> Because the user code starts depending on things, the library author might
> not want it to depend on.
> Much like "don't reopen std", "don't take the address of a std function",
> library authors want the arguments to remain outside the interface to their
> code.
>

Too bad?  If we have named parameters, parameters will have to have
meaningful names.  That's a good thing anyway, because it helps document
what functions do.

>
> From a practical standpoint, the author might want to introduce naming
> partially either because the code is in flux,
>  or simply because he considers only few argument important and worthy of
> standardizing - after all it is his interface, he should be able to design
> it how he wants it.
>

No.  It's much more important to have a consistent language.  Letting
people decide that only certain parameters are named is silly.

Also, with a separate syntax the author *should* be able to use any word,
> including keywords
>

This is ridiculously unnecessary.

--
You received this message because you are 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/CAHSYqdZhJMgVd155mRzgL3zgakPpV3UY%2BxGTAyMZKtVy0rcaLA%40mail.gmail.com.

--00000000000093bd0b05744efab2
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, =
Aug 24, 2018, 6:00 PM  &lt;<a href=3D"mailto:mihailnajdenov@gmail.com">miha=
ilnajdenov@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"><di=
v dir=3D"ltr">On Saturday, August 25, 2018 at 12:16:12 AM UTC+3, Hyman Rose=
n wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_quote"><div dir=3D"ltr">On Fri, Aug 24, 2018 at 4:22 PM &lt;<a re=
l=3D"nofollow noreferrer">mihailn...@gmail.com</a>&gt; wrote:</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">On Friday, August 24, 2018 at 10:22=
:11 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-24 15:03, <a rel=3D"nofollow noreferrer">mihailn...@gmail.com</=
a> wrote:
<br>&gt; That aside, it seems so far the weak names are the only ones desir=
ed. <br>Really?
<br>Granted, I&#39;m not sure at this point what &quot;weak names&quot; mea=
ns, but I&#39;m not
<br>sure I agree with that statement.=C2=A0</blockquote><div>As far as the =
votes so far are concerned. As you know, I believe we need both.</div></div=
></blockquote><div><br></div></div></div></blockquote><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_qu=
ote"><div>I don&#39;t see why leaving declarations alone affects using para=
meter names to specify arguments.=C2=A0</div></div></div></blockquote><div>=
=C2=A0</div><div>Because the user code starts depending on things, the libr=
ary author might not want it to depend on.=C2=A0</div><div>Much like &quot;=
don&#39;t reopen std&quot;, &quot;don&#39;t take the address of a std funct=
ion&quot;, library authors want the arguments to remain outside the interfa=
ce to their code.</div></div></blockquote></div></div><div dir=3D"auto"><br=
></div><div dir=3D"auto">Too bad?=C2=A0 If we have named parameters, parame=
ters will have to have meaningful names.=C2=A0 That&#39;s a good thing anyw=
ay, because it helps document what functions do.</div><div dir=3D"auto"><di=
v 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"ltr"><di=
v><br></div><div>From a practical standpoint, the author might want to intr=
oduce naming partially either because the code is in flux,</div><div>=C2=A0=
or simply because he considers only few argument important and worthy of st=
andardizing - after all it is his interface, he should be able to design it=
 how he wants it.</div></div></blockquote></div></div><div dir=3D"auto"><br=
></div><div dir=3D"auto">No.=C2=A0 It&#39;s much more important to have a c=
onsistent language.=C2=A0 Letting people decide that only certain parameter=
s are named is silly.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><d=
iv 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"ltr"><d=
iv>Also, with a separate syntax the author <i>should</i> be able to use any=
 word, including keywords</div><div dir=3D"auto"></div></div></blockquote><=
/div></div><div dir=3D"auto"><br></div><div dir=3D"auto">This is ridiculous=
ly unnecessary.</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/CAHSYqdZhJMgVd155mRzgL3zgakPpV3UY%2Bx=
GTAyMZKtVy0rcaLA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZhJMgVd1=
55mRzgL3zgakPpV3UY%2BxGTAyMZKtVy0rcaLA%40mail.gmail.com</a>.<br />

--00000000000093bd0b05744efab2--

.

------=_Part_629_1145315042.1535276914548
Content-Type: multipart/alternative;
 boundary="----=_Part_630_950672733.1535276914549"

------=_Part_630_950672733.1535276914549
Content-Type: text/plain; charset="UTF-8"



On Sunday, August 26, 2018 at 7:24:06 AM UTC+3, Hyman Rosen wrote:
>
> On Fri, Aug 24, 2018, 6:00 PM <mihailn...@gmail.com <javascript:>> wrote:
>
>> On Saturday, August 25, 2018 at 12:16:12 AM UTC+3, Hyman Rosen wrote:
>>>
>>> On Fri, Aug 24, 2018 at 4:22 PM <mihailn...@gmail.com> wrote:
>>>
>>>> On Friday, August 24, 2018 at 10:22:11 PM UTC+3, Matthew Woehlke wrote:
>>>>>
>>>>> On 2018-08-24 15:03, mihailn...@gmail.com wrote:
>>>>> > That aside, it seems so far the weak names are the only ones
>>>>> desired.
>>>>> Really?
>>>>> Granted, I'm not sure at this point what "weak names" means, but I'm
>>>>> not
>>>>> sure I agree with that statement.
>>>>
>>>> As far as the votes so far are concerned. As you know, I believe we
>>>> need both.
>>>>
>>>
>>>
>>
>>> I don't see why leaving declarations alone affects using parameter names
>>> to specify arguments.
>>>
>>
>> Because the user code starts depending on things, the library author
>> might not want it to depend on.
>> Much like "don't reopen std", "don't take the address of a std function",
>> library authors want the arguments to remain outside the interface to their
>> code.
>>
>
> Too bad?  If we have named parameters, parameters will have to have
> meaningful names.  That's a good thing anyway, because it helps document
> what functions do.
>

Sure, in principal, but in practice this is not always possible or even
desirable, especially considering the prize to pay is breaking someone's
build.

And it is not just "library authors" breaking "users" code.

Think about a class that has a public interface and private implementation,
be it private functions, functions in anonymous ns, pimpl etc.

Ok, one will be a good guy and be careful to pick correct names upfront for
the public interface, what about all *other* functions that a *coworker*
might use?
Dozens upon dozens helper and implementation functions across all sorts of
files with different state of stability!

Without an ability to *pin* a name as *stable* there is no guarantee ever
one is not breaking someone else's code, even his own.

What would be the solution to this? A convection? Documentation? How is
this better then expressing it all in the code itself!


>
>> From a practical standpoint, the author might want to introduce naming
>> partially either because the code is in flux,
>>  or simply because he considers only few argument important and worthy of
>> standardizing - after all it is his interface, he should be able to design
>> it how he wants it.
>>
>
> No.  It's much more important to have a consistent language.  Letting
> people decide that only certain parameters are named is silly.
>

It is not so silly, even if we take stability of the code away from the
picture (and we can't, but lets say we do) - often the name is redundant
and/or there is no good name.

How to name the argument of sqrt? Why is it named that way? Is it
self-explanatory? Do you know how it is called according to the standard
library right now? Which implementation of it?

This tiny example shows all the problems with reusing arguments for names -
arguments *might* or might *not* require design and expressiveness,  names,
*always* *do*.

And it does not stop there. Do you really need the begin and end iterators
of every algorithm named? And how would you name them? begin and end,
possibly colliding with the functions?
first and last, like they are now *unofficially* called and documented in
cppreference? *But this is wrong, end is not last, but one past last! *

And so on, reusing arguments creates problems *bigger*, then the
"simplicity" it promises:

 Every argument ever, on every function ever,* can break code*, AND every
argument is essentially *mandatory* to design, you can't even mark it as
"name can be skipped" like in swift sqrt(_ val: double)

There is a reason this idea did not get traction in 91, no need to go the
same path again. We should move forward.


>
> Also, with a separate syntax the author *should* be able to use any word,
>> including keywords
>>
>
> This is ridiculously unnecessary.
>

--
You received this message because you are 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/5940029a-6a96-47d7-86cf-4ae915a1f86f%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Sunday, August 26, 2018 at 7:24:06 AM UTC+3, Hy=
man Rosen 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"au=
to"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Aug 24, 2018, =
6:00 PM  &lt;<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"rflgdl=
yIAQAJ">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">On Saturday, August 25, 2018 at 12:16:12 AM UTC+3, Hy=
man Rosen 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 class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Aug 24, 2018 at 4:22 PM &=
lt;<a rel=3D"nofollow noreferrer">mihailn...@gmail.com</a>&gt; wrote:</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Friday, August 24, 2018 =
at 10:22:11 PM UTC+3, Matthew Woehlke wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">On 2018-08-24 15:03, <a rel=3D"nofollow noreferrer">mihailn...@gma=
il.com</a> wrote:
<br>&gt; That aside, it seems so far the weak names are the only ones desir=
ed. <br>Really?
<br>Granted, I&#39;m not sure at this point what &quot;weak names&quot; mea=
ns, but I&#39;m not
<br>sure I agree with that statement.=C2=A0</blockquote><div>As far as the =
votes so far are concerned. As you know, I believe we need both.</div></div=
></blockquote><div><br></div></div></div></blockquote><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_qu=
ote"><div>I don&#39;t see why leaving declarations alone affects using para=
meter names to specify arguments.=C2=A0</div></div></div></blockquote><div>=
=C2=A0</div><div>Because the user code starts depending on things, the libr=
ary author might not want it to depend on.=C2=A0</div><div>Much like &quot;=
don&#39;t reopen std&quot;, &quot;don&#39;t take the address of a std funct=
ion&quot;, library authors want the arguments to remain outside the interfa=
ce to their code.</div></div></blockquote></div></div><div dir=3D"auto"><br=
></div><div dir=3D"auto">Too bad?=C2=A0 If we have named parameters, parame=
ters will have to have meaningful names.=C2=A0 That&#39;s a good thing anyw=
ay, because it helps document what functions do.</div></div></blockquote><d=
iv><br></div><div>Sure, in principal, but in practice this is not always po=
ssible or even desirable, especially considering the prize to pay is breaki=
ng someone&#39;s build.</div><div><br></div><div>And it is not just &quot;l=
ibrary authors&quot; breaking &quot;users&quot; code.=C2=A0</div><div><br><=
/div><div>Think about a class that has a public interface and private imple=
mentation, be it private functions, functions in anonymous ns, pimpl etc.</=
div><div><br></div><div>Ok, one will be a good guy and be careful to pick c=
orrect names upfront for the public interface, what about all <i>other</i> =
functions that a <i>coworker</i> might use?=C2=A0</div><div>Dozens upon doz=
ens helper and implementation functions across all sorts of files with diff=
erent state of stability!=C2=A0</div><div><br></div><div>Without an ability=
 to <i>pin</i> a name as <i>stable</i> there is no guarantee ever one is no=
t breaking someone else&#39;s code, even his own.</div><div><br></div><div>=
What would be the solution to this? A convection? Documentation? How is thi=
s better then expressing it all in the code itself!</div><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 dir=3D"auto"><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"=
ltr"><div><br></div><div>From a practical standpoint, the author might want=
 to introduce naming partially either because the code is in flux,</div><di=
v>=C2=A0or simply because he considers only few argument important and wort=
hy of standardizing - after all it is his interface, he should be able to d=
esign it how he wants it.</div></div></blockquote></div></div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">No.=C2=A0 It&#39;s much more important to =
have a consistent language.=C2=A0 Letting people decide that only certain p=
arameters are named is silly.</div></div></blockquote><div><br></div><div>I=
t is not so silly, even if we take stability of the code away from the pict=
ure (and we can&#39;t, but lets say we do) - often the name is redundant an=
d/or there is no good name.</div><div><br></div><div>How to name the argume=
nt of=C2=A0<font face=3D"courier new,monospace">sqrt</font>? Why is it name=
d that way? Is it self-explanatory? Do you know how it is called according =
to the standard library right now? Which implementation of it?</div><div><b=
r></div><div>This tiny example shows all the problems with reusing argument=
s for names - arguments <i>might</i> or might <i>not</i> require design and=
 expressiveness,=C2=A0 names, <i>always</i> <i>do</i>.</div><div><br></div>=
<div>And it does not stop there. Do you really need the <font face=3D"couri=
er new,monospace">begin</font> and <font face=3D"courier new,monospace">end=
</font> iterators of every algorithm named? And how would you name them? <f=
ont face=3D"courier new,monospace">begin</font> and <font face=3D"courier n=
ew,monospace">end</font>, possibly colliding with the functions?</div><div>=
<font face=3D"courier new,monospace">first</font> and <font face=3D"courier=
 new,monospace">last</font>, like they are now <i>unofficially</i> called a=
nd documented in cppreference? <i>But this is wrong, end is not last, but o=
ne past last!=C2=A0</i></div><div><br></div><div>And so on, reusing argumen=
ts creates problems <i>bigger</i>, then the &quot;simplicity&quot; it promi=
ses:</div><div><br></div><div>=C2=A0Every argument ever, on every function =
ever,<i> can break code</i>, AND every argument is essentially <i>mandatory=
</i> to design, you can&#39;t even mark it as &quot;name can be skipped&quo=
t; like in swift<font face=3D"courier new,monospace"> sqrt(_ val: double)</=
font></div><div><font face=3D"courier new,monospace"><br></font></div><div>=
<font face=3D"arial,sans-serif">There is a reason this idea did not get tra=
ction in 91, no need to go the same path again. We should move forward.</fo=
nt></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"auto"><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"ltr"><div>Also, with=
 a separate syntax the author <i>should</i> be able to use any word, includ=
ing keywords</div><div dir=3D"auto"></div></div></blockquote></div></div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">This is ridiculously unnecessar=
y.</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/5940029a-6a96-47d7-86cf-4ae915a1f86f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5940029a-6a96-47d7-86cf-4ae915a1f86f=
%40isocpp.org</a>.<br />

------=_Part_630_950672733.1535276914549--

------=_Part_629_1145315042.1535276914548--

.

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

On Sun, Aug 26, 2018 at 5:48 AM <mihailnajdenov@gmail.com> wrote:

> Too bad?  If we have named parameters, parameters will have to have
>> meaningful names.  That's a good thing anyway, because it helps document
>> what functions do.
>>
>
> Sure, in principal, but in practice this is not always possible or even
> desirable, especially considering the prize to pay is breaking someone's
> build.
>

The parameter names become part of the interface. If you change method
names, you can break a build.  If you add overloads, you can break a
build.  If you change parameter names, you can break a build.

So don't?  Or notify the users first?  Other languages with named
parameters seem to have coped.

Without an ability to *pin* a name as *stable* there is no guarantee ever
> one is not breaking someone else's code, even his own.
> What would be the solution to this? A convection? Documentation? How is
> this better then expressing it all in the code itself!
>

The "explanation" is the name of the parameter in the declaration.  Nothing
more is needed.

It is not so silly, even if we take stability of the code away from the
> picture (and we can't, but lets say we do) - often the name is redundant
> and/or there is no good name.
>

The parameter must have some name.  That becomes the name used for named
parameter passing.

How to name the argument of sqrt? Why is it named that way? Is it
> self-explanatory? Do you know how it is called according to the standard
> library right now? Which implementation of it?
>

It's named 'x' because that's how the C standard refers to it.  The
parameters of operator<= are named 'lhs' and 'rhs'.
Whatever.  Some name gets picked, and that's the name.

This tiny example shows all the problems with reusing arguments for names -
> arguments *might* or might *not* require design and expressiveness,
> names, *always* *do*.
>

Parameters always require expressiveness, because the contract that defines
what the function does needs to refer to them in a way that makes sense.
(Which, by the way, can be the next fight - national language arguments
over named parameters.)

And it does not stop there. Do you really need the begin and end iterators
> of every algorithm named? And how would you name them? begin and end,
> possibly colliding with the functions?
> first and last, like they are now *unofficially* called and documented in
> cppreference? *But this is wrong, end is not last, but one past last! *
>

Yes, we need them named, because the contract that describes what the
function does has to refer to them by name.
If 'begin' and 'end' are the best names, then those are the names to use,
and the implementation just has to deal with it.

 Every argument ever, on every function ever,* can break code*, AND every
> argument is essentially *mandatory* to design, you can't even mark it as
> "name can be skipped" like in swift sqrt(_ val: double)
>

Huh?  Named parameters don't eliminate positional parameters.  If you want
to call sqrt(7.3), that works fine.  (I'm assuming the Ada version of named
parameters, which is a leading set of positional arguments followed by a
trailing set of named arguments in arbitrary order, with defaulted
parameters elidable.)

--
You received this message because you are 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/CAHSYqdaF-UCWCkR0CbgeCU_y6Bg51Hwjy8_ft2Lfxc91n7B-CA%40mail.gmail.com.

--000000000000e5a46a05746bfff3
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 Sun, Aug 26=
, 2018 at 5:48 AM &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"><div dir=3D"auto"><div dir=
=3D"auto">Too bad?=C2=A0 If we have named parameters, parameters will have =
to have meaningful names.=C2=A0 That&#39;s a good thing anyway, because it =
helps document what functions do.</div></div></blockquote><div><br></div><d=
iv>Sure, in principal, but in practice this is not always possible or even =
desirable, especially considering the prize to pay is breaking someone&#39;=
s build.</div></div></blockquote><div><br>The parameter names become part o=
f the interface. If you change method names, you can break a build.=C2=A0 I=
f you add overloads, you can break a build.=C2=A0 If you change parameter n=
ames, you can break a build.<br><br>So don&#39;t?=C2=A0 Or notify the users=
 first?=C2=A0 Other languages with named parameters seem to have coped.<br>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Without an a=
bility to <i>pin</i> a name as <i>stable</i> there is no guarantee ever one=
 is not breaking someone else&#39;s code, even his own.</div><div>What woul=
d be the solution to this? A convection? Documentation? How is this better =
then expressing it all in the code itself!</div></div></blockquote><div><br=
>The &quot;explanation&quot; is the name of the parameter in the declaratio=
n.=C2=A0 Nothing more is needed.<br><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div>It is not so silly, even if we take stability of th=
e code away from the picture (and we can&#39;t, but lets say we do) - often=
 the name is redundant and/or there is no good name.</div></div></blockquot=
e><div><br>The parameter must have some name.=C2=A0 That becomes the name u=
sed for named parameter passing.<br><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div>How to name the argument of=C2=A0<font face=3D"cour=
ier new,monospace">sqrt</font>? Why is it named that way? Is it self-explan=
atory? Do you know how it is called according to the standard library right=
 now? Which implementation of it?</div></div></blockquote><div><br>It&#39;s=
 named &#39;x&#39; because that&#39;s how the C standard refers to it.=C2=
=A0 The parameters of operator&lt;=3D are named &#39;lhs&#39; and &#39;rhs&=
#39;.<br>Whatever.=C2=A0 Some name gets picked, and that&#39;s the name.<br=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>This tiny e=
xample shows all the problems with reusing arguments for names - arguments =
<i>might</i> or might <i>not</i> require design and expressiveness,=C2=A0 n=
ames, <i>always</i> <i>do</i>.</div></div></blockquote><div><br>Parameters =
always require expressiveness, because the contract that defines what the f=
unction does needs to refer to them in a way that makes sense.=C2=A0 (Which=
, by the way, can be the next fight - national language arguments over name=
d parameters.)<br><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div>And it does not stop there. Do you really need the <font face=3D"cour=
ier new,monospace">begin</font> and <font face=3D"courier new,monospace">en=
d</font> iterators of every algorithm named? And how would you name them? <=
font face=3D"courier new,monospace">begin</font> and <font face=3D"courier =
new,monospace">end</font>, possibly colliding with the functions?</div><div=
><font face=3D"courier new,monospace">first</font> and <font face=3D"courie=
r new,monospace">last</font>, like they are now <i>unofficially</i> called =
and documented in cppreference? <i>But this is wrong, end is not last, but =
one past last!=C2=A0</i></div></div></blockquote><div><br>Yes, we need them=
 named, because the contract that describes what the function does has to r=
efer to them by name.<br>If &#39;begin&#39; and &#39;end&#39; are the best =
names, then those are the names to use, and the implementation just has to =
deal with it.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div>=C2=A0Every argument ever, on every function ever,<i> can break code</=
i>, AND every argument is essentially <i>mandatory</i> to design, you can&#=
39;t even mark it as &quot;name can be skipped&quot; like in swift<font fac=
e=3D"courier new,monospace"> sqrt(_ val: double)</font></div></div></blockq=
uote><div><br>Huh?=C2=A0 Named parameters don&#39;t eliminate positional pa=
rameters.=C2=A0 If you want to call sqrt(7.3), that works fine.=C2=A0 (I&#3=
9;m assuming the Ada version of named parameters, which is a leading set of=
 positional arguments followed by a trailing set of named arguments in arbi=
trary order, with defaulted parameters elidable.)</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/CAHSYqdaF-UCWCkR0CbgeCU_y6Bg51Hwjy8_f=
t2Lfxc91n7B-CA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaF-UCWCkR0=
CbgeCU_y6Bg51Hwjy8_ft2Lfxc91n7B-CA%40mail.gmail.com</a>.<br />

--000000000000e5a46a05746bfff3--

.

On 2018-08-27 11:01, Hyman Rosen wrote:
> The parameter names become part of the interface. If you change method
> names, you can break a build.  If you add overloads, you can break a
> build.  If you change parameter names, you can break a build.
>
> So don't?  Or notify the users first?  Other languages with named
> parameters seem to have coped.

....but in other languages, argument names have *always* been part of the
API, yes?

If C++ had done that from day one, it would probably be okay. It's the
notion of *changing* this that makes people nervous.

> On Sun, Aug 26, 2018 at 5:48 AM <mihailnajdenov@gmail.com> wrote:
>> How to name the argument of sqrt? Why is it named that way? Is it
>> self-explanatory? Do you know how it is called according to the standard
>> library right now? Which implementation of it?
>
> It's named 'x' because that's how the C standard refers to it.  The
> parameters of operator<= are named 'lhs' and 'rhs'.
> Whatever.  Some name gets picked, and that's the name.

And just how do you expect all the existing standard library
implementations, which not only don't use standard names right now, but
*need to be robust against users #define'ing those names*, to get fixed?

Remember, right now this code is supposed to compile:

  #define lhs if(0)
  #include <algorithm>
  // do stuff

(Are you proposing that these named arguments will be *absolutely
dependent* on modules?)

> Parameters always require expressiveness, because the contract that defines
> what the function does needs to refer to them in a way that makes sense.

By "contract", are you talking about Contracts, or just the textual
description? Because I'm not convinced that every function will use the
former, and the latter can certainly say things like "the first argument".

> (Which, by the way, can be the next fight - national language arguments
> over named parameters.)

No, we don't need to go there. The function names are en_US. Not using
the same for the parameter names also would be madness.

--
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/2db8cc0a-5c6c-486c-f550-ec87e31e4f7d%40gmail.com.

.

On Sun, Aug 26, 2018 at 12:23:55AM -0400, Hyman Rosen wrote:
> On Fri, Aug 24, 2018, 6:00 PM <mihailnajdenov@gmail.com> wrote:
>
> > On Saturday, August 25, 2018 at 12:16:12 AM UTC+3, Hyman Rosen wrote:
> >>
> >> On Fri, Aug 24, 2018 at 4:22 PM <mihailn...@gmail.com> wrote:
> >>
> >>> On Friday, August 24, 2018 at 10:22:11 PM UTC+3, Matthew Woehlke wrote:
> >>>>
> >>>> On 2018-08-24 15:03, mihailn...@gmail.com wrote:
> >>>> > That aside, it seems so far the weak names are the only ones desired.
> >>>> Really?
> >>>> Granted, I'm not sure at this point what "weak names" means, but I'm
> >>>> not
> >>>> sure I agree with that statement.
> >>>
> >>> As far as the votes so far are concerned. As you know, I believe we need
> >>> both.
> >>>
> >>
> >>
> >
> >> I don't see why leaving declarations alone affects using parameter names
> >> to specify arguments.
> >>
> >
> > Because the user code starts depending on things, the library author might
> > not want it to depend on.
> > Much like "don't reopen std", "don't take the address of a std function",
> > library authors want the arguments to remain outside the interface to their
> > code.
> >
>
> Too bad?  If we have named parameters, parameters will have to have
> meaningful names.  That's a good thing anyway, because it helps document
> what functions do.

They will? What is the name?

Consider

int foo(double, double);
int foo(double xpos, double ypos);
int foo(double len, double angle);

Today that is legal C++ and all declarations of foo refer to the same
function, I am assuming that we can't break that.

The first declaration would obviously not introduce any parameter names but
the latter two does.

I suppose a call to

foo(.xpos = 1, .angle = 2);

should be ill formed - the argument against that is if we want to introduce
alternative names for named arguments.

This by the way also rules out any kind of overloading on parameter names.

One thing it don't rule out is usage of parameter names as guides in deducing
the type of an argument so

struct angle { angle(double); };
int foo(double xpos, double ypos);
int foo(double len, angle angle);

foo(1, .angle = 1);

could be seen as not ambigous with the xpos variant.

/MF

> >
> > From a practical standpoint, the author might want to introduce naming
> > partially either because the code is in flux,
> >  or simply because he considers only few argument important and worthy of
> > standardizing - after all it is his interface, he should be able to design
> > it how he wants it.
> >
>
> No.  It's much more important to have a consistent language.  Letting
> people decide that only certain parameters are named is silly.
>
> Also, with a separate syntax the author *should* be able to use any word,
> > including keywords
> >
>
> This is ridiculously unnecessary.
>
> --
> You received this message because you are 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/CAHSYqdZhJMgVd155mRzgL3zgakPpV3UY%2BxGTAyMZKtVy0rcaLA%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/20181020071836.GA1476%40noemi.bahnhof.se.

.

--00000000000002723a0578b16a72
Content-Type: text/plain; charset="UTF-8"

On Sat, Oct 20, 2018, 3:18 AM Magnus Fromreide <magfr@lysator.liu.se> wrote:

> int foo(double, double);
> int foo(double xpos, double ypos);
> int foo(double len, double angle);
>
> Today that is legal C++ and all declarations of foo refer to the same
> function, I am assuming that we can't break that.
>

Assume away.  I would happily break that.  In fact, we have a static
analysis tool at my company for which I personally have written the test
that detects and warns about inconsistent parameter names.

What with contracts and modules, the first declaration is assuming
increased signifigance anyway.  But if you want maximum preservation of
silliness, it's easy enough - make it the rule that if a function is
declared with the same parameter given multiple names, that parameter
cannot be specified by a named argument association.

>

--
You received this message because you are 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/CAHSYqdaGiE9vFd3ugXuRCOnSxWitO1KKy76pXr04mmfAqrcJgQ%40mail.gmail.com.

--00000000000002723a0578b16a72
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 Sat, =
Oct 20, 2018, 3:18 AM Magnus Fromreide &lt;<a href=3D"mailto:magfr@lysator.=
liu.se">magfr@lysator.liu.se</a>&gt; wrote:</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">
int foo(double, double);<br>
int foo(double xpos, double ypos);<br>
int foo(double len, double angle);<br>
<br>
Today that is legal C++ and all declarations of foo refer to the same<br>
function, I am assuming that we can&#39;t break that.<br></blockquote></div=
></div><div dir=3D"auto"><br></div><div dir=3D"auto">Assume away.=C2=A0 I w=
ould happily break that.=C2=A0 In fact, we have a static analysis tool at m=
y company for which I personally have written the test that detects and war=
ns about inconsistent parameter names.</div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">What with contracts and modules, the first declaration is as=
suming increased signifigance anyway.=C2=A0 But if you want maximum preserv=
ation of silliness, it&#39;s easy enough - make it the rule that if a funct=
ion is declared with the same parameter given multiple names, that paramete=
r cannot be specified by a named argument association.</div><div dir=3D"aut=
o"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: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/CAHSYqdaGiE9vFd3ugXuRCOnSxWitO1KKy76p=
Xr04mmfAqrcJgQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaGiE9vFd3u=
gXuRCOnSxWitO1KKy76pXr04mmfAqrcJgQ%40mail.gmail.com</a>.<br />

--00000000000002723a0578b16a72--

.