As a followup to my previous email on named parameters, I've collected as b=
est I can what I think everybody actually wants.  This is round one of requ=
irements - there are some that are in conflict with others. There are other=
s than strongly desired by some and strongly opposed by others.

The high level problem statement we want to make writing AND maintaining co=
rrect code easier. We can all write correct code today; but there are times=
 where you either have to write a lot of boilerplate code, write code with =
a nasty syntax, or just trust that you got the parameters right because the=
 compiler won't tell you. This is undesirable, people often write unsafe co=
de just because the alternatives are perceived as too difficult/too ugly.

goals:

Have C support the syntax as well. While C++ has a lot of things that C can=
not do, interoperability with C is a very strong selling point of C++. Thus=
 a proposal that is accepted by WG14 at the same time is desired.  The C++ =
version will likely be more complex to handle things in C++ that don't exis=
t in C, but we would like compatibility for the parts that are common with =
C.

Not change ABI. This is controversial. There are some things people would l=
ike to do that require ABI changes. These are not necessarily bad ideas, an=
d may be worth doing. However any proposal that changes ABI will face a lar=
ger battle and need stronger justification.

Do things that cannot be done with the type system. There are many people w=
ho consider c++ a strongly typed language, they consider most proposals a w=
ork around for cases where the type system is too weak.=20

Support future expansion. There are a number of different ideas out there s=
olving semi-disjoint problems. Whatever is done first will not be last. Do =
our best to not lock out the ideas that other people care about that you do=
 not care about.

Existing code needs to still build and work. Of course if the existing  cod=
e is actually wrong and nobody noticed before it would be nice if it fails =
to build; but assuming no bugs, code that builds today needs to build tomor=
row.

Work with all existing parts of C++. If sometimes the user gets an error fr=
om what looks like the same syntax of the last function call just because t=
his one happens to use a dark corner of C++, that is undesired.

Not sink the Vasa. C++ is already a complex language, all additions will be=
 looked on with suspicion. The gain needs to justify the costs.


Problems we want to fix.  These can be separate proposals, but if so they n=
eed to allow the others

The first problem we want to fix is the "why did the previous maintainer ca=
ll that function with those parameters" For example, in python syntax AddGr=
aphPoint(x=3DEmployeeId, y=3Dincome) - employeeID is a great variable name =
in general, but it generally isn't something you normally graph, at least w=
e know it is intentional.

The second problem is when writing code it is easy to mix up the order of i=
dentical typed parameters. It would be nice if matrix.GetCell(row, column) =
would tell me if it should be matrix.GetCell(column, row).=20

The third problem is  GUI windows often have a large number of things the u=
ser can set on creation, and typically the user will accept the defaults fo=
r 90%, but it is a different set of parameters where the default is wrong f=
or each user. The current options tend to be inefficient. Sometimes the ine=
fficiency is runtime, sometimes it is compile time, and sometimes it is hum=
an typing/reading time, but all are inefficient.


For the second problem there are some who would like the compiler to reorde=
r the call to just do the right thing. Defining the rules for when this can=
 happen is probably easy, but I would suggest that we first get the above w=
orking before thinking about this. Real world experience one a small change=
 can drive this latter.


There are some who argue that we can already do the first two with the exis=
ting c++98 code. While technically true, they all sink the Vasa in real wor=
ld code. Sure the c++ standard is small, but there is a lot of extra, and s=
ubjectively ugly code required to make it work.

For example

struct ICannotBeliveItIsNotAnInt {int TheInteger;};   This starts looking f=
ine, but to be really useful this needs to implement all the operators.  Wh=
en you finally break down and do that you discover you also have to overloa=
d everything in <cmath> so you can get std::abs working - users are not all=
owed to extend the std namespace, but we need to break this rule if our new=
 type is to work.  Before you propose fixing this, remember that Meter::ope=
rator* returns a SquareMeter not a meter.=20

This isn't to say that you cannot expand strong types to fix the above, but=
 if you want to do that you need to write your own proposal.


So what do you think, did I get a reasonably balanced view of what people w=
ant and what is painful enough that it is worth considering?  Is it worth g=
oing farther? This could be turned into a proposal to the EWG, which if suc=
cessful will give everyone who has a specific syntax in mind a direction to=
 focus their efforts (either just write the proposal, or come up with a str=
ong argument why something everyone thinks we need is worth sacrificing)

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

.

On 2018-08-24 16:46, Henry Miller wrote:
> Have C support the syntax as well.

....but what does that even mean? C can't overload. C can't do default
parameters. That means all that named parameters could bring to C is
checking (which we already have since C++98), and maybe reordering. (And
while C probably doesn't mind allowing reordering, designated
initializers suggest that C++ *might*.)

While I agree this sounds nice, I question whether it there is any
*genuine* value.

> Do things that cannot be done with the type system. There are many
> people who consider c++ a strongly typed language, they consider
> most proposals a work around for cases where the type system is too
> weak.

"Not have incredibly obtuse syntax" can't be done by the type system
*alone* :-).

What about forwarding?

--
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/7178be8f-9579-6887-a49c-9321a7b39122%40gmail.com.

.

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

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

> (And while C probably doesn't mind allowing reordering, designated
> initializers suggest that C++ *might*.)
>

As far as I'm concerned, named parameters without reordering is a complete
non-starter.

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

--000000000000bbaa70057434f1e4
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 5:03 PM Matthew Woehlke &lt;<a href=3D"mailto:mwoehlke.floss@gmai=
l.com">mwoehlke.floss@gmail.com</a>&gt; wrote:</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">(And while C probably doesn&#39;t mind allowing reordering, designa=
ted<br>
initializers suggest that C++ *might*.)<br></blockquote><div><br>As far as =
I&#39;m concerned, named parameters without reordering is a complete non-st=
arter.=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/CAHSYqdbPbPrEYJM2okzTaSZArBxv3FoCdjgN=
zvn5LwSgxJATMg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbPbPrEYJM2=
okzTaSZArBxv3FoCdjgNzvn5LwSgxJATMg%40mail.gmail.com</a>.<br />

--000000000000bbaa70057434f1e4--

.

------=_Part_451_872959918.1535185363947
Content-Type: multipart/alternative;
 boundary="----=_Part_452_33677697.1535185363948"

------=_Part_452_33677697.1535185363948
Content-Type: text/plain; charset="UTF-8"



On Friday, August 24, 2018 at 11:46:32 PM UTC+3, Henry Miller wrote:
>
>
> As a followup to my previous email on named parameters, I've collected as
> best I can what I think everybody actually wants.  This is round one of
> requirements - there are some that are in conflict with others. There are
> others than strongly desired by some and strongly opposed by others.
>
> The high level problem statement we want to make writing AND maintaining
> correct code easier. We can all write correct code today; but there are
> times where you either have to write a lot of boilerplate code, write code
> with a nasty syntax, or just trust that you got the parameters right
> because the compiler won't tell you. This is undesirable, people often
> write unsafe code just because the alternatives are perceived as too
> difficult/too ugly.
>
> goals:
>
> Have C support the syntax as well. While C++ has a lot of things that C
> cannot do, interoperability with C is a very strong selling point of C++.
> Thus a proposal that is accepted by WG14 at the same time is desired.  The
> C++ version will likely be more complex to handle things in C++ that don't
> exist in C, but we would like compatibility for the parts that are common
> with C.
>

What does this mean? Does it mean we are still at "reuse arguments as
names", 1991 style
<http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/1991/WG21%201991/X3J16_91-0127%20WG21_N0060.pdf>
?
Or, because no ABI break we can use macros if we are compiling for C, like
we do today with default values:
#ifdef __cplusplus
#define FI_DEFAULT(x) = x
#else
#define FI_DEFAULT(x)


>
> Not change ABI. This is controversial. There are some things people would
> like to do that require ABI changes. These are not necessarily bad ideas,
> and may be worth doing. However any proposal that changes ABI will face a
> larger battle and need stronger justification.
>
> Do things that cannot be done with the type system. There are many people
> who consider c++ a strongly typed language, they consider most proposals a
> work around for cases where the type system is too weak.
>
> Support future expansion. There are a number of different ideas out there
> solving semi-disjoint problems. Whatever is done first will not be last. Do
> our best to not lock out the ideas that other people care about that you do
> not care about.
>
> Existing code needs to still build and work. Of course if the existing
>  code is actually wrong and nobody noticed before it would be nice if it
> fails to build; but assuming no bugs, code that builds today needs to build
> tomorrow.
>
> Work with all existing parts of C++. If sometimes the user gets an error
> from what looks like the same syntax of the last function call just because
> this one happens to use a dark corner of C++, that is undesired.
>
> Not sink the Vasa. C++ is already a complex language, all additions will
> be looked on with suspicion. The gain needs to justify the costs.
>


>
> Problems we want to fix.  These can be separate proposals, but if so they
> need to allow the others
>
> The first problem we want to fix is the "why did the previous maintainer
> call that function with those parameters" For example, in python syntax
> AddGraphPoint(x=EmployeeId, y=income) - employeeID is a great variable name
> in general, but it generally isn't something you normally graph, at least
> we know it is intentional.
>
> The second problem is when writing code it is easy to mix up the order of
> identical typed parameters. It would be nice if matrix.GetCell(row, column)
> would tell me if it should be matrix.GetCell(column, row).
>
> The third problem is  GUI windows often have a large number of things the
> user can set on creation, and typically the user will accept the defaults
> for 90%, but it is a different set of parameters where the default is wrong
> for each user. The current options tend to be inefficient. Sometimes the
> inefficiency is runtime, sometimes it is compile time, and sometimes it is
> human typing/reading time, but all are inefficient.
>

Forth problem people want fixed is the named constructor problem. For this
we need strong names, but it is valid request never the less.
Just yesterday spend 5 minutes looking how to create a QMessageBox that
shows a warning-styled ready dialog: the constructor did not help as it is
an all-in-one one, could not find any suitable get* static function,
so had to look the documentation (*online*, because I don't have it
locally). Turned out there is a warning static function. One might argue,
"it is all clear", but is it.

Note that that exact problem could not be solved gracefully by types
either, tags might be ok, but as always they will fight for naming and
scoping - where to put them, how to name them to be clear what is going on.


>
>
> For the second problem there are some who would like the compiler to
> reorder the call to just do the right thing. Defining the rules for when
> this can happen is probably easy, but I would suggest that we first get the
> above working before thinking about this. Real world experience one a small
> change can drive this latter.
>
>
> There are some who argue that we can already do the first two with the
> existing c++98 code. While technically true, they all sink the Vasa in real
> world code. Sure the c++ standard is small, but there is a lot of extra,
> and subjectively ugly code required to make it work.
>
> For example
>
> struct ICannotBeliveItIsNotAnInt {int TheInteger;};   This starts looking
> fine, but to be really useful this needs to implement all the operators.
>  When you finally break down and do that you discover you also have to
> overload everything in <cmath> so you can get std::abs working - users are
> not allowed to extend the std namespace, but we need to break this rule if
> our new type is to work.  Before you propose fixing this, remember that
> Meter::operator* returns a SquareMeter not a meter.
>
> This isn't to say that you cannot expand strong types to fix the above,
> but if you want to do that you need to write your own proposal.
>
>

> So what do you think, did I get a reasonably balanced view of what people
> want and what is painful enough that it is worth considering?  Is it worth
> going farther? This could be turned into a proposal to the EWG, which if
> successful will give everyone who has a specific syntax in mind a direction
> to focus their efforts (either just write the proposal, or come up with a
> strong argument why something everyone thinks we need is worth sacrificing)
>

I think it is the correct approach, focusing on requirements, leaving
syntax and implementation flavors aside for now.

--
You received this message because you are subscribed to 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/391e060e-a7eb-48b0-9646-38d6e8bad6ff%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, August 24, 2018 at 11:46:32 PM UTC+3, H=
enry Miller wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>As a followup to my previous email on named parameters, I&#39;ve collec=
ted as best I can what I think everybody actually wants. =C2=A0This is roun=
d one of requirements - there are some that are in conflict with others. Th=
ere are others than strongly desired by some and strongly opposed by others=
..
<br>
<br>The high level problem statement we want to make writing AND maintainin=
g correct code easier. We can all write correct code today; but there are t=
imes where you either have to write a lot of boilerplate code, write code w=
ith a nasty syntax, or just trust that you got the parameters right because=
 the compiler won&#39;t tell you. This is undesirable, people often write u=
nsafe code just because the alternatives are perceived as too difficult/too=
 ugly.
<br>
<br>goals:
<br>
<br>Have C support the syntax as well. While C++ has a lot of things that C=
 cannot do, interoperability with C is a very strong selling point of C++. =
Thus a proposal that is accepted by WG14 at the same time is desired. =C2=
=A0The C++ version will likely be more complex to handle things in C++ that=
 don&#39;t exist in C, but we would like compatibility for the parts that a=
re common with C.
<br></blockquote><div><br></div><div>What does this mean? Does it mean we a=
re still at &quot;reuse arguments as names&quot;,<a href=3D"http://www.open=
-std.org/Jtc1/sc22/wg21/docs/papers/1991/WG21%201991/X3J16_91-0127%20WG21_N=
0060.pdf"> 1991 style</a>?=C2=A0</div><div>Or, because no ABI break we can =
use macros if we are compiling for C, like we do today with default values:=
<br></div><div><font face=3D"courier new,monospace">#ifdef __cplusplus=C2=
=A0</font></div><div><font face=3D"courier new,monospace">#define FI_DEFAUL=
T(x) =3D x</font><font face=3D"courier new,monospace"><br></font></div><fon=
t face=3D"courier new,monospace"> #else<br> #define FI_DEFAULT(x)</font><br=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Not change ABI. This is controversial. There are some things people wou=
ld like to do that require ABI changes. These are not necessarily bad ideas=
, and may be worth doing. However any proposal that changes ABI will face a=
 larger battle and need stronger justification.
<br>
<br>Do things that cannot be done with the type system. There are many peop=
le who consider c++ a strongly typed language, they consider most proposals=
 a work around for cases where the type system is too weak.=20
<br>
<br>Support future expansion. There are a number of different ideas out the=
re solving semi-disjoint problems. Whatever is done first will not be last.=
 Do our best to not lock out the ideas that other people care about that yo=
u do not care about.
<br>
<br>Existing code needs to still build and work. Of course if the existing =
=C2=A0code is actually wrong and nobody noticed before it would be nice if =
it fails to build; but assuming no bugs, code that builds today needs to bu=
ild tomorrow.
<br>
<br>Work with all existing parts of C++. If sometimes the user gets an erro=
r from what looks like the same syntax of the last function call just becau=
se this one happens to use a dark corner of C++, that is undesired.
<br>
<br>Not sink the Vasa. C++ is already a complex language, all additions wil=
l be looked on with suspicion. The gain needs to justify the costs.=C2=A0<b=
r></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
">
<br>Problems we want to fix. =C2=A0These can be separate proposals, but if =
so they need to allow the others
<br>
<br>The first problem we want to fix is the &quot;why did the previous main=
tainer call that function with those parameters&quot; For example, in pytho=
n syntax AddGraphPoint(x=3DEmployeeId, y=3Dincome) - employeeID is a great =
variable name in general, but it generally isn&#39;t something you normally=
 graph, at least we know it is intentional.
<br>
<br>The second problem is when writing code it is easy to mix up the order =
of identical typed parameters. It would be nice if matrix.GetCell(row, colu=
mn) would tell me if it should be matrix.GetCell(column, row).=20
<br>
<br>The third problem is =C2=A0GUI windows often have a large number of thi=
ngs the user can set on creation, and typically the user will accept the de=
faults for 90%, but it is a different set of parameters where the default i=
s wrong for each user. The current options tend to be inefficient. Sometime=
s the inefficiency is runtime, sometimes it is compile time, and sometimes =
it is human typing/reading time, but all are inefficient.
<br></blockquote><div><br></div><div>Forth problem people want fixed is the=
 named constructor problem. For this we need strong names, but it is valid =
request never the less.</div><div>Just yesterday spend 5 minutes looking ho=
w to create a QMessageBox that shows a warning-styled ready dialog: the con=
structor did not help as it is an all-in-one one, could not find any suitab=
le get* static function,=C2=A0</div><div>so had to look the documentation (=
<i>online</i>, because I don&#39;t have it locally). Turned out there is a =
<font face=3D"courier new,monospace">warning</font> static function. One mi=
ght argue, &quot;it is all clear&quot;, but is it.</div><div><br></div><div=
>Note that that exact problem could not be solved gracefully by types eithe=
r, tags might be ok, but as always they will fight for naming and scoping -=
 where to put them, how to name them to be clear what is going on.</div><di=
v>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>
<br>For the second problem there are some who would like the compiler to re=
order the call to just do the right thing. Defining the rules for when this=
 can happen is probably easy, but I would suggest that we first get the abo=
ve working before thinking about this. Real world experience one a small ch=
ange can drive this latter.
<br>
<br>
<br>There are some who argue that we can already do the first two with the =
existing c++98 code. While technically true, they all sink the Vasa in real=
 world code. Sure the c++ standard is small, but there is a lot of extra, a=
nd subjectively ugly code required to make it work.
<br>
<br>For example
<br>
<br>struct ICannotBeliveItIsNotAnInt {int TheInteger;}; =C2=A0 This starts =
looking fine, but to be really useful this needs to implement all the opera=
tors. =C2=A0When you finally break down and do that you discover you also h=
ave to overload everything in &lt;cmath&gt; so you can get std::abs working=
 - users are not allowed to extend the std namespace, but we need to break =
this rule if our new type is to work. =C2=A0Before you propose fixing this,=
 remember that Meter::operator* returns a SquareMeter not a meter.=20
<br>
<br>This isn&#39;t to say that you cannot expand strong types to fix the ab=
ove, but if you want to do that you need to write your own proposal.
<br><br></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;">So what do you think, did I get a reasonably balanced view of what =
people want and what is painful enough that it is worth considering? =C2=A0=
Is it worth going farther? This could be turned into a proposal to the EWG,=
 which if successful will give everyone who has a specific syntax in mind a=
 direction to focus their efforts (either just write the proposal, or come =
up with a strong argument why something everyone thinks we need is worth sa=
crificing)
<br></blockquote><div><br></div><div>I think it is the correct approach, fo=
cusing on requirements, <span style=3D"display: inline !important; float: n=
one; background-color: transparent; color: rgb(34, 34, 34); font-family: &q=
uot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-sty=
le: normal; font-variant: normal; font-weight: 400; letter-spacing: normal;=
 orphans: 2; text-align: left; text-decoration: none; text-indent: 0px; tex=
t-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; wor=
d-spacing: 0px;">leaving syntax and implementation flavors aside</span> for=
 now.</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/391e060e-a7eb-48b0-9646-38d6e8bad6ff%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/391e060e-a7eb-48b0-9646-38d6e8bad6ff=
%40isocpp.org</a>.<br />

------=_Part_452_33677697.1535185363948--

------=_Part_451_872959918.1535185363947--

.

This is a multi-part message in MIME format.

--_----------=_15352020428947770
Content-Type: text/plain; charset="UTF-8"



On Sat, Aug 25, 2018, at 3:22 AM, mihailnajdenov@gmail.com wrote:
>
>
> On Friday, August 24, 2018 at 11:46:32 PM UTC+3, Henry Miller wrote:
>>
>> As a followup to my previous email on named parameters, I've
>> collected as best I can what I think everybody actually wants.  This
>> is round one of requirements - there are some that are in conflict
>> with others. There are others than strongly desired by some and
>> strongly opposed by others.>>
>> The high level problem statement we want to make writing AND
>> maintaining correct code easier. We can all write correct code today;
>> but there are times where you either have to write a lot of
>> boilerplate code, write code with a nasty syntax, or just trust that
>> you got the parameters right because the compiler won't tell you.
>> This is undesirable, people often write unsafe code just because the
>> alternatives are perceived as too difficult/too ugly.>>
>> goals:
>>
>> Have C support the syntax as well. While C++ has a lot of things that
>> C cannot do, interoperability with C is a very strong selling point
>> of C++. Thus a proposal that is accepted by WG14 at the same time is
>> desired.  The C++ version will likely be more complex to handle
>> things in C++ that don't exist in C, but we would like compatibility
>> for the parts that are common with C.>
> What does this mean? Does it mean we are still at "reuse arguments as
> names", 1991 style[1]?> Or, because no ABI break we can use macros if we are compiling for C,
> like we do today with default values:> #ifdef __cplusplus
> #define FI_DEFAULT(x) = x
> #else
>  #define FI_DEFAULT(x)
>

C has the same problem we have. Consider this c function
Manipulate2dArray(int array*, int numRows, int numColumns);

I no longer remember what the typical way to pass a 2 dimensional array
of arbitrary size is, but in some way they need to know rows and
columns. Woe to the programmer who mixes them up (it won't crash but it
can give incorrect results). We would like to be compatible with them
for these functions if they will accept any proposal.

>>
>> Not change ABI. This is controversial. There are some things people
>> would like to do that require ABI changes. These are not necessarily
>> bad ideas, and may be worth doing. However any proposal that changes
>> ABI will face a larger battle and need stronger justification.>>
>> Do things that cannot be done with the type system. There are many
>> people who consider c++ a strongly typed language, they consider most
>> proposals a work around for cases where the type system is too weak.>>
>> Support future expansion. There are a number of different ideas out
>> there solving semi-disjoint problems. Whatever is done first will not
>> be last. Do our best to not lock out the ideas that other people care
>> about that you do not care about.>>
>> Existing code needs to still build and work. Of course if the
>> existing  code is actually wrong and nobody noticed before it would
>> be nice if it fails to build; but assuming no bugs, code that builds
>> today needs to build tomorrow.>>
>> Work with all existing parts of C++. If sometimes the user gets an
>> error from what looks like the same syntax of the last function call
>> just because this one happens to use a dark corner of C++, that is
>> undesired.>>
>> Not sink the Vasa. C++ is already a complex language, all
>> additions will be looked on with suspicion. The gain needs to
>> justify the costs.>
>>
>> Problems we want to fix.  These can be separate proposals, but if so
>> they need to allow the others>>
>> The first problem we want to fix is the "why did the previous
>> maintainer call that function with those parameters" For example, in
>> python syntax AddGraphPoint(x=EmployeeId, y=income) - employeeID is a
>> great variable name in general, but it generally isn't something you
>> normally graph, at least we know it is intentional.>>
>> The second problem is when writing code it is easy to mix up the
>> order of identical typed parameters. It would be nice if
>> matrix.GetCell(row, column) would tell me if it should be
>> matrix.GetCell(column, row).>>
>> The third problem is  GUI windows often have a large number of things
>> the user can set on creation, and typically the user will accept the
>> defaults for 90%, but it is a different set of parameters where the
>> default is wrong for each user. The current options tend to be
>> inefficient. Sometimes the inefficiency is runtime, sometimes it is
>> compile time, and sometimes it is human typing/reading time, but all
>> are inefficient.>
> Forth problem people want fixed is the named constructor problem. For
> this we need strong names, but it is valid request never the less.> Just yesterday spend 5 minutes looking how to create a QMessageBox
> that shows a warning-styled ready dialog: the constructor did not help
> as it is an all-in-one one, could not find any suitable get* static
> function,> so had to look the documentation (*online*, because I don't have it
> locally). Turned out there is a warning static function. One might
> argue, "it is all clear", but is it.>
> Note that that exact problem could not be solved gracefully by types
> either, tags might be ok, but as always they will fight for naming and
> scoping - where to put them, how to name them to be clear what is
> going on.>
I don't understand the problem. The static function controls lifetime
and returns a value, both things that a constructor cannot do.
What is the problem that cannot be solved with an enum? Enum class
messagetype { about, critical, information, warning}
Or with types
MessageBox(warningText("ut oh"))

>>
>>
>> For the second problem there are some who would like the compiler to
>> reorder the call to just do the right thing. Defining the rules for
>> when this can happen is probably easy, but I would suggest that we
>> first get the above working before thinking about this. Real world
>> experience one a small change can drive this latter.>>
>>
>> There are some who argue that we can already do the first two with
>> the existing c++98 code. While technically true, they all sink the
>> Vasa in real world code. Sure the c++ standard is small, but there is
>> a lot of extra, and subjectively ugly code required to make it work.>>
>> For example
>>
>> struct ICannotBeliveItIsNotAnInt {int TheInteger;};   This starts
>> looking fine, but to be really useful this needs to implement all the
>> operators.  When you finally break down and do that you discover you
>> also have to overload everything in <cmath> so you can get std::abs
>> working - users are not allowed to extend the std namespace, but we
>> need to break this rule if our new type is to work.  Before you
>> propose fixing this, remember that Meter::operator* returns a
>> SquareMeter not a meter.>>
>> This isn't to say that you cannot expand strong types to fix the
>> above, but if you want to do that you need to write your own
>> proposal.>
>> So what do you think, did I get a reasonably balanced view of what
>> people want and what is painful enough that it is worth considering?
>> Is it worth going farther? This could be turned into a proposal to
>> the EWG, which if successful will give everyone who has a specific
>> syntax in mind a direction to focus their efforts (either just write
>> the proposal, or come up with a strong argument why something
>> everyone thinks we need is worth sacrificing)>
> I think it is the correct approach, focusing on requirements, leaving
> syntax and implementation flavors aside for now.>


> --
>  You received this message because you are subscribed to 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/391e060e-a7eb-48b0-9646-38d6e8bad6ff%40isocpp.org[2].
Links:

  1. http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/1991/WG21%201991/X3J16_91-0127%20WG21_N0060.pdf
  2. https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/391e060e-a7eb-48b0-9646-38d6e8bad6ff%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/1535202042.894777.1485823136.142315CB%40webmail.messagingengine.com.

--_----------=_15352020428947770
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;"><br></div>
<div><br></div>
<div>On Sat, Aug 25, 2018, at 3:22 AM, <a href=3D"mailto:mihailnajdenov@gma=
il.com">mihailnajdenov@gmail.com</a> wrote:<br></div>
<blockquote type=3D"cite"><div dir=3D"ltr"><div style=3D"font-family:Arial;=
"><br></div>
<div style=3D"font-family:Arial;"><br></div>
<div style=3D"font-family:Arial;">On Friday, August 24, 2018 at 11:46:32 PM=
 UTC+3, 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;">As a followup to my previous email on nam=
ed parameters, I've collected as best I can what I think everybody actually=
 wants. &nbsp;This is round one of requirements - there are some that are i=
n conflict with others. There are others than strongly desired by some and =
strongly opposed by others. <br></div>
<div style=3D"font-family:Arial;"> <br></div>
<div style=3D"font-family:Arial;">The high level problem statement we want =
to make writing AND maintaining correct code easier. We can all write corre=
ct code today; but there are times where you either have to write a lot of =
boilerplate code, write code with a nasty syntax, or just trust that you go=
t the parameters right because the compiler won't tell you. This is undesir=
able, people often write unsafe code just because the alternatives are perc=
eived as too difficult/too ugly. <br></div>
<div style=3D"font-family:Arial;"> <br></div>
<div style=3D"font-family:Arial;">goals: <br></div>
<div style=3D"font-family:Arial;"> <br></div>
<div style=3D"font-family:Arial;">Have C support the syntax as well. While =
C++ has a lot of things that C cannot do, interoperability with C is a very=
 strong selling point of C++. Thus a proposal that is accepted by WG14 at t=
he same time is desired. &nbsp;The C++ version will likely be more complex =
to handle things in C++ that don't exist in C, but we would like compatibil=
ity for the parts that are common with C. <br></div>
</blockquote><div><br></div>
<div>What does this mean? Does it mean we are still at "reuse arguments as =
names",<a href=3D"http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/1991/W=
G21%201991/X3J16_91-0127%20WG21_N0060.pdf"> 1991 style</a>?&nbsp;<br></div>
<div>Or, because no ABI break we can use macros if we are compiling for C, =
like we do today with default values:<br></div>
<div><span class=3D"font" style=3D"font-family:&quot;courier new&quot;, mon=
ospace">#ifdef __cplusplus&nbsp;</span><br></div>
<div><span class=3D"font" style=3D"font-family:&quot;courier new&quot;, mon=
ospace">#define FI_DEFAULT(x) =3D x</span><span class=3D"font" style=3D"fon=
t-family:&quot;courier new&quot;, monospace"></span><br></div>
<div style=3D"font-family:Arial;"><span class=3D"font" style=3D"font-family=
:&quot;courier new&quot;, monospace">#else<br> #define FI_DEFAULT(x)</span>=
</div>
<div>&nbsp;<br></div>
</div>
</blockquote><div style=3D"font-family:Arial;"><br></div>
<div style=3D"font-family:Arial;">C has the same problem we have. Consider =
this c function&nbsp;<br></div>
<div style=3D"font-family:Arial;">Manipulate2dArray(int array*, int numRows=
, int numColumns);&nbsp;<br></div>
<div style=3D"font-family:Arial;"><br></div>
<div style=3D"font-family:Arial;">I no longer remember what the typical way=
 to pass a 2 dimensional array of arbitrary size is, but in some way they n=
eed to know rows and columns. Woe to the programmer who mixes them up (it w=
on't crash but it can give incorrect results). We would like to be compatib=
le with them for these functions if they will accept any proposal.&nbsp;</d=
iv>
<div style=3D"font-family:Arial;"><br></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;"><=
br></div>
<div style=3D"font-family:Arial;">Not change ABI. This is controversial. Th=
ere are some things people would like to do that require ABI changes. These=
 are not necessarily bad ideas, and may be worth doing. However any proposa=
l that changes ABI will face a larger battle and need stronger justificatio=
n. <br></div>
<div style=3D"font-family:Arial;"> <br></div>
<div style=3D"font-family:Arial;">Do things that cannot be done with the ty=
pe system. There are many people who consider c++ a strongly typed language=
, they consider most proposals a work around for cases where the type syste=
m is too weak. <br></div>
<div style=3D"font-family:Arial;"> <br></div>
<div style=3D"font-family:Arial;">Support future expansion. There are a num=
ber of different ideas out there solving semi-disjoint problems. Whatever i=
s done first will not be last. Do our best to not lock out the ideas that o=
ther people care about that you do not care about. <br></div>
<div style=3D"font-family:Arial;"> <br></div>
<div style=3D"font-family:Arial;">Existing code needs to still build and wo=
rk. Of course if the existing &nbsp;code is actually wrong and nobody notic=
ed before it would be nice if it fails to build; but assuming no bugs, code=
 that builds today needs to build tomorrow. <br></div>
<div style=3D"font-family:Arial;"> <br></div>
<div style=3D"font-family:Arial;">Work with all existing parts of C++. If s=
ometimes the user gets an error from what looks like the same syntax of the=
 last function call just because this one happens to use a dark corner of C=
++, that is undesired. <br></div>
<div style=3D"font-family:Arial;"> <br></div>
<div style=3D"font-family:Arial;">Not sink the Vasa. C++ is already a compl=
ex language, all additions will be looked on with suspicion. The gain needs=
 to justify the costs.&nbsp;<br></div>
</blockquote><div>&nbsp;<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;">Problems we want to fix. &nbsp;These can =
be separate proposals, but if so they need to allow the others <br></div>
<div style=3D"font-family:Arial;"> <br></div>
<div style=3D"font-family:Arial;">The first problem we want to fix is the "=
why did the previous maintainer call that function with those parameters" F=
or example, in python syntax AddGraphPoint(x=3DEmployeeId, y=3Dincome) - em=
ployeeID is a great variable name in general, but it generally isn't someth=
ing you normally graph, at least we know it is intentional. <br></div>
<div style=3D"font-family:Arial;"> <br></div>
<div style=3D"font-family:Arial;">The second problem is when writing code i=
t is easy to mix up the order of identical typed parameters. It would be ni=
ce if matrix.GetCell(row, column) would tell me if it should be matrix.GetC=
ell(column, row). <br></div>
<div style=3D"font-family:Arial;"> <br></div>
<div style=3D"font-family:Arial;">The third problem is &nbsp;GUI windows of=
ten have a large number of things the user can set on creation, and typical=
ly the user will accept the defaults for 90%, but it is a different set of =
parameters where the default is wrong for each user. The current options te=
nd to be inefficient. Sometimes the inefficiency is runtime, sometimes it i=
s compile time, and sometimes it is human typing/reading time, but all are =
inefficient. <br></div>
</blockquote><div><br></div>
<div>Forth problem people want fixed is the named constructor problem. For =
this we need strong names, but it is valid request never the less.</div>
</div>
</blockquote><blockquote type=3D"cite"><div dir=3D"ltr"><div>Just yesterday=
 spend 5 minutes looking how to create a QMessageBox that shows a warning-s=
tyled ready dialog: the constructor did not help as it is an all-in-one one=
, could not find any suitable get* static function,&nbsp;<br></div>
<div>so had to look the documentation (<i>online</i>, because I don't have =
it locally). Turned out there is a <span class=3D"font" style=3D"font-famil=
y:&quot;courier new&quot;, monospace">warning</span> static function. One m=
ight argue, "it is all clear", but is it.<br></div>
<div><br></div>
<div>Note that that exact problem could not be solved gracefully by types e=
ither, tags might be ok, but as always they will fight for naming and scopi=
ng - where to put them, how to name them to be clear what is going on.<br><=
/div>
<div>&nbsp;<br></div>
</div>
</blockquote><div style=3D"font-family:Arial;">I don't understand the probl=
em. The static function controls lifetime and returns a value, both things =
that a constructor cannot do.&nbsp;<br></div>
<div style=3D"font-family:Arial;"><br></div>
<div style=3D"font-family:Arial;">What is the problem that cannot be solved=
 with an enum?&nbsp;<span style=3D"font-size: 17.145px; letter-spacing: 0.1=
px;">Enum class messagetype { about, critical, information, warning}&nbsp;<=
/span><br></div>
<div style=3D"font-family:Arial;"><br></div>
<div style=3D"font-family:Arial;"><span style=3D"font-size: 17.145px; lette=
r-spacing: 0.1px;">Or with types </span><br></div>
<div style=3D"font-family:Arial;"><span style=3D"font-size: 17.145px; lette=
r-spacing: 0.1px;">MessageBox(warningText("ut oh")) </span><br></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;"><=
br></div>
<div style=3D"font-family:Arial;"><br></div>
<div style=3D"font-family:Arial;">For the second problem there are some who=
 would like the compiler to reorder the call to just do the right thing. De=
fining the rules for when this can happen is probably easy, but I would sug=
gest that we first get the above working before thinking about this. Real w=
orld experience one a small change can drive this latter. <br></div>
<div style=3D"font-family:Arial;"> <br></div>
<div style=3D"font-family:Arial;"> <br></div>
<div style=3D"font-family:Arial;">There are some who argue that we can alre=
ady do the first two with the existing c++98 code. While technically true, =
they all sink the Vasa in real world code. Sure the c++ standard is small, =
but there is a lot of extra, and subjectively ugly code required to make it=
 work. <br></div>
<div style=3D"font-family:Arial;"> <br></div>
<div style=3D"font-family:Arial;">For example <br></div>
<div style=3D"font-family:Arial;"> <br></div>
<div style=3D"font-family:Arial;">struct ICannotBeliveItIsNotAnInt {int The=
Integer;}; &nbsp; This starts looking fine, but to be really useful this ne=
eds to implement all the operators. &nbsp;When you finally break down and d=
o that you discover you also have to overload everything in &lt;cmath&gt; s=
o you can get std::abs working - users are not allowed to extend the std na=
mespace, but we need to break this rule if our new type is to work. &nbsp;B=
efore you propose fixing this, remember that Meter::operator* returns a Squ=
areMeter not a meter. <br></div>
<div style=3D"font-family:Arial;"> <br></div>
<div style=3D"font-family:Arial;">This isn't to say that you cannot expand =
strong types to fix the above, but if you want to do that you need to write=
 your own proposal. <br></div>
</blockquote><div>&nbsp;<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;">So =
what do you think, did I get a reasonably balanced view of what people want=
 and what is painful enough that it is worth considering? &nbsp;Is it worth=
 going farther? This could be turned into a proposal to the EWG, which if s=
uccessful will give everyone who has a specific syntax in mind a direction =
to focus their efforts (either just write the proposal, or come up with a s=
trong argument why something everyone thinks we need is worth sacrificing) =
<br></blockquote><div><br></div>
<div>I think it is the correct approach, focusing on requirements, <span cl=
ass=3D"highlight" style=3D"background-color:transparent"><span class=3D"col=
our" style=3D"color:rgb(34, 34, 34)"><span class=3D"font" style=3D"font-fam=
ily:Arial, Helvetica, sans-serif"><span class=3D"size" style=3D"font-size:1=
3px">leaving syntax and implementation flavors aside</span></span></span></=
span> for now.<br></div>
</div>
<p><br></p><div style=3D"font-family:Arial;">--<br></div>
<div style=3D"font-family:Arial;"> You received this message because you ar=
e subscribed to the Google Groups "ISO C++ Standard - Future Proposals" gro=
up.<br></div>
<div style=3D"font-family:Arial;"> To unsubscribe from this group and stop =
receiving emails from it, send an email to <a href=3D"mailto:std-proposals+=
unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br></div>
<div style=3D"font-family:Arial;"> To post to this group, send email to <a =
href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br><=
/div>
<div style=3D"font-family:Arial;"> To view this discussion on the web visit=
 <a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/39=
1e060e-a7eb-48b0-9646-38d6e8bad6ff%40isocpp.org?utm_medium=3Demail&amp;utm_=
source=3Dfooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposa=
ls/391e060e-a7eb-48b0-9646-38d6e8bad6ff%40isocpp.org</a>.<br></div>
</blockquote></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/1535202042.894777.1485823136.142315CB=
%40webmail.messagingengine.com?utm_medium=3Demail&utm_source=3Dfooter">http=
s://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1535202042.894777.=
1485823136.142315CB%40webmail.messagingengine.com</a>.<br />

--_----------=_15352020428947770--


.

------=_Part_533_96660702.1535205219827
Content-Type: multipart/alternative;
 boundary="----=_Part_534_355403563.1535205219828"

------=_Part_534_355403563.1535205219828
Content-Type: text/plain; charset="UTF-8"



On Saturday, August 25, 2018 at 4:00:46 PM UTC+3, Henry Miller wrote:
>
>
>
> On Sat, Aug 25, 2018, at 3:22 AM, mihailn...@gmail.com <javascript:>
> wrote:
>
>
>
> On Friday, August 24, 2018 at 11:46:32 PM UTC+3, Henry Miller wrote:
>
>
> As a followup to my previous email on named parameters, I've collected as
> best I can what I think everybody actually wants.  This is round one of
> requirements - there are some that are in conflict with others. There are
> others than strongly desired by some and strongly opposed by others.
>
> The high level problem statement we want to make writing AND maintaining
> correct code easier. We can all write correct code today; but there are
> times where you either have to write a lot of boilerplate code, write code
> with a nasty syntax, or just trust that you got the parameters right
> because the compiler won't tell you. This is undesirable, people often
> write unsafe code just because the alternatives are perceived as too
> difficult/too ugly.
>
> goals:
>
>

>
> Have C support the syntax as well. While C++ has a lot of things that C
> cannot do, interoperability with C is a very strong selling point of C++.
> Thus a proposal that is accepted by WG14 at the same time is desired.  The
> C++ version will likely be more complex to handle things in C++ that don't
> exist in C, but we would like compatibility for the parts that are common
> with C.
>
>
> What does this mean? Does it mean we are still at "reuse arguments as
> names", 1991 style
> <http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/1991/WG21%201991/X3J16_91-0127%20WG21_N0060.pdf>
> ?
> Or, because no ABI break we can use macros if we are compiling for C, like
> we do today with default values:
> #ifdef __cplusplus
> #define FI_DEFAULT(x) = x
> #else
> #define FI_DEFAULT(x)
>
>
>
> C has the same problem we have. Consider this c function
> Manipulate2dArray(int array*, int numRows, int numColumns);
>
> I no longer remember what the typical way to pass a 2 dimensional array of
> arbitrary size is, but in some way they need to know rows and columns. Woe
> to the programmer who mixes them up (it won't crash but it can give
> incorrect results). We would like to be compatible with them for these
> functions if they will accept any proposal.
>

If we are talking just for C++, one can always wrap the call, using better
types and/or names.
The requirement to work with C is a feature creep, that ultimately does not
suit many (library authors), and, as said, has already failed.


>
>
>
> Not change ABI. This is controversial. There are some things people would
> like to do that require ABI changes. These are not necessarily bad ideas,
> and may be worth doing. However any proposal that changes ABI will face a
> larger battle and need stronger justification.
>
> Do things that cannot be done with the type system. There are many people
> who consider c++ a strongly typed language, they consider most proposals a
> work around for cases where the type system is too weak.
>
> Support future expansion. There are a number of different ideas out there
> solving semi-disjoint problems. Whatever is done first will not be last. Do
> our best to not lock out the ideas that other people care about that you do
> not care about.
>
> Existing code needs to still build and work. Of course if the existing
>  code is actually wrong and nobody noticed before it would be nice if it
> fails to build; but assuming no bugs, code that builds today needs to build
> tomorrow.
>
> Work with all existing parts of C++. If sometimes the user gets an error
> from what looks like the same syntax of the last function call just because
> this one happens to use a dark corner of C++, that is undesired.
>
> Not sink the Vasa. C++ is already a complex language, all additions will
> be looked on with suspicion. The gain needs to justify the costs.
>
>
>
>
> Problems we want to fix.  These can be separate proposals, but if so they
> need to allow the others
>
> The first problem we want to fix is the "why did the previous maintainer
> call that function with those parameters" For example, in python syntax
> AddGraphPoint(x=EmployeeId, y=income) - employeeID is a great variable name
> in general, but it generally isn't something you normally graph, at least
> we know it is intentional.
>
> The second problem is when writing code it is easy to mix up the order of
> identical typed parameters. It would be nice if matrix.GetCell(row, column)
> would tell me if it should be matrix.GetCell(column, row).
>
> The third problem is  GUI windows often have a large number of things the
> user can set on creation, and typically the user will accept the defaults
> for 90%, but it is a different set of parameters where the default is wrong
> for each user. The current options tend to be inefficient. Sometimes the
> inefficiency is runtime, sometimes it is compile time, and sometimes it is
> human typing/reading time, but all are inefficient.
>
>
> Forth problem people want fixed is the named constructor problem. For this
> we need strong names, but it is valid request never the less.
>
> Just yesterday spend 5 minutes looking how to create a QMessageBox that
> shows a warning-styled ready dialog: the constructor did not help as it is
> an all-in-one one, could not find any suitable get* static function,
> so had to look the documentation (*online*, because I don't have it
> locally). Turned out there is a warning static function. One might argue,
> "it is all clear", but is it.
>
> Note that that exact problem could not be solved gracefully by types
> either, tags might be ok, but as always they will fight for naming and
> scoping - where to put them, how to name them to be clear what is going on.
>
>
> I don't understand the problem. The static function controls lifetime and
> returns a value, both things that a constructor cannot do.
>
> What is the problem that cannot be solved with an enum? Enum class
> messagetype { about, critical, information, warning}
>
> Or with types
> MessageBox(warningText("ut oh"))
>

With enums the implementation is affected considerably - one will have to
use switch and dispatch to helper functions to do construction.
Also, not all types of ready-made dialogs have the same params - 'about'
does not take buttons.

Types don't scale all that well. Also, they will untimely be confusing to
the user when he sees them, they will have to be documented as "only here
because overloading, nothings special, really".
That is the problem with introducing types with no meaning of its own and
probably that is why it is not a common practice.

None of the solutions are bad, honestly, but they are only as good as a
workaround goes, and quite a few people want that improved with names.


>
>
>
>
> For the second problem there are some who would like the compiler to
> reorder the call to just do the right thing. Defining the rules for when
> this can happen is probably easy, but I would suggest that we first get the
> above working before thinking about this. Real world experience one a small
> change can drive this latter.
>
>
> There are some who argue that we can already do the first two with the
> existing c++98 code. While technically true, they all sink the Vasa in real
> world code. Sure the c++ standard is small, but there is a lot of extra,
> and subjectively ugly code required to make it work.
>
> For example
>
> struct ICannotBeliveItIsNotAnInt {int TheInteger;};   This starts looking
> fine, but to be really useful this needs to implement all the operators.
>  When you finally break down and do that you discover you also have to
> overload everything in <cmath> so you can get std::abs working - users are
> not allowed to extend the std namespace, but we need to break this rule if
> our new type is to work.  Before you propose fixing this, remember that
> Meter::operator* returns a SquareMeter not a meter.
>
> This isn't to say that you cannot expand strong types to fix the above,
> but if you want to do that you need to write your own proposal.
>
>
>
> So what do you think, did I get a reasonably balanced view of what people
> want and what is painful enough that it is worth considering?  Is it worth
> going farther? This could be turned into a proposal to the EWG, which if
> successful will give everyone who has a specific syntax in mind a direction
> to focus their efforts (either just write the proposal, or come up with a
> strong argument why something everyone thinks we need is worth sacrificing)
>
>
> I think it is the correct approach, focusing on requirements, leaving
> syntax and implementation flavors aside for now.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/391e060e-a7eb-48b0-9646-38d6e8bad6ff%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/391e060e-a7eb-48b0-9646-38d6e8bad6ff%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/57934e52-1e0b-4fdb-9cb9-894eb3c7cc07%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Saturday, August 25, 2018 at 4:00:46 PM UTC+3, =
Henry Miller wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">





<div><div style=3D"font-family:Arial"><br></div>
<div><br></div>
<div>On Sat, Aug 25, 2018, at 3:22 AM, <a onmousedown=3D"this.href=3D&#39;j=
avascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;=
return true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-o=
bfuscated-mailto=3D"wheWgflVAQAJ">mihailn...@gmail.com</a> wrote:<br></div>
<blockquote type=3D"cite"><div dir=3D"ltr"><div style=3D"font-family:Arial"=
><br></div>
<div style=3D"font-family:Arial"><br></div>
<div style=3D"font-family:Arial">On Friday, August 24, 2018 at 11:46:32 PM =
UTC+3, Henry Miller wrote:<br></div>
<blockquote style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;marg=
in-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-col=
or:rgb(204,204,204);padding-left:1ex"><div style=3D"font-family:Arial"><br>=
</div>
<div style=3D"font-family:Arial">As a followup to my previous email on name=
d parameters, I&#39;ve collected as best I can what I think everybody actua=
lly wants. =C2=A0This is round one of requirements - there are some that ar=
e in conflict with others. There are others than strongly desired by some a=
nd strongly opposed by others. <br></div>
<div style=3D"font-family:Arial"> <br></div>
<div style=3D"font-family:Arial">The high level problem statement we want t=
o make writing AND maintaining correct code easier. We can all write correc=
t code today; but there are times where you either have to write a lot of b=
oilerplate code, write code with a nasty syntax, or just trust that you got=
 the parameters right because the compiler won&#39;t tell you. This is unde=
sirable, people often write unsafe code just because the alternatives are p=
erceived as too difficult/too ugly. <br></div>
<div style=3D"font-family:Arial"> <br></div>
<div style=3D"font-family:Arial">goals: <br></div></blockquote></div></bloc=
kquote></div></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"><div><blockquote type=3D"cite"><div dir=3D"ltr"><blockquote st=
yle=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;=
border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204=
,204);padding-left:1ex"><div style=3D"font-family:Arial"></div>
<div style=3D"font-family:Arial"> <br></div>
<div style=3D"font-family:Arial">Have C support the syntax as well. While C=
++ has a lot of things that C cannot do, interoperability with C is a very =
strong selling point of C++. Thus a proposal that is accepted by WG14 at th=
e same time is desired. =C2=A0The C++ version will likely be more complex t=
o handle things in C++ that don&#39;t exist in C, but we would like compati=
bility for the parts that are common with C. <br></div>
</blockquote><div><br></div>
<div>What does this mean? Does it mean we are still at &quot;reuse argument=
s as names&quot;,<a onmousedown=3D"this.href=3D&#39;http://www.google.com/u=
rl?q\x3dhttp%3A%2F%2Fwww.open-std.org%2FJtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%=
2F1991%2FWG21%25201991%2FX3J16_91-0127%2520WG21_N0060.pdf\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNEpWKkbSG2QYbub9tpCDH7cwTe-cg&#39;;return true;" oncl=
ick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.ope=
n-std.org%2FJtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F1991%2FWG21%25201991%2FX3J=
16_91-0127%2520WG21_N0060.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEpWKk=
bSG2QYbub9tpCDH7cwTe-cg&#39;;return true;" href=3D"http://www.open-std.org/=
Jtc1/sc22/wg21/docs/papers/1991/WG21%201991/X3J16_91-0127%20WG21_N0060.pdf"=
 target=3D"_blank" rel=3D"nofollow"> 1991 style</a>?=C2=A0<br></div>
<div>Or, because no ABI break we can use macros if we are compiling for C, =
like we do today with default values:<br></div>
<div><span style=3D"font-family:&quot;courier new&quot;,monospace">#ifdef _=
_cplusplus=C2=A0</span><br></div>
<div><span style=3D"font-family:&quot;courier new&quot;,monospace">#define =
FI_DEFAULT(x) =3D x</span><span style=3D"font-family:&quot;courier new&quot=
;,monospace"></span><br></div>
<div style=3D"font-family:Arial"><span style=3D"font-family:&quot;courier n=
ew&quot;,monospace">#else<br> #define FI_DEFAULT(x)</span></div>
<div>=C2=A0<br></div>
</div>
</blockquote><div style=3D"font-family:Arial"><br></div>
<div style=3D"font-family:Arial">C has the same problem we have. Consider t=
his c function=C2=A0<br></div>
<div style=3D"font-family:Arial">Manipulate2dArray(int array*, int numRows,=
 int numColumns);=C2=A0<br></div>
<div style=3D"font-family:Arial"><br></div>
<div style=3D"font-family:Arial">I no longer remember what the typical way =
to pass a 2 dimensional array of arbitrary size is, but in some way they ne=
ed to know rows and columns. Woe to the programmer who mixes them up (it wo=
n&#39;t crash but it can give incorrect results). We would like to be compa=
tible with them for these functions if they will accept any proposal.=C2=A0=
</div></div></blockquote><div><br></div><div>If we are talking just for C++=
, one can always wrap the call, using better types and/or names.=C2=A0</div=
><div>The requirement to work with C is a feature creep, that ultimately do=
es not suit many (library authors), and, as said, has already failed.=C2=A0=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>
<div style=3D"font-family:Arial"><br></div>
<div style=3D"font-family:Arial"><br></div>
<blockquote type=3D"cite"><div dir=3D"ltr"><blockquote style=3D"margin-top:=
0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;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">Not change ABI. This is controversial. The=
re are some things people would like to do that require ABI changes. These =
are not necessarily bad ideas, and may be worth doing. However any proposal=
 that changes ABI will face a larger battle and need stronger justification=
.. <br></div>
<div style=3D"font-family:Arial"> <br></div>
<div style=3D"font-family:Arial">Do things that cannot be done with the typ=
e system. There are many people who consider c++ a strongly typed language,=
 they consider most proposals a work around for cases where the type system=
 is too weak. <br></div>
<div style=3D"font-family:Arial"> <br></div>
<div style=3D"font-family:Arial">Support future expansion. There are a numb=
er of different ideas out there solving semi-disjoint problems. Whatever is=
 done first will not be last. Do our best to not lock out the ideas that ot=
her people care about that you do not care about. <br></div>
<div style=3D"font-family:Arial"> <br></div>
<div style=3D"font-family:Arial">Existing code needs to still build and wor=
k. Of course if the existing =C2=A0code is actually wrong and nobody notice=
d before it would be nice if it fails to build; but assuming no bugs, code =
that builds today needs to build tomorrow. <br></div>
<div style=3D"font-family:Arial"> <br></div>
<div style=3D"font-family:Arial">Work with all existing parts of C++. If so=
metimes the user gets an error from what looks like the same syntax of the =
last function call just because this one happens to use a dark corner of C+=
+, that is undesired. <br></div>
<div style=3D"font-family:Arial"> <br></div>
<div style=3D"font-family:Arial">Not sink the Vasa. C++ is already a comple=
x language, all additions will be looked on with suspicion. The gain needs =
to justify the costs.=C2=A0<br></div>
</blockquote><div>=C2=A0<br></div>
<blockquote style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;marg=
in-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-col=
or:rgb(204,204,204);padding-left:1ex"><div style=3D"font-family:Arial"><br>=
</div>
<div style=3D"font-family:Arial">Problems we want to fix. =C2=A0These can b=
e separate proposals, but if so they need to allow the others <br></div>
<div style=3D"font-family:Arial"> <br></div>
<div style=3D"font-family:Arial">The first problem we want to fix is the &q=
uot;why did the previous maintainer call that function with those parameter=
s&quot; For example, in python syntax AddGraphPoint(x=3DEmployeeId, y=3Dinc=
ome) - employeeID is a great variable name in general, but it generally isn=
&#39;t something you normally graph, at least we know it is intentional. <b=
r></div>
<div style=3D"font-family:Arial"> <br></div>
<div style=3D"font-family:Arial">The second problem is when writing code it=
 is easy to mix up the order of identical typed parameters. It would be nic=
e if matrix.GetCell(row, column) would tell me if it should be matrix.GetCe=
ll(column, row). <br></div>
<div style=3D"font-family:Arial"> <br></div>
<div style=3D"font-family:Arial">The third problem is =C2=A0GUI windows oft=
en have a large number of things the user can set on creation, and typicall=
y the user will accept the defaults for 90%, but it is a different set of p=
arameters where the default is wrong for each user. The current options ten=
d to be inefficient. Sometimes the inefficiency is runtime, sometimes it is=
 compile time, and sometimes it is human typing/reading time, but all are i=
nefficient. <br></div>
</blockquote><div><br></div>
<div>Forth problem people want fixed is the named constructor problem. For =
this we need strong names, but it is valid request never the less.</div>
</div>
</blockquote><blockquote type=3D"cite"><div dir=3D"ltr"><div>Just yesterday=
 spend 5 minutes looking how to create a QMessageBox that shows a warning-s=
tyled ready dialog: the constructor did not help as it is an all-in-one one=
, could not find any suitable get* static function,=C2=A0<br></div>
<div>so had to look the documentation (<i>online</i>, because I don&#39;t h=
ave it locally). Turned out there is a <span style=3D"font-family:&quot;cou=
rier new&quot;,monospace">warning</span> static function. One might argue, =
&quot;it is all clear&quot;, but is it.<br></div>
<div><br></div>
<div>Note that that exact problem could not be solved gracefully by types e=
ither, tags might be ok, but as always they will fight for naming and scopi=
ng - where to put them, how to name them to be clear what is going on.<br><=
/div>
<div>=C2=A0<br></div>
</div>
</blockquote><div style=3D"font-family:Arial">I don&#39;t understand the pr=
oblem. The static function controls lifetime and returns a value, both thin=
gs that a constructor cannot do.=C2=A0<br></div>
<div style=3D"font-family:Arial"><br></div>
<div style=3D"font-family:Arial">What is the problem that cannot be solved =
with an enum?=C2=A0<span style=3D"font-size:17.145px;letter-spacing:0.1px">=
Enum class messagetype { about, critical, information, warning}=C2=A0</span=
><br></div>
<div style=3D"font-family:Arial"><br></div>
<div style=3D"font-family:Arial"><span style=3D"font-size:17.145px;letter-s=
pacing:0.1px">Or with types </span><br></div>
<div style=3D"font-family:Arial"><span style=3D"font-size:17.145px;letter-s=
pacing:0.1px">MessageBox(warningText(&quot;ut oh&quot;)) </span></div></div=
></blockquote><div><br></div><div>With enums the implementation is affected=
 considerably - one will have to use switch and dispatch to helper function=
s to do construction.=C2=A0</div><div>Also, not all types of ready-made dia=
logs have the same params - &#39;about&#39; does not take buttons.</div><di=
v><br></div><div>Types don&#39;t scale all that well. Also, they will untim=
ely be confusing to the user when he sees them, they will have to be docume=
nted as &quot;only here because overloading, nothings special, really&quot;=
..</div><div>That is the problem with introducing types with no meaning of i=
ts own and probably that is why it is not a common practice.=C2=A0</div><di=
v><br></div><div>None of the solutions are bad, honestly, but they are only=
 as good as a workaround goes, and quite a few people want that improved wi=
th names.=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div><div style=3D"font-family:Arial"><br></div>
<div style=3D"font-family:Arial"><br></div>
<blockquote type=3D"cite"><div dir=3D"ltr"><blockquote style=3D"margin-top:=
0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;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"><br></div>
<div style=3D"font-family:Arial">For the second problem there are some who =
would like the compiler to reorder the call to just do the right thing. Def=
ining the rules for when this can happen is probably easy, but I would sugg=
est that we first get the above working before thinking about this. Real wo=
rld experience one a small change can drive this latter. <br></div>
<div style=3D"font-family:Arial"> <br></div>
<div style=3D"font-family:Arial"> <br></div>
<div style=3D"font-family:Arial">There are some who argue that we can alrea=
dy do the first two with the existing c++98 code. While technically true, t=
hey all sink the Vasa in real world code. Sure the c++ standard is small, b=
ut there is a lot of extra, and subjectively ugly code required to make it =
work. <br></div>
<div style=3D"font-family:Arial"> <br></div>
<div style=3D"font-family:Arial">For example <br></div>
<div style=3D"font-family:Arial"> <br></div>
<div style=3D"font-family:Arial">struct ICannotBeliveItIsNotAnInt {int TheI=
nteger;}; =C2=A0 This starts looking fine, but to be really useful this nee=
ds to implement all the operators. =C2=A0When you finally break down and do=
 that you discover you also have to overload everything in &lt;cmath&gt; so=
 you can get std::abs working - users are not allowed to extend the std nam=
espace, but we need to break this rule if our new type is to work. =C2=A0Be=
fore you propose fixing this, remember that Meter::operator* returns a Squa=
reMeter not a meter. <br></div>
<div style=3D"font-family:Arial"> <br></div>
<div style=3D"font-family:Arial">This isn&#39;t to say that you cannot expa=
nd strong types to fix the above, but if you want to do that you need to wr=
ite your own proposal. <br></div>
</blockquote><div>=C2=A0<br></div>
<blockquote style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;marg=
in-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-col=
or:rgb(204,204,204);padding-left:1ex">So what do you think, did I get a rea=
sonably balanced view of what people want and what is painful enough that i=
t is worth considering? =C2=A0Is it worth going farther? This could be turn=
ed into a proposal to the EWG, which if successful will give everyone who h=
as a specific syntax in mind a direction to focus their efforts (either jus=
t write the proposal, or come up with a strong argument why something every=
one thinks we need is worth sacrificing) <br></blockquote><div><br></div>
<div>I think it is the correct approach, focusing on requirements, <span st=
yle=3D"background-color:transparent"><span style=3D"color:rgb(34,34,34)"><s=
pan style=3D"font-family:Arial,Helvetica,sans-serif"><span style=3D"font-si=
ze:13px">leaving syntax and implementation flavors aside</span></span></spa=
n></span> for now.<br></div>
</div>
<p><br></p><div style=3D"font-family:Arial">--<br></div>
<div style=3D"font-family:Arial"> You received this message because you are=
 subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&=
quot; group.<br></div>
<div style=3D"font-family:Arial"> To unsubscribe from this group and stop r=
eceiving emails from it, send an email to <a onmousedown=3D"this.href=3D&#3=
9;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#3=
9;;return true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gd=
f-obfuscated-mailto=3D"wheWgflVAQAJ">std-proposal...@<wbr>isocpp.org</a>.<b=
r></div>
<div style=3D"font-family:Arial"> To post to this group, send email to <a o=
nmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"th=
is.href=3D&#39;javascript:&#39;;return true;" href=3D"javascript:" target=
=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"wheWgflVAQAJ">std-pr.=
...@isocpp.org</a>.<br></div>
<div style=3D"font-family:Arial"> To view this discussion on the web visit =
<a onmousedown=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d=
/msgid/std-proposals/391e060e-a7eb-48b0-9646-38d6e8bad6ff%40isocpp.org?utm_=
medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick=3D"this.=
href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/39=
1e060e-a7eb-48b0-9646-38d6e8bad6ff%40isocpp.org?utm_medium\x3demail\x26utm_=
source\x3dfooter&#39;;return true;" href=3D"https://groups.google.com/a/iso=
cpp.org/d/msgid/std-proposals/391e060e-a7eb-48b0-9646-38d6e8bad6ff%40isocpp=
..org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" rel=3D"n=
ofollow">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>propo=
sals/391e060e-a7eb-48b0-<wbr>9646-38d6e8bad6ff%40isocpp.org</a><wbr>.<br></=
div>
</blockquote></div>

</blockquote></div>

<p></p>

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

------=_Part_534_355403563.1535205219828--

------=_Part_533_96660702.1535205219827--

.

On 2018-08-24 17:20, Hyman Rosen wrote:
> On Fri, Aug 24, 2018 at 5:03 PM Matthew Woehlke wrote:
>> (And while C probably doesn't mind allowing reordering, designated
>> initializers suggest that C++ *might*.)
>>
>
> As far as I'm concerned, named parameters without reordering is a complete
> non-starter.

....and given the "anti-optimizationist" sentiment that's been flying
around as of late, you expect that the effect this will have on
deterministic order of argument evaluation will be taken in stride?
(Say, aren't *you* one of those people?)

I'm not holding my breath.

Besides, *why* you think reordering is a "must have"? *I* don't see it
that way...

--
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/a15f1777-35e9-52b4-fd1f-fdb8ed8e75c6%40gmail.com.

.

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

On Mon, Aug 27, 2018 at 11:09 AM Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2018-08-24 17:20, Hyman Rosen wrote:
> > On Fri, Aug 24, 2018 at 5:03 PM Matthew Woehlke wrote:
> >> (And while C probably doesn't mind allowing reordering, designated
> >> initializers suggest that C++ *might*.)
> >>
> >
> > As far as I'm concerned, named parameters without reordering is a
> complete
> > non-starter.
>
> ...and given the "anti-optimizationist" sentiment that's been flying
> around as of late, you expect that the effect this will have on
> deterministic order of argument evaluation will be taken in stride?
> (Say, aren't *you* one of those people?)
>

The order of evaluation for function call arguments adopted by the standard
is
"arbitrary order, but each parameter fully initialized before evaluation of
another
argument begins" so reordered parameters aren't affected.  (My preference
would
be strict left-to-right evaluation as written, with reordered parameters
allowed.)

Besides, *why* you think reordering is a "must have"? *I* don't see it that
> way...
>

The caller gets to specify the order and values of the arguments that makes
sense
at the point of call.  Given that named parameters are especially useful
for the case
of "many parameters, all with defaults" it seems wrong to annoy people with
a
required order.
    std::string format(double value,
                       e_format style = E_SCIENTIFIC
                       int digits = -1,
                       sign_E sign = E_ALWAYS,
                       case_e case = E_LOWER,
                       decimal_point = '.');
    std::string s = format(1.0 / 3.0, .digits = 6, .style = e_FIXED);

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

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Aug 27=
, 2018 at 11:09 AM Matthew Woehlke &lt;<a href=3D"mailto:mwoehlke.floss@gma=
il.com">mwoehlke.floss@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">On 2018-08-24 17:20, Hyman Rosen wrote:<br>
&gt; On Fri, Aug 24, 2018 at 5:03 PM Matthew Woehlke wrote:<br>
&gt;&gt; (And while C probably doesn&#39;t mind allowing reordering, design=
ated<br>
&gt;&gt; initializers suggest that C++ *might*.)<br>
&gt;&gt;<br>
&gt; <br>
&gt; As far as I&#39;m concerned, named parameters without reordering is a =
complete<br>
&gt; non-starter.<br>
<br>
....and given the &quot;anti-optimizationist&quot; sentiment that&#39;s been=
 flying<br>
around as of late, you expect that the effect this will have on<br>
deterministic order of argument evaluation will be taken in stride?<br>
(Say, aren&#39;t *you* one of those people?)<br></blockquote><div><br>The o=
rder of evaluation for function call arguments adopted by the standard is<b=
r>&quot;arbitrary order, but each parameter fully initialized before evalua=
tion of another<br>argument begins&quot; so reordered parameters aren&#39;t=
 affected.=C2=A0 (My preference would<br>be strict left-to-right evaluation=
 as written, with reordered parameters allowed.)<br><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">
Besides, *why* you think reordering is a &quot;must have&quot;? *I* don&#39=
;t see it that way...<br></blockquote><div><br>The caller gets to specify t=
he order and values of the arguments that makes sense<br>at the point of ca=
ll.=C2=A0 Given that named parameters are especially useful for the case<br=
>of &quot;many parameters, all with defaults&quot; it seems wrong to annoy =
people with a<br>required order.<br><font face=3D"monospace, monospace">=C2=
=A0 =C2=A0 std::string format(double value,</font>

<br style=3D"font-family:monospace,monospace"><span style=3D"font-family:mo=
nospace,monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0e_format style =3D E_SCIENTIFIC</span>=C2=A0=C2=
=A0<font face=3D"monospace, monospace"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0int digits =3D -1,<br>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0sign_E sign =3D E_ALWAYS,</font></div><div><font face=3D"monospac=
e, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0case_e case =3D E_LOWER,</font></div><div><font fac=
e=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0decimal_point =3D &#39;.&#39;);<br>=C2=
=A0 =C2=A0 std::string s =3D format(1.0 / 3.0, .digits =3D 6, .style =3D e_=
FIXED);</font></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/CAHSYqdbGjgS6t3owit3fed29SoNS1rdcGg2x=
nihVM8v_rTgHLQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbGjgS6t3ow=
it3fed29SoNS1rdcGg2xnihVM8v_rTgHLQ%40mail.gmail.com</a>.<br />

--000000000000fb506205746ca1a0--

.

On 2018-08-27 11:46, Hyman Rosen wrote:
> On Mon, Aug 27, 2018 at 11:09 AM Matthew Woehlke wrote:
>> On 2018-08-24 17:20, Hyman Rosen wrote:
>>> On Fri, Aug 24, 2018 at 5:03 PM Matthew Woehlke wrote:
>>> As far as I'm concerned, named parameters without reordering is a
>>> complete non-starter.
>>
>> ...and given the "anti-optimizationist" sentiment that's been flying
>> around as of late, you expect that the effect this will have on
>> deterministic order of argument evaluation will be taken in stride?
>> (Say, aren't *you* one of those people?)
>
> The order of evaluation for function call arguments adopted by the
> standard is "arbitrary order, but each parameter fully initialized
> before evaluation of another argument begins" so reordered parameters
> aren't affected.  (My preference would be strict left-to-right
> evaluation as written, with reordered parameters allowed.)
Yes, that's the case AFAICT in C++17. Have folks given up trying to
change it?

To be clear, I'm not *against* reordering, I just don't personally feel
it's necessary, and, accordingly, don't want to fight for it if that's
going to be difficult. (It's also pretty easy to add reordering on top
of any accepted proposal that doesn't have it.)

--
Matthew

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

.

--0000000000004d225a05746e08fa
Content-Type: text/plain; charset="UTF-8"

On Mon, 27 Aug 2018, 17:15 Matthew Woehlke, <mwoehlke.floss@gmail.com>
wrote:

> To be clear, I'm not *against* reordering, I just don't personally feel
> it's necessary, and, accordingly, don't want to fight for it if that's
> going to be difficult. (It's also pretty easy to add reordering on top
> of any accepted proposal that doesn't have it.)
>

The more I see these conversations develop, the more sceptical I get about
named parameters (and I wasn't fully on board to begin with).

However, if the named parameters proposal gets anywhere, I think it should
necessarily have reordering either included or added as a strong future
consideration. Otherwise there really isn't a selling point beyond choosing
between overloads. To me that's just a lazy way of having a fraction of the
benefits of strong types.

As nasty as I find pythonic bag functions, there is some level of demand
for them, possibly helping to drive the push for named parameters in the
first place (I think there are a number of people here who want named
parameters specifically for that purpose). I think any implementation
should at the very least be written in preparation for a future change that
allows for them. Otherwise, it's possible that implementations introduce
hurdles that may prevent the change that some people want out of this in
the first place.


I'm not sure if the current format of this discussion is sufficient to
really get much progress going. At the moment we have N threads
cross-discussing M different approaches and its hard to keep up with, let
alone make progress. Perhaps a thread for each combination of features,
with a separate debate on each one, and a mother thread for general
cross-discussion might suffice.

--
You received this message because you are subscribed to 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%2B0CCOoxSh%2BkL12v3vWUpt%2BZsYPGOw%3DKPjyWYtiR3dabWd8fw%40mail.gmail.com.

--0000000000004d225a05746e08fa
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 Mon, =
27 Aug 2018, 17:15 Matthew Woehlke, &lt;<a href=3D"mailto:mwoehlke.floss@gm=
ail.com">mwoehlke.floss@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">To be clear, I&#39;m not *against* reordering, I just don&#39=
;t personally feel<br>
it&#39;s necessary, and, accordingly, don&#39;t want to fight for it if tha=
t&#39;s<br>
going to be difficult. (It&#39;s also pretty easy to add reordering on top<=
br>
of any accepted proposal that doesn&#39;t have it.)<br></blockquote></div><=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">The more I see these con=
versations develop, the more sceptical I get about named parameters (and I =
wasn&#39;t fully on board to begin with).</div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">However, if the named parameters proposal gets anywhere, =
I think it should necessarily have reordering either included or added as a=
 strong future consideration. Otherwise there really isn&#39;t a selling po=
int beyond choosing between overloads. To me that&#39;s just a lazy way of =
having a fraction of the benefits of strong types.</div><div dir=3D"auto"><=
br></div><div dir=3D"auto">As nasty as I find pythonic bag functions, there=
 is some level of demand for them, possibly helping to drive the push for n=
amed parameters in the first place (I think there are a number of people he=
re who want named parameters specifically for that purpose). I think any im=
plementation should at the very least be written in preparation for a futur=
e change that allows for them. Otherwise, it&#39;s possible that implementa=
tions introduce hurdles that may prevent the change that some people want o=
ut of this in the first place.</div><div dir=3D"auto"><br></div><div dir=3D=
"auto"><br></div><div dir=3D"auto">I&#39;m not sure if the current format o=
f this discussion is sufficient to really get much progress going. At the m=
oment we have N threads cross-discussing M different approaches and its har=
d to keep up with, let alone make progress. Perhaps a thread for each combi=
nation of features, with a separate debate on each one, and a mother thread=
 for general cross-discussion might suffice.</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%2B0CCOoxSh%2BkL12v3vWUpt%2BZsYPGO=
w%3DKPjyWYtiR3dabWd8fw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CC=
OoxSh%2BkL12v3vWUpt%2BZsYPGOw%3DKPjyWYtiR3dabWd8fw%40mail.gmail.com</a>.<br=
 />

--0000000000004d225a05746e08fa--

.

On 2018-08-27 13:25, Jake Arkinstall wrote:
> As nasty as I find pythonic bag functions, there is some level of demand
> for them, possibly helping to drive the push for named parameters in the
> first place (I think there are a number of people here who want named
> parameters specifically for that purpose).

Yes. In particular, I am one of them; for me, this is *the* compelling
feature. I also like overloading on names, but not as much as skipping
arguments, and I can take or leave reordering.

I suppose this is part of the problem; different people have different
priorities, which can conflict violently.

--
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/6df3c211-6190-5289-ff04-ed4511d9f9c7%40gmail.com.

.

--000000000000807eab05746e6f6a
Content-Type: text/plain; charset="UTF-8"

On Mon, Aug 27, 2018 at 1:33 PM Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> I suppose this is part of the problem; different people have different
> priorities, which can conflict violently.
>

My heuristic is, if Ada did it that way, someone sensible thought very
hard about it and decided it was a good idea.  So unless there's some
essential reason why the Ada approach is wrong for C++, I tend to just
go with that.

--
You received this message because you are subscribed to 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/CAHSYqda04B%2BFukj64i-4d__EW27dZ6g5xNYhVEGOut_bdywmAQ%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Aug 27=
, 2018 at 1:33 PM Matthew Woehlke &lt;<a href=3D"mailto:mwoehlke.floss@gmai=
l.com">mwoehlke.floss@gmail.com</a>&gt; wrote:</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
I suppose this is part of the problem; different people have different<br>
priorities, which can conflict violently.<br></blockquote><div><br>My heuri=
stic is, if Ada did it that way, someone sensible thought very<br>hard abou=
t it and decided it was a good idea.=C2=A0 So unless there&#39;s some<br>es=
sential reason why the Ada approach is wrong for C++, I tend to just<br>go =
with that.</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/CAHSYqda04B%2BFukj64i-4d__EW27dZ6g5xN=
YhVEGOut_bdywmAQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqda04B%2BF=
ukj64i-4d__EW27dZ6g5xNYhVEGOut_bdywmAQ%40mail.gmail.com</a>.<br />

--000000000000807eab05746e6f6a--

.

--Apple-Mail-6AC85C10-DFD4-4F40-9268-1275056CE0CB
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Ada had a completely different set of requirements and abstraction capabili=
ties from C++. Please do not forget that you can define your own types that=
 are as efficient as the built -ins without their negative features, except=
 where you need code to sidestep the negative features like integer overflo=
w internally.

Get rid of primitive obsession, especially in multi-parameter functions.

Sent from Peter Sommerlad's iPad
+41 79 432 23 32

> On 27 Aug 2018, at 19:55, Hyman Rosen <hyman.rosen@gmail.com> wrote:
>=20
>> On Mon, Aug 27, 2018 at 1:33 PM Matthew Woehlke <mwoehlke.floss@gmail.co=
m> wrote:
>> I suppose this is part of the problem; different people have different
>> priorities, which can conflict violently.
>=20
> My heuristic is, if Ada did it that way, someone sensible thought very
> hard about it and decided it was a good idea.  So unless there's some
> essential reason why the Ada approach is wrong for C++, I tend to just
> go with that.
> --=20
> You received this message because you are subscribed to the Google Groups=
 "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/CAHSYqda04B%2BFukj64i-4d__EW27dZ6g5xNYhVEGOut_=
bdywmAQ%40mail.gmail.com.

--=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/A4018A9D-A9C5-4C69-9984-AB434336B4AD%40hsr.ch.

--Apple-Mail-6AC85C10-DFD4-4F40-9268-1275056CE0CB
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 dir=3D"auto">Ada had a completely different set of r=
equirements and abstraction capabilities from C++. Please do not forget tha=
t you can define your own types that are as efficient as the built -ins wit=
hout their negative features, except where you need code to sidestep the ne=
gative features like integer overflow internally.<div><br></div><div>Get ri=
d of primitive obsession, especially in multi-parameter functions.<br><br><=
div id=3D"AppleMailSignature">Sent from Peter Sommerlad's<span class=3D"App=
le-style-span" style=3D"-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296=
875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webki=
t-composition-frame-color: rgba(77, 128, 180, 0.230469); ">&nbsp;iPad</span=
><div><span class=3D"Apple-style-span" style=3D"-webkit-tap-highlight-color=
: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192=
, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230=
469); ">+41 79 432 23 32</span></div></div><div><br>On 27 Aug 2018, at 19:5=
5, Hyman Rosen &lt;<a href=3D"mailto:hyman.rosen@gmail.com">hyman.rosen@gma=
il.com</a>&gt; wrote:<br><br></div><blockquote type=3D"cite"><div><meta htt=
p-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 Mon, Aug 27, 2018 at 1=
:33 PM Matthew Woehlke &lt;<a href=3D"mailto:mwoehlke.floss@gmail.com">mwoe=
hlke.floss@gmail.com</a>&gt; wrote:</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I suppose this is part of the problem; different people have different<br>
priorities, which can conflict violently.<br></blockquote><div><br>My heuri=
stic is, if Ada did it that way, someone sensible thought very<br>hard abou=
t it and decided it was a good idea.&nbsp; So unless there's some<br>essent=
ial reason why the Ada approach is wrong for C++, I tend to just<br>go with=
 that.</div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"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/CAHSYqda04B%2BFukj64i-4d__EW27dZ6g5xN=
YhVEGOut_bdywmAQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqda04B=
%2BFukj64i-4d__EW27dZ6g5xNYhVEGOut_bdywmAQ%40mail.gmail.com</a>.<br>
</div></blockquote></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/A4018A9D-A9C5-4C69-9984-AB434336B4AD%=
40hsr.ch?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/A4018A9D-A9C5-4C69-9984-AB434336B4AD%40h=
sr.ch</a>.<br />

--Apple-Mail-6AC85C10-DFD4-4F40-9268-1275056CE0CB--

.

On 27 August 2018 at 21:52, Peter Sommerlad <peter.sommerlad@hsr.ch> wrote:
> Ada had a completely different set of requirements and abstraction
> capabilities from C++. Please do not forget that you can define your own
> types that are as efficient as the built -ins without their negative
> features, except where you need code to sidestep the negative features like
> integer overflow internally.
>
> Get rid of primitive obsession, especially in multi-parameter functions.

We have tried to get rid of "primitive obsession" for two decades. The
workarounds entail
such an amount of boilerplate or other unfortunate package deals
(function-specific types
in namespace scope) that users choose to live with bugs rather than
introduce the workarounds.
So, rather than try to force users to do something they refuse to do,
which is using the
current known workarounds, we can make the workaround less
boilerplatey, or we can remove
the one problem that always kills a named argument proposal, which is
that they can't be used
with standard library functions.

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

.

I am working on  less boilerplaty solution. Inherting aggregates seem to work nicely. The problem is otoh to get developers thinking in domain types and understanding what they actually model instead of just using int and string.

Even the standard library (implementations) do a bad job internally. I just found one example today where difference_type and size_type are combined in interesting ways, but conceptually wrong.

Sent from Peter Sommerlad's iPad
+41 79 432 23 32

> On 27 Aug 2018, at 21:14, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>
>> On 27 August 2018 at 21:52, Peter Sommerlad <peter.sommerlad@hsr.ch> wrote:
>> Ada had a completely different set of requirements and abstraction
>> capabilities from C++. Please do not forget that you can define your own
>> types that are as efficient as the built -ins without their negative
>> features, except where you need code to sidestep the negative features like
>> integer overflow internally.
>>
>> Get rid of primitive obsession, especially in multi-parameter functions.
>
> We have tried to get rid of "primitive obsession" for two decades. The
> workarounds entail
> such an amount of boilerplate or other unfortunate package deals
> (function-specific types
> in namespace scope) that users choose to live with bugs rather than
> introduce the workarounds.
> So, rather than try to force users to do something they refuse to do,
> which is using the
> current known workarounds, we can make the workaround less
> boilerplatey, or we can remove
> the one problem that always kills a named argument proposal, which is
> that they can't be used
> with standard library functions.
>
> --
> You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZ8hiTfMMvSETLrKmPPZuqiuXJVW7Hi%3DyBzUdnx8HJXKA%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/64F33438-17FC-42C4-A900-549C0256E5E4%40hsr.ch.

.

On 27 August 2018 at 22:35, Peter Sommerlad <peter.sommerlad@hsr.ch> wrote:
> I am working on  less boilerplaty solution. Inherting aggregates seem to work nicely. The problem is otoh to get developers thinking in domain types and understanding what they actually model instead of just using int and string.

You can get developers thinking in domain types all you want, but as
soon as a function has two parameters of the same type, the desire
for being able to explicitly name the arguments arises. Other
languages manage to provide that mechanism without requiring
users to object-wrap themselves unconscious.

--
You received this message because you are subscribed to 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/CAFk2RUb8PA72eMvzs5H%3DeDZMXsA9Cy%3DkP4mSrbcXRWynsAO%3DvA%40mail.gmail.com.

.