------=_Part_138_277726230.1439657390639
Content-Type: multipart/alternative;
 boundary="----=_Part_139_1642294065.1439657390639"

------=_Part_139_1642294065.1439657390639
Content-Type: text/plain; charset=UTF-8

Hi,
Does anyone see helpfulness of such solution:
Having fnc:

void f(int a = 0, int b = 1, int c = 2, int d = 3);

I think that it would be nice to be able to say whilst calling it and
requiring only some of those args to be non-default:

f(default,2,default,4);

Thoughts?





--

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

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

<div dir=3D"ltr">Hi, <br>Does anyone see helpfulness of such solution:<br>H=
aving fnc:<br><br>void f(int a =3D 0, int b =3D 1, int c =3D 2, int d =3D 3=
);<br><br>I think that it would be nice to be able to say whilst calling it=
 and requiring only some of those args to be non-default:<br><br>f(default,=
2,default,4);<br><br>Thoughts?<br><br><br><br><br><br></div>

<p></p>

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

------=_Part_139_1642294065.1439657390639--
------=_Part_138_277726230.1439657390639--

.

------=_Part_2_1853422674.1439659769915
Content-Type: multipart/alternative;
 boundary="----=_Part_3_267507032.1439659769915"

------=_Part_3_267507032.1439659769915
Content-Type: text/plain; charset=UTF-8

On Saturday, August 15, 2015 at 12:49:50 PM UTC-4, Arthur Tchaikovsky wrote:
>
> Hi,
> Does anyone see helpfulness of such solution:
> Having fnc:
>
> void f(int a = 0, int b = 1, int c = 2, int d = 3);
>
> I think that it would be nice to be able to say whilst calling it and
> requiring only some of those args to be non-default:
>
> f(default,2,default,4);
>
> Thoughts?
>

This is probably the best language enhancement to default arguments I've
seen (admittedly, that's not saying much, considering the quality of the
others). It uses an existing keyword in a way that doesn't break existing
code. It provides genuinely useful functionality, solving a (relatively
minor) problem. And it would make it reasonable to define default arguments
other than at the end of a parameter list.

My only concern is that it could tie up more useful syntax. With Uniform
Initialization syntax, you can perform value initialization and
construction initialization. But there's no way to generically use default
initialization. So we might someday want `f(default)` to mean "default
initialize the parameter".

Then again, maybe we don't want 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Saturday, August 15, 2015 at 12:49:50 PM UTC-4, Arthur =
Tchaikovsky wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">Hi, <br>Does anyone see helpfulness of such solution:<br>Having fnc:<b=
r><br>void f(int a =3D 0, int b =3D 1, int c =3D 2, int d =3D 3);<br><br>I =
think that it would be nice to be able to say whilst calling it and requiri=
ng only some of those args to be non-default:<br><br>f(default,2,default,4)=
;<br><br>Thoughts?<br></div></blockquote><div><br>This is probably the best=
 language enhancement to default arguments I&#39;ve seen (admittedly, that&=
#39;s not saying much, considering the quality of the others). It uses an e=
xisting keyword in a way that doesn&#39;t break existing code. It provides =
genuinely useful functionality, solving a (relatively minor) problem. And i=
t would make it reasonable to define default arguments other than at the en=
d of a parameter list.<br><br>My only concern is that it could tie up more =
useful syntax. With Uniform Initialization syntax, you can perform value in=
itialization and construction initialization. But there&#39;s no way to gen=
erically use default initialization. So we might someday want `f(default)` =
to mean &quot;default initialize the parameter&quot;.<br><br>Then again, ma=
ybe we don&#39;t want that.<br></div></div>

<p></p>

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

------=_Part_3_267507032.1439659769915--
------=_Part_2_1853422674.1439659769915--

.

--Apple-Mail=_74117612-8957-4073-BC71-32E748042A2B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9308=E2=80=9316, at 1:29 AM, Nicol Bolas <jmckesson@gmail.c=
om> wrote:
>=20
> My only concern is that it could tie up more useful syntax. With Uniform =
Initialization syntax, you can perform value initialization and constructio=
n initialization. But there's no way to generically use default initializat=
ion. So we might someday want `f(default)` to mean "default initialize the =
parameter".

C-style variadic arguments come close to implementing default-initialized (=
uninitialized) parameters. The receiver needs to explicitly make a decision=
 whether to access the parameter and assert that it was actually passed.

Default-initialized values, when distinct from value-initialized, are indet=
erminate. Parameter passing uses copy-initialization, and you usually can=
=E2=80=99t copy an indeterminate value. So f(default) would seem to be UB e=
xcept when the argument is a temporary passed by reference.

TL;DR: Default-initialized parameters, not very useful.

--=20

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

--Apple-Mail=_74117612-8957-4073-BC71-32E748042A2B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9308=
=E2=80=9316, at 1:29 AM, Nicol Bolas &lt;<a href=3D"mailto:jmckesson@gmail.=
com" class=3D"">jmckesson@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-=
interchange-newline"><div class=3D""><span style=3D"font-family: Helvetica;=
 font-size: 12px; font-style: normal; font-variant: normal; font-weight: no=
rmal; letter-spacing: normal; line-height: normal; orphans: auto; text-alig=
n: start; text-indent: 0px; text-transform: none; white-space: normal; wido=
ws: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; d=
isplay: inline !important;" class=3D"">My only concern is that it could tie=
 up more useful syntax. With Uniform Initialization syntax, you can perform=
 value initialization and construction initialization. But there's no way t=
o generically use default initialization. So we might someday want `f(defau=
lt)` to mean "default initialize the parameter".</span><br style=3D"font-fa=
mily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal;=
 font-weight: normal; letter-spacing: normal; line-height: normal; orphans:=
 auto; text-align: start; text-indent: 0px; text-transform: none; white-spa=
ce: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px=
;" class=3D""></div></blockquote></div><br class=3D""><div class=3D"">C-sty=
le variadic arguments come close to implementing default-initialized (unini=
tialized) parameters. The receiver needs to explicitly make a decision whet=
her to access the parameter and assert that it was actually passed.</div><d=
iv class=3D""><br class=3D""></div><div class=3D"">Default-initialized valu=
es, when distinct from value-initialized, are indeterminate. Parameter pass=
ing uses copy-initialization, and you usually can=E2=80=99t copy an indeter=
minate value. So <font face=3D"Courier" class=3D"">f(default)</font> would =
seem to be UB except when the argument is a temporary passed by reference.<=
/div><div class=3D""><br class=3D""></div><div class=3D"">TL;DR: Default-in=
itialized parameters, not very useful.</div><div class=3D""><br class=3D"">=
</div></body></html>

<p></p>

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

--Apple-Mail=_74117612-8957-4073-BC71-32E748042A2B--

.

------=_Part_489_1032625889.1439836646196
Content-Type: multipart/alternative;
 boundary="----=_Part_490_1488867531.1439836646197"

------=_Part_490_1488867531.1439836646197
Content-Type: text/plain; charset=UTF-8

I would really appreciate some feedback from people, or is this proposal so
uninteresting that there is no point in wasting keyboard on it?

On Saturday, 15 August 2015 17:49:50 UTC+1, Arthur Tchaikovsky wrote:
>
> Hi,
> Does anyone see helpfulness of such solution:
> Having fnc:
>
> void f(int a = 0, int b = 1, int c = 2, int d = 3);
>
> I think that it would be nice to be able to say whilst calling it and
> requiring only some of those args to be non-default:
>
> f(default,2,default,4);
>
> Thoughts?
>
>
>
>
>
>

--

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

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

<div dir=3D"ltr">I would really appreciate some feedback from people, or is=
 this proposal so uninteresting that there is no point in wasting keyboard =
on it?<br><br>On Saturday, 15 August 2015 17:49:50 UTC+1, Arthur Tchaikovsk=
y  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Hi, =
<br>Does anyone see helpfulness of such solution:<br>Having fnc:<br><br>voi=
d f(int a =3D 0, int b =3D 1, int c =3D 2, int d =3D 3);<br><br>I think tha=
t it would be nice to be able to say whilst calling it and requiring only s=
ome of those args to be non-default:<br><br>f(default,2,default,4);<br><br>=
Thoughts?<br><br><br><br><br><br></div></blockquote></div>

<p></p>

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

------=_Part_490_1488867531.1439836646197--
------=_Part_489_1032625889.1439836646196--

.

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

El 15/8/2015 13:49, "Arthur Tchaikovsky" <atch.cpp@gmail.com> escribi=C3=B3=
:
>
> Hi,
> Does anyone see helpfulness of such solution:
> Having fnc:
>
> void f(int a =3D 0, int b =3D 1, int c =3D 2, int d =3D 3);
>
> I think that it would be nice to be able to say whilst calling it and
requiring only some of those args to be non-default:
>
> f(default,2,default,4);
>
> Thoughts?

I think you should google better ;-)

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1466.pdf

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

--=20

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

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

<p dir=3D"ltr"><br>
El 15/8/2015 13:49, &quot;Arthur Tchaikovsky&quot; &lt;<a href=3D"mailto:at=
ch.cpp@gmail.com">atch.cpp@gmail.com</a>&gt; escribi=C3=B3:<br>
&gt;<br>
&gt; Hi, <br>
&gt; Does anyone see helpfulness of such solution:<br>
&gt; Having fnc:<br>
&gt;<br>
&gt; void f(int a =3D 0, int b =3D 1, int c =3D 2, int d =3D 3);<br>
&gt;<br>
&gt; I think that it would be nice to be able to say whilst calling it and =
requiring only some of those args to be non-default:<br>
&gt;<br>
&gt; f(default,2,default,4);<br>
&gt;<br>
&gt; Thoughts?</p>
<p dir=3D"ltr">I think you should google better ;-)</p>
<p dir=3D"ltr"><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/paper=
s/2003/n1466.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n=
1466.pdf</a><br></p>
<p dir=3D"ltr">&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; -- <br>
&gt;<br>
&gt; --- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-propos=
als/</a>.<br>
</p>

<p></p>

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

--047d7bea2f9847d8ce051d865ca8--

.

On 2015-08-17 20:37, Arthur Tchaikovsky wrote:
> I would really appreciate some feedback from people, or is this proposal
> so uninteresting that there is no point in wasting keyboard on it?

You might wonder how widely used it will be?

If not all parameters are of the same type, you can already get some of
the effect with a few overloads:

     void f(int a = 0, string b = "1",
            complex<double> c = 2.0, type4 d = 3);

     inline void f(int a, complex<double> c)
     { f(a, "1", c, 3); }

     inline void f(string b, complex<double> c)
     { f(0, b, c, 3); }

assuming that d is put last because you hardly ever want to change the
default.

Just saying that you can already do this without a language change.


    Bo Persson



>
> On Saturday, 15 August 2015 17:49:50 UTC+1, Arthur Tchaikovsky wrote:
>
>     Hi,
>     Does anyone see helpfulness of such solution:
>     Having fnc:
>
>     void f(int a = 0, int b = 1, int c = 2, int d = 3);
>
>     I think that it would be nice to be able to say whilst calling it
>     and requiring only some of those args to be non-default:
>
>     f(default,2,default,4);
>
>     Thoughts?
>
>


--

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

.

------=_Part_1740_1780373017.1439851944288
Content-Type: multipart/alternative;
 boundary="----=_Part_1741_413134508.1439851944288"

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

I work on a codebase where this feature would have lots of use-cases,=20
because we have lots of classes whose constructors have defaulted=20
parameters:

    C(int buffer_size =3D 1024, int timeout =3D 10, int tries =3D 3) :=20
buffer_size_(buffer_size), timeout_(timeout), tries_(tries) {}

    auto cptr =3D new C();  // usually the defaults are okay
    auto c2ptr =3D new C(2048);  // use a bigger buffer
    auto c3ptr =3D new C(1024, 1);  // use the default buffer size but with=
 a=20
shorter timeout
    auto c4ptr =3D new C(2048, 10, 5);  // testing: bump up the number of=
=20
tries

It would be marginally more convenient (and refactor-proof) to be able to=
=20
write

    auto cptr =3D new C();  // usually the defaults are okay
    auto c2ptr =3D new C(2048);  // use a bigger buffer
    auto c3ptr =3D new C(default, 1);  // use the default buffer size but=
=20
with a shorter timeout
    auto c4ptr =3D new C(2048, default, 5);  // testing: bump up the number=
=20
of tries

However, I consider defaulted parameters in general to be a huge=20
antipattern, and this constructor pattern in particular to be even worse.
I would MUCH rather just rewrite all these constructors so that they could=
=20
be used as

    auto cptr =3D new C();  // usually the defaults are okay
    auto c2ptr =3D new C().withBufferSize(2048);  // use a bigger buffer
    auto c3ptr =3D new C().withTimeout(1);  // use the default buffer size=
=20
but with a shorter timeout
    auto c4ptr =3D new C().withBufferSize(2048).withTries(5);  // testing:=
=20
bump up the number of tries

or

    auto cptr =3D new C();  // usually the defaults are okay
    auto c2ptr =3D new C(C::BufferSize(2048));  // use a bigger buffer
    auto c3ptr =3D new C(C::Timeout(1));  // use the default buffer size bu=
t=20
with a shorter timeout
    auto c4ptr =3D new C(C::BufferSize(2048), C::Tries(5));  // testing: bu=
mp=20
up the number of tries

or (the most conservative way to rewrite our existing code)

    static constexpr int default_buffer_size =3D 1024;
    static constexpr int default_timeout =3D 10;
    static constexpr int default_tries =3D 3;
    C() : buffer_size_(default_buffer_size), timeout_(default_timeout),=20
tries_(default_tries) {}
    C(int buffer_size, int timeout, int tries) : buffer_size_(buffer_size),=
=20
timeout_(timeout), tries_(tries) {}

    auto cptr =3D new C();  // usually the defaults are okay
    auto c2ptr =3D new C(2048, C::default_timeout, C::default_tries);  // u=
se=20
a bigger buffer
    auto c3ptr =3D new C(C::default_buffer_size, 1, C::default_tries);  //=
=20
use the default buffer size but with a shorter timeout
    auto c4ptr =3D new C(2048, C::default_timeout, 5);  // testing: bump up=
=20
the number of tries

I don't really want to make it *easier* for people to write the "function=
=20
taking tons of defaulted parameters" antipattern.
Let's teach people how to avoid the use of defaulted parameters, instead.

=E2=80=93Arthur


On Monday, August 17, 2015 at 11:58:41 AM UTC-7, Bo Persson wrote:
>
> On 2015-08-17 20:37, Arthur Tchaikovsky wrote:=20
> > I would really appreciate some feedback from people, or is this proposa=
l=20
> > so uninteresting that there is no point in wasting keyboard on it?=20
>
> You might wonder how widely used it will be?=20
>
> If not all parameters are of the same type, you can already get some of=
=20
> the effect with a few overloads:=20
>
>      void f(int a =3D 0, string b =3D "1",=20
>             complex<double> c =3D 2.0, type4 d =3D 3);=20
>
>      inline void f(int a, complex<double> c)=20
>      { f(a, "1", c, 3); }=20
>
>      inline void f(string b, complex<double> c)=20
>      { f(0, b, c, 3); }=20
>
> assuming that d is put last because you hardly ever want to change the=20
> default.=20
>
> Just saying that you can already do this without a language change.=20
>
>
>     Bo Persson=20
>
>
>
> >=20
> > On Saturday, 15 August 2015 17:49:50 UTC+1, Arthur Tchaikovsky wrote:=
=20
> >=20
> >     Hi,=20
> >     Does anyone see helpfulness of such solution:=20
> >     Having fnc:=20
> >=20
> >     void f(int a =3D 0, int b =3D 1, int c =3D 2, int d =3D 3);=20
> >=20
> >     I think that it would be nice to be able to say whilst calling it=
=20
> >     and requiring only some of those args to be non-default:=20
> >=20
> >     f(default,2,default,4);=20
> >=20
> >     Thoughts?=20
> >=20
> >=20
>
>
>

--=20

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

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

<div dir=3D"ltr">I work on a codebase where this feature would have lots of=
 use-cases, because we have lots of classes whose constructors have default=
ed parameters:<div><br></div><div>=C2=A0 =C2=A0 C(int buffer_size =3D 1024,=
 int timeout =3D 10, int tries =3D 3) : buffer_size_(buffer_size), timeout_=
(timeout), tries_(tries) {}</div><div><br></div><div>=C2=A0 =C2=A0 auto cpt=
r =3D new C(); =C2=A0// usually the defaults are okay</div><div>=C2=A0 =C2=
=A0 auto c2ptr =3D new C(2048); =C2=A0// use a bigger buffer<br>=C2=A0 =C2=
=A0 auto c3ptr =3D new C(1024, 1); =C2=A0// use the default buffer size but=
 with a shorter timeout</div><div>=C2=A0 =C2=A0 auto c4ptr =3D new C(2048, =
10, 5); =C2=A0// testing: bump up the number of tries</div><div><br></div><=
div>It would be marginally more convenient (and refactor-proof) to be able =
to write</div><div><br></div><div><div>=C2=A0 =C2=A0 auto cptr =3D new C();=
 =C2=A0// usually the defaults are okay</div><div>=C2=A0 =C2=A0 auto c2ptr =
=3D new C(2048); =C2=A0// use a bigger buffer<br>=C2=A0 =C2=A0 auto c3ptr =
=3D new C(default, 1); =C2=A0// use the default buffer size but with a shor=
ter timeout</div><div>=C2=A0 =C2=A0 auto c4ptr =3D new C(2048,=C2=A0default=
, 5); =C2=A0// testing: bump up the number of tries</div><div><br></div><di=
v>However, I consider defaulted parameters in general to be a huge antipatt=
ern, and this constructor pattern in particular to be even worse.</div><div=
>I would MUCH rather just rewrite all these constructors so that they could=
 be used as</div><div><br></div><div>=C2=A0 =C2=A0 auto cptr =3D new C(); =
=C2=A0// usually the defaults are okay</div><div>=C2=A0 =C2=A0 auto c2ptr =
=3D new C().withBufferSize(2048); =C2=A0// use a bigger buffer<br>=C2=A0 =
=C2=A0 auto c3ptr =3D new C().withTimeout(1); =C2=A0// use the default buff=
er size but with a shorter timeout</div><div>=C2=A0 =C2=A0 auto c4ptr =3D n=
ew C().withBufferSize(2048).withTries(5); =C2=A0// testing: bump up the num=
ber of tries</div><div><br></div><div>or</div><div><br></div><div><div>=C2=
=A0 =C2=A0 auto cptr =3D new C(); =C2=A0// usually the defaults are okay</d=
iv><div>=C2=A0 =C2=A0 auto c2ptr =3D new C(C::BufferSize(2048)); =C2=A0// u=
se a bigger buffer<br>=C2=A0 =C2=A0 auto c3ptr =3D new C(C::Timeout(1)); =
=C2=A0// use the default buffer size but with a shorter timeout</div><div>=
=C2=A0 =C2=A0 auto c4ptr =3D new C(C::BufferSize(2048), C::Tries(5)); =C2=
=A0// testing: bump up the number of tries</div></div><div><br></div><div>o=
r (the most conservative way to rewrite our existing code)</div><div><br></=
div><div>=C2=A0 =C2=A0 static constexpr int default_buffer_size =3D 1024;</=
div><div>=C2=A0 =C2=A0 static constexpr int default_timeout =3D 10;</div><d=
iv></div><div>=C2=A0 =C2=A0 static constexpr int default_tries =3D 3;</div>=
<div></div><div>=C2=A0 =C2=A0 C() : buffer_size_(default_buffer_size), time=
out_(default_timeout), tries_(default_tries) {}<br></div><div><div><div>=C2=
=A0 =C2=A0 C(int buffer_size, int timeout, int tries) : buffer_size_(buffer=
_size), timeout_(timeout), tries_(tries) {}</div><div></div></div></div><di=
v><br></div><div>=C2=A0 =C2=A0 auto cptr =3D new C(); =C2=A0// usually the =
defaults are okay<br></div><div><div>=C2=A0 =C2=A0 auto c2ptr =3D new C(204=
8, C::default_timeout, C::default_tries); =C2=A0// use a bigger buffer<br>=
=C2=A0 =C2=A0 auto c3ptr =3D new C(C::default_buffer_size, 1, C::default_tr=
ies); =C2=A0// use the default buffer size but with a shorter timeout</div>=
<div>=C2=A0 =C2=A0 auto c4ptr =3D new C(2048, C::default_timeout, 5); =C2=
=A0// testing: bump up the number of tries</div></div><div><br></div><div>I=
 don&#39;t really want to make it <i>easier</i> for people to write the &qu=
ot;function taking tons of defaulted parameters&quot; antipattern.</div><di=
v>Let&#39;s teach people how to avoid the use of defaulted parameters, inst=
ead.</div><div><br></div><div>=E2=80=93Arthur</div><div><br></div><div><br>=
</div>On Monday, August 17, 2015 at 11:58:41 AM UTC-7, Bo Persson wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">On 2015-08-17 20:37, Arthur Tchai=
kovsky wrote:
<br>&gt; I would really appreciate some feedback from people, or is this pr=
oposal
<br>&gt; so uninteresting that there is no point in wasting keyboard on it?
<br>
<br>You might wonder how widely used it will be?
<br>
<br>If not all parameters are of the same type, you can already get some of=
=20
<br>the effect with a few overloads:
<br>
<br>=C2=A0 =C2=A0 =C2=A0void f(int a =3D 0, string b =3D &quot;1&quot;,
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 complex&lt;double&gt; c =3D 2=
..0, type4 d =3D 3);
<br>
<br>=C2=A0 =C2=A0 =C2=A0inline void f(int a, complex&lt;double&gt; c)
<br>=C2=A0 =C2=A0 =C2=A0{ f(a, &quot;1&quot;, c, 3); }
<br>
<br>=C2=A0 =C2=A0 =C2=A0inline void f(string b, complex&lt;double&gt; c)
<br>=C2=A0 =C2=A0 =C2=A0{ f(0, b, c, 3); }
<br>
<br>assuming that d is put last because you hardly ever want to change the=
=20
<br>default.
<br>
<br>Just saying that you can already do this without a language change.
<br>
<br>
<br>=C2=A0 =C2=A0 Bo Persson
<br>
<br>
<br>
<br>&gt;
<br>&gt; On Saturday, 15 August 2015 17:49:50 UTC+1, Arthur Tchaikovsky wro=
te:
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 Hi,
<br>&gt; =C2=A0 =C2=A0 Does anyone see helpfulness of such solution:
<br>&gt; =C2=A0 =C2=A0 Having fnc:
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 void f(int a =3D 0, int b =3D 1, int c =3D 2, int d =
=3D 3);
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 I think that it would be nice to be able to say whil=
st calling it
<br>&gt; =C2=A0 =C2=A0 and requiring only some of those args to be non-defa=
ult:
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 f(default,2,default,4);
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 Thoughts?
<br>&gt;
<br>&gt;
<br>
<br>
<br></blockquote></div></div>

<p></p>

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

------=_Part_1741_413134508.1439851944288--
------=_Part_1740_1780373017.1439851944288--

.

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

On 2015-08-18 00:52, Arthur O'Dwyer wrote:
> I work on a codebase where this feature would have lots of use-cases,
> because we have lots of classes whose constructors have defaulted
> parameters:
>
>     C(int buffer_size =3D 1024, int timeout =3D 10, int tries =3D 3) :
> buffer_size_(buffer_size), timeout_(timeout), tries_(tries) {}
>
>     auto cptr =3D new C();  // usually the defaults are okay
>     auto c2ptr =3D new C(2048);  // use a bigger buffer
>     auto c3ptr =3D new C(1024, 1);  // use the default buffer size but
> with a shorter timeout
>     auto c4ptr =3D new C(2048, 10, 5);  // testing: bump up the number
> of tries
>
> It would be marginally more convenient (and refactor-proof) to be able
> to write
>
>     auto cptr =3D new C();  // usually the defaults are okay
>     auto c2ptr =3D new C(2048);  // use a bigger buffer
>     auto c3ptr =3D new C(default, 1);  // use the default buffer size
> but with a shorter timeout
>     auto c4ptr =3D new C(2048, default, 5);  // testing: bump up the
> number of tries
>
> However, I consider defaulted parameters in general to be a huge
> antipattern, and this constructor pattern in particular to be even worse.

+10 (at least)

> I would MUCH rather just rewrite all these constructors so that they
> could be used as
>
>     auto cptr =3D new C();  // usually the defaults are okay
>     auto c2ptr =3D new C().withBufferSize(2048);  // use a bigger buffer
>     auto c3ptr =3D new C().withTimeout(1);  // use the default buffer
> size but with a shorter timeout
>     auto c4ptr =3D new C().withBufferSize(2048).withTries(5);  //
> testing: bump up the number of tries
>
> or
>
>     auto cptr =3D new C();  // usually the defaults are okay
>     auto c2ptr =3D new C(C::BufferSize(2048));  // use a bigger buffer
>     auto c3ptr =3D new C(C::Timeout(1));  // use the default buffer size
> but with a shorter timeout
>     auto c4ptr =3D new C(C::BufferSize(2048), C::Tries(5));  // testing:
> bump up the number of tries

Or (if you are definining individual types for your parameters anyway),
why not

    auto cptr =3D new C();  // usually the defaults are okay
    auto c2ptr =3D new C(bufferSize =3D 2048);  // use a bigger buffer
    auto c3ptr =3D new C(timeout =3D 1);  // use the default buffer size bu=
t
with a shorter timeout
    auto c4ptr =3D new C(bufferSize =3D 2048, tries =3D 5);  // testing: bu=
mp
up the number of tries

You would have but one constructor (assuming Concepts Lite and Folding
Expressions):

template<Assignment... A)
C(const A&... a) : buffer_size_(1024), timeout_(10), tries_(3)
{
  (a(*this),...);
}

And some types/constexprs:

struct BufferSizeAssignment
{
   int value;

   template<typename T>
   void operator()(T& t)
   {
      t.buffer_size_ =3D value;// or t.setBufferSize(value)
   }
};

struct BufferSize
{
   BufferSizeAssignment operator=3D(int value)
   {
      return {value};
   }
};

constexpr auto bufferSize =3D BufferSize{};


Of course, this would be much more convenient if we could configure
names in template parameters and could write

constexpr auto bufferSize =3D std::named_parameter<int, `buffer_size_`>;
constexpr auto timeout =3D std::named_parameter<int, `timeout_`>;
constexpr auto tries =3D std::named_parameter<int, `tries_`>;

Still trying to find the time to write the proposal for that...


Best,

Roland

>
> or (the most conservative way to rewrite our existing code)
>
>     static constexpr int default_buffer_size =3D 1024;
>     static constexpr int default_timeout =3D 10;
>     static constexpr int default_tries =3D 3;
>     C() : buffer_size_(default_buffer_size),
> timeout_(default_timeout), tries_(default_tries) {}
>     C(int buffer_size, int timeout, int tries) :
> buffer_size_(buffer_size), timeout_(timeout), tries_(tries) {}
>
>     auto cptr =3D new C();  // usually the defaults are okay
>     auto c2ptr =3D new C(2048, C::default_timeout, C::default_tries);
>  // use a bigger buffer
>     auto c3ptr =3D new C(C::default_buffer_size, 1, C::default_tries);
>  // use the default buffer size but with a shorter timeout
>     auto c4ptr =3D new C(2048, C::default_timeout, 5);  // testing: bump
> up the number of tries
>
> I don't really want to make it /easier/ for people to write the
> "function taking tons of defaulted parameters" antipattern.
> Let's teach people how to avoid the use of defaulted parameters, instead.
>
> =E2=80=93Arthur
>
>
> On Monday, August 17, 2015 at 11:58:41 AM UTC-7, Bo Persson wrote:
>
>     On 2015-08-17 20:37, Arthur Tchaikovsky wrote:
>     > I would really appreciate some feedback from people, or is this
>     proposal
>     > so uninteresting that there is no point in wasting keyboard on it?
>
>     You might wonder how widely used it will be?
>
>     If not all parameters are of the same type, you can already get
>     some of
>     the effect with a few overloads:
>
>          void f(int a =3D 0, string b =3D "1",
>                 complex<double> c =3D 2.0, type4 d =3D 3);
>
>          inline void f(int a, complex<double> c)
>          { f(a, "1", c, 3); }
>
>          inline void f(string b, complex<double> c)
>          { f(0, b, c, 3); }
>
>     assuming that d is put last because you hardly ever want to change
>     the
>     default.
>
>     Just saying that you can already do this without a language change.
>
>
>         Bo Persson
>
>
>
>     >
>     > On Saturday, 15 August 2015 17:49:50 UTC+1, Arthur Tchaikovsky
>     wrote:
>     >
>     >     Hi,
>     >     Does anyone see helpfulness of such solution:
>     >     Having fnc:
>     >
>     >     void f(int a =3D 0, int b =3D 1, int c =3D 2, int d =3D 3);
>     >
>     >     I think that it would be nice to be able to say whilst
>     calling it
>     >     and requiring only some of those args to be non-default:
>     >
>     >     f(default,2,default,4);
>     >
>     >     Thoughts?
>     >
>     >
>
>
> --=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
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--=20

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

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 2015-08-18 00:52, Arthur O'Dwyer
      wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:86717349-1fce-4247-9372-08eedce4cd30@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">I work on a codebase where this feature would have
        lots of use-cases, because we have lots of classes whose
        constructors have defaulted parameters:
        <div><br>
        </div>
        <div>=C2=A0 =C2=A0 C(int buffer_size =3D 1024, int timeout =3D 10, =
int tries =3D
          3) : buffer_size_(buffer_size), timeout_(timeout),
          tries_(tries) {}</div>
        <div><br>
        </div>
        <div>=C2=A0 =C2=A0 auto cptr =3D new C(); =C2=A0// usually the defa=
ults are okay</div>
        <div>=C2=A0 =C2=A0 auto c2ptr =3D new C(2048); =C2=A0// use a bigge=
r buffer<br>
          =C2=A0 =C2=A0 auto c3ptr =3D new C(1024, 1); =C2=A0// use the def=
ault buffer
          size but with a shorter timeout</div>
        <div>=C2=A0 =C2=A0 auto c4ptr =3D new C(2048, 10, 5); =C2=A0// test=
ing: bump up
          the number of tries</div>
        <div><br>
        </div>
        <div>It would be marginally more convenient (and refactor-proof)
          to be able to write</div>
        <div><br>
        </div>
        <div>
          <div>=C2=A0 =C2=A0 auto cptr =3D new C(); =C2=A0// usually the de=
faults are
            okay</div>
          <div>=C2=A0 =C2=A0 auto c2ptr =3D new C(2048); =C2=A0// use a big=
ger buffer<br>
            =C2=A0 =C2=A0 auto c3ptr =3D new C(default, 1); =C2=A0// use th=
e default
            buffer size but with a shorter timeout</div>
          <div>=C2=A0 =C2=A0 auto c4ptr =3D new C(2048,=C2=A0default, 5); =
=C2=A0// testing:
            bump up the number of tries</div>
          <div><br>
          </div>
          <div>However, I consider defaulted parameters in general to be
            a huge antipattern, and this constructor pattern in
            particular to be even worse.</div>
        </div>
      </div>
    </blockquote>
    <br>
    +10 (at least)<br>
    <br>
    <blockquote
      cite=3D"mid:86717349-1fce-4247-9372-08eedce4cd30@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>I would MUCH rather just rewrite all these constructors
            so that they could be used as</div>
          <div><br>
          </div>
          <div>=C2=A0 =C2=A0 auto cptr =3D new C(); =C2=A0// usually the de=
faults are
            okay</div>
          <div>=C2=A0 =C2=A0 auto c2ptr =3D new C().withBufferSize(2048); =
=C2=A0// use a
            bigger buffer<br>
            =C2=A0 =C2=A0 auto c3ptr =3D new C().withTimeout(1); =C2=A0// u=
se the default
            buffer size but with a shorter timeout</div>
          <div>=C2=A0 =C2=A0 auto c4ptr =3D new
            C().withBufferSize(2048).withTries(5); =C2=A0// testing: bump u=
p
            the number of tries</div>
          <div><br>
          </div>
          <div>or</div>
          <div><br>
          </div>
          <div>
            <div>=C2=A0 =C2=A0 auto cptr =3D new C(); =C2=A0// usually the =
defaults are
              okay</div>
            <div>=C2=A0 =C2=A0 auto c2ptr =3D new C(C::BufferSize(2048)); =
=C2=A0// use a
              bigger buffer<br>
              =C2=A0 =C2=A0 auto c3ptr =3D new C(C::Timeout(1)); =C2=A0// u=
se the default
              buffer size but with a shorter timeout</div>
            <div>=C2=A0 =C2=A0 auto c4ptr =3D new C(C::BufferSize(2048),
              C::Tries(5)); =C2=A0// testing: bump up the number of tries</=
div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Or (if you are definining individual types for your parameters
    anyway), why not <br>
    <br>
    <div>
      <div><tt>=C2=A0 =C2=A0 auto cptr =3D new C(); =C2=A0// usually the de=
faults are
          okay</tt></div>
      <div><tt>=C2=A0 =C2=A0 auto c2ptr =3D new C(bufferSize =3D 2048); =C2=
=A0// use a
          bigger buffer</tt><tt><br>
        </tt><tt>=C2=A0 =C2=A0 auto c3ptr =3D new C(timeout =3D 1); =C2=A0/=
/ use the
          default buffer size but with a shorter timeout</tt></div>
      <div><tt>=C2=A0 =C2=A0 auto c4ptr =3D new C(bufferSize =3D 2048, trie=
s =3D 5); =C2=A0//
          testing: bump up the number of tries</tt></div>
    </div>
    <br>
    You would have but one constructor (assuming Concepts Lite and
    Folding Expressions):<br>
    <br>
    <tt>template&lt;Assignment... A</tt><tt>)</tt><tt><br>
    </tt><tt>C(const A&amp;... a) : buffer_size_(1024), timeout_(10),
      tries_(3)</tt><tt><br>
    </tt><tt>{</tt><tt><br>
    </tt><tt>=C2=A0 (a(*this),...);</tt><tt><br>
    </tt><tt>}</tt><br>
    <br>
    And some types/constexprs:<br>
    <br>
    <tt>struct BufferSizeAssignment</tt><tt><br>
    </tt><tt>{</tt><tt><br>
    </tt><tt>=C2=A0=C2=A0 int value;</tt><tt><br>
    </tt><tt><br>
    </tt><tt>=C2=A0=C2=A0 template&lt;typename T&gt;</tt><tt><br>
    </tt><tt>=C2=A0=C2=A0 void operator()(T&amp; t)</tt><tt><br>
    </tt><tt>=C2=A0=C2=A0 {</tt><tt><br>
    </tt><tt>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 t.buffer_size_ =3D value;</tt><=
tt> // or
      t.setBufferSize(value)<br>
    </tt><tt>=C2=A0=C2=A0 }</tt><tt><br>
    </tt><tt>};</tt><tt><br>
    </tt><tt><br>
    </tt><tt>struct BufferSize</tt><tt><br>
    </tt><tt>{</tt><tt><br>
    </tt><tt>=C2=A0=C2=A0 BufferSizeAssignment operator=3D(int value)</tt><=
tt><br>
    </tt><tt>=C2=A0=C2=A0 {</tt><tt><br>
    </tt><tt>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return {value};</tt><tt><br>
    </tt><tt>=C2=A0=C2=A0 }</tt><tt><br>
    </tt><tt>};</tt><tt><br>
    </tt><tt><br>
    </tt><tt>constexpr auto bufferSize =3D BufferSize{};</tt><tt><br>
    </tt><br>
    <br>
    Of course, this would be much more convenient if we could configure
    names in template parameters and could write<br>
    <br>
    <tt>constexpr auto bufferSize =3D std::named_parameter&lt;int,
      `buffer_size_`&gt;;</tt><tt><br>
    </tt><tt>
      constexpr auto timeout =3D std::named_parameter&lt;int,
      `timeout_`&gt;;</tt><tt><br>
    </tt><tt>constexpr auto tries =3D std::named_parameter&lt;int,
      `tries_`&gt;;</tt><tt><br>
    </tt><br>
    Still trying to find the time to write the proposal for that...<br>
    <br>
    <br>
    Best,<br>
    <br>
    Roland<br>
    <br>
    <blockquote
      cite=3D"mid:86717349-1fce-4247-9372-08eedce4cd30@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div><br>
          </div>
          <div>or (the most conservative way to rewrite our existing
            code)</div>
          <div><br>
          </div>
          <div>=C2=A0 =C2=A0 static constexpr int default_buffer_size =3D 1=
024;</div>
          <div>=C2=A0 =C2=A0 static constexpr int default_timeout =3D 10;</=
div>
          <div>=C2=A0 =C2=A0 static constexpr int default_tries =3D 3;</div=
>
          <div>=C2=A0 =C2=A0 C() : buffer_size_(default_buffer_size),
            timeout_(default_timeout), tries_(default_tries) {}<br>
          </div>
          <div>
            <div>
              <div>=C2=A0 =C2=A0 C(int buffer_size, int timeout, int tries)=
 :
                buffer_size_(buffer_size), timeout_(timeout),
                tries_(tries) {}</div>
            </div>
          </div>
          <div><br>
          </div>
          <div>=C2=A0 =C2=A0 auto cptr =3D new C(); =C2=A0// usually the de=
faults are
            okay<br>
          </div>
          <div>
            <div>=C2=A0 =C2=A0 auto c2ptr =3D new C(2048, C::default_timeou=
t,
              C::default_tries); =C2=A0// use a bigger buffer<br>
              =C2=A0 =C2=A0 auto c3ptr =3D new C(C::default_buffer_size, 1,
              C::default_tries); =C2=A0// use the default buffer size but
              with a shorter timeout</div>
            <div>=C2=A0 =C2=A0 auto c4ptr =3D new C(2048, C::default_timeou=
t, 5);
              =C2=A0// testing: bump up the number of tries</div>
          </div>
          <div><br>
          </div>
          <div>I don't really want to make it <i>easier</i> for people
            to write the "function taking tons of defaulted parameters"
            antipattern.</div>
          <div>Let's teach people how to avoid the use of defaulted
            parameters, instead.</div>
          <div><br>
          </div>
          <div>=E2=80=93Arthur</div>
          <div><br>
          </div>
          <div><br>
          </div>
          On Monday, August 17, 2015 at 11:58:41 AM UTC-7, Bo Persson
          wrote:
          <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
            0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On
            2015-08-17 20:37, Arthur Tchaikovsky wrote:
            <br>
            &gt; I would really appreciate some feedback from people, or
            is this proposal
            <br>
            &gt; so uninteresting that there is no point in wasting
            keyboard on it?
            <br>
            <br>
            You might wonder how widely used it will be?
            <br>
            <br>
            If not all parameters are of the same type, you can already
            get some of <br>
            the effect with a few overloads:
            <br>
            <br>
            =C2=A0 =C2=A0 =C2=A0void f(int a =3D 0, string b =3D "1",
            <br>
            =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 complex&lt;double&gt;=
 c =3D 2.0, type4 d =3D 3);
            <br>
            <br>
            =C2=A0 =C2=A0 =C2=A0inline void f(int a, complex&lt;double&gt; =
c)
            <br>
            =C2=A0 =C2=A0 =C2=A0{ f(a, "1", c, 3); }
            <br>
            <br>
            =C2=A0 =C2=A0 =C2=A0inline void f(string b, complex&lt;double&g=
t; c)
            <br>
            =C2=A0 =C2=A0 =C2=A0{ f(0, b, c, 3); }
            <br>
            <br>
            assuming that d is put last because you hardly ever want to
            change the <br>
            default.
            <br>
            <br>
            Just saying that you can already do this without a language
            change.
            <br>
            <br>
            <br>
            =C2=A0 =C2=A0 Bo Persson
            <br>
            <br>
            <br>
            <br>
            &gt;
            <br>
            &gt; On Saturday, 15 August 2015 17:49:50 UTC+1, Arthur
            Tchaikovsky wrote:
            <br>
            &gt;
            <br>
            &gt; =C2=A0 =C2=A0 Hi,
            <br>
            &gt; =C2=A0 =C2=A0 Does anyone see helpfulness of such solution=
:
            <br>
            &gt; =C2=A0 =C2=A0 Having fnc:
            <br>
            &gt;
            <br>
            &gt; =C2=A0 =C2=A0 void f(int a =3D 0, int b =3D 1, int c =3D 2=
, int d =3D 3);
            <br>
            &gt;
            <br>
            &gt; =C2=A0 =C2=A0 I think that it would be nice to be able to =
say
            whilst calling it
            <br>
            &gt; =C2=A0 =C2=A0 and requiring only some of those args to be
            non-default:
            <br>
            &gt;
            <br>
            &gt; =C2=A0 =C2=A0 f(default,2,default,4);
            <br>
            &gt;
            <br>
            &gt; =C2=A0 =C2=A0 Thoughts?
            <br>
            &gt;
            <br>
            &gt;
            <br>
            <br>
            <br>
          </blockquote>
        </div>
      </div>
      -- <br>
      <br>
      --- <br>
      You received this message because you are subscribed to the Google
      Groups "ISO C++ Standard - Future Proposals" group.<br>
      To unsubscribe from this group and stop receiving emails from it,
      send an email to <a moz-do-not-send=3D"true"
        href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+=
unsubscribe@isocpp.org</a>.<br>
      To post to this group, send email to <a moz-do-not-send=3D"true"
        href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</=
a>.<br>
      Visit this group at <a moz-do-not-send=3D"true"
        href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
>http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
    </blockquote>
    <br>
  </body>
</html>

<p></p>

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

--------------010403090403020403070202--

.

------=_Part_4029_420810057.1439889620237
Content-Type: multipart/alternative;
 boundary="----=_Part_4030_460870604.1439889620237"

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

"I would MUCH rather just rewrite all these constructors"

But did you do it or simply wish that at some point you will find the time=
=20
(and will) to do it, but in the mean time you are still using those "old"=
=20
constructors? Because I also would MUCH rather have C++ cleaned up, yet=20
this will never happen, and I need to use C++ in its current state. What I=
=20
wish is very different to what I have.

And as for you saying that defaulted constructors are antipattern, is that=
=20
a fact or it is simply your opinion?

On Monday, 17 August 2015 23:52:24 UTC+1, Arthur O'Dwyer wrote:
>
> I work on a codebase where this feature would have lots of use-cases,=20
> because we have lots of classes whose constructors have defaulted=20
> parameters:
>
>     C(int buffer_size =3D 1024, int timeout =3D 10, int tries =3D 3) :=20
> buffer_size_(buffer_size), timeout_(timeout), tries_(tries) {}
>
>     auto cptr =3D new C();  // usually the defaults are okay
>     auto c2ptr =3D new C(2048);  // use a bigger buffer
>     auto c3ptr =3D new C(1024, 1);  // use the default buffer size but wi=
th=20
> a shorter timeout
>     auto c4ptr =3D new C(2048, 10, 5);  // testing: bump up the number of=
=20
> tries
>
> It would be marginally more convenient (and refactor-proof) to be able to=
=20
> write
>
>     auto cptr =3D new C();  // usually the defaults are okay
>     auto c2ptr =3D new C(2048);  // use a bigger buffer
>     auto c3ptr =3D new C(default, 1);  // use the default buffer size but=
=20
> with a shorter timeout
>     auto c4ptr =3D new C(2048, default, 5);  // testing: bump up the numb=
er=20
> of tries
>
> However, I consider defaulted parameters in general to be a huge=20
> antipattern, and this constructor pattern in particular to be even worse.
> I would MUCH rather just rewrite all these constructors so that they coul=
d=20
> be used as
>
>     auto cptr =3D new C();  // usually the defaults are okay
>     auto c2ptr =3D new C().withBufferSize(2048);  // use a bigger buffer
>     auto c3ptr =3D new C().withTimeout(1);  // use the default buffer siz=
e=20
> but with a shorter timeout
>     auto c4ptr =3D new C().withBufferSize(2048).withTries(5);  // testing=
:=20
> bump up the number of tries
>
> or
>
>     auto cptr =3D new C();  // usually the defaults are okay
>     auto c2ptr =3D new C(C::BufferSize(2048));  // use a bigger buffer
>     auto c3ptr =3D new C(C::Timeout(1));  // use the default buffer size =
but=20
> with a shorter timeout
>     auto c4ptr =3D new C(C::BufferSize(2048), C::Tries(5));  // testing:=
=20
> bump up the number of tries
>
> or (the most conservative way to rewrite our existing code)
>
>     static constexpr int default_buffer_size =3D 1024;
>     static constexpr int default_timeout =3D 10;
>     static constexpr int default_tries =3D 3;
>     C() : buffer_size_(default_buffer_size), timeout_(default_timeout),=
=20
> tries_(default_tries) {}
>     C(int buffer_size, int timeout, int tries) :=20
> buffer_size_(buffer_size), timeout_(timeout), tries_(tries) {}
>
>     auto cptr =3D new C();  // usually the defaults are okay
>     auto c2ptr =3D new C(2048, C::default_timeout, C::default_tries);  //=
=20
> use a bigger buffer
>     auto c3ptr =3D new C(C::default_buffer_size, 1, C::default_tries);  /=
/=20
> use the default buffer size but with a shorter timeout
>     auto c4ptr =3D new C(2048, C::default_timeout, 5);  // testing: bump =
up=20
> the number of tries
>
> I don't really want to make it *easier* for people to write the "function=
=20
> taking tons of defaulted parameters" antipattern.
> Let's teach people how to avoid the use of defaulted parameters, instead.
>
> =E2=80=93Arthur
>
>
> On Monday, August 17, 2015 at 11:58:41 AM UTC-7, Bo Persson wrote:
>>
>> On 2015-08-17 20:37, Arthur Tchaikovsky wrote:=20
>> > I would really appreciate some feedback from people, or is this=20
>> proposal=20
>> > so uninteresting that there is no point in wasting keyboard on it?=20
>>
>> You might wonder how widely used it will be?=20
>>
>> If not all parameters are of the same type, you can already get some of=
=20
>> the effect with a few overloads:=20
>>
>>      void f(int a =3D 0, string b =3D "1",=20
>>             complex<double> c =3D 2.0, type4 d =3D 3);=20
>>
>>      inline void f(int a, complex<double> c)=20
>>      { f(a, "1", c, 3); }=20
>>
>>      inline void f(string b, complex<double> c)=20
>>      { f(0, b, c, 3); }=20
>>
>> assuming that d is put last because you hardly ever want to change the=
=20
>> default.=20
>>
>> Just saying that you can already do this without a language change.=20
>>
>>
>>     Bo Persson=20
>>
>>
>>
>> >=20
>> > On Saturday, 15 August 2015 17:49:50 UTC+1, Arthur Tchaikovsky wrote:=
=20
>> >=20
>> >     Hi,=20
>> >     Does anyone see helpfulness of such solution:=20
>> >     Having fnc:=20
>> >=20
>> >     void f(int a =3D 0, int b =3D 1, int c =3D 2, int d =3D 3);=20
>> >=20
>> >     I think that it would be nice to be able to say whilst calling it=
=20
>> >     and requiring only some of those args to be non-default:=20
>> >=20
>> >     f(default,2,default,4);=20
>> >=20
>> >     Thoughts?=20
>> >=20
>> >=20
>>
>>
>>

--=20

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

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

<div dir=3D"ltr">&quot;I would MUCH rather just rewrite all these construct=
ors&quot;<br><br>But did you do it or simply wish that at some point you wi=
ll find the time (and will) to do it, but in the mean time you are still us=
ing those &quot;old&quot; constructors? Because I also would MUCH rather ha=
ve C++ cleaned up, yet this will never happen, and I need to use C++ in its=
 current state. What I wish is very different to what I have.<br><br>And as=
 for you saying that defaulted constructors are antipattern, is that a fact=
 or it is simply your opinion?<br><br>On Monday, 17 August 2015 23:52:24 UT=
C+1, Arthur O&#39;Dwyer  wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr">I work on a codebase where this feature would have lots o=
f use-cases, because we have lots of classes whose constructors have defaul=
ted parameters:<div><br></div><div>=C2=A0 =C2=A0 C(int buffer_size =3D 1024=
, int timeout =3D 10, int tries =3D 3) : buffer_size_(buffer_size), timeout=
_(timeout), tries_(tries) {}</div><div><br></div><div>=C2=A0 =C2=A0 auto cp=
tr =3D new C(); =C2=A0// usually the defaults are okay</div><div>=C2=A0 =C2=
=A0 auto c2ptr =3D new C(2048); =C2=A0// use a bigger buffer<br>=C2=A0 =C2=
=A0 auto c3ptr =3D new C(1024, 1); =C2=A0// use the default buffer size but=
 with a shorter timeout</div><div>=C2=A0 =C2=A0 auto c4ptr =3D new C(2048, =
10, 5); =C2=A0// testing: bump up the number of tries</div><div><br></div><=
div>It would be marginally more convenient (and refactor-proof) to be able =
to write</div><div><br></div><div><div>=C2=A0 =C2=A0 auto cptr =3D new C();=
 =C2=A0// usually the defaults are okay</div><div>=C2=A0 =C2=A0 auto c2ptr =
=3D new C(2048); =C2=A0// use a bigger buffer<br>=C2=A0 =C2=A0 auto c3ptr =
=3D new C(default, 1); =C2=A0// use the default buffer size but with a shor=
ter timeout</div><div>=C2=A0 =C2=A0 auto c4ptr =3D new C(2048,=C2=A0default=
, 5); =C2=A0// testing: bump up the number of tries</div><div><br></div><di=
v>However, I consider defaulted parameters in general to be a huge antipatt=
ern, and this constructor pattern in particular to be even worse.</div><div=
>I would MUCH rather just rewrite all these constructors so that they could=
 be used as</div><div><br></div><div>=C2=A0 =C2=A0 auto cptr =3D new C(); =
=C2=A0// usually the defaults are okay</div><div>=C2=A0 =C2=A0 auto c2ptr =
=3D new C().withBufferSize(2048); =C2=A0// use a bigger buffer<br>=C2=A0 =
=C2=A0 auto c3ptr =3D new C().withTimeout(1); =C2=A0// use the default buff=
er size but with a shorter timeout</div><div>=C2=A0 =C2=A0 auto c4ptr =3D n=
ew C().withBufferSize(2048).<wbr>withTries(5); =C2=A0// testing: bump up th=
e number of tries</div><div><br></div><div>or</div><div><br></div><div><div=
>=C2=A0 =C2=A0 auto cptr =3D new C(); =C2=A0// usually the defaults are oka=
y</div><div>=C2=A0 =C2=A0 auto c2ptr =3D new C(C::BufferSize(2048)); =C2=A0=
// use a bigger buffer<br>=C2=A0 =C2=A0 auto c3ptr =3D new C(C::Timeout(1))=
; =C2=A0// use the default buffer size but with a shorter timeout</div><div=
>=C2=A0 =C2=A0 auto c4ptr =3D new C(C::BufferSize(2048), C::Tries(5)); =C2=
=A0// testing: bump up the number of tries</div></div><div><br></div><div>o=
r (the most conservative way to rewrite our existing code)</div><div><br></=
div><div>=C2=A0 =C2=A0 static constexpr int default_buffer_size =3D 1024;</=
div><div>=C2=A0 =C2=A0 static constexpr int default_timeout =3D 10;</div><d=
iv></div><div>=C2=A0 =C2=A0 static constexpr int default_tries =3D 3;</div>=
<div></div><div>=C2=A0 =C2=A0 C() : buffer_size_(default_buffer_<wbr>size),=
 timeout_(default_timeout), tries_(default_tries) {}<br></div><div><div><di=
v>=C2=A0 =C2=A0 C(int buffer_size, int timeout, int tries) : buffer_size_(b=
uffer_size), timeout_(timeout), tries_(tries) {}</div><div></div></div></di=
v><div><br></div><div>=C2=A0 =C2=A0 auto cptr =3D new C(); =C2=A0// usually=
 the defaults are okay<br></div><div><div>=C2=A0 =C2=A0 auto c2ptr =3D new =
C(2048, C::default_timeout, C::default_tries); =C2=A0// use a bigger buffer=
<br>=C2=A0 =C2=A0 auto c3ptr =3D new C(C::default_buffer_size, 1, C::defaul=
t_tries); =C2=A0// use the default buffer size but with a shorter timeout</=
div><div>=C2=A0 =C2=A0 auto c4ptr =3D new C(2048, C::default_timeout, 5); =
=C2=A0// testing: bump up the number of tries</div></div><div><br></div><di=
v>I don&#39;t really want to make it <i>easier</i> for people to write the =
&quot;function taking tons of defaulted parameters&quot; antipattern.</div>=
<div>Let&#39;s teach people how to avoid the use of defaulted parameters, i=
nstead.</div><div><br></div><div>=E2=80=93Arthur</div><div><br></div><div><=
br></div>On Monday, August 17, 2015 at 11:58:41 AM UTC-7, Bo Persson wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">On 2015-08-17 20:37, Arthur Tchaiko=
vsky wrote:
<br>&gt; I would really appreciate some feedback from people, or is this pr=
oposal
<br>&gt; so uninteresting that there is no point in wasting keyboard on it?
<br>
<br>You might wonder how widely used it will be?
<br>
<br>If not all parameters are of the same type, you can already get some of=
=20
<br>the effect with a few overloads:
<br>
<br>=C2=A0 =C2=A0 =C2=A0void f(int a =3D 0, string b =3D &quot;1&quot;,
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 complex&lt;double&gt; c =3D 2=
..0, type4 d =3D 3);
<br>
<br>=C2=A0 =C2=A0 =C2=A0inline void f(int a, complex&lt;double&gt; c)
<br>=C2=A0 =C2=A0 =C2=A0{ f(a, &quot;1&quot;, c, 3); }
<br>
<br>=C2=A0 =C2=A0 =C2=A0inline void f(string b, complex&lt;double&gt; c)
<br>=C2=A0 =C2=A0 =C2=A0{ f(0, b, c, 3); }
<br>
<br>assuming that d is put last because you hardly ever want to change the=
=20
<br>default.
<br>
<br>Just saying that you can already do this without a language change.
<br>
<br>
<br>=C2=A0 =C2=A0 Bo Persson
<br>
<br>
<br>
<br>&gt;
<br>&gt; On Saturday, 15 August 2015 17:49:50 UTC+1, Arthur Tchaikovsky wro=
te:
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 Hi,
<br>&gt; =C2=A0 =C2=A0 Does anyone see helpfulness of such solution:
<br>&gt; =C2=A0 =C2=A0 Having fnc:
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 void f(int a =3D 0, int b =3D 1, int c =3D 2, int d =
=3D 3);
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 I think that it would be nice to be able to say whil=
st calling it
<br>&gt; =C2=A0 =C2=A0 and requiring only some of those args to be non-defa=
ult:
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 f(default,2,default,4);
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 Thoughts?
<br>&gt;
<br>&gt;
<br>
<br>
<br></blockquote></div></div></blockquote></div>

<p></p>

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

------=_Part_4030_460870604.1439889620237--
------=_Part_4029_420810057.1439889620237--

.

------=_Part_2571_738170135.1439889983683
Content-Type: multipart/alternative;
 boundary="----=_Part_2572_312150191.1439889983683"

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

@dgutson
I've typed the phrase in google, nothing came up on first page.=20
So to your reply I say:
I think you should be more polite, and instead of say what you've just=20
said, you should say:
"Hi, I've already proposed something identical really, great to have=20
someone who thinks along the same lines ;)"

But no, instead of being civilized and pleasant you've decided to post=20
smart as** comment. And you consider yourself a professional? Unbelievable.

On Monday, 17 August 2015 19:56:35 UTC+1, dgutson wrote:
>
>
> El 15/8/2015 13:49, "Arthur Tchaikovsky" <atch...@gmail.com <javascript:>=
>=20
> escribi=C3=B3:
> >
> > Hi,=20
> > Does anyone see helpfulness of such solution:
> > Having fnc:
> >
> > void f(int a =3D 0, int b =3D 1, int c =3D 2, int d =3D 3);
> >
> > I think that it would be nice to be able to say whilst calling it and=
=20
> requiring only some of those args to be non-default:
> >
> > f(default,2,default,4);
> >
> > Thoughts?
>
> I think you should google better ;-)
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1466.pdf
>
> >
> >
> >
> >
> >
> > --=20
> >
> > ---=20
> > You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an email to std-proposal...@isocpp.org <javascript:>.
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..
> > Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

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

<div dir=3D"ltr">@dgutson<br>I&#39;ve typed the phrase in google, nothing c=
ame up on first page. <br>So to your reply I say:<br>I think you should be =
more polite, and instead of say what you&#39;ve just said, you should say:<=
br>&quot;Hi, I&#39;ve already proposed something identical really, great to=
 have someone who thinks along the same lines ;)&quot;<br><br>But no, inste=
ad of being civilized and pleasant you&#39;ve decided to post smart as** co=
mment. And you consider yourself a professional? Unbelievable.<br><br>On Mo=
nday, 17 August 2015 19:56:35 UTC+1, dgutson  wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><p dir=3D"ltr"><br>
El 15/8/2015 13:49, &quot;Arthur Tchaikovsky&quot; &lt;<a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"27Jwz1WkAwAJ" rel=3D"nofollo=
w" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=
=3D"this.href=3D&#39;javascript:&#39;;return true;">atch...@gmail.com</a>&g=
t; escribi=C3=B3:<br>
&gt;<br>
&gt; Hi, <br>
&gt; Does anyone see helpfulness of such solution:<br>
&gt; Having fnc:<br>
&gt;<br>
&gt; void f(int a =3D 0, int b =3D 1, int c =3D 2, int d =3D 3);<br>
&gt;<br>
&gt; I think that it would be nice to be able to say whilst calling it and =
requiring only some of those args to be non-default:<br>
&gt;<br>
&gt; f(default,2,default,4);<br>
&gt;<br>
&gt; Thoughts?</p>
<p dir=3D"ltr">I think you should google better ;-)</p>
<p dir=3D"ltr"><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/paper=
s/2003/n1466.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc=
1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2003%2Fn1466.pdf\46sa\75D\46sntz\0751\46u=
sg\75AFQjCNH6n-B7857cuj_lMr4yqOp36CJ-rg&#39;;return true;" onclick=3D"this.=
href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fj=
tc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2003%2Fn1466.pdf\46sa\75D\46sntz\0751\4=
6usg\75AFQjCNH6n-B7857cuj_lMr4yqOp36CJ-rg&#39;;return true;">http://www.ope=
n-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2003/<wbr>n1466.pdf</a><br></p>
<p dir=3D"ltr">&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; -- <br>
&gt;<br>
&gt; --- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"27Jwz1WkAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">std-proposal...@<wbr>isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"27Jwz1WkAwAJ" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=
=3D&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this=
..href=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39=
;;return true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isoc=
pp.org/group/std-proposals/&#39;;return true;">http://groups.google.com/a/<=
wbr>isocpp.org/group/std-<wbr>proposals/</a>.<br>
</p>
</blockquote></div>

<p></p>

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

------=_Part_2572_312150191.1439889983683--
------=_Part_2571_738170135.1439889983683--

.

------=_Part_4344_1260351735.1439890023398
Content-Type: multipart/alternative;
 boundary="----=_Part_4345_374877958.1439890023399"

------=_Part_4345_374877958.1439890023399
Content-Type: text/plain; charset=UTF-8


>
>
> f(default,2,default,4);
>
> I think that named arguments built into the language would solve the same
problem and in a more general way:

f(b : 2, d : 4);

I recall there was a paper about it somewhere at some point. I do not know
if it is the last one though:

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




--

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

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><br>f(default,2,default,4);<br><br></div></blockquote><div>I think that=
 named arguments built into the language would solve the same problem and i=
n a more general way:</div><div><br></div><div>f(b : 2, d : 4);</div><div><=
br></div><div>I recall there was a paper about it somewhere at some point. =
I do not know if it is the last one though:</div><div><br></div><div>http:/=
/www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4172.htm<br></div><div><=
br></div><div><br></div><div>=C2=A0</div></div>

<p></p>

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

------=_Part_4345_374877958.1439890023399--
------=_Part_4344_1260351735.1439890023398--

.

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

Am 15.08.2015 18:49 schrieb "Arthur Tchaikovsky" <atch.cpp@gmail.com>:
>
> Hi,
> Does anyone see helpfulness of such solution:
> Having fnc:
>
> void f(int a = 0, int b = 1, int c = 2, int d = 3);
>
> I think that it would be nice to be able to say whilst calling it and
requiring only some of those args to be non-default:
>
> f(default,2,default,4);
>
> Thoughts?
>

I would also wanna solve this with named arguments

  f(.b = 2, .d = 4)

And index based

  f([1] = 2, [3] = 4)

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

--

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

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

<p dir=3D"ltr"><br>
Am 15.08.2015 18:49 schrieb &quot;Arthur Tchaikovsky&quot; &lt;<a href=3D"m=
ailto:atch.cpp@gmail.com">atch.cpp@gmail.com</a>&gt;:<br>
&gt;<br>
&gt; Hi, <br>
&gt; Does anyone see helpfulness of such solution:<br>
&gt; Having fnc:<br>
&gt;<br>
&gt; void f(int a =3D 0, int b =3D 1, int c =3D 2, int d =3D 3);<br>
&gt;<br>
&gt; I think that it would be nice to be able to say whilst calling it and =
requiring only some of those args to be non-default:<br>
&gt;<br>
&gt; f(default,2,default,4);<br>
&gt;<br>
&gt; Thoughts?<br>
&gt;</p>
<p dir=3D"ltr">I would also wanna solve this with named arguments</p>
<p dir=3D"ltr">=C2=A0 f(.b =3D 2, .d =3D 4)</p>
<p dir=3D"ltr">And index based</p>
<p dir=3D"ltr">=C2=A0 f([1] =3D 2, [3] =3D 4)</p>
<p dir=3D"ltr">&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; -- <br>
&gt;<br>
&gt; --- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-propos=
als/</a>.<br>
</p>

<p></p>

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

--089e0118482c730407051d92a043--

.

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

Am 15.08.2015 18:49 schrieb "Arthur Tchaikovsky" <atch.cpp@gmail.com>:
>
> Hi,
> Does anyone see helpfulness of such solution:
> Having fnc:
>
> void f(int a = 0, int b = 1, int c = 2, int d = 3);
>
> I think that it would be nice to be able to say whilst calling it and
requiring only some of those args to be non-default:
>
> f(default,2,default,4);
>
> Thoughts?

And if you support the default indicator here, please allow it in aggregate
initialization aswell to mean either value initialize or take the inclass
initializer.

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

--

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

--047d7b10ca837cfd79051d92a0ce
Content-Type: text/html; charset=UTF-8

<p dir="ltr"><br>
Am 15.08.2015 18:49 schrieb &quot;Arthur Tchaikovsky&quot; &lt;<a href="mailto:atch.cpp@gmail.com">atch.cpp@gmail.com</a>&gt;:<br>
&gt;<br>
&gt; Hi, <br>
&gt; Does anyone see helpfulness of such solution:<br>
&gt; Having fnc:<br>
&gt;<br>
&gt; void f(int a = 0, int b = 1, int c = 2, int d = 3);<br>
&gt;<br>
&gt; I think that it would be nice to be able to say whilst calling it and requiring only some of those args to be non-default:<br>
&gt;<br>
&gt; f(default,2,default,4);<br>
&gt;<br>
&gt; Thoughts?</p>
<p dir="ltr">And if you support the default indicator here, please allow it in aggregate initialization aswell to mean either value initialize or take the inclass initializer.</p>
<p dir="ltr">&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; -- <br>
&gt;<br>
&gt; --- <br>
&gt; You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</p>

<p></p>

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

--047d7b10ca837cfd79051d92a0ce--

.

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

El 18/8/2015 6:26, "Arthur Tchaikovsky" <atch.cpp@gmail.com> escribi=C3=B3:
>
> @dgutson
> I've typed the phrase in google, nothing came up on first page.
> So to your reply I say:
> I think you should be more polite, and instead of say what you've just
said, you should say:
> "Hi, I've already proposed something identical really, great to have
someone who thinks along the same lines ;)"
>
> But no, instead of being civilized and pleasant you've decided to post
smart as** comment. And you consider yourself a professional? Unbelievable.

I'm just someone with different sense of humor and who wrote something that
also considered overloading more than 10 years ago. You might wonder now
why the proposal didn't suceed then, in case you become unoffended.

>
> On Monday, 17 August 2015 19:56:35 UTC+1, dgutson wrote:
>>
>>
>> El 15/8/2015 13:49, "Arthur Tchaikovsky" <atch...@gmail.com> escribi=C3=
=B3:
>> >
>> > Hi,
>> > Does anyone see helpfulness of such solution:
>> > Having fnc:
>> >
>> > void f(int a =3D 0, int b =3D 1, int c =3D 2, int d =3D 3);
>> >
>> > I think that it would be nice to be able to say whilst calling it and
requiring only some of those args to be non-default:
>> >
>> > f(default,2,default,4);
>> >
>> > Thoughts?
>>
>> I think you should google better ;-)
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1466.pdf
>>
>> >
>> >
>> >
>> >
>> >
>> > --
>> >
>> > ---
>> > You received this message because you are subscribed to the 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.
>> > To post to this group, send email to std-pr...@isocpp.org.
>>
>> > Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/.

--=20

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

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

<p dir=3D"ltr"><br>
El 18/8/2015 6:26, &quot;Arthur Tchaikovsky&quot; &lt;<a href=3D"mailto:atc=
h.cpp@gmail.com">atch.cpp@gmail.com</a>&gt; escribi=C3=B3:<br>
&gt;<br>
&gt; @dgutson<br>
&gt; I&#39;ve typed the phrase in google, nothing came up on first page. <b=
r>
&gt; So to your reply I say:<br>
&gt; I think you should be more polite, and instead of say what you&#39;ve =
just said, you should say:<br>
&gt; &quot;Hi, I&#39;ve already proposed something identical really, great =
to have someone who thinks along the same lines ;)&quot;<br>
&gt;<br>
&gt; But no, instead of being civilized and pleasant you&#39;ve decided to =
post smart as** comment. And you consider yourself a professional? Unbeliev=
able.</p>
<p dir=3D"ltr">I&#39;m just someone with different sense of humor and who w=
rote something that also considered overloading more than 10 years ago. You=
 might wonder now why the proposal didn&#39;t suceed then, in case you beco=
me unoffended.</p>
<p dir=3D"ltr">&gt;<br>
&gt; On Monday, 17 August 2015 19:56:35 UTC+1, dgutson wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; El 15/8/2015 13:49, &quot;Arthur Tchaikovsky&quot; &lt;<a href=3D"=
mailto:atch...@gmail.com">atch...@gmail.com</a>&gt; escribi=C3=B3:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Hi, <br>
&gt;&gt; &gt; Does anyone see helpfulness of such solution:<br>
&gt;&gt; &gt; Having fnc:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; void f(int a =3D 0, int b =3D 1, int c =3D 2, int d =3D 3);<b=
r>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I think that it would be nice to be able to say whilst callin=
g it and requiring only some of those args to be non-default:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; f(default,2,default,4);<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Thoughts?<br>
&gt;&gt;<br>
&gt;&gt; I think you should google better ;-)<br>
&gt;&gt;<br>
&gt;&gt; <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003=
/n1466.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1466.p=
df</a><br>
&gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; -- <br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; --- <br>
&gt;&gt; &gt; You received this message because you are subscribed to the G=
oogle Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt;&gt; &gt; To unsubscribe from this group and stop receiving emails from=
 it, send an email to <a href=3D"mailto:std-proposal...@isocpp.org">std-pro=
posal...@isocpp.org</a>.<br>
&gt;&gt; &gt; To post to this group, send email to <a href=3D"mailto:std-pr=
....@isocpp.org">std-pr...@isocpp.org</a>.<br>
&gt;&gt;<br>
&gt;&gt; &gt; Visit this group at <a href=3D"http://groups.google.com/a/iso=
cpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/s=
td-proposals/</a>.<br>
&gt;<br>
&gt; -- <br>
&gt;<br>
&gt; --- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-propos=
als/</a>.<br>
</p>

<p></p>

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

--001a1140f16e2384fe051d92a27f--

.

On 18 August 2015 at 12:27, Germ=C3=A1n Diago <germandiago@gmail.com> wrote=
:
>>
>> f(default,2,default,4);
>>
> I think that named arguments built into the language would solve the same
> problem and in a more general way:
>
> f(b : 2, d : 4);
>
> I recall there was a paper about it somewhere at some point. I do not kno=
w
> if it is the last one though:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4172.htm


That paper was rejected: http://cplusplus.github.io/EWG/ewg-closed.html#150
Every other attempt at it has been rejected as well.

--=20

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

.

------=_Part_4056_1077283914.1439890845862
Content-Type: multipart/alternative;
 boundary="----=_Part_4057_732610153.1439890845863"

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

Fair play, bit of a friendly fire I suppose. ;)

On Tuesday, 18 August 2015 10:35:29 UTC+1, dgutson wrote:
>
>
> El 18/8/2015 6:26, "Arthur Tchaikovsky" <atch...@gmail.com <javascript:>>=
=20
> escribi=C3=B3:
> >
> > @dgutson
> > I've typed the phrase in google, nothing came up on first page.=20
> > So to your reply I say:
> > I think you should be more polite, and instead of say what you've just=
=20
> said, you should say:
> > "Hi, I've already proposed something identical really, great to have=20
> someone who thinks along the same lines ;)"
> >
> > But no, instead of being civilized and pleasant you've decided to post=
=20
> smart as** comment. And you consider yourself a professional? Unbelievabl=
e.
>
> I'm just someone with different sense of humor and who wrote something=20
> that also considered overloading more than 10 years ago. You might wonder=
=20
> now why the proposal didn't suceed then, in case you become unoffended.
>
> >
> > On Monday, 17 August 2015 19:56:35 UTC+1, dgutson wrote:
> >>
> >>
> >> El 15/8/2015 13:49, "Arthur Tchaikovsky" <atch...@gmail.com> escribi=
=C3=B3:
> >> >
> >> > Hi,=20
> >> > Does anyone see helpfulness of such solution:
> >> > Having fnc:
> >> >
> >> > void f(int a =3D 0, int b =3D 1, int c =3D 2, int d =3D 3);
> >> >
> >> > I think that it would be nice to be able to say whilst calling it an=
d=20
> requiring only some of those args to be non-default:
> >> >
> >> > f(default,2,default,4);
> >> >
> >> > Thoughts?
> >>
> >> I think you should google better ;-)
> >>
> >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1466.pdf
> >>
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > --=20
> >> >
> >> > ---=20
> >> > You received this message because you are subscribed to the Google=
=20
> Groups "ISO C++ Standard - Future Proposals" group.
> >> > To unsubscribe from this group and stop receiving emails from it,=20
> send an email to std-proposal...@isocpp.org.
> >> > To post to this group, send email to std-pr...@isocpp.org.
> >>
> >> > Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
> >
> > --=20
> >
> > ---=20
> > You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an email to std-proposal...@isocpp.org <javascript:>.
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..
> > Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

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

<div dir=3D"ltr">Fair play, bit of a friendly fire I suppose. ;)<br><br>On =
Tuesday, 18 August 2015 10:35:29 UTC+1, dgutson  wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><p dir=3D"ltr"><br>
El 18/8/2015 6:26, &quot;Arthur Tchaikovsky&quot; &lt;<a href=3D"javascript=
:" target=3D"_blank" gdf-obfuscated-mailto=3D"9GmkvEvUAwAJ" rel=3D"nofollow=
" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D=
"this.href=3D&#39;javascript:&#39;;return true;">atch...@gmail.com</a>&gt; =
escribi=C3=B3:<br>
&gt;<br>
&gt; @dgutson<br>
&gt; I&#39;ve typed the phrase in google, nothing came up on first page. <b=
r>
&gt; So to your reply I say:<br>
&gt; I think you should be more polite, and instead of say what you&#39;ve =
just said, you should say:<br>
&gt; &quot;Hi, I&#39;ve already proposed something identical really, great =
to have someone who thinks along the same lines ;)&quot;<br>
&gt;<br>
&gt; But no, instead of being civilized and pleasant you&#39;ve decided to =
post smart as** comment. And you consider yourself a professional? Unbeliev=
able.</p>
<p dir=3D"ltr">I&#39;m just someone with different sense of humor and who w=
rote something that also considered overloading more than 10 years ago. You=
 might wonder now why the proposal didn&#39;t suceed then, in case you beco=
me unoffended.</p>
<p dir=3D"ltr">&gt;<br>
&gt; On Monday, 17 August 2015 19:56:35 UTC+1, dgutson wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; El 15/8/2015 13:49, &quot;Arthur Tchaikovsky&quot; &lt;<a>atch...@=
gmail.com</a>&gt; escribi=C3=B3:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Hi, <br>
&gt;&gt; &gt; Does anyone see helpfulness of such solution:<br>
&gt;&gt; &gt; Having fnc:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; void f(int a =3D 0, int b =3D 1, int c =3D 2, int d =3D 3);<b=
r>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I think that it would be nice to be able to say whilst callin=
g it and requiring only some of those args to be non-default:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; f(default,2,default,4);<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Thoughts?<br>
&gt;&gt;<br>
&gt;&gt; I think you should google better ;-)<br>
&gt;&gt;<br>
&gt;&gt; <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003=
/n1466.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc=
22%2Fwg21%2Fdocs%2Fpapers%2F2003%2Fn1466.pdf\46sa\75D\46sntz\0751\46usg\75A=
FQjCNH6n-B7857cuj_lMr4yqOp36CJ-rg&#39;;return true;" onclick=3D"this.href=
=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%=
2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2003%2Fn1466.pdf\46sa\75D\46sntz\0751\46usg=
\75AFQjCNH6n-B7857cuj_lMr4yqOp36CJ-rg&#39;;return true;">http://www.open-st=
d.org/jtc1/<wbr>sc22/wg21/docs/papers/2003/<wbr>n1466.pdf</a><br>
&gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; -- <br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; --- <br>
&gt;&gt; &gt; You received this message because you are subscribed to the G=
oogle Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt;&gt; &gt; To unsubscribe from this group and stop receiving emails from=
 it, send an email to <a>std-proposal...@isocpp.org</a>.<br>
&gt;&gt; &gt; To post to this group, send email to <a>std-pr...@isocpp.org<=
/a>.<br>
&gt;&gt;<br>
&gt;&gt; &gt; Visit this group at <a href=3D"http://groups.google.com/a/iso=
cpp.org/group/std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.org/group/std-propo=
sals/&#39;;return true;" onclick=3D"this.href=3D&#39;http://groups.google.c=
om/a/isocpp.org/group/std-proposals/&#39;;return true;">http://groups.googl=
e.com/a/<wbr>isocpp.org/group/std-<wbr>proposals/</a>.<br>
&gt;<br>
&gt; -- <br>
&gt;<br>
&gt; --- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"9GmkvEvUAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">std-proposal...@<wbr>isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"9GmkvEvUAwAJ" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=
=3D&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this=
..href=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39=
;;return true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isoc=
pp.org/group/std-proposals/&#39;;return true;">http://groups.google.com/a/<=
wbr>isocpp.org/group/std-<wbr>proposals/</a>.<br>
</p>
</blockquote></div>

<p></p>

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

------=_Part_4057_732610153.1439890845863--
------=_Part_4056_1077283914.1439890845862--

.

------=_Part_84_713134243.1439890939278
Content-Type: multipart/alternative;
 boundary="----=_Part_85_837242700.1439890939278"

------=_Part_85_837242700.1439890939278
Content-Type: text/plain; charset=UTF-8

That genuinely seems pointless/silly to me, unless you can provide some
convincing use cases.

On Tuesday, 18 August 2015 10:34:39 UTC+1, Johannes Schaub wrote:
>
>
> Am 15.08.2015 18:49 schrieb "Arthur Tchaikovsky" <atch...@gmail.com
> <javascript:>>:
> >
> > Hi,
> > Does anyone see helpfulness of such solution:
> > Having fnc:
> >
> > void f(int a = 0, int b = 1, int c = 2, int d = 3);
> >
> > I think that it would be nice to be able to say whilst calling it and
> requiring only some of those args to be non-default:
> >
> > f(default,2,default,4);
> >
> > Thoughts?
> >
>
> I would also wanna solve this with named arguments
>
>   f(.b = 2, .d = 4)
>
> And index based
>
>   f([1] = 2, [3] = 4)
>
> >
> >
> >
> >
> > --
> >
> > ---
> > You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to std-proposal...@isocpp.org <javascript:>.
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> > Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr">That genuinely seems pointless/silly to me, unless you can=
 provide some convincing use cases.<br><br>On Tuesday, 18 August 2015 10:34=
:39 UTC+1, Johannes Schaub  wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><p dir=3D"ltr"><br>
Am 15.08.2015 18:49 schrieb &quot;Arthur Tchaikovsky&quot; &lt;<a href=3D"j=
avascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"CFhE-z_UAwAJ" rel=3D=
"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" o=
nclick=3D"this.href=3D&#39;javascript:&#39;;return true;">atch...@gmail.com=
</a>&gt;:<br>
&gt;<br>
&gt; Hi, <br>
&gt; Does anyone see helpfulness of such solution:<br>
&gt; Having fnc:<br>
&gt;<br>
&gt; void f(int a =3D 0, int b =3D 1, int c =3D 2, int d =3D 3);<br>
&gt;<br>
&gt; I think that it would be nice to be able to say whilst calling it and =
requiring only some of those args to be non-default:<br>
&gt;<br>
&gt; f(default,2,default,4);<br>
&gt;<br>
&gt; Thoughts?<br>
&gt;</p>
<p dir=3D"ltr">I would also wanna solve this with named arguments</p>
<p dir=3D"ltr">=C2=A0 f(.b =3D 2, .d =3D 4)</p>
<p dir=3D"ltr">And index based</p>
<p dir=3D"ltr">=C2=A0 f([1] =3D 2, [3] =3D 4)</p>
<p dir=3D"ltr">&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; -- <br>
&gt;<br>
&gt; --- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"CFhE-z_UAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">std-proposal...@<wbr>isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"CFhE-z_UAwAJ" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=
=3D&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this=
..href=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39=
;;return true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isoc=
pp.org/group/std-proposals/&#39;;return true;">http://groups.google.com/a/<=
wbr>isocpp.org/group/std-<wbr>proposals/</a>.<br>
</p>
</blockquote></div>

<p></p>

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

------=_Part_85_837242700.1439890939278--
------=_Part_84_713134243.1439890939278--

.

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

Am 18.08.2015 11:42 schrieb "Arthur Tchaikovsky" <atch.cpp@gmail.com>:
>
> That genuinely seems pointless/silly to me, unless you can provide some
convincing use cases.
>

These are designated initializers and why stop at making initialization
uniform just before designated initializers?

It seems natural to me to allow them in function argument lists including
for constructors. And the index notion looks like an elegant solution to
skip arguments.

> On Tuesday, 18 August 2015 10:34:39 UTC+1, Johannes Schaub wrote:
>>
>>
>> Am 15.08.2015 18:49 schrieb "Arthur Tchaikovsky" <atch...@gmail.com>:
>> >
>> > Hi,
>> > Does anyone see helpfulness of such solution:
>> > Having fnc:
>> >
>> > void f(int a = 0, int b = 1, int c = 2, int d = 3);
>> >
>> > I think that it would be nice to be able to say whilst calling it and
requiring only some of those args to be non-default:
>> >
>> > f(default,2,default,4);
>> >
>> > Thoughts?
>> >
>>
>> I would also wanna solve this with named arguments
>>
>>   f(.b = 2, .d = 4)
>>
>> And index based
>>
>>   f([1] = 2, [3] = 4)
>>
>> >
>> >
>> >
>> >
>> > --
>> >
>> > ---
>> > You received this message because you are subscribed to the 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.
>> > To post to this group, send email to std-pr...@isocpp.org.
>>
>> > Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

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

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

<p dir=3D"ltr"><br>
Am 18.08.2015 11:42 schrieb &quot;Arthur Tchaikovsky&quot; &lt;<a href=3D"m=
ailto:atch.cpp@gmail.com">atch.cpp@gmail.com</a>&gt;:<br>
&gt;<br>
&gt; That genuinely seems pointless/silly to me, unless you can provide som=
e convincing use cases.<br>
&gt;</p>
<p dir=3D"ltr">These are designated initializers and why stop at making ini=
tialization uniform just before designated initializers? </p>
<p dir=3D"ltr">It seems natural to me to allow them in function argument li=
sts including for constructors. And the index notion looks like an elegant =
solution to skip arguments.<br></p>
<p dir=3D"ltr">&gt; On Tuesday, 18 August 2015 10:34:39 UTC+1, Johannes Sch=
aub wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Am 15.08.2015 18:49 schrieb &quot;Arthur Tchaikovsky&quot; &lt;<a =
href=3D"mailto:atch...@gmail.com">atch...@gmail.com</a>&gt;:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Hi, <br>
&gt;&gt; &gt; Does anyone see helpfulness of such solution:<br>
&gt;&gt; &gt; Having fnc:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; void f(int a =3D 0, int b =3D 1, int c =3D 2, int d =3D 3);<b=
r>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I think that it would be nice to be able to say whilst callin=
g it and requiring only some of those args to be non-default:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; f(default,2,default,4);<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Thoughts?<br>
&gt;&gt; &gt;<br>
&gt;&gt;<br>
&gt;&gt; I would also wanna solve this with named arguments<br>
&gt;&gt;<br>
&gt;&gt; =C2=A0 f(.b =3D 2, .d =3D 4)<br>
&gt;&gt;<br>
&gt;&gt; And index based<br>
&gt;&gt;<br>
&gt;&gt; =C2=A0 f([1] =3D 2, [3] =3D 4)<br>
&gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; -- <br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; --- <br>
&gt;&gt; &gt; You received this message because you are subscribed to the G=
oogle Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt;&gt; &gt; To unsubscribe from this group and stop receiving emails from=
 it, send an email to <a href=3D"mailto:std-proposal...@isocpp.org">std-pro=
posal...@isocpp.org</a>.<br>
&gt;&gt; &gt; To post to this group, send email to <a href=3D"mailto:std-pr=
....@isocpp.org">std-pr...@isocpp.org</a>.<br>
&gt;&gt;<br>
&gt;&gt; &gt; Visit this group at <a href=3D"http://groups.google.com/a/iso=
cpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/s=
td-proposals/</a>.<br>
&gt;<br>
&gt; -- <br>
&gt;<br>
&gt; --- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-propos=
als/</a>.<br>
</p>

<p></p>

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

--001a113f92c031ac2d051d92ca8c--

.

------=_Part_201_1299394540.1439893335422
Content-Type: multipart/alternative;
 boundary="----=_Part_202_1423641478.1439893335435"

------=_Part_202_1423641478.1439893335435
Content-Type: text/plain; charset=UTF-8

I gotta be honest with you Johann, I simply don't buy it.
And index notion looks anything but elegant solution. That is my opinion of
course.

On Tuesday, 18 August 2015 10:46:19 UTC+1, Johannes Schaub wrote:
>
>
> Am 18.08.2015 11:42 schrieb "Arthur Tchaikovsky" <atch...@gmail.com
> <javascript:>>:
> >
> > That genuinely seems pointless/silly to me, unless you can provide some
> convincing use cases.
> >
>
> These are designated initializers and why stop at making initialization
> uniform just before designated initializers?
>
> It seems natural to me to allow them in function argument lists including
> for constructors. And the index notion looks like an elegant solution to
> skip arguments.
>
> > On Tuesday, 18 August 2015 10:34:39 UTC+1, Johannes Schaub wrote:
> >>
> >>
> >> Am 15.08.2015 18:49 schrieb "Arthur Tchaikovsky" <atch...@gmail.com>:
> >> >
> >> > Hi,
> >> > Does anyone see helpfulness of such solution:
> >> > Having fnc:
> >> >
> >> > void f(int a = 0, int b = 1, int c = 2, int d = 3);
> >> >
> >> > I think that it would be nice to be able to say whilst calling it and
> requiring only some of those args to be non-default:
> >> >
> >> > f(default,2,default,4);
> >> >
> >> > Thoughts?
> >> >
> >>
> >> I would also wanna solve this with named arguments
> >>
> >>   f(.b = 2, .d = 4)
> >>
> >> And index based
> >>
> >>   f([1] = 2, [3] = 4)
> >>
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> >
> >> > ---
> >> > You received this message because you are subscribed to the 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.
> >> > To post to this group, send email to std-pr...@isocpp.org.
> >>
> >> > Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
> >
> > --
> >
> > ---
> > You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to std-proposal...@isocpp.org <javascript:>.
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> > Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr">I gotta be honest with you Johann, I simply don&#39;t buy =
it.<br>And index notion looks anything but elegant solution. That is my opi=
nion of course.<br><br>On Tuesday, 18 August 2015 10:46:19 UTC+1, Johannes =
Schaub  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr"><=
br>
Am 18.08.2015 11:42 schrieb &quot;Arthur Tchaikovsky&quot; &lt;<a href=3D"j=
avascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"HjUVA-PUAwAJ" rel=3D=
"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" o=
nclick=3D"this.href=3D&#39;javascript:&#39;;return true;">atch...@gmail.com=
</a>&gt;:<br>
&gt;<br>
&gt; That genuinely seems pointless/silly to me, unless you can provide som=
e convincing use cases.<br>
&gt;</p>
<p dir=3D"ltr">These are designated initializers and why stop at making ini=
tialization uniform just before designated initializers? </p>
<p dir=3D"ltr">It seems natural to me to allow them in function argument li=
sts including for constructors. And the index notion looks like an elegant =
solution to skip arguments.<br></p>
<p dir=3D"ltr">&gt; On Tuesday, 18 August 2015 10:34:39 UTC+1, Johannes Sch=
aub wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Am 15.08.2015 18:49 schrieb &quot;Arthur Tchaikovsky&quot; &lt;<a>=
atch...@gmail.com</a>&gt;:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Hi, <br>
&gt;&gt; &gt; Does anyone see helpfulness of such solution:<br>
&gt;&gt; &gt; Having fnc:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; void f(int a =3D 0, int b =3D 1, int c =3D 2, int d =3D 3);<b=
r>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I think that it would be nice to be able to say whilst callin=
g it and requiring only some of those args to be non-default:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; f(default,2,default,4);<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Thoughts?<br>
&gt;&gt; &gt;<br>
&gt;&gt;<br>
&gt;&gt; I would also wanna solve this with named arguments<br>
&gt;&gt;<br>
&gt;&gt; =C2=A0 f(.b =3D 2, .d =3D 4)<br>
&gt;&gt;<br>
&gt;&gt; And index based<br>
&gt;&gt;<br>
&gt;&gt; =C2=A0 f([1] =3D 2, [3] =3D 4)<br>
&gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; -- <br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; --- <br>
&gt;&gt; &gt; You received this message because you are subscribed to the G=
oogle Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt;&gt; &gt; To unsubscribe from this group and stop receiving emails from=
 it, send an email to <a>std-proposal...@isocpp.org</a>.<br>
&gt;&gt; &gt; To post to this group, send email to <a>std-pr...@isocpp.org<=
/a>.<br>
&gt;&gt;<br>
&gt;&gt; &gt; Visit this group at <a href=3D"http://groups.google.com/a/iso=
cpp.org/group/std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.org/group/std-propo=
sals/&#39;;return true;" onclick=3D"this.href=3D&#39;http://groups.google.c=
om/a/isocpp.org/group/std-proposals/&#39;;return true;">http://groups.googl=
e.com/a/<wbr>isocpp.org/group/std-<wbr>proposals/</a>.<br>
&gt;<br>
&gt; -- <br>
&gt;<br>
&gt; --- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"HjUVA-PUAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">std-proposal...@<wbr>isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"HjUVA-PUAwAJ" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=
=3D&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this=
..href=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39=
;;return true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isoc=
pp.org/group/std-proposals/&#39;;return true;">http://groups.google.com/a/<=
wbr>isocpp.org/group/std-<wbr>proposals/</a>.<br>
</p>
</blockquote></div>

<p></p>

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

------=_Part_202_1423641478.1439893335435--
------=_Part_201_1299394540.1439893335422--

.

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

On Tue, Aug 18, 2015 at 10:42 AM, Arthur Tchaikovsky <atch.cpp@gmail.com>
wrote:

> That genuinely seems pointless/silly to me, unless you can provide some
> convincing use cases.
>

On Tuesday, 18 August 2015 10:34:39 UTC+1, Johannes Schaub wrote:
>>
>> I would also wanna solve this with named arguments
>>
>>   f(.b = 2, .d = 4)
>>
>> And index based
>>
>>   f([1] = 2, [3] = 4)
>>
>>
>>
Any use case in which you may end up using 'default' in your proposal is a
use case for these two approaches.  In the first case, it lets you focus on
what parameters are being configured (rather than defaulted) without having
to look at the function declaration, 'f(.b = 2, .d = 4)' is equivalent to
'f(default, 2, default, 4)' and I find the former easier to read.

Using indices is something that I had not considered before in the context
of a regular function call, but I can imagine how 'f([3] = 4)' might be
more readable than 'f(default, default, default, 4)' on two accounts: more
concise and the counting is done for you.

Now, going back from the high level desire to the implementability and
potential issues, these two are allowed as initializers for structs in C
(which is probably where Johannes is comming from), and while the former
('f(.b = 2)') is kind of clean the latter does lead to surprises for
inexperienced programmers:

int a[10] = { [3] = 1, [2] = 5, 6 }; // what values are in the array?

Still, that might be easier than implementing named arguments.  The "named"
arguments work nicely with a 'struct' since the type can be defined only
once, but it leads to different sorts of confusion for functions that may
have multiple declarations:

void f(int a = 1, int b = 2);
void f(int b = 1, int a = 2);  // redeclaration

f( .a = 5 ); // f(5, 2)? f(1, 5)?

Which AFAIK is one of the issues that this form of proposals have faced in
the past.  I recall also some discussions in this forum (or maybe even
papers?) aiming for a syntax that would allow this by enabling
warning/errors when a redeclaration used different names than the original
declaration but I did not see any of those prosper. BTW, forcing the same
name in redeclarations is part of what our internal coding guidelines
mandate and we have tools for verification, not sure about other shops.

Personally I have shifted from liking default arguments to trying to avoid
them if at all possible as they complicate changes in old code (add a new
non-defaulted argument and if unlucky users passing all arguments
explicitly will not fail to compile but do something different than they
intended).

Overall, I find that if a nice clean solution could be reached, it would
benefit the language, on those lines, I'd rather go into solutions that
allow tagging a function as "names are important" (maybe a function
attribute), having the compiler enforce that redeclarations use the same
names for functions tagged as such [optionally allow a name to be dropped,
but not changed, for implementations that might not use some of the
arguments] and then using named arguments in the call seems cleaner than
having to count the number of 'default'. On the other hand, this proposal
is much easier to get into the language.

    David

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Aug 18, 2015 at 10:42 AM, Arthur Tchaikovsky <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:atch.cpp@gmail.com" target=3D"_blank">atch.cpp@gmail.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">That g=
enuinely seems pointless/silly to me, unless you can provide some convincin=
g use cases.<br></div></blockquote><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr">On Tuesday, 18 August 2015 10:34:39 UTC+1, Johannes =
Schaub  wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""><p d=
ir=3D"ltr">I would also wanna solve this with named arguments<br></p>
<p dir=3D"ltr">=C2=A0 f(.b =3D 2, .d =3D 4)</p>
<p dir=3D"ltr">And index based</p>
<p dir=3D"ltr">=C2=A0 f([1] =3D 2, [3] =3D 4)</p>
</span><p dir=3D"ltr"><br></p></blockquote></div></blockquote><div><br>Any =
use case in which you may end up using &#39;default&#39; in your proposal i=
s a use case for these two approaches.=C2=A0 In the first case, it lets you=
 focus on what parameters are being configured (rather than defaulted) with=
out having to look at the function declaration, &#39;f(.b =3D 2, .d =3D 4)&=
#39; is equivalent to &#39;f(default, 2, default, 4)&#39; and I find the fo=
rmer easier to read.<br><br>Using indices is something that I had not consi=
dered before in the context of a regular function call, but I can imagine h=
ow &#39;f([3] =3D 4)&#39; might be more readable than &#39;f(default, defau=
lt, default, 4)&#39; on two accounts: more concise and the counting is done=
 for you.<br><br>Now, going back from the high level desire to the implemen=
tability and potential issues, these two are allowed as initializers for st=
ructs in C (which is probably where Johannes is comming from), and while th=
e former (&#39;f(.b =3D 2)&#39;) is kind of clean the latter does lead to s=
urprises for inexperienced programmers:<br><br>int a[10] =3D { [3] =3D 1, [=
2] =3D 5, 6 }; // what values are in the array?<br><br>Still, that might be=
 easier than implementing named arguments.=C2=A0 The &quot;named&quot; argu=
ments work nicely with a &#39;struct&#39; since the type can be defined onl=
y once, but it leads to different sorts of confusion for functions that may=
 have multiple declarations:<br><br>void f(int a =3D 1, int b =3D 2);<br>vo=
id f(int b =3D 1, int a =3D 2); =C2=A0// redeclaration<br><br>f( .a =3D 5 )=
; // f(5, 2)? f(1, 5)?=C2=A0<br><br>Which AFAIK is one of the issues that t=
his form of proposals have faced in the past.=C2=A0 I recall also some disc=
ussions in this forum (or maybe even papers?) aiming for a syntax that woul=
d allow this by enabling warning/errors when a redeclaration used different=
 names than the original declaration but I did not see any of those prosper=
.. BTW, forcing the same name in redeclarations is part of what our internal=
 coding guidelines mandate and we have tools for verification, not sure abo=
ut other shops.</div><div><br>Personally I have shifted from liking default=
 arguments to trying to avoid them if at all possible as they complicate ch=
anges in old code (add a new non-defaulted argument and if unlucky users pa=
ssing all arguments explicitly will not fail to compile but do something di=
fferent than they intended).<br><br>Overall, I find that if a nice clean so=
lution could be reached, it would benefit the language, on those lines, I&#=
39;d rather go into solutions that allow tagging a function as &quot;names =
are important&quot; (maybe a function attribute), having the compiler enfor=
ce that redeclarations use the same names for functions tagged as such [opt=
ionally allow a name to be dropped, but not changed, for implementations th=
at might not use some of the arguments] and then using named arguments in t=
he call seems cleaner than having to count the number of &#39;default&#39;.=
 On the other hand, this proposal is much easier to get into the language.<=
br><br>=C2=A0 =C2=A0 David</div></div></div></div>

<p></p>

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

--089e0111d0c8812933051d934b4b--

.

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

On Tue, Aug 18, 2015 at 11:22 AM, Arthur Tchaikovsky <atch.cpp@gmail.com>
wrote:

> I gotta be honest with you Johann, I simply don't buy it.
> And index notion looks anything but elegant solution. That is my opinion
> of course.
>
>
You  might not find it elegant, but it is a feature that has been present
in C for some time (to initialize objects) so there is prior art. It is
also tested and the shortcomings are known --at least for initialization,
which is not really the same as defaulting arguments to functions or
constructors.

--

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Aug 18, 2015 at 11:22 AM, Arthur Tchaikovsky <span dir=3D"ltr">=
&lt;<a href=3D"mailto:atch.cpp@gmail.com" target=3D"_blank">atch.cpp@gmail.=
com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
">I gotta be honest with you Johann, I simply don&#39;t buy it.<br>And inde=
x notion looks anything but elegant solution. That is my opinion of course.=
<br><br></div></blockquote><div>=C2=A0</div><div>You =C2=A0might not find i=
t elegant, but it is a feature that has been present in C for some time (to=
 initialize objects) so there is prior art. It is also tested and the short=
comings are known --at least for initialization, which is not really the sa=
me as defaulting arguments to functions or constructors.</div></div></div><=
/div>

<p></p>

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

--001a113fe51e4a3de3051d9355ba--

.

On Tue, Aug 18, 2015 at 1:25 PM, David Rodr=C3=ADguez Ibeas <dibeas@ieee.or=
g> wrote:
>
>
> On Tue, Aug 18, 2015 at 11:22 AM, Arthur Tchaikovsky <atch.cpp@gmail.com>
> wrote:
>>
>> I gotta be honest with you Johann, I simply don't buy it.
>> And index notion looks anything but elegant solution. That is my opinion
>> of course.
>>
>
> You  might not find it elegant, but it is a feature that has been present=
 in
> C for some time (to initialize objects) so there is prior art. It is also
> tested and the shortcomings are known --at least for initialization, whic=
h
> is not really the same as defaulting arguments to functions or constructo=
rs.

Structure members have stable names, function parameters do not and in
fact may have no names. I do find Boost.Parameter named parameters
useful sometimes, but with the existing rules defined by the standard
wrt function declarations I really doubt the named function arguments
will appear in the language as easily as you suggest. I would find
named member initializations for structs extremely useful though, as I
constantly find myself worrying that braced initialization will get
screwed when the order of the struct members changes.

About the original proposal (i.e. the use of the 'default' keyword to
designate default argument values), I like it. Not that I often need
something like that but sometimes that would be useful, at least to
decouple the interface from the user.

--=20

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

.

------=_Part_4330_1438715088.1439895527805
Content-Type: multipart/alternative;
 boundary="----=_Part_4331_1236664248.1439895527806"

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

Yes, but this is C++ not C,  and we are trying to make C++ more modern not=
=20
stick with the past, right?
Secondly, the idea that is designated initializers, seem to me that it is=
=20
violation of encapsulation, so really, personally I am against it/don't=20
like it.

On Tuesday, 18 August 2015 11:25:13 UTC+1, David Rodr=C3=ADguez Ibeas wrote=
:
>
>
>
> On Tue, Aug 18, 2015 at 11:22 AM, Arthur Tchaikovsky <atch...@gmail.com=
=20
> <javascript:>> wrote:
>
>> I gotta be honest with you Johann, I simply don't buy it.
>> And index notion looks anything but elegant solution. That is my opinion=
=20
>> of course.
>>
>> =20
> You  might not find it elegant, but it is a feature that has been present=
=20
> in C for some time (to initialize objects) so there is prior art. It is=
=20
> also tested and the shortcomings are known --at least for initialization,=
=20
> which is not really the same as defaulting arguments to functions or=20
> constructors.
>

--=20

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

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

<div dir=3D"ltr">Yes, but this is C++ not C,=C2=A0 and we are trying to mak=
e C++ more modern not stick with the past, right?<br>Secondly, the idea tha=
t is designated initializers, seem to me that it is violation of encapsulat=
ion, so really, personally I am against it/don&#39;t like it.<br><br>On Tue=
sday, 18 August 2015 11:25:13 UTC+1, David Rodr=C3=ADguez Ibeas  wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div><br><div=
 class=3D"gmail_quote">On Tue, Aug 18, 2015 at 11:22 AM, Arthur Tchaikovsky=
 <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"xN9ZhgLXAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#=
39;;return true;">atch...@gmail.com</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr">I gotta be honest with you Johann, I simp=
ly don&#39;t buy it.<br>And index notion looks anything but elegant solutio=
n. That is my opinion of course.<br><br></div></blockquote><div>=C2=A0</div=
><div>You =C2=A0might not find it elegant, but it is a feature that has bee=
n present in C for some time (to initialize objects) so there is prior art.=
 It is also tested and the shortcomings are known --at least for initializa=
tion, which is not really the same as defaulting arguments to functions or =
constructors.</div></div></div></div>
</blockquote></div>

<p></p>

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

------=_Part_4331_1236664248.1439895527806--
------=_Part_4330_1438715088.1439895527805--

.

------=_Part_4521_841019049.1439906079138
Content-Type: multipart/alternative;
 boundary="----=_Part_4522_1945168116.1439906079138"

------=_Part_4522_1945168116.1439906079138
Content-Type: text/plain; charset=UTF-8



On Tuesday, August 18, 2015 at 5:20:20 AM UTC-4, Arthur Tchaikovsky wrote:
>
> "I would MUCH rather just rewrite all these constructors"
>
> But did you do it or simply wish that at some point you will find the time
> (and will) to do it, but in the mean time you are still using those "old"
> constructors? Because I also would MUCH rather have C++ cleaned up, yet
> this will never happen, and I need to use C++ in its current state. What I
> wish is very different to what I have.
>
> And as for you saying that defaulted constructors are antipattern, is that
> a fact or it is simply your opinion?
>

.... What else would it be but an opinion? Is there some entirely objective
definition of "anti-pattern" that could be applied? Of course not; its
definition is based on user experience, which is always at least somewhat
subjective.

That being said, if quite a few C++ programmers, particularly those who
frequently work with codebases that use them, consider something to be an
anti-pattern, that's at least evidence for the position. And I don't think
I've seen too many people saying "we need people using default arguments in
C++ *more*".

I'm not against the functionality on principle. It's a simpler solution
than named arguments. And considering that the C++ committee has decided
that named arguments pretty much are never going to happen, it's probably
the best you can hope for.

At the same time, I don't think it's a very important feature. I agree with
the idea that using lots of default arguments (which this feature
encourages) is at the very least a code smell if not an anti-pattern. So I
can't say that this is a good idea.

--

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

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

<div dir=3D"ltr"><br><br>On Tuesday, August 18, 2015 at 5:20:20 AM UTC-4, A=
rthur Tchaikovsky wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">&quot;I would MUCH rather just rewrite all these constructors&qu=
ot;<br><br>But did you do it or simply wish that at some point you will fin=
d the time (and will) to do it, but in the mean time you are still using th=
ose &quot;old&quot; constructors? Because I also would MUCH rather have C++=
 cleaned up, yet this will never happen, and I need to use C++ in its curre=
nt state. What I wish is very different to what I have.<br><br>And as for y=
ou saying that defaulted constructors are antipattern, is that a fact or it=
 is simply your opinion?</div></blockquote><div><br>... What else would it =
be but an opinion? Is there some entirely objective definition of &quot;ant=
i-pattern&quot; that could be applied? Of course not; its definition is bas=
ed on user experience, which is always at least somewhat subjective.<br><br=
>That being said, if quite a few C++ programmers, particularly those who fr=
equently work with codebases that use them, consider something to be an ant=
i-pattern, that&#39;s at least evidence for the position. And I don&#39;t t=
hink I&#39;ve seen too many people saying &quot;we need people using defaul=
t arguments in C++ <i>more</i>&quot;.<br><br>I&#39;m not against the functi=
onality on principle. It&#39;s a simpler solution than named arguments. And=
 considering that the C++ committee has decided that named arguments pretty=
 much are never going to happen, it&#39;s probably the best you can hope fo=
r.<br><br>At the same time, I don&#39;t think it&#39;s a very important fea=
ture. I agree with the idea that using lots of default arguments (which thi=
s feature encourages) is at the very least a code smell if not an anti-patt=
ern. So I can&#39;t say that this is a good idea.<br></div></div>

<p></p>

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

------=_Part_4522_1945168116.1439906079138--
------=_Part_4521_841019049.1439906079138--

.

On 2015-08-18 06:22, David Rodr=C3=ADguez Ibeas wrote:
> On Tue, Aug 18, 2015 at 10:42 AM, Arthur Tchaikovsky wrote:
>> On Tuesday, 18 August 2015 10:34:39 UTC+1, Johannes Schaub wrote:
>>> I would also wanna solve this with named arguments
>>>
>>>   f(.b =3D 2, .d =3D 4)
>>
>> That genuinely seems pointless/silly to me, unless you can provide some
>> convincing use cases.
>
> Any use case in which you may end up using 'default' in your proposal is =
a
> use case for these two approaches.  In the first case, it lets you focus =
on
> what parameters are being configured (rather than defaulted) without havi=
ng
> to look at the function declaration, 'f(.b =3D 2, .d =3D 4)' is equivalen=
t to
> 'f(default, 2, default, 4)' and I find the former easier to read.

It's also self-documenting. Consider Arthur O'Dwyer's examples; which is
easier to understand?

  auto cptr =3D new C();         // usually the defaults are okay
  auto c2ptr =3D new C(2048);    // use a bigger buffer
  auto c3ptr =3D new C(default, 1); // use a shorter timeout

- vs. -

  auto cptr =3D new C{};
  auto c2ptr =3D new C{.buffer =3D 2048};
  auto c3ptr =3D new C{.timeout =3D 1};

There's a reason named arguments are so popular in Python :-).

> int a[10] =3D { [3] =3D 1, [2] =3D 5, 6 }; // what values are in the arra=
y?

This never happens because your example is ill-formed. Parameters that
are neither named nor indexed must precede parameters that are. (In
Python also, and for similar reasons.)

> Still, that might be easier than implementing named arguments.  The "name=
d"
> arguments work nicely with a 'struct' since the type can be defined only
> once, but it leads to different sorts of confusion for functions that may
> have multiple declarations:
>=20
> void f(int a =3D 1, int b =3D 2);
> void f(int b =3D 1, int a =3D 2);  // redeclaration
>=20
> Which AFAIK is one of the issues that this form of proposals have faced i=
n
> the past.  I recall also some discussions in this forum (or maybe even
> papers?) aiming for a syntax that would allow this by enabling
> warning/errors when a redeclaration used different names than the origina=
l
> declaration but I did not see any of those prosper.

Probably there should be a way of naming parameters that "codifies" the
name, making it part of the ABI. And, yes, such redeclarations would be
disallowed.

--=20
Matthew

--=20

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

.

------=_Part_438_480074727.1439915875035
Content-Type: multipart/alternative;
 boundary="----=_Part_439_656562220.1439915875035"

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

I dear to disagree with the statement that the following example is self=20
documenting and easier to read:
auto c3ptr =3D new C{.timeout =3D 1};=20
How is this^^^ easier to read? And how is this self documenting? Only on=20
surface it seems that it is, both, but when you really think about it it is=
=20
neither self documenting nor easy to read. Why? Because having only one=20
argument initialized in {}, that is .timeout, leaves us with question, is=
=20
that the only argument to that class, or are there any other? If so, are=20
those arguments inited by default? If so, how many? Etc.
Compared to this:
auto c3ptr =3D new C(default, 1); // use a shorter timeout=20
It is immediately obvious how many arguments there are and which one of=20
them are default. And as for self documentation?
auto c3ptr =3D new C(default, /*timeout*/1); // use a shorter timeout=20


On Tuesday, 18 August 2015 15:03:38 UTC+1, Matthew Woehlke wrote:
>
> On 2015-08-18 06:22, David Rodr=C3=ADguez Ibeas wrote:=20
> > On Tue, Aug 18, 2015 at 10:42 AM, Arthur Tchaikovsky wrote:=20
> >> On Tuesday, 18 August 2015 10:34:39 UTC+1, Johannes Schaub wrote:=20
> >>> I would also wanna solve this with named arguments=20
> >>>=20
> >>>   f(.b =3D 2, .d =3D 4)=20
> >>=20
> >> That genuinely seems pointless/silly to me, unless you can provide som=
e=20
> >> convincing use cases.=20
> >=20
> > Any use case in which you may end up using 'default' in your proposal i=
s=20
> a=20
> > use case for these two approaches.  In the first case, it lets you focu=
s=20
> on=20
> > what parameters are being configured (rather than defaulted) without=20
> having=20
> > to look at the function declaration, 'f(.b =3D 2, .d =3D 4)' is equival=
ent=20
> to=20
> > 'f(default, 2, default, 4)' and I find the former easier to read.=20
>
> It's also self-documenting. Consider Arthur O'Dwyer's examples; which is=
=20
> easier to understand?=20
>
>   auto cptr =3D new C();         // usually the defaults are okay=20
>   auto c2ptr =3D new C(2048);    // use a bigger buffer=20
>   auto c3ptr =3D new C(default, 1); // use a shorter timeout=20
>
> - vs. -=20
>
>   auto cptr =3D new C{};=20
>   auto c2ptr =3D new C{.buffer =3D 2048};=20
>   auto c3ptr =3D new C{.timeout =3D 1};=20
>
> There's a reason named arguments are so popular in Python :-).=20
>
> > int a[10] =3D { [3] =3D 1, [2] =3D 5, 6 }; // what values are in the ar=
ray?=20
>
> This never happens because your example is ill-formed. Parameters that=20
> are neither named nor indexed must precede parameters that are. (In=20
> Python also, and for similar reasons.)=20
>
> > Still, that might be easier than implementing named arguments.  The=20
> "named"=20
> > arguments work nicely with a 'struct' since the type can be defined onl=
y=20
> > once, but it leads to different sorts of confusion for functions that=
=20
> may=20
> > have multiple declarations:=20
> >=20
> > void f(int a =3D 1, int b =3D 2);=20
> > void f(int b =3D 1, int a =3D 2);  // redeclaration=20
> >=20
> > Which AFAIK is one of the issues that this form of proposals have faced=
=20
> in=20
> > the past.  I recall also some discussions in this forum (or maybe even=
=20
> > papers?) aiming for a syntax that would allow this by enabling=20
> > warning/errors when a redeclaration used different names than the=20
> original=20
> > declaration but I did not see any of those prosper.=20
>
> Probably there should be a way of naming parameters that "codifies" the=
=20
> name, making it part of the ABI. And, yes, such redeclarations would be=
=20
> disallowed.=20
>
> --=20
> Matthew=20
>
>

--=20

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

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

<div dir=3D"ltr">I dear to disagree with the statement that the following e=
xample is self documenting and easier to read:<br>auto c3ptr =3D new C{.tim=
eout =3D 1};
<br>How is this^^^ easier to read? And how is this self documenting? Only o=
n surface it seems that it is, both, but when you really think about it it =
is neither self documenting nor easy to read. Why? Because having only one =
argument initialized in {}, that is .timeout, leaves us with question, is t=
hat the only argument to that class, or are there any other? If so, are tho=
se arguments inited by default? If so, how many? Etc.<br>Compared to this:<=
br>auto c3ptr =3D new C(default, 1); // use a shorter timeout
<br>It is immediately obvious how many arguments there are and which one of=
 them are default. And as for self documentation?<br>auto c3ptr =3D new C(d=
efault, /*timeout*/1); // use a shorter timeout
<br><br><br>On Tuesday, 18 August 2015 15:03:38 UTC+1, Matthew Woehlke  wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-08-18 06:22, David =
Rodr=C3=ADguez Ibeas wrote:
<br>&gt; On Tue, Aug 18, 2015 at 10:42 AM, Arthur Tchaikovsky wrote:
<br>&gt;&gt; On Tuesday, 18 August 2015 10:34:39 UTC+1, Johannes Schaub wro=
te:
<br>&gt;&gt;&gt; I would also wanna solve this with named arguments
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; =C2=A0 f(.b =3D 2, .d =3D 4)
<br>&gt;&gt;
<br>&gt;&gt; That genuinely seems pointless/silly to me, unless you can pro=
vide some
<br>&gt;&gt; convincing use cases.
<br>&gt;
<br>&gt; Any use case in which you may end up using &#39;default&#39; in yo=
ur proposal is a
<br>&gt; use case for these two approaches. =C2=A0In the first case, it let=
s you focus on
<br>&gt; what parameters are being configured (rather than defaulted) witho=
ut having
<br>&gt; to look at the function declaration, &#39;f(.b =3D 2, .d =3D 4)&#3=
9; is equivalent to
<br>&gt; &#39;f(default, 2, default, 4)&#39; and I find the former easier t=
o read.
<br>
<br>It&#39;s also self-documenting. Consider Arthur O&#39;Dwyer&#39;s examp=
les; which is
<br>easier to understand?
<br>
<br>=C2=A0 auto cptr =3D new C(); =C2=A0 =C2=A0 =C2=A0 =C2=A0 // usually th=
e defaults are okay
<br>=C2=A0 auto c2ptr =3D new C(2048); =C2=A0 =C2=A0// use a bigger buffer
<br>=C2=A0 auto c3ptr =3D new C(default, 1); // use a shorter timeout
<br>
<br>- vs. -
<br>
<br>=C2=A0 auto cptr =3D new C{};
<br>=C2=A0 auto c2ptr =3D new C{.buffer =3D 2048};
<br>=C2=A0 auto c3ptr =3D new C{.timeout =3D 1};
<br>
<br>There&#39;s a reason named arguments are so popular in Python :-).
<br>
<br>&gt; int a[10] =3D { [3] =3D 1, [2] =3D 5, 6 }; // what values are in t=
he array?
<br>
<br>This never happens because your example is ill-formed. Parameters that
<br>are neither named nor indexed must precede parameters that are. (In
<br>Python also, and for similar reasons.)
<br>
<br>&gt; Still, that might be easier than implementing named arguments. =C2=
=A0The &quot;named&quot;
<br>&gt; arguments work nicely with a &#39;struct&#39; since the type can b=
e defined only
<br>&gt; once, but it leads to different sorts of confusion for functions t=
hat may
<br>&gt; have multiple declarations:
<br>&gt;=20
<br>&gt; void f(int a =3D 1, int b =3D 2);
<br>&gt; void f(int b =3D 1, int a =3D 2); =C2=A0// redeclaration
<br>&gt;=20
<br>&gt; Which AFAIK is one of the issues that this form of proposals have =
faced in
<br>&gt; the past. =C2=A0I recall also some discussions in this forum (or m=
aybe even
<br>&gt; papers?) aiming for a syntax that would allow this by enabling
<br>&gt; warning/errors when a redeclaration used different names than the =
original
<br>&gt; declaration but I did not see any of those prosper.
<br>
<br>Probably there should be a way of naming parameters that &quot;codifies=
&quot; the
<br>name, making it part of the ABI. And, yes, such redeclarations would be
<br>disallowed.
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote></div>

<p></p>

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

------=_Part_439_656562220.1439915875035--
------=_Part_438_480074727.1439915875035--

.

On Tue, Aug 18, 2015 at 7:37 PM, Arthur Tchaikovsky <atch.cpp@gmail.com> wrote:
> I dear to disagree with the statement that the following example is self
> documenting and easier to read:
> auto c3ptr = new C{.timeout = 1};
> How is this^^^ easier to read? And how is this self documenting? Only on
> surface it seems that it is, both, but when you really think about it it is
> neither self documenting nor easy to read. Why? Because having only one
> argument initialized in {}, that is .timeout, leaves us with question, is
> that the only argument to that class, or are there any other? If so, are
> those arguments inited by default? If so, how many? Etc.
> Compared to this:
> auto c3ptr = new C(default, 1); // use a shorter timeout
> It is immediately obvious how many arguments there are and which one of them
> are default.

Your argument works both ways - I cannot tell what other members C has
and how they are initialized by this constructor. In addition I don't
see what the constructor arguments are without looking at the
interface or docs.

> And as for self documentation?
> auto c3ptr = new C(default, /*timeout*/1); // use a shorter timeout

Multi-line comments are evil - they cause problems when you want to
comment a block of code. Besides interface documentation I try to
avoid them as much as possible.

IMHO, the true named member initialization is much more
self-explanatory and less error prone.

--

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

.

------=_Part_2570_821305239.1439917260085
Content-Type: multipart/alternative;
 boundary="----=_Part_2571_748565907.1439917260085"

------=_Part_2571_748565907.1439917260085
Content-Type: text/plain; charset=UTF-8

I believe that the conclusion is that they both have pluses and minuses.

On Tuesday, 18 August 2015 17:49:08 UTC+1, Andrey Semashev wrote:
>
> On Tue, Aug 18, 2015 at 7:37 PM, Arthur Tchaikovsky <atch...@gmail.com
> <javascript:>> wrote:
> > I dear to disagree with the statement that the following example is self
> > documenting and easier to read:
> > auto c3ptr = new C{.timeout = 1};
> > How is this^^^ easier to read? And how is this self documenting? Only on
> > surface it seems that it is, both, but when you really think about it it
> is
> > neither self documenting nor easy to read. Why? Because having only one
> > argument initialized in {}, that is .timeout, leaves us with question,
> is
> > that the only argument to that class, or are there any other? If so, are
> > those arguments inited by default? If so, how many? Etc.
> > Compared to this:
> > auto c3ptr = new C(default, 1); // use a shorter timeout
> > It is immediately obvious how many arguments there are and which one of
> them
> > are default.
>
> Your argument works both ways - I cannot tell what other members C has
> and how they are initialized by this constructor. In addition I don't
> see what the constructor arguments are without looking at the
> interface or docs.
>
> > And as for self documentation?
> > auto c3ptr = new C(default, /*timeout*/1); // use a shorter timeout
>
> Multi-line comments are evil - they cause problems when you want to
> comment a block of code. Besides interface documentation I try to
> avoid them as much as possible.
>
> IMHO, the true named member initialization is much more
> self-explanatory and less error prone.
>

--

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

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

<div dir=3D"ltr">I believe that the conclusion is that they both have pluse=
s and minuses.<br><br>On Tuesday, 18 August 2015 17:49:08 UTC+1, Andrey Sem=
ashev  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tue, Aug 18, 2=
015 at 7:37 PM, Arthur Tchaikovsky &lt;<a href=3D"javascript:" target=3D"_b=
lank" gdf-obfuscated-mailto=3D"kcrlsfXrAwAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">atch...@gmail.com</a>&gt; wrote:
<br>&gt; I dear to disagree with the statement that the following example i=
s self
<br>&gt; documenting and easier to read:
<br>&gt; auto c3ptr =3D new C{.timeout =3D 1};
<br>&gt; How is this^^^ easier to read? And how is this self documenting? O=
nly on
<br>&gt; surface it seems that it is, both, but when you really think about=
 it it is
<br>&gt; neither self documenting nor easy to read. Why? Because having onl=
y one
<br>&gt; argument initialized in {}, that is .timeout, leaves us with quest=
ion, is
<br>&gt; that the only argument to that class, or are there any other? If s=
o, are
<br>&gt; those arguments inited by default? If so, how many? Etc.
<br>&gt; Compared to this:
<br>&gt; auto c3ptr =3D new C(default, 1); // use a shorter timeout
<br>&gt; It is immediately obvious how many arguments there are and which o=
ne of them
<br>&gt; are default.
<br>
<br>Your argument works both ways - I cannot tell what other members C has
<br>and how they are initialized by this constructor. In addition I don&#39=
;t
<br>see what the constructor arguments are without looking at the
<br>interface or docs.
<br>
<br>&gt; And as for self documentation?
<br>&gt; auto c3ptr =3D new C(default, /*timeout*/1); // use a shorter time=
out
<br>
<br>Multi-line comments are evil - they cause problems when you want to
<br>comment a block of code. Besides interface documentation I try to
<br>avoid them as much as possible.
<br>
<br>IMHO, the true named member initialization is much more
<br>self-explanatory and less error prone.
<br></blockquote></div>

<p></p>

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

------=_Part_2571_748565907.1439917260085--
------=_Part_2570_821305239.1439917260085--

.

------=_Part_468_643451628.1439918611531
Content-Type: multipart/alternative;
 boundary="----=_Part_469_1189165838.1439918611531"

------=_Part_469_1189165838.1439918611531
Content-Type: text/plain; charset=UTF-8



On Tuesday, August 18, 2015 at 12:37:55 PM UTC-4, Arthur Tchaikovsky wrote:
>
> I dear to disagree with the statement that the following example is self
> documenting and easier to read:
> auto c3ptr = new C{.timeout = 1};
> How is this^^^ easier to read? And how is this self documenting? Only on
> surface it seems that it is, both, but when you really think about it it is
> neither self documenting nor easy to read. Why? Because having only one
> argument initialized in {}, that is .timeout, leaves us with question, is
> that the only argument to that class, or are there any other?
>

If I'm looking to understand what `new C{.timeout=1};` means, I don't care
how many arguments `C` could have in its constructor. From the user's
perspective, that's simply irrelevant. What matters is what it means to
pass the value `1` to the `timeout` argument of the constructor.

And since the word `timeout` is there, I can at least take a pretty good
guess as to what it means.

Remember: the whole point of default arguments is that you *don't have* to
know about them. To make a function that takes 6 arguments look like a
function that takes 3. Seeing `default` for an argument is just pointless
noise, which is necessary only because C++ doesn't allow for positional or
named arguments.


> If so, are those arguments inited by default? If so, how many? Etc.
> Compared to this:
> auto c3ptr = new C(default, 1); // use a shorter timeout
> It is immediately obvious how many arguments there are and which one of
> them are default. And as for self documentation?
> auto c3ptr = new C(default, /*timeout*/1); // use a shorter timeout
>

Comments are not "self documentation". Comments are not checked; *syntax*
is.

--

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

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

<div dir=3D"ltr"><br><br>On Tuesday, August 18, 2015 at 12:37:55 PM UTC-4, =
Arthur Tchaikovsky wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr">I dear to disagree with the statement that the following exampl=
e is self documenting and easier to read:<br>auto c3ptr =3D new C{.timeout =
=3D 1};
<br>How is this^^^ easier to read? And how is this self documenting? Only o=
n surface it seems that it is, both, but when you really think about it it =
is neither self documenting nor easy to read. Why? Because having only one =
argument initialized in {}, that is .timeout, leaves us with question, is t=
hat the only argument to that class, or are there any other?</div></blockqu=
ote><div><br>If I&#39;m looking to understand what `new C{.timeout=3D1};` m=
eans, I don&#39;t care how many arguments `C` could have in its constructor=
.. From the user&#39;s perspective, that&#39;s simply irrelevant. What matte=
rs is what it means to pass the value `1` to the `timeout` argument of the =
constructor.<br><br>And since the word `timeout` is there, I can at least t=
ake a pretty good guess as to what it means.<br><br>Remember: the whole poi=
nt of default arguments is that you <i>don&#39;t have</i> to know about the=
m. To make a function that takes 6 arguments look like a function that take=
s 3. Seeing `default` for an argument is just pointless noise, which is nec=
essary only because C++ doesn&#39;t allow for positional or named arguments=
..<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"> If so, are those arguments inited by default? If so, how many? Etc.<br=
>Compared to this:<br>auto c3ptr =3D new C(default, 1); // use a shorter ti=
meout
<br>It is immediately obvious how many arguments there are and which one of=
 them are default. And as for self documentation?<br>auto c3ptr =3D new C(d=
efault, /*timeout*/1); // use a shorter timeout
<br></div></blockquote><div><br>Comments are not &quot;self documentation&q=
uot;. Comments are not checked; <i>syntax</i> is.</div><br></div>

<p></p>

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

------=_Part_469_1189165838.1439918611531--
------=_Part_468_643451628.1439918611531--

.

2015-08-18 18:37 GMT+02:00 Arthur Tchaikovsky <atch.cpp@gmail.com>:
> I dear to disagree with the statement that the following example is self
> documenting and easier to read:
> auto c3ptr = new C{.timeout = 1};
> How is this^^^ easier to read? And how is this self documenting? Only on
> surface it seems that it is, both, but when you really think about it it is
> neither self documenting nor easy to read. Why? Because having only one
> argument initialized in {}, that is .timeout, leaves us with question, is
> that the only argument to that class, or are there any other? If so, are
> those arguments inited by default? If so, how many? Etc.
> Compared to this:
> auto c3ptr = new C(default, 1); // use a shorter timeout
> It is immediately obvious how many arguments there are and which one of them
> are default. And as for self documentation?

Err, no. There may be other parameters that have default arguments,
that you don't see aswell. So you don't see all parameter's
initializer values in both versions. So I fail to understand your
argument. I even fail earlier, without finding the counter example.
Why would you even care about the other arguments values? Do you care
about values that might influence the constructor's behavior that are
*not* passed as arguments but by another way, perhaps read as globals?

In summary, I think you are trying to find arguments against ".timeout
= ..." and come up with not-so-convincing examples.

--

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

.

On 2015-08-18 12:37, Arthur Tchaikovsky wrote:
> I dear to disagree with the statement that the following example is self
> documenting and easier to read:
> auto c3ptr = new C{.timeout = 1};
> How is this^^^ easier to read? And how is this self documenting?

Others have addressed this thoroughly; no need for me to repeat their
answers.

> If [the ctor takes more arguments than are named], are those
> arguments inited by default?

Um... yes? Any optional parameter not specified is defaulted. As always.
Nothing has changed here.

--
Matthew

--

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

.

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

On Sat, Aug 15, 2015 at 9:49 AM, Arthur Tchaikovsky <atch.cpp@gmail.com>
wrote:

> Hi,
> Does anyone see helpfulness of such solution:
> Having fnc:
>
> void f(int a = 0, int b = 1, int c = 2, int d = 3);
>
> I think that it would be nice to be able to say whilst calling it and
> requiring only some of those args to be non-default:
>
> f(default,2,default,4);
>
> Thoughts?
>

Yes, I think it's useful. Yes, I think named arguments are more useful,
though while there is overlap, they don't exactly solve the same set of
problems. Even with named arguments you might potentially want/need
something like this when in the presence of overloads.

However, I think named arguments are considerably less likely to get into
the language due to their complexity, but those are just my thoughts on the
matter. Defaults as you present them are considerably simpler and I also
would not consider it an "anti-pattern."

So, +1 on this or a similar proposal.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Aug 15, 2015 at 9:49 AM, Arthur Tchaikovsky <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:atch.cpp@gmail.com" target=3D"_blank">atch.cpp@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi, <br=
>Does anyone see helpfulness of such solution:<br>Having fnc:<br><br>void f=
(int a =3D 0, int b =3D 1, int c =3D 2, int d =3D 3);<br><br>I think that i=
t would be nice to be able to say whilst calling it and requiring only some=
 of those args to be non-default:<br><br>f(default,2,default,4);<br><br>Tho=
ughts?</div></blockquote><div><br></div><div>Yes, I think it&#39;s useful. =
Yes, I think named arguments are more useful, though while there is overlap=
, they don&#39;t exactly solve the same set of problems. Even with named ar=
guments you might potentially want/need something like this when in the pre=
sence of overloads.</div><div><br></div><div>However, I think named argumen=
ts are considerably less likely to get into the language due to their compl=
exity, but those are just my thoughts on the matter. Defaults as you presen=
t them are considerably simpler and I also would not consider it an &quot;a=
nti-pattern.&quot;</div><div><br></div><div>So, +1 on this or a similar pro=
posal.</div></div></div></div>

<p></p>

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

--001a113cd41a7f3152051d99db51--

.

------=_Part_32_1452366758.1439964121460
Content-Type: text/plain; charset=UTF-8

I have to agree with Matt Calabrese completely. As it was already asserted named arguments are not going to happen anytime soon (if at all).

Earlier in this thread there were workarounds listed which are more or less comparable to the proposal in their effect.
I would like to elaborate some more on one of these workarounds, as it can be mapped pretty much 1-to-1 to the proposal and it happens to be the solution I employ when encountering this kind of problem.


# Current workaround.

struct s {
    static int const default_a = 1337;
    static int const default_b = 4096;
    s(int a = default_a, int b = default_b)
        : a(a), b(b) { }
    int a;
    int b;
};

int main() {
    s x;
    s y(42);
    s z(s::default_a, 42);
    return 0;
}

See working code here: http://ideone.com/OKtbuc


# Using the proposed syntax.

struct s {
    s(int a = 1337, int b = 4096)
        : a(a), b(b) { }
    int a;
    int b;
};

int main() {
    s x;
    s y(42);
    s z(default, 42);
    return 0;
}

The current solution has a number of drawbacks.
1) It's unnecessarily verbose.
2) It's easy to mess up for parameters that have the same type. (`s z(s::default_b, 42)` - Oops, passed `default_b` as `a`.)
3) When looking up the actual default values there is one more hop to make. It's not sufficient to look at the function declaration but additionally we have to look for e.g. default_a.

--

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

------=_Part_32_1452366758.1439964121460--

.

------=_Part_5858_1598653176.1439996932421
Content-Type: multipart/alternative;
 boundary="----=_Part_5859_389752403.1439996932421"

------=_Part_5859_389752403.1439996932421
Content-Type: text/plain; charset=UTF-8

It's even simpler if we could write

struct s {
    int a = 1337;
    int b = 4096;
};

int main() {
    s x;
    s y { 42 }; // or s y { .a = 42 };
    s z { .b = 42 };
    return 0;
}

:)

On Wednesday, August 19, 2015 at 2:02:01 PM UTC+8, Max Truxa wrote:
>
> I have to agree with Matt Calabrese completely. As it was already asserted
> named arguments are not going to happen anytime soon (if at all).
>
> Earlier in this thread there were workarounds listed which are more or
> less comparable to the proposal in their effect.
> I would like to elaborate some more on one of these workarounds, as it can
> be mapped pretty much 1-to-1 to the proposal and it happens to be the
> solution I employ when encountering this kind of problem.
>
>
> # Current workaround.
>
> struct s {
>     static int const default_a = 1337;
>     static int const default_b = 4096;
>     s(int a = default_a, int b = default_b)
>         : a(a), b(b) { }
>     int a;
>     int b;
> };
>
> int main() {
>     s x;
>     s y(42);
>     s z(s::default_a, 42);
>     return 0;
> }
>
> See working code here: http://ideone.com/OKtbuc
>
>
> # Using the proposed syntax.
>
> struct s {
>     s(int a = 1337, int b = 4096)
>         : a(a), b(b) { }
>     int a;
>     int b;
> };
>
> int main() {
>     s x;
>     s y(42);
>     s z(default, 42);
>     return 0;
> }
>
> The current solution has a number of drawbacks.
> 1) It's unnecessarily verbose.
> 2) It's easy to mess up for parameters that have the same type. (`s
> z(s::default_b, 42)` - Oops, passed `default_b` as `a`.)
> 3) When looking up the actual default values there is one more hop to
> make. It's not sufficient to look at the function declaration but
> additionally we have to look for e.g. default_a.
>
>

--

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

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

<div dir=3D"ltr">It&#39;s even simpler if we could write <br><br><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> s </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> a </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by=
-prettify">1337</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> b =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #066;" class=3D"styled-by-prettify">4096</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>=C2=A0<br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> main</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=
=A0 s x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 s y </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #066;" class=3D"styled-by-prettify">42</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// or s y { .a =3D 42 };</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 s z </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">b </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">=
42</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">return</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">}</span></div></code></div><br>:)<br><br>On Wednesd=
ay, August 19, 2015 at 2:02:01 PM UTC+8, Max Truxa wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">I have to agree with Matt Calabrese completely.=
 As it was already asserted named arguments are not going to happen anytime=
 soon (if at all).<p>Earlier in this thread there were workarounds listed w=
hich are more or less comparable to the proposal in their effect.<br>I woul=
d like to elaborate some more on one of these workarounds, as it can be map=
ped pretty much 1-to-1 to the proposal and it happens to be the solution I =
employ when encountering this kind of problem.</p><p><br># Current workarou=
nd.</p><p>struct s {<br>=C2=A0 =C2=A0 static int const default_a =3D 1337;<=
br>=C2=A0 =C2=A0 static int const default_b =3D 4096;<br>=C2=A0 =C2=A0 s(in=
t a =3D default_a, int b =3D default_b) <br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 : a=
(a), b(b) { }<br>=C2=A0 =C2=A0 int a;<br>=C2=A0 =C2=A0 int b;<br>};<br>=C2=
=A0<br>int main() {<br>=C2=A0 =C2=A0 s x;<br>=C2=A0 =C2=A0 s y(42);<br>=C2=
=A0 =C2=A0 s z(s::default_a, 42);<br>=C2=A0 =C2=A0 return 0;<br>}</p><p>See=
 working code here: <a href=3D"http://ideone.com/OKtbuc" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?=
q\75http%3A%2F%2Fideone.com%2FOKtbuc\46sa\75D\46sntz\0751\46usg\75AFQjCNFJT=
tR-2NKU_hCXpY0qHPmkHWZV9g&#39;;return true;" onclick=3D"this.href=3D&#39;ht=
tp://www.google.com/url?q\75http%3A%2F%2Fideone.com%2FOKtbuc\46sa\75D\46snt=
z\0751\46usg\75AFQjCNFJTtR-2NKU_hCXpY0qHPmkHWZV9g&#39;;return true;">http:/=
/ideone.com/OKtbuc</a></p><p><br># Using the proposed syntax.</p><p>struct =
s {<br>=C2=A0 =C2=A0 s(int a =3D 1337, int b =3D 4096) <br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 : a(a), b(b) { }<br>=C2=A0 =C2=A0 int a;<br>=C2=A0 =C2=A0 int=
 b;<br>};<br>=C2=A0<br>int main() {<br>=C2=A0 =C2=A0 s x;<br>=C2=A0 =C2=A0 =
s y(42);<br>=C2=A0 =C2=A0 s z(default, 42);<br>=C2=A0 =C2=A0 return 0;<br>}=
</p><p>The current solution has a number of drawbacks.<br>1) It&#39;s unnec=
essarily verbose.<br>2) It&#39;s easy to mess up for parameters that have t=
he same type. (`s z(s::default_b, 42)` - Oops, passed `default_b` as `a`.)<=
br>3) When looking up the actual default values there is one more hop to ma=
ke. It&#39;s not sufficient to look at the function declaration but additio=
nally we have to look for e.g. default_a.</p><p></p><p></p><p></p><p></p><p=
></p><p></p></blockquote></div>

<p></p>

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

------=_Part_5859_389752403.1439996932421--
------=_Part_5858_1598653176.1439996932421--

.

------=_Part_458_1030215788.1440001629518
Content-Type: multipart/alternative;
 boundary="----=_Part_459_863877001.1440001629519"

------=_Part_459_863877001.1440001629519
Content-Type: text/plain; charset=UTF-8

It *is not* simpler. What you've just shown is a violation of
encapsulation. Not simplification.

On Wednesday, 19 August 2015 16:08:52 UTC+1, S.B. wrote:
>
> It's even simpler if we could write
>
> struct s {
>     int a = 1337;
>     int b = 4096;
> };
>
> int main() {
>     s x;
>     s y { 42 }; // or s y { .a = 42 };
>     s z { .b = 42 };
>     return 0;
> }
>
> :)
>
> On Wednesday, August 19, 2015 at 2:02:01 PM UTC+8, Max Truxa wrote:
>>
>> I have to agree with Matt Calabrese completely. As it was already
>> asserted named arguments are not going to happen anytime soon (if at all).
>>
>> Earlier in this thread there were workarounds listed which are more or
>> less comparable to the proposal in their effect.
>> I would like to elaborate some more on one of these workarounds, as it
>> can be mapped pretty much 1-to-1 to the proposal and it happens to be the
>> solution I employ when encountering this kind of problem.
>>
>>
>> # Current workaround.
>>
>> struct s {
>>     static int const default_a = 1337;
>>     static int const default_b = 4096;
>>     s(int a = default_a, int b = default_b)
>>         : a(a), b(b) { }
>>     int a;
>>     int b;
>> };
>>
>> int main() {
>>     s x;
>>     s y(42);
>>     s z(s::default_a, 42);
>>     return 0;
>> }
>>
>> See working code here: http://ideone.com/OKtbuc
>>
>>
>> # Using the proposed syntax.
>>
>> struct s {
>>     s(int a = 1337, int b = 4096)
>>         : a(a), b(b) { }
>>     int a;
>>     int b;
>> };
>>
>> int main() {
>>     s x;
>>     s y(42);
>>     s z(default, 42);
>>     return 0;
>> }
>>
>> The current solution has a number of drawbacks.
>> 1) It's unnecessarily verbose.
>> 2) It's easy to mess up for parameters that have the same type. (`s
>> z(s::default_b, 42)` - Oops, passed `default_b` as `a`.)
>> 3) When looking up the actual default values there is one more hop to
>> make. It's not sufficient to look at the function declaration but
>> additionally we have to look for e.g. default_a.
>>
>>

--

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

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

<div dir=3D"ltr">It *is not* simpler. What you&#39;ve just shown is a viola=
tion of encapsulation. Not simplification.<br><br>On Wednesday, 19 August 2=
015 16:08:52 UTC+1, S.B.  wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div dir=3D"ltr">It&#39;s even simpler if we could write <br><br><div sty=
le=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);borde=
r-style:solid;border-width:1px;word-wrap:break-word"><code><div><span style=
=3D"color:#008">struct</span><span style=3D"color:#000"> s </span><span sty=
le=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </sp=
an><span style=3D"color:#008">int</span><span style=3D"color:#000"> a </spa=
n><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><=
span style=3D"color:#066">1337</span><span style=3D"color:#660">;</span><sp=
an style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008"=
>int</span><span style=3D"color:#000"> b </span><span style=3D"color:#660">=
=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#066">409=
6</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br><=
/span><span style=3D"color:#660">};</span><span style=3D"color:#000"><br>=
=C2=A0<br></span><span style=3D"color:#008">int</span><span style=3D"color:=
#000"> main</span><span style=3D"color:#660">()</span><span style=3D"color:=
#000"> </span><span style=3D"color:#660">{</span><span style=3D"color:#000"=
><br>=C2=A0 =C2=A0 s x</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 s y </span><span style=3D"color:#660">{</=
span><span style=3D"color:#000"> </span><span style=3D"color:#066">42</span=
><span style=3D"color:#000"> </span><span style=3D"color:#660">};</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#800">// or s y { .a =
=3D 42 };</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 s z </span><sp=
an style=3D"color:#660">{</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#660">.</span><span style=3D"color:#000">b </span><span style=
=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D=
"color:#066">42</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#660">};</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span=
 style=3D"color:#008">return</span><span style=3D"color:#000"> </span><span=
 style=3D"color:#066">0</span><span style=3D"color:#660">;</span><span styl=
e=3D"color:#000"><br></span><span style=3D"color:#660">}</span></div></code=
></div><br>:)<br><br>On Wednesday, August 19, 2015 at 2:02:01 PM UTC+8, Max=
 Truxa wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex">I have to agree with M=
att Calabrese completely. As it was already asserted named arguments are no=
t going to happen anytime soon (if at all).<p>Earlier in this thread there =
were workarounds listed which are more or less comparable to the proposal i=
n their effect.<br>I would like to elaborate some more on one of these work=
arounds, as it can be mapped pretty much 1-to-1 to the proposal and it happ=
ens to be the solution I employ when encountering this kind of problem.</p>=
<p><br># Current workaround.</p><p>struct s {<br>=C2=A0 =C2=A0 static int c=
onst default_a =3D 1337;<br>=C2=A0 =C2=A0 static int const default_b =3D 40=
96;<br>=C2=A0 =C2=A0 s(int a =3D default_a, int b =3D default_b) <br>=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 : a(a), b(b) { }<br>=C2=A0 =C2=A0 int a;<br>=C2=A0 =
=C2=A0 int b;<br>};<br>=C2=A0<br>int main() {<br>=C2=A0 =C2=A0 s x;<br>=C2=
=A0 =C2=A0 s y(42);<br>=C2=A0 =C2=A0 s z(s::default_a, 42);<br>=C2=A0 =C2=
=A0 return 0;<br>}</p><p>See working code here: <a href=3D"http://ideone.co=
m/OKtbuc" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#3=
9;http://www.google.com/url?q\75http%3A%2F%2Fideone.com%2FOKtbuc\46sa\75D\4=
6sntz\0751\46usg\75AFQjCNFJTtR-2NKU_hCXpY0qHPmkHWZV9g&#39;;return true;" on=
click=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fideone=
..com%2FOKtbuc\46sa\75D\46sntz\0751\46usg\75AFQjCNFJTtR-2NKU_hCXpY0qHPmkHWZV=
9g&#39;;return true;">http://ideone.com/OKtbuc</a></p><p><br># Using the pr=
oposed syntax.</p><p>struct s {<br>=C2=A0 =C2=A0 s(int a =3D 1337, int b =
=3D 4096) <br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 : a(a), b(b) { }<br>=C2=A0 =C2=A0=
 int a;<br>=C2=A0 =C2=A0 int b;<br>};<br>=C2=A0<br>int main() {<br>=C2=A0 =
=C2=A0 s x;<br>=C2=A0 =C2=A0 s y(42);<br>=C2=A0 =C2=A0 s z(default, 42);<br=
>=C2=A0 =C2=A0 return 0;<br>}</p><p>The current solution has a number of dr=
awbacks.<br>1) It&#39;s unnecessarily verbose.<br>2) It&#39;s easy to mess =
up for parameters that have the same type. (`s z(s::default_b, 42)` - Oops,=
 passed `default_b` as `a`.)<br>3) When looking up the actual default value=
s there is one more hop to make. It&#39;s not sufficient to look at the fun=
ction declaration but additionally we have to look for e.g. default_a.</p><=
p></p><p></p><p></p><p></p><p></p><p></p></blockquote></div></blockquote></=
div>

<p></p>

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

------=_Part_459_863877001.1440001629519--
------=_Part_458_1030215788.1440001629518--

.

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

How does that violate an encapsulation that does not exist? All members are
public in the struct=E2=80=A6 you might dislike it on different accounts bu=
t
encapsulation is not an issue with that code.  Other pro=C2=B4s, the argume=
nts
are named, which is stable across refactors that might shift the positions
(assuming sensible names, the caller wants the 'a' to have value X or the
'b' to have value Z. Depending on the position of the member in the struct
(and passing 'default' if needed for the previous arguments) is *more*
coupled, not less coupled.

For initialization of structs, the C way is clearly better than the C++ way
here. A different question is whether we want to put some effort into that
part of the language when we can assume that most types are not
all-members-public.

Then again this is only related to default arguments to functions in that
uniform initialization would be even less uniform in certain cases.  I do
see the problems with named arguments, I still think that to be the better
way. Whether initialization of structs can be made compatible with C once
again=E2=80=A6 would be nice here, but I imagine not that many people care.

     David

On Wed, Aug 19, 2015 at 5:27 PM, Arthur Tchaikovsky <atch.cpp@gmail.com>
wrote:

> It *is not* simpler. What you've just shown is a violation of
> encapsulation. Not simplification.
>
>
> On Wednesday, 19 August 2015 16:08:52 UTC+1, S.B. wrote:
>>
>> It's even simpler if we could write
>>
>> struct s {
>>     int a =3D 1337;
>>     int b =3D 4096;
>> };
>>
>> int main() {
>>     s x;
>>     s y { 42 }; // or s y { .a =3D 42 };
>>     s z { .b =3D 42 };
>>     return 0;
>> }
>>
>> :)
>>
>> On Wednesday, August 19, 2015 at 2:02:01 PM UTC+8, Max Truxa wrote:
>>>
>>> I have to agree with Matt Calabrese completely. As it was already
>>> asserted named arguments are not going to happen anytime soon (if at al=
l).
>>>
>>> Earlier in this thread there were workarounds listed which are more or
>>> less comparable to the proposal in their effect.
>>> I would like to elaborate some more on one of these workarounds, as it
>>> can be mapped pretty much 1-to-1 to the proposal and it happens to be t=
he
>>> solution I employ when encountering this kind of problem.
>>>
>>>
>>> # Current workaround.
>>>
>>> struct s {
>>>     static int const default_a =3D 1337;
>>>     static int const default_b =3D 4096;
>>>     s(int a =3D default_a, int b =3D default_b)
>>>         : a(a), b(b) { }
>>>     int a;
>>>     int b;
>>> };
>>>
>>> int main() {
>>>     s x;
>>>     s y(42);
>>>     s z(s::default_a, 42);
>>>     return 0;
>>> }
>>>
>>> See working code here: http://ideone.com/OKtbuc
>>>
>>>
>>> # Using the proposed syntax.
>>>
>>> struct s {
>>>     s(int a =3D 1337, int b =3D 4096)
>>>         : a(a), b(b) { }
>>>     int a;
>>>     int b;
>>> };
>>>
>>> int main() {
>>>     s x;
>>>     s y(42);
>>>     s z(default, 42);
>>>     return 0;
>>> }
>>>
>>> The current solution has a number of drawbacks.
>>> 1) It's unnecessarily verbose.
>>> 2) It's easy to mess up for parameters that have the same type. (`s
>>> z(s::default_b, 42)` - Oops, passed `default_b` as `a`.)
>>> 3) When looking up the actual default values there is one more hop to
>>> make. It's not sufficient to look at the function declaration but
>>> additionally we have to look for e.g. default_a.
>>>
>>> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

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

<div dir=3D"ltr">How does that violate an encapsulation that does not exist=
? All members are public in the struct=E2=80=A6 you might dislike it on dif=
ferent accounts but encapsulation is not an issue with that code.=C2=A0 Oth=
er pro=C2=B4s, the arguments are named, which is stable across refactors th=
at might shift the positions (assuming sensible names, the caller wants the=
 &#39;a&#39; to have value X or the &#39;b&#39; to have value Z. Depending =
on the position of the member in the struct (and passing &#39;default&#39; =
if needed for the previous arguments) is *more* coupled, not less coupled.<=
div><br></div><div>For initialization of structs, the C way is clearly bett=
er than the C++ way here. A different question is whether we want to put so=
me effort into that part of the language when we can assume that most types=
 are not all-members-public.=C2=A0</div><div><br></div><div>Then again this=
 is only related to default arguments to functions in that uniform initiali=
zation would be even less uniform in certain cases.=C2=A0 I do see the prob=
lems with named arguments, I still think that to be the better way. Whether=
 initialization of structs can be made compatible with C once again=E2=80=
=A6 would be nice here, but I imagine not that many people care.</div><div>=
<br></div><div>=C2=A0 =C2=A0 =C2=A0David</div></div><div class=3D"gmail_ext=
ra"><br><div class=3D"gmail_quote">On Wed, Aug 19, 2015 at 5:27 PM, Arthur =
Tchaikovsky <span dir=3D"ltr">&lt;<a href=3D"mailto:atch.cpp@gmail.com" tar=
get=3D"_blank">atch.cpp@gmail.com</a>&gt;</span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr">It *is not* simpler. What you&#39;ve just s=
hown is a violation of encapsulation. Not simplification.<div><div class=3D=
"h5"><br><br>On Wednesday, 19 August 2015 16:08:52 UTC+1, S.B.  wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">It&#39;s even simpler i=
f we could write <br><br><div style=3D"background-color:rgb(250,250,250);bo=
rder-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:b=
reak-word"><code><div><span style=3D"color:#008">struct</span><span style=
=3D"color:#000"> s </span><span style=3D"color:#660">{</span><span style=3D=
"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">int</span>=
<span style=3D"color:#000"> a </span><span style=3D"color:#660">=3D</span><=
span style=3D"color:#000"> </span><span style=3D"color:#066">1337</span><sp=
an style=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color:#008">int</span><span style=3D"color:#000">=
 b </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> =
</span><span style=3D"color:#066">4096</span><span style=3D"color:#660">;</=
span><span style=3D"color:#000"><br></span><span style=3D"color:#660">};</s=
pan><span style=3D"color:#000"><br>=C2=A0<br></span><span style=3D"color:#0=
08">int</span><span style=3D"color:#000"> main</span><span style=3D"color:#=
660">()</span><span style=3D"color:#000"> </span><span style=3D"color:#660"=
>{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 s x</span><span style=
=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 s y </=
span><span style=3D"color:#660">{</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#066">42</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#660">};</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#800">// or s y { .a =3D 42 };</span><span style=3D"color:#000=
"><br>=C2=A0 =C2=A0 s z </span><span style=3D"color:#660">{</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#660">.</span><span style=3D=
"color:#000">b </span><span style=3D"color:#660">=3D</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#066">42</span><span style=3D"color=
:#000"> </span><span style=3D"color:#660">};</span><span style=3D"color:#00=
0"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">return</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#066">0</span><span style=
=3D"color:#660">;</span><span style=3D"color:#000"><br></span><span style=
=3D"color:#660">}</span></div></code></div><br>:)<br><br>On Wednesday, Augu=
st 19, 2015 at 2:02:01 PM UTC+8, Max Truxa wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">I have to agree with Matt Calabrese completely. As it was alr=
eady asserted named arguments are not going to happen anytime soon (if at a=
ll).<p>Earlier in this thread there were workarounds listed which are more =
or less comparable to the proposal in their effect.<br>I would like to elab=
orate some more on one of these workarounds, as it can be mapped pretty muc=
h 1-to-1 to the proposal and it happens to be the solution I employ when en=
countering this kind of problem.</p><p><br># Current workaround.</p><p>stru=
ct s {<br>=C2=A0 =C2=A0 static int const default_a =3D 1337;<br>=C2=A0 =C2=
=A0 static int const default_b =3D 4096;<br>=C2=A0 =C2=A0 s(int a =3D defau=
lt_a, int b =3D default_b) <br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 : a(a), b(b) { }=
<br>=C2=A0 =C2=A0 int a;<br>=C2=A0 =C2=A0 int b;<br>};<br>=C2=A0<br>int mai=
n() {<br>=C2=A0 =C2=A0 s x;<br>=C2=A0 =C2=A0 s y(42);<br>=C2=A0 =C2=A0 s z(=
s::default_a, 42);<br>=C2=A0 =C2=A0 return 0;<br>}</p><p>See working code h=
ere: <a href=3D"http://ideone.com/OKtbuc" rel=3D"nofollow" target=3D"_blank=
">http://ideone.com/OKtbuc</a></p><p><br># Using the proposed syntax.</p><p=
>struct s {<br>=C2=A0 =C2=A0 s(int a =3D 1337, int b =3D 4096) <br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 : a(a), b(b) { }<br>=C2=A0 =C2=A0 int a;<br>=C2=A0 =C2=
=A0 int b;<br>};<br>=C2=A0<br>int main() {<br>=C2=A0 =C2=A0 s x;<br>=C2=A0 =
=C2=A0 s y(42);<br>=C2=A0 =C2=A0 s z(default, 42);<br>=C2=A0 =C2=A0 return =
0;<br>}</p><p>The current solution has a number of drawbacks.<br>1) It&#39;=
s unnecessarily verbose.<br>2) It&#39;s easy to mess up for parameters that=
 have the same type. (`s z(s::default_b, 42)` - Oops, passed `default_b` as=
 `a`.)<br>3) When looking up the actual default values there is one more ho=
p to make. It&#39;s not sufficient to look at the function declaration but =
additionally we have to look for e.g. default_a.</p><p></p><p></p><p></p><p=
></p><p></p><p></p></blockquote></div></blockquote></div></div></div><div c=
lass=3D"HOEnZb"><div class=3D"h5">

<p></p>

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

<p></p>

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

--001a11c332da717d3f051dadaaa4--

.

------=_Part_528_1346400368.1440007620379
Content-Type: multipart/alternative;
 boundary="----=_Part_529_550259881.1440007620379"

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

Not all members in struct are public. From elementary school, everyone=20
knows that struct differs from class that *by default* members are public=
=20
in struct and private in class. ;)
That's why I see it as a violation of encapsulation. Secondly, not only=20
structs should be concerned, but classes too. And not only initialization=
=20
should be a concern here but also setting value *after* the object had been=
=20
initialized. Taken all this above, I say that accessing members of a=20
class/struct by names, be it during initialization or after that fact is=20
violation of encapsulation and it should be discouraged in modern C++. This=
=20
kind of code may very well be OK for C but C++ is not C.=20

On Wednesday, 19 August 2015 18:50:13 UTC+1, David Rodr=C3=ADguez Ibeas wro=
te:
>
> How does that violate an encapsulation that does not exist? All members=
=20
> are public in the struct=E2=80=A6 you might dislike it on different accou=
nts but=20
> encapsulation is not an issue with that code.  Other pro=C2=B4s, the argu=
ments=20
> are named, which is stable across refactors that might shift the position=
s=20
> (assuming sensible names, the caller wants the 'a' to have value X or the=
=20
> 'b' to have value Z. Depending on the position of the member in the struc=
t=20
> (and passing 'default' if needed for the previous arguments) is *more*=20
> coupled, not less coupled.
>
> For initialization of structs, the C way is clearly better than the C++=
=20
> way here. A different question is whether we want to put some effort into=
=20
> that part of the language when we can assume that most types are not=20
> all-members-public.=20
>
> Then again this is only related to default arguments to functions in that=
=20
> uniform initialization would be even less uniform in certain cases.  I do=
=20
> see the problems with named arguments, I still think that to be the bette=
r=20
> way. Whether initialization of structs can be made compatible with C once=
=20
> again=E2=80=A6 would be nice here, but I imagine not that many people car=
e.
>
>      David
>
> On Wed, Aug 19, 2015 at 5:27 PM, Arthur Tchaikovsky <atch...@gmail.com=20
> <javascript:>> wrote:
>
>> It *is not* simpler. What you've just shown is a violation of=20
>> encapsulation. Not simplification.
>>
>>
>> On Wednesday, 19 August 2015 16:08:52 UTC+1, S.B. wrote:
>>>
>>> It's even simpler if we could write=20
>>>
>>> struct s {
>>>     int a =3D 1337;
>>>     int b =3D 4096;
>>> };
>>> =20
>>> int main() {
>>>     s x;
>>>     s y { 42 }; // or s y { .a =3D 42 };
>>>     s z { .b =3D 42 };
>>>     return 0;
>>> }
>>>
>>> :)
>>>
>>> On Wednesday, August 19, 2015 at 2:02:01 PM UTC+8, Max Truxa wrote:
>>>>
>>>> I have to agree with Matt Calabrese completely. As it was already=20
>>>> asserted named arguments are not going to happen anytime soon (if at a=
ll).
>>>>
>>>> Earlier in this thread there were workarounds listed which are more or=
=20
>>>> less comparable to the proposal in their effect.
>>>> I would like to elaborate some more on one of these workarounds, as it=
=20
>>>> can be mapped pretty much 1-to-1 to the proposal and it happens to be =
the=20
>>>> solution I employ when encountering this kind of problem.
>>>>
>>>>
>>>> # Current workaround.
>>>>
>>>> struct s {
>>>>     static int const default_a =3D 1337;
>>>>     static int const default_b =3D 4096;
>>>>     s(int a =3D default_a, int b =3D default_b)=20
>>>>         : a(a), b(b) { }
>>>>     int a;
>>>>     int b;
>>>> };
>>>> =20
>>>> int main() {
>>>>     s x;
>>>>     s y(42);
>>>>     s z(s::default_a, 42);
>>>>     return 0;
>>>> }
>>>>
>>>> See working code here: http://ideone.com/OKtbuc
>>>>
>>>>
>>>> # Using the proposed syntax.
>>>>
>>>> struct s {
>>>>     s(int a =3D 1337, int b =3D 4096)=20
>>>>         : a(a), b(b) { }
>>>>     int a;
>>>>     int b;
>>>> };
>>>> =20
>>>> int main() {
>>>>     s x;
>>>>     s y(42);
>>>>     s z(default, 42);
>>>>     return 0;
>>>> }
>>>>
>>>> The current solution has a number of drawbacks.
>>>> 1) It's unnecessarily verbose.
>>>> 2) It's easy to mess up for parameters that have the same type. (`s=20
>>>> z(s::default_b, 42)` - Oops, passed `default_b` as `a`.)
>>>> 3) When looking up the actual default values there is one more hop to=
=20
>>>> make. It's not sufficient to look at the function declaration but=20
>>>> additionally we have to look for e.g. default_a.
>>>>
>>>> --=20
>>
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--=20

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

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

<div dir=3D"ltr">Not all members in struct are public. From elementary scho=
ol, everyone knows that struct differs from class that *by default* members=
 are public in struct and private in class. ;)<br>That&#39;s why I see it a=
s a violation of encapsulation. Secondly, not only structs should be concer=
ned, but classes too. And not only initialization should be a concern here =
but also setting value *after* the object had been initialized. Taken all t=
his above, I say that accessing members of a class/struct by names, be it d=
uring initialization or after that fact is violation of encapsulation and i=
t should be discouraged in modern C++. This kind of code may very well be O=
K for C but C++ is not C. <br><br>On Wednesday, 19 August 2015 18:50:13 UTC=
+1, David Rodr=C3=ADguez Ibeas  wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr">How does that violate an encapsulation that does n=
ot exist? All members are public in the struct=E2=80=A6 you might dislike i=
t on different accounts but encapsulation is not an issue with that code.=
=C2=A0 Other pro=C2=B4s, the arguments are named, which is stable across re=
factors that might shift the positions (assuming sensible names, the caller=
 wants the &#39;a&#39; to have value X or the &#39;b&#39; to have value Z. =
Depending on the position of the member in the struct (and passing &#39;def=
ault&#39; if needed for the previous arguments) is *more* coupled, not less=
 coupled.<div><br></div><div>For initialization of structs, the C way is cl=
early better than the C++ way here. A different question is whether we want=
 to put some effort into that part of the language when we can assume that =
most types are not all-members-public.=C2=A0</div><div><br></div><div>Then =
again this is only related to default arguments to functions in that unifor=
m initialization would be even less uniform in certain cases.=C2=A0 I do se=
e the problems with named arguments, I still think that to be the better wa=
y. Whether initialization of structs can be made compatible with C once aga=
in=E2=80=A6 would be nice here, but I imagine not that many people care.</d=
iv><div><br></div><div>=C2=A0 =C2=A0 =C2=A0David</div></div><div><br><div c=
lass=3D"gmail_quote">On Wed, Aug 19, 2015 at 5:27 PM, Arthur Tchaikovsky <s=
pan dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"hSbHst89BAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;=
javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;=
;return true;">atch...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">It *is not* simpler. What you&#39;ve just sh=
own is a violation of encapsulation. Not simplification.<div><div><br><br>O=
n Wednesday, 19 August 2015 16:08:52 UTC+1, S.B.  wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">It&#39;s even simpler if we could w=
rite <br><br><div style=3D"background-color:rgb(250,250,250);border-color:r=
gb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><=
code><div><span style=3D"color:#008">struct</span><span style=3D"color:#000=
"> s </span><span style=3D"color:#660">{</span><span style=3D"color:#000"><=
br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">int</span><span style=3D=
"color:#000"> a </span><span style=3D"color:#660">=3D</span><span style=3D"=
color:#000"> </span><span style=3D"color:#066">1337</span><span style=3D"co=
lor:#660">;</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span=
 style=3D"color:#008">int</span><span style=3D"color:#000"> b </span><span =
style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#066">4096</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#660">};</span><span style=
=3D"color:#000"><br>=C2=A0<br></span><span style=3D"color:#008">int</span><=
span style=3D"color:#000"> main</span><span style=3D"color:#660">()</span><=
span style=3D"color:#000"> </span><span style=3D"color:#660">{</span><span =
style=3D"color:#000"><br>=C2=A0 =C2=A0 s x</span><span style=3D"color:#660"=
>;</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 s y </span><span styl=
e=3D"color:#660">{</span><span style=3D"color:#000"> </span><span style=3D"=
color:#066">42</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">};</span><span style=3D"color:#000"> </span><span style=3D"color:#8=
00">// or s y { .a =3D 42 };</span><span style=3D"color:#000"><br>=C2=A0 =
=C2=A0 s z </span><span style=3D"color:#660">{</span><span style=3D"color:#=
000"> </span><span style=3D"color:#660">.</span><span style=3D"color:#000">=
b </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#066">42</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#660">};</span><span style=3D"color:#000"><br>=C2=A0=
 =C2=A0 </span><span style=3D"color:#008">return</span><span style=3D"color=
:#000"> </span><span style=3D"color:#066">0</span><span style=3D"color:#660=
">;</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">=
}</span></div></code></div><br>:)<br><br>On Wednesday, August 19, 2015 at 2=
:02:01 PM UTC+8, Max Truxa wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">I =
have to agree with Matt Calabrese completely. As it was already asserted na=
med arguments are not going to happen anytime soon (if at all).<p>Earlier i=
n this thread there were workarounds listed which are more or less comparab=
le to the proposal in their effect.<br>I would like to elaborate some more =
on one of these workarounds, as it can be mapped pretty much 1-to-1 to the =
proposal and it happens to be the solution I employ when encountering this =
kind of problem.</p><p><br># Current workaround.</p><p>struct s {<br>=C2=A0=
 =C2=A0 static int const default_a =3D 1337;<br>=C2=A0 =C2=A0 static int co=
nst default_b =3D 4096;<br>=C2=A0 =C2=A0 s(int a =3D default_a, int b =3D d=
efault_b) <br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 : a(a), b(b) { }<br>=C2=A0 =C2=A0=
 int a;<br>=C2=A0 =C2=A0 int b;<br>};<br>=C2=A0<br>int main() {<br>=C2=A0 =
=C2=A0 s x;<br>=C2=A0 =C2=A0 s y(42);<br>=C2=A0 =C2=A0 s z(s::default_a, 42=
);<br>=C2=A0 =C2=A0 return 0;<br>}</p><p>See working code here: <a href=3D"=
http://ideone.com/OKtbuc" rel=3D"nofollow" target=3D"_blank" onmousedown=3D=
"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fideone.com%2FO=
Ktbuc\46sa\75D\46sntz\0751\46usg\75AFQjCNFJTtR-2NKU_hCXpY0qHPmkHWZV9g&#39;;=
return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\75htt=
p%3A%2F%2Fideone.com%2FOKtbuc\46sa\75D\46sntz\0751\46usg\75AFQjCNFJTtR-2NKU=
_hCXpY0qHPmkHWZV9g&#39;;return true;">http://ideone.com/OKtbuc</a></p><p><b=
r># Using the proposed syntax.</p><p>struct s {<br>=C2=A0 =C2=A0 s(int a =
=3D 1337, int b =3D 4096) <br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 : a(a), b(b) { }<=
br>=C2=A0 =C2=A0 int a;<br>=C2=A0 =C2=A0 int b;<br>};<br>=C2=A0<br>int main=
() {<br>=C2=A0 =C2=A0 s x;<br>=C2=A0 =C2=A0 s y(42);<br>=C2=A0 =C2=A0 s z(d=
efault, 42);<br>=C2=A0 =C2=A0 return 0;<br>}</p><p>The current solution has=
 a number of drawbacks.<br>1) It&#39;s unnecessarily verbose.<br>2) It&#39;=
s easy to mess up for parameters that have the same type. (`s z(s::default_=
b, 42)` - Oops, passed `default_b` as `a`.)<br>3) When looking up the actua=
l default values there is one more hop to make. It&#39;s not sufficient to =
look at the function declaration but additionally we have to look for e.g. =
default_a.</p><p></p><p></p><p></p><p></p><p></p><p></p></blockquote></div>=
</blockquote></div></div></div><div><div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
hSbHst89BAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"hSbHst89BAAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.or=
g/group/std-proposals/&#39;;return true;">http://groups.google.com/a/<wbr>i=
socpp.org/group/std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div>

<p></p>

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

------=_Part_529_550259881.1440007620379--
------=_Part_528_1346400368.1440007620379--

.

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

Arthur, please refrain from implying that someone needs to go back to
elementary school based on your personal interpretation of something that
someone else said. Also, if you know of an elementary school that teaches
C++ then I'd love to hear about it.

The notion that every single class ever needs to have strict encapsulation
for every single data member is fairly ridiculous in my opinion.
Encapsulation is a tool used to achieve certain software engineering goals
and it can be misused like any other tool.


On Wed, Aug 19, 2015 at 1:07 PM, Arthur Tchaikovsky <atch.cpp@gmail.com>
wrote:

> Not all members in struct are public. From elementary school, everyone
> knows that struct differs from class that *by default* members are public
> in struct and private in class. ;)
> That's why I see it as a violation of encapsulation. Secondly, not only
> structs should be concerned, but classes too. And not only initialization
> should be a concern here but also setting value *after* the object had be=
en
> initialized. Taken all this above, I say that accessing members of a
> class/struct by names, be it during initialization or after that fact is
> violation of encapsulation and it should be discouraged in modern C++. Th=
is
> kind of code may very well be OK for C but C++ is not C.
>
> On Wednesday, 19 August 2015 18:50:13 UTC+1, David Rodr=C3=ADguez Ibeas w=
rote:
>>
>> How does that violate an encapsulation that does not exist? All members
>> are public in the struct=E2=80=A6 you might dislike it on different acco=
unts but
>> encapsulation is not an issue with that code.  Other pro=C2=B4s, the arg=
uments
>> are named, which is stable across refactors that might shift the positio=
ns
>> (assuming sensible names, the caller wants the 'a' to have value X or th=
e
>> 'b' to have value Z. Depending on the position of the member in the stru=
ct
>> (and passing 'default' if needed for the previous arguments) is *more*
>> coupled, not less coupled.
>>
>> For initialization of structs, the C way is clearly better than the C++
>> way here. A different question is whether we want to put some effort int=
o
>> that part of the language when we can assume that most types are not
>> all-members-public.
>>
>> Then again this is only related to default arguments to functions in tha=
t
>> uniform initialization would be even less uniform in certain cases.  I d=
o
>> see the problems with named arguments, I still think that to be the bett=
er
>> way. Whether initialization of structs can be made compatible with C onc=
e
>> again=E2=80=A6 would be nice here, but I imagine not that many people ca=
re.
>>
>>      David
>>
>> On Wed, Aug 19, 2015 at 5:27 PM, Arthur Tchaikovsky <atch...@gmail.com>
>> wrote:
>>
>>> It *is not* simpler. What you've just shown is a violation of
>>> encapsulation. Not simplification.
>>>
>>>
>>> On Wednesday, 19 August 2015 16:08:52 UTC+1, S.B. wrote:
>>>>
>>>> It's even simpler if we could write
>>>>
>>>> struct s {
>>>>     int a =3D 1337;
>>>>     int b =3D 4096;
>>>> };
>>>>
>>>> int main() {
>>>>     s x;
>>>>     s y { 42 }; // or s y { .a =3D 42 };
>>>>     s z { .b =3D 42 };
>>>>     return 0;
>>>> }
>>>>
>>>> :)
>>>>
>>>> On Wednesday, August 19, 2015 at 2:02:01 PM UTC+8, Max Truxa wrote:
>>>>>
>>>>> I have to agree with Matt Calabrese completely. As it was already
>>>>> asserted named arguments are not going to happen anytime soon (if at =
all).
>>>>>
>>>>> Earlier in this thread there were workarounds listed which are more o=
r
>>>>> less comparable to the proposal in their effect.
>>>>> I would like to elaborate some more on one of these workarounds, as i=
t
>>>>> can be mapped pretty much 1-to-1 to the proposal and it happens to be=
 the
>>>>> solution I employ when encountering this kind of problem.
>>>>>
>>>>>
>>>>> # Current workaround.
>>>>>
>>>>> struct s {
>>>>>     static int const default_a =3D 1337;
>>>>>     static int const default_b =3D 4096;
>>>>>     s(int a =3D default_a, int b =3D default_b)
>>>>>         : a(a), b(b) { }
>>>>>     int a;
>>>>>     int b;
>>>>> };
>>>>>
>>>>> int main() {
>>>>>     s x;
>>>>>     s y(42);
>>>>>     s z(s::default_a, 42);
>>>>>     return 0;
>>>>> }
>>>>>
>>>>> See working code here: http://ideone.com/OKtbuc
>>>>>
>>>>>
>>>>> # Using the proposed syntax.
>>>>>
>>>>> struct s {
>>>>>     s(int a =3D 1337, int b =3D 4096)
>>>>>         : a(a), b(b) { }
>>>>>     int a;
>>>>>     int b;
>>>>> };
>>>>>
>>>>> int main() {
>>>>>     s x;
>>>>>     s y(42);
>>>>>     s z(default, 42);
>>>>>     return 0;
>>>>> }
>>>>>
>>>>> The current solution has a number of drawbacks.
>>>>> 1) It's unnecessarily verbose.
>>>>> 2) It's easy to mess up for parameters that have the same type. (`s
>>>>> z(s::default_b, 42)` - Oops, passed `default_b` as `a`.)
>>>>> 3) When looking up the actual default values there is one more hop to
>>>>> make. It's not sufficient to look at the function declaration but
>>>>> additionally we have to look for e.g. default_a.
>>>>>
>>>>> --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

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

<div dir=3D"ltr">Arthur, please refrain from implying that someone needs to=
 go back to elementary school based on your personal interpretation of some=
thing that someone else said. Also, if you know of an elementary school tha=
t teaches C++ then I&#39;d love to hear about it.<div><br></div><div>The no=
tion that every single class ever needs to have strict encapsulation for ev=
ery single data member is fairly ridiculous in my opinion. Encapsulation is=
 a tool used to achieve certain software engineering goals and it can be mi=
sused like any other tool.<div><br></div></div></div><div class=3D"gmail_ex=
tra"><br><div class=3D"gmail_quote">On Wed, Aug 19, 2015 at 1:07 PM, Arthur=
 Tchaikovsky <span dir=3D"ltr">&lt;<a href=3D"mailto:atch.cpp@gmail.com" ta=
rget=3D"_blank">atch.cpp@gmail.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">Not all members in struct are public. From=
 elementary school, everyone knows that struct differs from class that *by =
default* members are public in struct and private in class. ;)<br>That&#39;=
s why I see it as a violation of encapsulation. Secondly, not only structs =
should be concerned, but classes too. And not only initialization should be=
 a concern here but also setting value *after* the object had been initiali=
zed. Taken all this above, I say that accessing members of a class/struct b=
y names, be it during initialization or after that fact is violation of enc=
apsulation and it should be discouraged in modern C++. This kind of code ma=
y very well be OK for C but C++ is not C. <br><span class=3D""><br>On Wedne=
sday, 19 August 2015 18:50:13 UTC+1, David Rodr=C3=ADguez Ibeas  wrote:</sp=
an><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><span class=3D""><div dir=3D"ltr=
">How does that violate an encapsulation that does not exist? All members a=
re public in the struct=E2=80=A6 you might dislike it on different accounts=
 but encapsulation is not an issue with that code.=C2=A0 Other pro=C2=B4s, =
the arguments are named, which is stable across refactors that might shift =
the positions (assuming sensible names, the caller wants the &#39;a&#39; to=
 have value X or the &#39;b&#39; to have value Z. Depending on the position=
 of the member in the struct (and passing &#39;default&#39; if needed for t=
he previous arguments) is *more* coupled, not less coupled.<div><br></div><=
div>For initialization of structs, the C way is clearly better than the C++=
 way here. A different question is whether we want to put some effort into =
that part of the language when we can assume that most types are not all-me=
mbers-public.=C2=A0</div><div><br></div><div>Then again this is only relate=
d to default arguments to functions in that uniform initialization would be=
 even less uniform in certain cases.=C2=A0 I do see the problems with named=
 arguments, I still think that to be the better way. Whether initialization=
 of structs can be made compatible with C once again=E2=80=A6 would be nice=
 here, but I imagine not that many people care.</div><div><br></div><div>=
=C2=A0 =C2=A0 =C2=A0David</div></div></span><div><br><div class=3D"gmail_qu=
ote"><div><div class=3D"h5">On Wed, Aug 19, 2015 at 5:27 PM, Arthur Tchaiko=
vsky <span dir=3D"ltr">&lt;<a rel=3D"nofollow">atch...@gmail.com</a>&gt;</s=
pan> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class=
=3D"h5"><div dir=3D"ltr">It *is not* simpler. What you&#39;ve just shown is=
 a violation of encapsulation. Not simplification.<div><div><br><br>On Wedn=
esday, 19 August 2015 16:08:52 UTC+1, S.B.  wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr">It&#39;s even simpler if we could write <br=
><br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,1=
87,187);border-style:solid;border-width:1px;word-wrap:break-word"><code><di=
v><span style=3D"color:#008">struct</span><span style=3D"color:#000"> s </s=
pan><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=
=A0 =C2=A0 </span><span style=3D"color:#008">int</span><span style=3D"color=
:#000"> a </span><span style=3D"color:#660">=3D</span><span style=3D"color:=
#000"> </span><span style=3D"color:#066">1337</span><span style=3D"color:#6=
60">;</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color:#008">int</span><span style=3D"color:#000"> b </span><span style=
=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D=
"color:#066">4096</span><span style=3D"color:#660">;</span><span style=3D"c=
olor:#000"><br></span><span style=3D"color:#660">};</span><span style=3D"co=
lor:#000"><br>=C2=A0<br></span><span style=3D"color:#008">int</span><span s=
tyle=3D"color:#000"> main</span><span style=3D"color:#660">()</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#660">{</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 s x</span><span style=3D"color:#660">;</s=
pan><span style=3D"color:#000"><br>=C2=A0 =C2=A0 s y </span><span style=3D"=
color:#660">{</span><span style=3D"color:#000"> </span><span style=3D"color=
:#066">42</span><span style=3D"color:#000"> </span><span style=3D"color:#66=
0">};</span><span style=3D"color:#000"> </span><span style=3D"color:#800">/=
/ or s y { .a =3D 42 };</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =
s z </span><span style=3D"color:#660">{</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#660">.</span><span style=3D"color:#000">b </spa=
n><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><=
span style=3D"color:#066">42</span><span style=3D"color:#000"> </span><span=
 style=3D"color:#660">};</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0=
 </span><span style=3D"color:#008">return</span><span style=3D"color:#000">=
 </span><span style=3D"color:#066">0</span><span style=3D"color:#660">;</sp=
an><span style=3D"color:#000"><br></span><span style=3D"color:#660">}</span=
></div></code></div><br>:)<br><br>On Wednesday, August 19, 2015 at 2:02:01 =
PM UTC+8, Max Truxa wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">I have to=
 agree with Matt Calabrese completely. As it was already asserted named arg=
uments are not going to happen anytime soon (if at all).<p>Earlier in this =
thread there were workarounds listed which are more or less comparable to t=
he proposal in their effect.<br>I would like to elaborate some more on one =
of these workarounds, as it can be mapped pretty much 1-to-1 to the proposa=
l and it happens to be the solution I employ when encountering this kind of=
 problem.</p><p><br># Current workaround.</p><p>struct s {<br>=C2=A0 =C2=A0=
 static int const default_a =3D 1337;<br>=C2=A0 =C2=A0 static int const def=
ault_b =3D 4096;<br>=C2=A0 =C2=A0 s(int a =3D default_a, int b =3D default_=
b) <br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 : a(a), b(b) { }<br>=C2=A0 =C2=A0 int a;=
<br>=C2=A0 =C2=A0 int b;<br>};<br>=C2=A0<br>int main() {<br>=C2=A0 =C2=A0 s=
 x;<br>=C2=A0 =C2=A0 s y(42);<br>=C2=A0 =C2=A0 s z(s::default_a, 42);<br>=
=C2=A0 =C2=A0 return 0;<br>}</p><p>See working code here: <a href=3D"http:/=
/ideone.com/OKtbuc" rel=3D"nofollow" target=3D"_blank">http://ideone.com/OK=
tbuc</a></p><p><br># Using the proposed syntax.</p><p>struct s {<br>=C2=A0 =
=C2=A0 s(int a =3D 1337, int b =3D 4096) <br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 : =
a(a), b(b) { }<br>=C2=A0 =C2=A0 int a;<br>=C2=A0 =C2=A0 int b;<br>};<br>=C2=
=A0<br>int main() {<br>=C2=A0 =C2=A0 s x;<br>=C2=A0 =C2=A0 s y(42);<br>=C2=
=A0 =C2=A0 s z(default, 42);<br>=C2=A0 =C2=A0 return 0;<br>}</p><p>The curr=
ent solution has a number of drawbacks.<br>1) It&#39;s unnecessarily verbos=
e.<br>2) It&#39;s easy to mess up for parameters that have the same type. (=
`s z(s::default_b, 42)` - Oops, passed `default_b` as `a`.)<br>3) When look=
ing up the actual default values there is one more hop to make. It&#39;s no=
t sufficient to look at the function declaration but additionally we have t=
o look for e.g. default_a.</p><p></p><p></p><p></p><p></p><p></p><p></p></b=
lockquote></div></blockquote></div></div></div></div></div><div><div><div><=
div class=3D"h5">

<p></p>

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

<p></p>

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

<p></p>

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

--94eb2c0912546d21f2051dadfff8--

.

On 19.08.2015 21:07, Arthur Tchaikovsky wrote:
> Not all members in struct are public. From elementary school, everyone
> knows that struct differs from class that *by default* members are
> public in struct and private in class. ;)
> That's why I see it as a violation of encapsulation.

I don't see the connection between the default access mode and
encapsulation. Encapsulation is implementation hiding. It can be
achieved by different means, including but not limited to member access
management. Classes are no different from structs except for the default
access mode - both can be used to achieve the same level of encapsulation.

And no, all-public structs do not violate encapsulation in general. For
instance, std::pair - a struct with public data, does not break
encapsulation of std::(unordered_)map.

> Secondly, not only
> structs should be concerned, but classes too. And not only
> initialization should be a concern here but also setting value *after*
> the object had been initialized. Taken all this above, I say that
> accessing members of a class/struct by names, be it during
> initialization or after that fact is violation of encapsulation and it
> should be discouraged in modern C++. This kind of code may very well be
> OK for C but C++ is not C.

I don't mean to sound harsh, but that's narrow minded thinking. The 'OOP
everywhere' era has passed as people realized that it is not efficient
in all scenarios. C-style structs are useful in some contexts and named
member initialization is useful as well. See ffmpeg code for instance,
the way codecs and formats are described. That's C, naturally, but
imagine how much more code that would require in today's C++ with
private members, constructors and default arguments. And then imagine
how difficult it would be to modify the struct used as the descriptor.

--

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

.

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

On the subject of C and named parameters, I'll add that Ben Klemens' "21st
Century C" <http://shop.oreilly.com/product/0636920025108.do> shows a very
nice idiom for getting Python-style named parameters out of a C99 compiler.
I'm paraphrasing from memory a bit in the code sample below...

struct MyFunc_parameters {
  int buffer_size;
  int timeout;
  int tries;
};
#define MyFunc(...) MyFunc_((struct MyFunc_parameters){ .buffer_size=3D1024=
,
..timeout=3D5, .tries=3D3, ##__VA_ARGS__ })
void MyFunc_(struct MyFunc_parameters p) {
  for (int i=3D0; i < p.tries; ++i) {
    allocate(p.buffer_size);
    if (time() > p.timeout) bail();
  }
}

int main() {
  MyFunc();
  MyFunc(.buffer_size =3D 2048);
  MyFunc(.timeout =3D 10);
  MyFunc(.tries =3D 5, .buffer_size =3D 2048);
}

(I don't think the book is suggesting that every function in every C
program ought to use this idiom, any more than every Python function ought
to use **kwargs. It's just a nice technique for building user-friendly C99
APIs.)

This uses a whole bunch of C99-specific features; it's unlikely that C++
will *ever* get *all* of the necessary features. But it shows that you
don't need specific language-level support for defaulted parameters in
order to achieve Pythonesque syntax =E2=80=94 and in fact a syntax *nicer* =
than
C++98's defaulted parameters! (Because the caller doesn't need to care
about the order in which the callee declared its arguments; and because
it's obvious to the callee that the "parameters"' names are part of the
API.)

=E2=80=93Arthur



On Wed, Aug 19, 2015 at 10:50 AM, David Rodr=C3=ADguez Ibeas <dibeas@ieee.o=
rg>
wrote:

> How does that violate an encapsulation that does not exist? All members
> are public in the struct=E2=80=A6 you might dislike it on different accou=
nts but
> encapsulation is not an issue with that code.  Other pro=C2=B4s, the argu=
ments
> are named, which is stable across refactors that might shift the position=
s
> (assuming sensible names, the caller wants the 'a' to have value X or the
> 'b' to have value Z. Depending on the position of the member in the struc=
t
> (and passing 'default' if needed for the previous arguments) is *more*
> coupled, not less coupled.
>
> For initialization of structs, the C way is clearly better than the C++
> way here. A different question is whether we want to put some effort into
> that part of the language when we can assume that most types are not
> all-members-public.
>
> Then again this is only related to default arguments to functions in that
> uniform initialization would be even less uniform in certain cases.  I do
> see the problems with named arguments, I still think that to be the bette=
r
> way. Whether initialization of structs can be made compatible with C once
> again=E2=80=A6 would be nice here, but I imagine not that many people car=
e.
>
>      David
>
> On Wed, Aug 19, 2015 at 5:27 PM, Arthur Tchaikovsky <atch.cpp@gmail.com>
> wrote:
>
>> It *is not* simpler. What you've just shown is a violation of
>> encapsulation. Not simplification.
>>
>>
>> On Wednesday, 19 August 2015 16:08:52 UTC+1, S.B. wrote:
>>>
>>> It's even simpler if we could write
>>>
>>> struct s {
>>>     int a =3D 1337;
>>>     int b =3D 4096;
>>> };
>>>
>>> int main() {
>>>     s x;
>>>     s y { 42 }; // or s y { .a =3D 42 };
>>>     s z { .b =3D 42 };
>>>     return 0;
>>> }
>>>
>>> :)
>>>
>>> On Wednesday, August 19, 2015 at 2:02:01 PM UTC+8, Max Truxa wrote:
>>>>
>>>> I have to agree with Matt Calabrese completely. As it was already
>>>> asserted named arguments are not going to happen anytime soon (if at a=
ll).
>>>>
>>>> Earlier in this thread there were workarounds listed which are more or
>>>> less comparable to the proposal in their effect.
>>>> I would like to elaborate some more on one of these workarounds, as it
>>>> can be mapped pretty much 1-to-1 to the proposal and it happens to be =
the
>>>> solution I employ when encountering this kind of problem.
>>>>
>>>>
>>>> # Current workaround.
>>>>
>>>> struct s {
>>>>     static int const default_a =3D 1337;
>>>>     static int const default_b =3D 4096;
>>>>     s(int a =3D default_a, int b =3D default_b)
>>>>         : a(a), b(b) { }
>>>>     int a;
>>>>     int b;
>>>> };
>>>>
>>>> int main() {
>>>>     s x;
>>>>     s y(42);
>>>>     s z(s::default_a, 42);
>>>>     return 0;
>>>> }
>>>>
>>>> See working code here: http://ideone.com/OKtbuc
>>>>
>>>>
>>>> # Using the proposed syntax.
>>>>
>>>> struct s {
>>>>     s(int a =3D 1337, int b =3D 4096)
>>>>         : a(a), b(b) { }
>>>>     int a;
>>>>     int b;
>>>> };
>>>>
>>>> int main() {
>>>>     s x;
>>>>     s y(42);
>>>>     s z(default, 42);
>>>>     return 0;
>>>> }
>>>>
>>>> The current solution has a number of drawbacks.
>>>> 1) It's unnecessarily verbose.
>>>> 2) It's easy to mess up for parameters that have the same type. (`s
>>>> z(s::default_b, 42)` - Oops, passed `default_b` as `a`.)
>>>> 3) When looking up the actual default values there is one more hop to
>>>> make. It's not sufficient to look at the function declaration but
>>>> additionally we have to look for e.g. default_a.
>>>>
>>>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/3iegpTsMuT0/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

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

<div dir=3D"ltr">On the subject of C and named parameters, I&#39;ll add tha=
t <a href=3D"http://shop.oreilly.com/product/0636920025108.do">Ben Klemens&=
#39; &quot;21st Century C&quot;</a> shows a very nice idiom for getting Pyt=
hon-style named parameters out of a C99 compiler. I&#39;m paraphrasing from=
 memory a bit in the code sample below...<br><br><div><font face=3D"monospa=
ce, monospace">struct MyFunc_parameters {</font></div><div><font face=3D"mo=
nospace, monospace">=C2=A0 int buffer_size;</font></div><div><font face=3D"=
monospace, monospace">=C2=A0 int timeout;</font></div><div><font face=3D"mo=
nospace, monospace">=C2=A0 int tries;</font></div><div><font face=3D"monosp=
ace, monospace">};<br></font></div><div><font face=3D"monospace, monospace"=
>#define MyFunc(...) MyFunc_((struct MyFunc_parameters){ .buffer_size=3D102=
4, .timeout=3D5, .tries=3D3, ##__VA_ARGS__ })</font></div><div><font face=
=3D"monospace, monospace">void MyFunc_(struct MyFunc_parameters p) {</font>=
</div><div><font face=3D"monospace, monospace">=C2=A0 for (int i=3D0; i &lt=
; p.tries; ++i) {</font></div><div><font face=3D"monospace, monospace">=C2=
=A0 =C2=A0 allocate(p.buffer_size);</font></div><div><font face=3D"monospac=
e, monospace">=C2=A0 =C2=A0 if (time() &gt; p.timeout) bail();</font></div>=
<div><font face=3D"monospace, monospace">=C2=A0 }</font></div><div><font fa=
ce=3D"monospace, monospace">}<br></font></div><div><font face=3D"monospace,=
 monospace"><br></font></div><div><font face=3D"monospace, monospace">int m=
ain() {</font></div><div><font face=3D"monospace, monospace">=C2=A0 MyFunc(=
);</font></div><div><font face=3D"monospace, monospace">=C2=A0 MyFunc(.buff=
er_size =3D 2048);</font></div><div><font face=3D"monospace, monospace">=C2=
=A0 MyFunc(.timeout =3D 10);</font></div><div><font face=3D"monospace, mono=
space">=C2=A0 MyFunc(.tries =3D 5, .buffer_size =3D 2048);</font></div><div=
><font face=3D"monospace, monospace">}</font></div><div><br></div><div>(I d=
on&#39;t think the book is suggesting that every function in every C progra=
m ought to use this idiom, any more than every Python function ought to use=
 <font face=3D"monospace, monospace">**kwargs</font>. It&#39;s just a nice =
technique for building user-friendly C99 APIs.)</div><div><br></div><div>Th=
is uses a whole bunch of C99-specific features; it&#39;s unlikely that C++ =
will <i>ever</i> get <i>all</i> of the necessary features. But it shows tha=
t you don&#39;t need specific language-level support for defaulted paramete=
rs in order to achieve Pythonesque syntax =E2=80=94 and in fact a syntax <i=
>nicer</i> than C++98&#39;s defaulted parameters! (Because the caller doesn=
&#39;t need to care about the order in which the callee declared its argume=
nts; and because it&#39;s obvious to the callee that the &quot;parameters&q=
uot;&#39; names are part of the API.)</div><div><br></div><div>=E2=80=93Art=
hur</div><div><br></div><div><br></div></div><div class=3D"gmail_extra"><br=
><div class=3D"gmail_quote">On Wed, Aug 19, 2015 at 10:50 AM, David Rodr=C3=
=ADguez Ibeas <span dir=3D"ltr">&lt;<a href=3D"mailto:dibeas@ieee.org" targ=
et=3D"_blank">dibeas@ieee.org</a>&gt;</span> wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr">How does that violate an encapsulation that doe=
s not exist? All members are public in the struct=E2=80=A6 you might dislik=
e it on different accounts but encapsulation is not an issue with that code=
..=C2=A0 Other pro=C2=B4s, the arguments are named, which is stable across r=
efactors that might shift the positions (assuming sensible names, the calle=
r wants the &#39;a&#39; to have value X or the &#39;b&#39; to have value Z.=
 Depending on the position of the member in the struct (and passing &#39;de=
fault&#39; if needed for the previous arguments) is *more* coupled, not les=
s coupled.<div><br></div><div>For initialization of structs, the C way is c=
learly better than the C++ way here. A different question is whether we wan=
t to put some effort into that part of the language when we can assume that=
 most types are not all-members-public.=C2=A0</div><div><br></div><div>Then=
 again this is only related to default arguments to functions in that unifo=
rm initialization would be even less uniform in certain cases.=C2=A0 I do s=
ee the problems with named arguments, I still think that to be the better w=
ay. Whether initialization of structs can be made compatible with C once ag=
ain=E2=80=A6 would be nice here, but I imagine not that many people care.</=
div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0David</div></div><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote">On Wed, Aug 19, 2015 at 5:27 PM=
, Arthur Tchaikovsky <span dir=3D"ltr">&lt;<a href=3D"mailto:atch.cpp@gmail=
..com" target=3D"_blank">atch.cpp@gmail.com</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr">It *is not* simpler. What you&#39;=
ve just shown is a violation of encapsulation. Not simplification.<div><div=
><br><br>On Wednesday, 19 August 2015 16:08:52 UTC+1, S.B.  wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">It&#39;s even simpler if we=
 could write <br><br><div style=3D"background-color:rgb(250,250,250);border=
-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break=
-word"><code><div><span style=3D"color:#008">struct</span><span style=3D"co=
lor:#000"> s </span><span style=3D"color:#660">{</span><span style=3D"color=
:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">int</span><span =
style=3D"color:#000"> a </span><span style=3D"color:#660">=3D</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#066">1337</span><span sty=
le=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </sp=
an><span style=3D"color:#008">int</span><span style=3D"color:#000"> b </spa=
n><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><=
span style=3D"color:#066">4096</span><span style=3D"color:#660">;</span><sp=
an style=3D"color:#000"><br></span><span style=3D"color:#660">};</span><spa=
n style=3D"color:#000"><br>=C2=A0<br></span><span style=3D"color:#008">int<=
/span><span style=3D"color:#000"> main</span><span style=3D"color:#660">()<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#660">{</span=
><span style=3D"color:#000"><br>=C2=A0 =C2=A0 s x</span><span style=3D"colo=
r:#660">;</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 s y </span><sp=
an style=3D"color:#660">{</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#066">42</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">};</span><span style=3D"color:#000"> </span><span style=3D"=
color:#800">// or s y { .a =3D 42 };</span><span style=3D"color:#000"><br>=
=C2=A0 =C2=A0 s z </span><span style=3D"color:#660">{</span><span style=3D"=
color:#000"> </span><span style=3D"color:#660">.</span><span style=3D"color=
:#000">b </span><span style=3D"color:#660">=3D</span><span style=3D"color:#=
000"> </span><span style=3D"color:#066">42</span><span style=3D"color:#000"=
> </span><span style=3D"color:#660">};</span><span style=3D"color:#000"><br=
>=C2=A0 =C2=A0 </span><span style=3D"color:#008">return</span><span style=
=3D"color:#000"> </span><span style=3D"color:#066">0</span><span style=3D"c=
olor:#660">;</span><span style=3D"color:#000"><br></span><span style=3D"col=
or:#660">}</span></div></code></div><br>:)<br><br>On Wednesday, August 19, =
2015 at 2:02:01 PM UTC+8, Max Truxa wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">I have to agree with Matt Calabrese completely. As it was already as=
serted named arguments are not going to happen anytime soon (if at all).<p>=
Earlier in this thread there were workarounds listed which are more or less=
 comparable to the proposal in their effect.<br>I would like to elaborate s=
ome more on one of these workarounds, as it can be mapped pretty much 1-to-=
1 to the proposal and it happens to be the solution I employ when encounter=
ing this kind of problem.</p><p><br># Current workaround.</p><p>struct s {<=
br>=C2=A0 =C2=A0 static int const default_a =3D 1337;<br>=C2=A0 =C2=A0 stat=
ic int const default_b =3D 4096;<br>=C2=A0 =C2=A0 s(int a =3D default_a, in=
t b =3D default_b) <br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 : a(a), b(b) { }<br>=C2=
=A0 =C2=A0 int a;<br>=C2=A0 =C2=A0 int b;<br>};<br>=C2=A0<br>int main() {<b=
r>=C2=A0 =C2=A0 s x;<br>=C2=A0 =C2=A0 s y(42);<br>=C2=A0 =C2=A0 s z(s::defa=
ult_a, 42);<br>=C2=A0 =C2=A0 return 0;<br>}</p><p>See working code here: <a=
 href=3D"http://ideone.com/OKtbuc" rel=3D"nofollow" target=3D"_blank">http:=
//ideone.com/OKtbuc</a></p><p><br># Using the proposed syntax.</p><p>struct=
 s {<br>=C2=A0 =C2=A0 s(int a =3D 1337, int b =3D 4096) <br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 : a(a), b(b) { }<br>=C2=A0 =C2=A0 int a;<br>=C2=A0 =C2=A0 int=
 b;<br>};<br>=C2=A0<br>int main() {<br>=C2=A0 =C2=A0 s x;<br>=C2=A0 =C2=A0 =
s y(42);<br>=C2=A0 =C2=A0 s z(default, 42);<br>=C2=A0 =C2=A0 return 0;<br>}=
</p><p>The current solution has a number of drawbacks.<br>1) It&#39;s unnec=
essarily verbose.<br>2) It&#39;s easy to mess up for parameters that have t=
he same type. (`s z(s::default_b, 42)` - Oops, passed `default_b` as `a`.)<=
br>3) When looking up the actual default values there is one more hop to ma=
ke. It&#39;s not sufficient to look at the function declaration but additio=
nally we have to look for e.g. default_a.</p><span class=3D"HOEnZb"><font c=
olor=3D"#888888"><p></p><p></p><p></p><p></p><p></p><p></p></font></span></=
blockquote></div></blockquote></div></div></div><span class=3D"HOEnZb"><fon=
t color=3D"#888888"><div><div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></font></span></blockquote></div><span class=3D"HOEnZb"><font c=
olor=3D"#888888"><br></font></span></div><span class=3D"HOEnZb"><font color=
=3D"#888888">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/3iegpTsMuT0/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/3iegpTsMuT0=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

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

--e89a8f647a39c5acd3051db2bc9d--

.

--Apple-Mail=_DB5477E2-B84A-45DE-AD7C-95E5C8FE6C41
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9308=E2=80=9320, at 7:53 AM, Arthur O'Dwyer <arthur.j.odwye=
r@gmail.com> wrote:
>=20
> On the subject of C and named parameters, I'll add that Ben Klemens' "21s=
t Century C" <http://shop.oreilly.com/product/0636920025108.do> shows a ver=
y nice idiom for getting Python-style named parameters out of a C99 compile=
r. I'm paraphrasing from memory a bit in the code sample below=E2=80=A6


Perhaps the syntax of an expression-list beginning with =E2=80=9C.=E2=80=9D=
 should indicate implicit braces, added as sugar. I think that passing a st=
ruct is a superior design when lots of parameters are present, and one supp=
orted by decades of experience.

struct parameters {
  int buffer_size =3D 1024;
  int timeout =3D 10;
  int tries =3D 3;
};

int foo( parameters );
int x =3D foo( .buffer_size =3D 100, .timeout =3D 2, .tries =3D 3 ); // imp=
licit braces

class non_aggregate {
public:
  non_aggregate( int, int, int ); // A
  non_aggregate( parameters ); // B
};

non_aggregate a( 1, 2, 3 ); // A
non_aggregate b{ 1, 2, 3 }; // A
non_aggregate c({ .buffer_size =3D 100, .timeout =3D 2, .tries =3D 3 }); //=
 B (no extension beyond designated initializers)
non_aggregate d{{ .buffer_size =3D 100, .timeout =3D 2, .tries =3D 3 }}; //=
 B (no extension beyond designated initializers)
non_aggregate e( .buffer_size =3D 100, .timeout =3D 2, .tries =3D 3 ); // B=
 (implicit braces)
non_aggregate f{ .buffer_size =3D 100, .timeout =3D 2, .tries =3D 3 }; // e=
rror: braces are implicit only inside parens

It=E2=80=99s better to disallow the last case, because list-initialization =
should represent aggregation; it shouldn=E2=80=99t be used to express gener=
ating an object from a set of abstract parameters or constraints.

--=20

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

--Apple-Mail=_DB5477E2-B84A-45DE-AD7C-95E5C8FE6C41
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9308=
=E2=80=9320, at 7:53 AM, Arthur O'Dwyer &lt;<a href=3D"mailto:arthur.j.odwy=
er@gmail.com" class=3D"">arthur.j.odwyer@gmail.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px;" class=3D"">On the subject of C and named parameters, I'll add=
 that<span class=3D"Apple-converted-space">&nbsp;</span><a href=3D"http://s=
hop.oreilly.com/product/0636920025108.do" class=3D"">Ben Klemens' "21st Cen=
tury C"</a><span class=3D"Apple-converted-space">&nbsp;</span>shows a very =
nice idiom for getting Python-style named parameters out of a C99 compiler.=
 I'm paraphrasing from memory a bit in the code sample below=E2=80=A6</div>=
</div></blockquote></div><div class=3D""><br class=3D""></div>Perhaps the s=
yntax of an&nbsp;<i class=3D"">expression-list</i>&nbsp;beginning with =E2=
=80=9C<font face=3D"Courier" class=3D"">.</font>=E2=80=9D should indicate i=
mplicit braces, added as sugar.&nbsp;I think that passing a&nbsp;<font face=
=3D"Courier" class=3D"">struct</font>&nbsp;is a superior design when lots o=
f parameters are present, and one supported by decades of experience.<div c=
lass=3D""><div class=3D""><br class=3D""></div><div class=3D""><div class=
=3D""><font face=3D"monospace, monospace" class=3D"">struct parameters {</f=
ont></div><div class=3D""><font face=3D"monospace, monospace" class=3D"">&n=
bsp; int buffer_size =3D 1024;</font></div><div class=3D""><font face=3D"mo=
nospace, monospace" class=3D"">&nbsp; int timeout =3D 10;</font></div><div =
class=3D""><font face=3D"monospace, monospace" class=3D"">&nbsp; int tries =
=3D 3;</font></div><div class=3D""><font face=3D"monospace, monospace" clas=
s=3D"">};<br class=3D""></font></div><div class=3D""><font face=3D"monospac=
e, monospace" class=3D""><br class=3D""></font></div><div class=3D""><font =
face=3D"monospace, monospace" class=3D"">int foo( parameters );</font></div=
><div class=3D""><font face=3D"monospace, monospace" class=3D"">int x =3D f=
oo</font><span style=3D"font-family: monospace, monospace;" class=3D"">( .b=
uffer_size =3D 100, .timeout =3D 2, .tries =3D 3 ); // implicit braces</spa=
n></div><div class=3D""><span style=3D"font-family: monospace, monospace;" =
class=3D""><br class=3D""></span></div><div class=3D""><font face=3D"monosp=
ace, monospace" class=3D"">class non_aggregate {</font></div><div class=3D"=
"><font face=3D"monospace, monospace" class=3D"">public:</font></div><div c=
lass=3D""><font face=3D"monospace, monospace" class=3D"">&nbsp; non_aggrega=
te( int, int, int ); // A</font></div><div class=3D""><font face=3D"monospa=
ce, monospace" class=3D"">&nbsp; non_aggregate(&nbsp;</font><span style=3D"=
font-family: monospace, monospace;" class=3D"">parameters</span><font face=
=3D"monospace, monospace" class=3D"">&nbsp;); // B</font></div><div class=
=3D""><font face=3D"monospace, monospace" class=3D"">};</font></div><div cl=
ass=3D""><font face=3D"monospace, monospace" class=3D""><br class=3D""></fo=
nt></div><div class=3D""><span style=3D"font-family: monospace, monospace;"=
 class=3D"">non_aggregate a( 1, 2, 3 ); // A</span></div><div class=3D""><d=
iv class=3D""><font face=3D"monospace, monospace" class=3D"">non_aggregate =
b{ 1, 2, 3 }; // A</font></div></div><div class=3D""><div class=3D""><font =
face=3D"monospace, monospace" class=3D"">non_aggregate c({ .buffer_size =3D=
 100, .timeout =3D 2, .tries =3D 3 }); // B (no extension</font><span style=
=3D"font-family: monospace, monospace;" class=3D"">&nbsp;</span><span style=
=3D"font-family: monospace, monospace;" class=3D"">beyond designated initia=
lizers</span><span style=3D"font-family: monospace, monospace;" class=3D"">=
)</span></div><div class=3D""><font face=3D"monospace, monospace" class=3D"=
">non_aggregate d{{ .buffer_size =3D 100, .timeout =3D 2, .tries =3D 3 }};<=
/font><font face=3D"monospace, monospace" class=3D"">&nbsp;// B (no extensi=
on</font><span style=3D"font-family: monospace, monospace;" class=3D"">&nbs=
p;</span><span style=3D"font-family: monospace, monospace;" class=3D"">beyo=
nd designated initializers</span><span style=3D"font-family: monospace, mon=
ospace;" class=3D"">)</span></div><div class=3D""><span style=3D"font-famil=
y: monospace, monospace;" class=3D"">non_aggregate e( .buffer_size =3D 100,=
 .timeout =3D 2, .tries =3D 3 ); // B (implicit braces)</span></div><div cl=
ass=3D""><span style=3D"font-family: monospace, monospace;" class=3D"">non_=
aggregate f{ .buffer_size =3D 100, .timeout =3D 2, .tries =3D 3 }; // error=
: braces are implicit only inside parens</span></div></div></div></div><div=
 class=3D""><br class=3D""></div><div class=3D"">It=E2=80=99s better to dis=
allow the last case, because list-initialization should represent aggregati=
on; it shouldn=E2=80=99t be used to express generating an object from a set=
 of abstract parameters or constraints.</div><div class=3D""><br class=3D""=
></div></body></html>

<p></p>

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

--Apple-Mail=_DB5477E2-B84A-45DE-AD7C-95E5C8FE6C41--

.

------=_Part_4985_769217796.1440043164405
Content-Type: multipart/alternative;
 boundary="----=_Part_4986_330267063.1440043164405"

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



On Wednesday, August 19, 2015 at 9:59:08 PM UTC-4, David Krauss wrote:
>
>
> On 2015=E2=80=9308=E2=80=9320, at 7:53 AM, Arthur O'Dwyer <arthur....@gma=
il.com=20
> <javascript:>> wrote:
>
> On the subject of C and named parameters, I'll add that Ben Klemens'=20
> "21st Century C" <http://shop.oreilly.com/product/0636920025108.do> shows=
=20
> a very nice idiom for getting Python-style named parameters out of a C99=
=20
> compiler. I'm paraphrasing from memory a bit in the code sample below=E2=
=80=A6
>
>
> Perhaps the syntax of an *expression-list* beginning with =E2=80=9C.=E2=
=80=9D should=20
> indicate implicit braces, added as sugar. I think that passing a struct i=
s=20
> a superior design when lots of parameters are present, and one supported =
by=20
> decades of experience.
>

Generally speaking, if you have that many parameters, then some of those=20
parameters almost certainly are pieces of larger semantic groupings. And=20
therefore they should have been grouped into structs to begin with.

What you're doing is enforcing a single struct policy, which is not=20
something I would want to see advocated or become commonplace. However, it=
=20
does lack the terrible syntactic noise of the C version, so it's already=20
ahead of the curve ;)

The big downside I think has to do with the language. Your proposal makes=
=20
sense, but not once you start providing default parameters. Here's an=20
example:

parameters value{.buffer_size =3D 100, .timeout =3D 2, .tries =3D 3};

What does this do? I don't me from a top-level perspective; I'm not asking=
=20
what you want it to mean. I'm asking what this actually does, in terms of=
=20
the language?

That braced-init-list *cannot* perform aggregate initialization, because=20
`parameters` is not an aggregate. Aggregates cannot have non-static data=20
member initializers.

So what exactly are you proposing that this do? Do you intend to define a=
=20
new class of pseudo-aggregate, which has all of the limitations of a=20
regular aggregate, only it allows NSDMIs?

The problem with that is that NSDMI's operate by effectively modifying=20
constructors. They provide default parameters for a constructor's=20
initialization list; that's why they're not aggregates. If there are no=20
user-provided constructors, and you're not using the default constructor=20
(or one of the other special ones), it's not clear at all to me what code=
=20
will be used to initialize the pseudo-aggregate. Where does the constructor=
=20
you call get defined?

Oh sure, we all know what we *want* to have happen. It's a matter of making=
=20
it work in the language without breaking 20 other things.

As for the implicit braces thing, that sounds like a very bad idea. Uniform=
=20
initialization already has way too many implicit braces, to the point where=
=20
it actually gets non-uniform. It's two extra characters; I don't see it as=
=20
provoking that much syntactic noise.

--=20

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

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

<br><br>On Wednesday, August 19, 2015 at 9:59:08 PM UTC-4, David Krauss wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:bre=
ak-word"><br><div><blockquote type=3D"cite"><div>On 2015=E2=80=9308=E2=80=
=9320, at 7:53 AM, Arthur O&#39;Dwyer &lt;<a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"kiYUy41YBAAJ" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=
=3D&#39;javascript:&#39;;return true;">arthur....@gmail.com</a>&gt; wrote:<=
/div><br><div><div dir=3D"ltr" style=3D"font-family:Helvetica;font-size:12p=
x;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:n=
ormal;line-height:normal;text-align:start;text-indent:0px;text-transform:no=
ne;white-space:normal;word-spacing:0px">On the subject of C and named param=
eters, I&#39;ll add that<span>=C2=A0</span><a href=3D"http://shop.oreilly.c=
om/product/0636920025108.do" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fshop.oreill=
y.com%2Fproduct%2F0636920025108.do\46sa\75D\46sntz\0751\46usg\75AFQjCNGyBnX=
ZMDytQk6NbNcL80rjED7X0g&#39;;return true;" onclick=3D"this.href=3D&#39;http=
://www.google.com/url?q\75http%3A%2F%2Fshop.oreilly.com%2Fproduct%2F0636920=
025108.do\46sa\75D\46sntz\0751\46usg\75AFQjCNGyBnXZMDytQk6NbNcL80rjED7X0g&#=
39;;return true;">Ben Klemens&#39; &quot;21st Century C&quot;</a><span>=C2=
=A0</span>shows a very nice idiom for getting Python-style named parameters=
 out of a C99 compiler. I&#39;m paraphrasing from memory a bit in the code =
sample below=E2=80=A6</div></div></blockquote></div><div><br></div>Perhaps =
the syntax of an=C2=A0<i>expression-list</i>=C2=A0beginning with =E2=80=9C<=
font face=3D"Courier">.</font>=E2=80=9D should indicate implicit braces, ad=
ded as sugar.=C2=A0I think that passing a=C2=A0<font face=3D"Courier">struc=
t</font>=C2=A0is a superior design when lots of parameters are present, and=
 one supported by decades of experience.</div></blockquote><div><br>General=
ly speaking, if you have that many parameters, then some of those parameter=
s almost certainly are pieces of larger semantic groupings. And therefore t=
hey should have been grouped into structs to begin with.<br><br>What you&#3=
9;re doing is enforcing a single struct policy, which is not something I wo=
uld want to see advocated or become commonplace. However, it does lack the =
terrible syntactic noise of the C version, so it&#39;s already ahead of the=
 curve ;)<br><br>The big downside I think has to do with the language. Your=
 proposal makes sense, but not once you start providing default parameters.=
 Here&#39;s an example:<br><br><div class=3D"prettyprint" style=3D"backgrou=
nd-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-styl=
e: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">parameters value</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{.</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">buffer_size </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettif=
y">100</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">timeout </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" cla=
ss=3D"styled-by-prettify">2</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">.=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">tries </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">3</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">};</span></div></code></div><br>What =
does this do? I don&#39;t me from a top-level perspective; I&#39;m not aski=
ng what you want it to mean. I&#39;m asking what this actually does, in ter=
ms of the language?<br><br>That braced-init-list <i>cannot</i> perform aggr=
egate initialization, because `parameters` is not an aggregate. Aggregates =
cannot have non-static data member initializers.<br><br>So what exactly are=
 you proposing that this do? Do you intend to define a new class of pseudo-=
aggregate, which has all of the limitations of a regular aggregate, only it=
 allows NSDMIs?<br><br>The problem with that is that NSDMI&#39;s operate by=
 effectively modifying constructors. They provide default parameters for a =
constructor&#39;s initialization list; that&#39;s why they&#39;re not aggre=
gates. If there are no user-provided constructors, and you&#39;re not using=
 the default constructor (or one of the other special ones), it&#39;s not c=
lear at all to me what code will be used to initialize the pseudo-aggregate=
.. Where does the constructor you call get defined?<br><br>Oh sure, we all k=
now what we <i>want</i> to have happen. It&#39;s a matter of making it work=
 in the language without breaking 20 other things.<br><br>As for the implic=
it braces thing, that sounds like a very bad idea. Uniform initialization a=
lready has way too many implicit braces, to the point where it actually get=
s non-uniform. It&#39;s two extra characters; I don&#39;t see it as provoki=
ng that much syntactic noise.<br></div>

<p></p>

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

------=_Part_4986_330267063.1440043164405--
------=_Part_4985_769217796.1440043164405--

.

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

Le 15/08/15 18:49, Arthur Tchaikovsky a =C3=A9crit :
> Hi,
> Does anyone see helpfulness of such solution:
> Having fnc:
>
> void f(int a =3D 0, int b =3D 1, int c =3D 2, int d =3D 3);
>
> I think that it would be nice to be able to say whilst calling it and
> requiring only some of those args to be non-default:
>
> f(default,2,default,4);
>
> Thoughts?
>
>
Hi, note that I'm not against the proposal.

Just wanted to share a way to do what you are proposing in C++14. It is=20
an alternative that is cumbersome and error prone. It consist in using=20
overloading and a default_t type and a default_ instance of default_t.

     f(int buffer_size =3D 1024, int timeout =3D 10, int tries =3D 3);
     f(default_t, int timeout =3D 10, int tries =3D 3) { return f(1024, tim=
eout, tries); }
     f(int buffer_size, default_t, int tries =3D 3) { return f(buffer_size,=
 10, tries); }

f();
f(default_, 0);
f(default_, default_, 20);

The function provider can use constant for the defaults of course but the u=
seof the constants is however error prone.

IMO, this kind of approach should appear in a possible proposal as your pro=
posal solves all the issues of this approach.

Vicente





--=20

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

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 15/08/15 18:49, Arthur Tchaikovsky a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:ef9c7cbe-e8f1-4196-83bc-11a1c9b2798c@isocpp.org"
      type=3D"cite">
      <pre wrap=3D"">Hi,=20
Does anyone see helpfulness of such solution:
Having fnc:

void f(int a =3D 0, int b =3D 1, int c =3D 2, int d =3D 3);

I think that it would be nice to be able to say whilst calling it and=20
requiring only some of those args to be non-default:

f(default,2,default,4);

Thoughts?


</pre>
    </blockquote>
    <font size=3D"+1">Hi, note that I'm not against the proposal.<br>
      <br>
      Just wanted to share a way to do what you are proposing in C++14.
      It is an alternative that is cumbersome and error prone. It
      consist in using overloading and a default_t type and a default_
      instance of default_t.</font><br>
    <br>
    <pre wrap=3D"">    f(int buffer_size =3D 1024, int timeout =3D 10, int =
tries =3D 3);
    f(default_t, int timeout =3D 10, int tries =3D 3) { return f(1024, time=
out, tries); }
    f(int buffer_size, default_t, int tries =3D 3) { return f(buffer_size, =
10, tries); }

f();
f(default_, 0);
f(default_, default_, 20);

The function provider can use constant for the defaults of course but the u=
seof the constants is however error prone.

IMO, this kind of approach should appear in a possible proposal as your pro=
posal solves all the issues of this approach. =20

Vicente




</pre>
    <br>
  </body>
</html>

<p></p>

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

--------------030205020903080201030404--

.

--Apple-Mail=_5C8BF3B8-BE47-48D0-B5F8-273C6BB21D04
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9308=E2=80=9320, at 11:59 AM, Nicol Bolas <jmckesson@gmail.=
com> wrote:
>=20
> What you're doing is enforcing a single struct policy, which is not somet=
hing I would want to see advocated or become commonplace. However, it does =
lack the terrible syntactic noise of the C version, so it's already ahead o=
f the curve ;)

One is better than zero=E2=80=A6 but what=E2=80=99s the impediment to group=
ing by nested sub-aggregates?

> The problem with that is that NSDMI's operate by effectively modifying co=
nstructors.

Since C++14, NSDMIs have a second method of action, by aggregate initializa=
tion. They are already allowed in aggregates.

> As for the implicit braces thing, that sounds like a very bad idea. Unifo=
rm initialization already has way too many implicit braces, to the point wh=
ere it actually gets non-uniform. It's two extra characters; I don't see it=
 as provoking that much syntactic noise.

Hmm, are you for the proposal or against? Implicit braces are the entirety =
of it. (Note that Clang and GCC already implement designated initializers, =
both only issuing a warning under -pedantic.) And they specifically don=E2=
=80=99t apply under brace (uniform) initialization.

The problem with adding designated initializers alone is that they enhance =
aggregates but not classes with constructors. This impedes refactoring an a=
ggregate into a non-aggregate, which is a very common operation.

If you look closer, there is a common syntax (already compatible with GCC <=
http://coliru.stacked-crooked.com/a/b5ecf9099e190e01> and Clang <http://col=
iru.stacked-crooked.com/a/49c98dc08aac1b18> for initializing an aggregate w=
ith designated initializers or a non-aggregate by a =E2=80=9Cvalue prototyp=
e=E2=80=9D aggregate, which is to use both parens and braces as foo({.x =3D=
 42}). It=E2=80=99s not that much typing, but it=E2=80=99s too much to be i=
diomatic, especially for a quick-and-dirty aggregate that just might become=
 more complex later.

So, my suggestion is to use parens with designated initializers as a common=
 ground between aggregates and constructors. If you=E2=80=99re writing an a=
ggregate that perhaps shouldn=E2=80=99t be an aggregate, it encourages you =
to use parens and designated initializers. This should have the added benef=
it of reducing abuse of =E2=80=9Cuniform=E2=80=9D initialization to call or=
dinary constructors. On the other hand, most such aggregates only have 2-3 =
members, and splitting out the parameter class is a bit of extra effort and=
 noise.

--=20

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

--Apple-Mail=_5C8BF3B8-BE47-48D0-B5F8-273C6BB21D04
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div class=3D""><b=
r class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On 2=
015=E2=80=9308=E2=80=9320, at 11:59 AM, Nicol Bolas &lt;<a href=3D"mailto:j=
mckesson@gmail.com" class=3D"">jmckesson@gmail.com</a>&gt; wrote:</div><div=
 class=3D""><br class=3D""><div class=3D"">What you're doing is enforcing a=
 single struct policy, which is not something I would want to see advocated=
 or become commonplace. However, it does lack the terrible syntactic noise =
of the C version, so it's already ahead of the curve ;)<br class=3D""></div=
></div></blockquote><div><br class=3D""></div><div>One is better than zero=
=E2=80=A6 but what=E2=80=99s the impediment to grouping by nested sub-aggre=
gates?</div><br class=3D""><blockquote type=3D"cite" class=3D""><div class=
=3D""><div class=3D"">The problem with that is that NSDMI's operate by effe=
ctively modifying constructors. </div></div></blockquote><div><br class=3D"=
"></div><div>Since C++14, NSDMIs have a second method of action, by aggrega=
te initialization. They are already allowed in aggregates.</div><br class=
=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div class=3D"">=
As for the implicit braces thing, that sounds like a very bad idea. Uniform=
 initialization already has way too many implicit braces, to the point wher=
e it actually gets non-uniform. It's two extra characters; I don't see it a=
s provoking that much syntactic noise.<br class=3D""></div></div></blockquo=
te><div><br class=3D""></div></div>Hmm, are you for the proposal or against=
? Implicit braces are the entirety of it. (Note that Clang and GCC already =
implement designated initializers, both only issuing a warning under -pedan=
tic.) And they specifically don=E2=80=99t apply under brace (uniform) initi=
alization.</div><div class=3D""><br class=3D""></div><div class=3D"">The pr=
oblem with adding designated initializers alone is that they enhance aggreg=
ates but not classes with constructors. This impedes refactoring an aggrega=
te into a non-aggregate, which is a very common operation.</div><div class=
=3D""><br class=3D""></div><div class=3D"">If you look closer, there is a c=
ommon syntax (already compatible with&nbsp;<a href=3D"http://coliru.stacked=
-crooked.com/a/b5ecf9099e190e01" class=3D"">GCC</a>&nbsp;and&nbsp;<a href=
=3D"http://coliru.stacked-crooked.com/a/49c98dc08aac1b18" class=3D"">Clang<=
/a>&nbsp;for initializing an aggregate with designated initializers or a no=
n-aggregate by a =E2=80=9Cvalue prototype=E2=80=9D aggregate, which is to u=
se both parens and braces as <font face=3D"Courier" class=3D"">foo({.x =3D =
42})</font>. It=E2=80=99s not <i class=3D"">that</i>&nbsp;much typing, but =
it=E2=80=99s too much to be idiomatic, especially for a quick-and-dirty agg=
regate that just might become more complex later.</div><div class=3D""><br =
class=3D""></div><div class=3D"">So, my suggestion is to use parens with de=
signated initializers as a common ground between aggregates and constructor=
s. If you=E2=80=99re writing an aggregate that perhaps shouldn=E2=80=99t be=
 an aggregate, it encourages you to use parens and designated initializers.=
 This should have the added benefit of reducing abuse of =E2=80=9Cuniform=
=E2=80=9D initialization to call ordinary constructors. On the other hand, =
most such aggregates only have 2-3 members, and splitting out the parameter=
 class is a bit of extra effort and noise.</div><div class=3D""><br class=
=3D""></div></body></html>

<p></p>

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

--Apple-Mail=_5C8BF3B8-BE47-48D0-B5F8-273C6BB21D04--

.

------=_Part_133_1006987662.1440061903824
Content-Type: multipart/alternative;
 boundary="----=_Part_134_2055303384.1440061903824"

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

I would urge you to read my post again and not the smily icon at the end of=
=20
my sentece, and just mention, that as well as I made mistake judging=20
@dgutson's sense of humor you've made identical mistake not realizing that=
=20
I'm simply joking with David.

On Wednesday, 19 August 2015 19:13:56 UTC+1, Brent Friedman wrote:
>
> Arthur, please refrain from implying that someone needs to go back to=20
> elementary school based on your personal interpretation of something that=
=20
> someone else said. Also, if you know of an elementary school that teaches=
=20
> C++ then I'd love to hear about it.
>
> The notion that every single class ever needs to have strict encapsulatio=
n=20
> for every single data member is fairly ridiculous in my opinion.=20
> Encapsulation is a tool used to achieve certain software engineering goal=
s=20
> and it can be misused like any other tool.
>
>
> On Wed, Aug 19, 2015 at 1:07 PM, Arthur Tchaikovsky <atch...@gmail.com=20
> <javascript:>> wrote:
>
>> Not all members in struct are public. From elementary school, everyone=
=20
>> knows that struct differs from class that *by default* members are publi=
c=20
>> in struct and private in class. ;)
>> That's why I see it as a violation of encapsulation. Secondly, not only=
=20
>> structs should be concerned, but classes too. And not only initializatio=
n=20
>> should be a concern here but also setting value *after* the object had b=
een=20
>> initialized. Taken all this above, I say that accessing members of a=20
>> class/struct by names, be it during initialization or after that fact is=
=20
>> violation of encapsulation and it should be discouraged in modern C++. T=
his=20
>> kind of code may very well be OK for C but C++ is not C.=20
>>
>> On Wednesday, 19 August 2015 18:50:13 UTC+1, David Rodr=C3=ADguez Ibeas =
wrote:
>>>
>>> How does that violate an encapsulation that does not exist? All members=
=20
>>> are public in the struct=E2=80=A6 you might dislike it on different acc=
ounts but=20
>>> encapsulation is not an issue with that code.  Other pro=C2=B4s, the ar=
guments=20
>>> are named, which is stable across refactors that might shift the positi=
ons=20
>>> (assuming sensible names, the caller wants the 'a' to have value X or t=
he=20
>>> 'b' to have value Z. Depending on the position of the member in the str=
uct=20
>>> (and passing 'default' if needed for the previous arguments) is *more*=
=20
>>> coupled, not less coupled.
>>>
>>> For initialization of structs, the C way is clearly better than the C++=
=20
>>> way here. A different question is whether we want to put some effort in=
to=20
>>> that part of the language when we can assume that most types are not=20
>>> all-members-public.=20
>>>
>>> Then again this is only related to default arguments to functions in=20
>>> that uniform initialization would be even less uniform in certain cases=
..  I=20
>>> do see the problems with named arguments, I still think that to be the=
=20
>>> better way. Whether initialization of structs can be made compatible wi=
th C=20
>>> once again=E2=80=A6 would be nice here, but I imagine not that many peo=
ple care.
>>>
>>>      David
>>>
>>> On Wed, Aug 19, 2015 at 5:27 PM, Arthur Tchaikovsky <atch...@gmail.com>=
=20
>>> wrote:
>>>
>>>> It *is not* simpler. What you've just shown is a violation of=20
>>>> encapsulation. Not simplification.
>>>>
>>>>
>>>> On Wednesday, 19 August 2015 16:08:52 UTC+1, S.B. wrote:
>>>>>
>>>>> It's even simpler if we could write=20
>>>>>
>>>>> struct s {
>>>>>     int a =3D 1337;
>>>>>     int b =3D 4096;
>>>>> };
>>>>> =20
>>>>> int main() {
>>>>>     s x;
>>>>>     s y { 42 }; // or s y { .a =3D 42 };
>>>>>     s z { .b =3D 42 };
>>>>>     return 0;
>>>>> }
>>>>>
>>>>> :)
>>>>>
>>>>> On Wednesday, August 19, 2015 at 2:02:01 PM UTC+8, Max Truxa wrote:
>>>>>>
>>>>>> I have to agree with Matt Calabrese completely. As it was already=20
>>>>>> asserted named arguments are not going to happen anytime soon (if at=
 all).
>>>>>>
>>>>>> Earlier in this thread there were workarounds listed which are more=
=20
>>>>>> or less comparable to the proposal in their effect.
>>>>>> I would like to elaborate some more on one of these workarounds, as=
=20
>>>>>> it can be mapped pretty much 1-to-1 to the proposal and it happens t=
o be=20
>>>>>> the solution I employ when encountering this kind of problem.
>>>>>>
>>>>>>
>>>>>> # Current workaround.
>>>>>>
>>>>>> struct s {
>>>>>>     static int const default_a =3D 1337;
>>>>>>     static int const default_b =3D 4096;
>>>>>>     s(int a =3D default_a, int b =3D default_b)=20
>>>>>>         : a(a), b(b) { }
>>>>>>     int a;
>>>>>>     int b;
>>>>>> };
>>>>>> =20
>>>>>> int main() {
>>>>>>     s x;
>>>>>>     s y(42);
>>>>>>     s z(s::default_a, 42);
>>>>>>     return 0;
>>>>>> }
>>>>>>
>>>>>> See working code here: http://ideone.com/OKtbuc
>>>>>>
>>>>>>
>>>>>> # Using the proposed syntax.
>>>>>>
>>>>>> struct s {
>>>>>>     s(int a =3D 1337, int b =3D 4096)=20
>>>>>>         : a(a), b(b) { }
>>>>>>     int a;
>>>>>>     int b;
>>>>>> };
>>>>>> =20
>>>>>> int main() {
>>>>>>     s x;
>>>>>>     s y(42);
>>>>>>     s z(default, 42);
>>>>>>     return 0;
>>>>>> }
>>>>>>
>>>>>> The current solution has a number of drawbacks.
>>>>>> 1) It's unnecessarily verbose.
>>>>>> 2) It's easy to mess up for parameters that have the same type. (`s=
=20
>>>>>> z(s::default_b, 42)` - Oops, passed `default_b` as `a`.)
>>>>>> 3) When looking up the actual default values there is one more hop t=
o=20
>>>>>> make. It's not sufficient to look at the function declaration but=20
>>>>>> additionally we have to look for e.g. default_a.
>>>>>>
>>>>>> --=20
>>>>
>>>> ---=20
>>>> You received this message because you are subscribed to the Google=20
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>>> an email to std-proposal...@isocpp.org.
>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>> Visit this group at=20
>>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>>
>>>
>>> --=20
>>
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--=20

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

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

<div dir=3D"ltr">I would urge you to read my post again and not the smily i=
con at the end of my sentece, and just mention, that as well as I made mist=
ake judging @dgutson&#39;s sense of humor you&#39;ve made identical mistake=
 not realizing that I&#39;m simply joking with David.<br><br>On Wednesday, =
19 August 2015 19:13:56 UTC+1, Brent Friedman  wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr">Arthur, please refrain from implyin=
g that someone needs to go back to elementary school based on your personal=
 interpretation of something that someone else said. Also, if you know of a=
n elementary school that teaches C++ then I&#39;d love to hear about it.<di=
v><br></div><div>The notion that every single class ever needs to have stri=
ct encapsulation for every single data member is fairly ridiculous in my op=
inion. Encapsulation is a tool used to achieve certain software engineering=
 goals and it can be misused like any other tool.<div><br></div></div></div=
><div><br><div class=3D"gmail_quote">On Wed, Aug 19, 2015 at 1:07 PM, Arthu=
r Tchaikovsky <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blan=
k" gdf-obfuscated-mailto=3D"syotKis_BAAJ" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;=
javascript:&#39;;return true;">atch...@gmail.com</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr">Not all members in struct ar=
e public. From elementary school, everyone knows that struct differs from c=
lass that *by default* members are public in struct and private in class. ;=
)<br>That&#39;s why I see it as a violation of encapsulation. Secondly, not=
 only structs should be concerned, but classes too. And not only initializa=
tion should be a concern here but also setting value *after* the object had=
 been initialized. Taken all this above, I say that accessing members of a =
class/struct by names, be it during initialization or after that fact is vi=
olation of encapsulation and it should be discouraged in modern C++. This k=
ind of code may very well be OK for C but C++ is not C. <br><span><br>On We=
dnesday, 19 August 2015 18:50:13 UTC+1, David Rodr=C3=ADguez Ibeas  wrote:<=
/span><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><span><div dir=3D"ltr">How do=
es that violate an encapsulation that does not exist? All members are publi=
c in the struct=E2=80=A6 you might dislike it on different accounts but enc=
apsulation is not an issue with that code.=C2=A0 Other pro=C2=B4s, the argu=
ments are named, which is stable across refactors that might shift the posi=
tions (assuming sensible names, the caller wants the &#39;a&#39; to have va=
lue X or the &#39;b&#39; to have value Z. Depending on the position of the =
member in the struct (and passing &#39;default&#39; if needed for the previ=
ous arguments) is *more* coupled, not less coupled.<div><br></div><div>For =
initialization of structs, the C way is clearly better than the C++ way her=
e. A different question is whether we want to put some effort into that par=
t of the language when we can assume that most types are not all-members-pu=
blic.=C2=A0</div><div><br></div><div>Then again this is only related to def=
ault arguments to functions in that uniform initialization would be even le=
ss uniform in certain cases.=C2=A0 I do see the problems with named argumen=
ts, I still think that to be the better way. Whether initialization of stru=
cts can be made compatible with C once again=E2=80=A6 would be nice here, b=
ut I imagine not that many people care.</div><div><br></div><div>=C2=A0 =C2=
=A0 =C2=A0David</div></div></span><div><br><div class=3D"gmail_quote"><div>=
<div>On Wed, Aug 19, 2015 at 5:27 PM, Arthur Tchaikovsky <span dir=3D"ltr">=
&lt;<a rel=3D"nofollow">atch...@gmail.com</a>&gt;</span> wrote:<br></div></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div><div><div dir=3D"ltr">It *is not* s=
impler. What you&#39;ve just shown is a violation of encapsulation. Not sim=
plification.<div><div><br><br>On Wednesday, 19 August 2015 16:08:52 UTC+1, =
S.B.  wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">It&#39=
;s even simpler if we could write <br><br><div style=3D"background-color:rg=
b(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-widt=
h:1px;word-wrap:break-word"><code><div><span style=3D"color:#008">struct</s=
pan><span style=3D"color:#000"> s </span><span style=3D"color:#660">{</span=
><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#=
008">int</span><span style=3D"color:#000"> a </span><span style=3D"color:#6=
60">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#066"=
>1337</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><=
br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">int</span><span style=3D=
"color:#000"> b </span><span style=3D"color:#660">=3D</span><span style=3D"=
color:#000"> </span><span style=3D"color:#066">4096</span><span style=3D"co=
lor:#660">;</span><span style=3D"color:#000"><br></span><span style=3D"colo=
r:#660">};</span><span style=3D"color:#000"><br>=C2=A0<br></span><span styl=
e=3D"color:#008">int</span><span style=3D"color:#000"> main</span><span sty=
le=3D"color:#660">()</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 s x</s=
pan><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=
=A0 =C2=A0 s y </span><span style=3D"color:#660">{</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#066">42</span><span style=3D"color:#=
000"> </span><span style=3D"color:#660">};</span><span style=3D"color:#000"=
> </span><span style=3D"color:#800">// or s y { .a =3D 42 };</span><span st=
yle=3D"color:#000"><br>=C2=A0 =C2=A0 s z </span><span style=3D"color:#660">=
{</span><span style=3D"color:#000"> </span><span style=3D"color:#660">.</sp=
an><span style=3D"color:#000">b </span><span style=3D"color:#660">=3D</span=
><span style=3D"color:#000"> </span><span style=3D"color:#066">42</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#660">};</span><span s=
tyle=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">ret=
urn</span><span style=3D"color:#000"> </span><span style=3D"color:#066">0</=
span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br></sp=
an><span style=3D"color:#660">}</span></div></code></div><br>:)<br><br>On W=
ednesday, August 19, 2015 at 2:02:01 PM UTC+8, Max Truxa wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex">I have to agree with Matt Calabrese completely.=
 As it was already asserted named arguments are not going to happen anytime=
 soon (if at all).<p>Earlier in this thread there were workarounds listed w=
hich are more or less comparable to the proposal in their effect.<br>I woul=
d like to elaborate some more on one of these workarounds, as it can be map=
ped pretty much 1-to-1 to the proposal and it happens to be the solution I =
employ when encountering this kind of problem.</p><p><br># Current workarou=
nd.</p><p>struct s {<br>=C2=A0 =C2=A0 static int const default_a =3D 1337;<=
br>=C2=A0 =C2=A0 static int const default_b =3D 4096;<br>=C2=A0 =C2=A0 s(in=
t a =3D default_a, int b =3D default_b) <br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 : a=
(a), b(b) { }<br>=C2=A0 =C2=A0 int a;<br>=C2=A0 =C2=A0 int b;<br>};<br>=C2=
=A0<br>int main() {<br>=C2=A0 =C2=A0 s x;<br>=C2=A0 =C2=A0 s y(42);<br>=C2=
=A0 =C2=A0 s z(s::default_a, 42);<br>=C2=A0 =C2=A0 return 0;<br>}</p><p>See=
 working code here: <a href=3D"http://ideone.com/OKtbuc" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?=
q\75http%3A%2F%2Fideone.com%2FOKtbuc\46sa\75D\46sntz\0751\46usg\75AFQjCNFJT=
tR-2NKU_hCXpY0qHPmkHWZV9g&#39;;return true;" onclick=3D"this.href=3D&#39;ht=
tp://www.google.com/url?q\75http%3A%2F%2Fideone.com%2FOKtbuc\46sa\75D\46snt=
z\0751\46usg\75AFQjCNFJTtR-2NKU_hCXpY0qHPmkHWZV9g&#39;;return true;">http:/=
/ideone.com/OKtbuc</a></p><p><br># Using the proposed syntax.</p><p>struct =
s {<br>=C2=A0 =C2=A0 s(int a =3D 1337, int b =3D 4096) <br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 : a(a), b(b) { }<br>=C2=A0 =C2=A0 int a;<br>=C2=A0 =C2=A0 int=
 b;<br>};<br>=C2=A0<br>int main() {<br>=C2=A0 =C2=A0 s x;<br>=C2=A0 =C2=A0 =
s y(42);<br>=C2=A0 =C2=A0 s z(default, 42);<br>=C2=A0 =C2=A0 return 0;<br>}=
</p><p>The current solution has a number of drawbacks.<br>1) It&#39;s unnec=
essarily verbose.<br>2) It&#39;s easy to mess up for parameters that have t=
he same type. (`s z(s::default_b, 42)` - Oops, passed `default_b` as `a`.)<=
br>3) When looking up the actual default values there is one more hop to ma=
ke. It&#39;s not sufficient to look at the function declaration but additio=
nally we have to look for e.g. default_a.</p><p></p><p></p><p></p><p></p><p=
></p><p></p></blockquote></div></blockquote></div></div></div></div></div><=
div><div><div><div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></div></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span><br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=
=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.or=
g/group/std-proposals/&#39;;return true;">http://groups.google.com/a/<wbr>i=
socpp.org/group/std-<wbr>proposals/</a>.<br>
</span></div></div></blockquote></div><br></div>
</blockquote></div><div><div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
syotKis_BAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"syotKis_BAAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.or=
g/group/std-proposals/&#39;;return true;">http://groups.google.com/a/<wbr>i=
socpp.org/group/std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div>

<p></p>

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

------=_Part_134_2055303384.1440061903824--
------=_Part_133_1006987662.1440061903824--

.

------=_Part_127_782561607.1440062431912
Content-Type: multipart/alternative;
 boundary="----=_Part_128_2034979186.1440062431912"

------=_Part_128_2034979186.1440062431912
Content-Type: text/plain; charset=UTF-8

First, I want to say that I don't mind harsh, not harsh, too harsh words as
long as their valid and I welcome any *valid* criticism and I consider your
input very, very valid. No problem with that and I will not get offended by
such thing. OK, let's go back to the business, point by point.
Andrey, you're saying that you don't see connection between default access
mode and encapsulation. Could you please give an example or two, so we can
see how that reflects reality? Because at this moment I'm having hard time
to accept it, given that we're talking about the same thing.
OK, second point. You're saying and I quote:
"And no, all-public structs do not violate encapsulation in general. For
instance, std::pair - a struct with public data, does not break
encapsulation of std::(unordered_)map. "
Again, why would unrelated type break encapsulation of other type? I really
don't see connection, in the same way I don't expect a container of ints to
automatically provide ++, -- and other operators. And also please note that
std::pair **do not** provide encapsulation. Because you can access it's
members.

OK, so you're asking me, what's my point then? My point is that I do
understand the fact that OOP is not the only technique we should use during
programming, but I **do not agree** with introduction of rules to the C++
language that would allow to *bypass* that encapsulation.
Thank you.

On Wednesday, 19 August 2015 19:39:10 UTC+1, Andrey Semashev wrote:
>
> On 19.08.2015 21:07, Arthur Tchaikovsky wrote:
> > Not all members in struct are public. From elementary school, everyone
> > knows that struct differs from class that *by default* members are
> > public in struct and private in class. ;)
> > That's why I see it as a violation of encapsulation.
>
> I don't see the connection between the default access mode and
> encapsulation. Encapsulation is implementation hiding. It can be
> achieved by different means, including but not limited to member access
> management. Classes are no different from structs except for the default
> access mode - both can be used to achieve the same level of encapsulation.
>
> And no, all-public structs do not violate encapsulation in general. For
> instance, std::pair - a struct with public data, does not break
> encapsulation of std::(unordered_)map.
>
> > Secondly, not only
> > structs should be concerned, but classes too. And not only
> > initialization should be a concern here but also setting value *after*
> > the object had been initialized. Taken all this above, I say that
> > accessing members of a class/struct by names, be it during
> > initialization or after that fact is violation of encapsulation and it
> > should be discouraged in modern C++. This kind of code may very well be
> > OK for C but C++ is not C.
>
> I don't mean to sound harsh, but that's narrow minded thinking. The 'OOP
> everywhere' era has passed as people realized that it is not efficient
> in all scenarios. C-style structs are useful in some contexts and named
> member initialization is useful as well. See ffmpeg code for instance,
> the way codecs and formats are described. That's C, naturally, but
> imagine how much more code that would require in today's C++ with
> private members, constructors and default arguments. And then imagine
> how difficult it would be to modify the struct used as the descriptor.
>
>

--

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

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

<div dir=3D"ltr">First, I want to say that I don&#39;t mind harsh, not hars=
h, too harsh words as long as their valid and I welcome any *valid* critici=
sm and I consider your input very, very valid. No problem with that and I w=
ill not get offended by such thing. OK, let&#39;s go back to the business, =
point by point. <br>Andrey, you&#39;re saying that you don&#39;t see connec=
tion between default access mode and encapsulation. Could you please give a=
n example or two, so we can see how that reflects reality? Because at this =
moment I&#39;m having hard time to accept it, given that we&#39;re talking =
about the same thing.<br>OK, second point. You&#39;re saying and I quote:<b=
r>&quot;And no, all-public structs do not violate encapsulation in general.=
 For=20
<br>instance, std::pair - a struct with public data, does not break=20
<br>encapsulation of std::(unordered_)map.
&quot;<br>Again, why would unrelated type break encapsulation of other type=
? I really don&#39;t see connection, in the same way I don&#39;t expect a c=
ontainer of ints to automatically provide ++, -- and other operators. And a=
lso please note that std::pair **do not** provide encapsulation. Because yo=
u can access it&#39;s members.<br><br>OK, so you&#39;re asking me, what&#39=
;s my point then? My point is that I do understand the fact that OOP is not=
 the only technique we should use during programming, but I **do not agree*=
* with introduction of rules to the C++ language that would allow to *bypas=
s* that encapsulation.<br>Thank you.<br><br>On Wednesday, 19 August 2015 19=
:39:10 UTC+1, Andrey Semashev  wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;">On 19.08.2015 21:07, Arthur Tchaikovsky wrote:
<br>&gt; Not all members in struct are public. From elementary school, ever=
yone
<br>&gt; knows that struct differs from class that *by default* members are
<br>&gt; public in struct and private in class. ;)
<br>&gt; That&#39;s why I see it as a violation of encapsulation.
<br>
<br>I don&#39;t see the connection between the default access mode and=20
<br>encapsulation. Encapsulation is implementation hiding. It can be=20
<br>achieved by different means, including but not limited to member access=
=20
<br>management. Classes are no different from structs except for the defaul=
t=20
<br>access mode - both can be used to achieve the same level of encapsulati=
on.
<br>
<br>And no, all-public structs do not violate encapsulation in general. For=
=20
<br>instance, std::pair - a struct with public data, does not break=20
<br>encapsulation of std::(unordered_)map.
<br>
<br>&gt; Secondly, not only
<br>&gt; structs should be concerned, but classes too. And not only
<br>&gt; initialization should be a concern here but also setting value *af=
ter*
<br>&gt; the object had been initialized. Taken all this above, I say that
<br>&gt; accessing members of a class/struct by names, be it during
<br>&gt; initialization or after that fact is violation of encapsulation an=
d it
<br>&gt; should be discouraged in modern C++. This kind of code may very we=
ll be
<br>&gt; OK for C but C++ is not C.
<br>
<br>I don&#39;t mean to sound harsh, but that&#39;s narrow minded thinking.=
 The &#39;OOP=20
<br>everywhere&#39; era has passed as people realized that it is not effici=
ent=20
<br>in all scenarios. C-style structs are useful in some contexts and named=
=20
<br>member initialization is useful as well. See ffmpeg code for instance,=
=20
<br>the way codecs and formats are described. That&#39;s C, naturally, but=
=20
<br>imagine how much more code that would require in today&#39;s C++ with=
=20
<br>private members, constructors and default arguments. And then imagine=
=20
<br>how difficult it would be to modify the struct used as the descriptor.
<br>
<br></blockquote></div>

<p></p>

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

------=_Part_128_2034979186.1440062431912--
------=_Part_127_782561607.1440062431912--

.

------=_Part_2777_1614810103.1440064631073
Content-Type: multipart/alternative;
 boundary="----=_Part_2778_268999758.1440064631073"

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

Hi Vincente,
Thank you for your words.
As you yourself noted, the alternative is cumbersome and error prone. On=20
top of that, there is a huge amount of work left to the=20
designer/implementer of said function to provide all valid overloads which=
=20
I'm not sure that if real world devs would really go to such extend and do=
=20
it. With my proposal, all this burden, that is cumbersomeness, error=20
proneness and a work of developer/designer of such function are simply=20
removed. All is left is nice, natural syntax for users to use if they wish=
=20
to. I know that is my proposal and I shouldn't really say it, but I=20
genuinely fail to see bad/weak points of my proposal. It fits so nicely=20
with C++ both philosophy (give a choice) and syntax that I really hope this=
=20
will get voted into C++.

Thank you.

On Thursday, 20 August 2015 06:53:59 UTC+1, Vicente J. Botet Escriba wrote:
>
> Le 15/08/15 18:49, Arthur Tchaikovsky a =C3=A9crit :
>
> Hi,=20
> Does anyone see helpfulness of such solution:
> Having fnc:
>
> void f(int a =3D 0, int b =3D 1, int c =3D 2, int d =3D 3);
>
> I think that it would be nice to be able to say whilst calling it and=20
> requiring only some of those args to be non-default:
>
> f(default,2,default,4);
>
> Thoughts?
>
>
>
> Hi, note that I'm not against the proposal.
>
> Just wanted to share a way to do what you are proposing in C++14. It is a=
n=20
> alternative that is cumbersome and error prone. It consist in using=20
> overloading and a default_t type and a default_ instance of default_t.
>
>     f(int buffer_size =3D 1024, int timeout =3D 10, int tries =3D 3);
>     f(default_t, int timeout =3D 10, int tries =3D 3) { return f(1024, ti=
meout, tries); }
>     f(int buffer_size, default_t, int tries =3D 3) { return f(buffer_size=
, 10, tries); }
>
> f();
> f(default_, 0);
> f(default_, default_, 20);
>
> The function provider can use constant for the defaults of course but the=
 useof the constants is however error prone.
>
> IMO, this kind of approach should appear in a possible proposal as your p=
roposal solves all the issues of this approach. =20
>
> Vicente
>
>
>
>
>
>
>

--=20

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

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

<div dir=3D"ltr">Hi Vincente,<br>Thank you for your words.<br>As you yourse=
lf noted, the alternative is cumbersome and error prone. On top of that, th=
ere is a huge amount of work left to the designer/implementer of said funct=
ion to provide all valid overloads which I&#39;m not sure that if real worl=
d devs would really go to such extend and do it. With my proposal, all this=
 burden, that is cumbersomeness, error proneness and a work of developer/de=
signer of such function are simply removed. All is left is nice, natural sy=
ntax for users to use if they wish to. I know that is my proposal and I sho=
uldn&#39;t really say it, but I genuinely fail to see bad/weak points of my=
 proposal. It fits so nicely with C++ both philosophy (give a choice) and s=
yntax that I really hope this will get voted into C++.<br><br>Thank you.<br=
><br>On Thursday, 20 August 2015 06:53:59 UTC+1, Vicente J. Botet Escriba  =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>Le 15/08/15 18:49, Arthur Tchaikovsky a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
      <pre>Hi,=20
Does anyone see helpfulness of such solution:
Having fnc:

void f(int a =3D 0, int b =3D 1, int c =3D 2, int d =3D 3);

I think that it would be nice to be able to say whilst calling it and=20
requiring only some of those args to be non-default:

f(default,2,default,4);

Thoughts?


</pre>
    </blockquote>
    <font size=3D"+1">Hi, note that I&#39;m not against the proposal.<br>
      <br>
      Just wanted to share a way to do what you are proposing in C++14.
      It is an alternative that is cumbersome and error prone. It
      consist in using overloading and a default_t type and a default_
      instance of default_t.</font><br>
    <br>
    <pre>    f(int buffer_size =3D 1024, int timeout =3D 10, int tries =3D =
3);
    f(default_t, int timeout =3D 10, int tries =3D 3) { return f(1024, time=
out, tries); }
    f(int buffer_size, default_t, int tries =3D 3) { return f(buffer_size, =
10, tries); }

f();
f(default_, 0);
f(default_, default_, 20);

The function provider can use constant for the defaults of course but the u=
seof the constants is however error prone.

IMO, this kind of approach should appear in a possible proposal as your pro=
posal solves all the issues of this approach. =20

Vicente




</pre>
    <br>
  </div>

</blockquote></div>

<p></p>

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

------=_Part_2778_268999758.1440064631073--
------=_Part_2777_1614810103.1440064631073--

.

------=_Part_7376_339109379.1440079031471
Content-Type: multipart/alternative;
 boundary="----=_Part_7377_1367054356.1440079031472"

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

On Thursday, August 20, 2015 at 3:11:02 AM UTC-4, David Krauss wrote:
>
>
> On 2015=E2=80=9308=E2=80=9320, at 11:59 AM, Nicol Bolas <jmck...@gmail.co=
m <javascript:>>=20
> wrote:
>
> What you're doing is enforcing a single struct policy, which is not=20
> something I would want to see advocated or become commonplace. However, i=
t=20
> does lack the terrible syntactic noise of the C version, so it's already=
=20
> ahead of the curve ;)
>
>
> One is better than zero=E2=80=A6 but what=E2=80=99s the impediment to gro=
uping by nested=20
> sub-aggregates?
>
> The problem with that is that NSDMI's operate by effectively modifying=20
> constructors.=20
>
>
> Since C++14, NSDMIs have a second method of action, by aggregate=20
> initialization. They are already allowed in aggregates.
>

I did not know this. I'm not sure how I missed that one, since my browser=
=20
history clearly showed that I found N3653...
=20

>
> As for the implicit braces thing, that sounds like a very bad idea.=20
> Uniform initialization already has way too many implicit braces, to the=
=20
> point where it actually gets non-uniform. It's two extra characters; I=20
> don't see it as provoking that much syntactic noise.
>
>
> Hmm, are you for the proposal or against? Implicit braces are the entiret=
y=20
> of it. (Note that Clang and GCC already implement designated initializers=
,=20
> both only issuing a warning under -pedantic.)
>

The fact that Clang and GCC implement designated inititalizers does not=20
make them actual features of the C++ standard. So you can't propose a=20
change that requires non-standard functionality.

Thus, this proposal *must include* designated initializers for aggregates.
=20

> And they specifically don=E2=80=99t apply under brace (uniform) initializ=
ation.
>

I don't know which "they" you're referring to: designated initializers or=
=20
brace elision. I'm going to assume that you mean to say that designated=20
initializers should be restricted to function calls, without explicit=20
braced-init-lists. If that's not the case, then just ignore this section.

Given that, I like it even less now. You're devising very special-case=20
syntax when there's no real need for it. Plus even though you're=20
initializing an object, you explicitly *cannot* use uniform initialization=
=20
syntax for it.

You're making uniform initialization even less uniform than it already was.=
=20
Do we really need to do that?

I think your idea is imposing limitations on this functionality that just=
=20
don't need to exist. Just provide designated initializers in C++ aggregate=
=20
initialization syntax, period. Since NSDMIs in C++14 don't prevent=20
something from being an aggregate or undergoing aggregate initialization,=
=20
just proceed forward from there. Not only do you get something like named=
=20
parameters, you also get generalized designated initalizers for aggregate=
=20
initialization.

Oh sure, you'll still need the braces: `f({...})`. But that's fine, since=
=20
it makes it clear to the user exactly what you're doing.

By requiring the braces, by making the object initialization more clear, it=
=20
*also* solves the function overloading problem, since generalized=20
designated initializer syntax would give you the ability to specify which=
=20
set of parameters to use:

f(param_set1{...});
f(param_set2{...});

I don't like the idea of hacking up a "solution" to named parameters this=
=20
way (admittedly, a solution that many other languages use). But I'd be much=
=20
happier with this if such a solution was just a natural outgrowth of a=20
generally useful feature like designated aggregate initializers.

That is, you get designated initializers, which *could* be used for named=
=20
parameters, rather than getting named parameters by a very restricted use=
=20
of designated initializers.

It feels less like a hack that way.

The problem with adding designated initializers alone is that they enhance=
=20
> aggregates but not classes with constructors. This impedes refactoring an=
=20
> aggregate into a non-aggregate, which is a very common operation.
>

That is something of a danger, yes. But I would rather find a way to=20
mitigate *that* problem than to deliberately gimp the functionality.

Here's a possible solution:

If the initializer list contains designated initializers, then it will=20
attempt to use aggregate initialization on the target object type. If the=
=20
target object is not an aggregate, then it will check all of the=20
constructors for the target. If it finds a constructor that takes only one=
=20
parameter (minus defaults of course) which *is* an aggregate, then it will=
=20
initialize an aggregate and pass it to that constructor.

You could even recursively apply those rules. If a constructor takes one=20
argument that has a constructor that takes one argument that has a=20
constructor that takes one argument that is an aggregate, then the=20
initializer list constructs that type, passes it to the next object, then=
=20
passes the result to the next, and so on.

That way, when you refactor an aggregate into a non-aggregate, all you need=
=20
to do is create a throwaway aggregate that matches the old aggregate, which=
=20
your now-non-aggregate type uses for named parameter object initialization.

Thus, *any* non-aggregate could be initialized like this:

non_aggregate nagg =3D {.param1 =3D 20, .param3 =3D 50};

Yeah, this suggestion effectively uses brace elision, which I despise. But=
=20
it does solve the problem, and it gives us nice functionality that your=20
more limited approach would not have provided.

--=20

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

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

On Thursday, August 20, 2015 at 3:11:02 AM UTC-4, David Krauss wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word">=
<div><br><div><blockquote type=3D"cite"><div>On 2015=E2=80=9308=E2=80=9320,=
 at 11:59 AM, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"CSSNApNpBAAJ" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;">jmck...@gmail.com</a>&gt; wrote:</div><div><br><di=
v>What you&#39;re doing is enforcing a single struct policy, which is not s=
omething I would want to see advocated or become commonplace. However, it d=
oes lack the terrible syntactic noise of the C version, so it&#39;s already=
 ahead of the curve ;)<br></div></div></blockquote><div><br></div><div>One =
is better than zero=E2=80=A6 but what=E2=80=99s the impediment to grouping =
by nested sub-aggregates?</div><br><blockquote type=3D"cite"><div><div>The =
problem with that is that NSDMI&#39;s operate by effectively modifying cons=
tructors. </div></div></blockquote><div><br></div><div>Since C++14, NSDMIs =
have a second method of action, by aggregate initialization. They are alrea=
dy allowed in aggregates.</div></div></div></div></blockquote><div><br>I di=
d not know this. I&#39;m not sure how I missed that one, since my browser h=
istory clearly showed that I found N3653...<br>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><div><div>=
<br><blockquote type=3D"cite"><div><div>As for the implicit braces thing, t=
hat sounds like a very bad idea. Uniform initialization already has way too=
 many implicit braces, to the point where it actually gets non-uniform. It&=
#39;s two extra characters; I don&#39;t see it as provoking that much synta=
ctic noise.<br></div></div></blockquote><div><br></div></div>Hmm, are you f=
or the proposal or against? Implicit braces are the entirety of it. (Note t=
hat Clang and GCC already implement designated initializers, both only issu=
ing a warning under -pedantic.)</div></div></blockquote><div><br>The fact t=
hat Clang and GCC implement designated inititalizers does not make them act=
ual features of the C++ standard. So you can&#39;t propose a change that re=
quires non-standard functionality.<br><br>Thus, this proposal <i>must inclu=
de</i> designated initializers for aggregates.<br>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><div>An=
d they specifically don=E2=80=99t apply under brace (uniform) initializatio=
n.</div></div></blockquote><div><br>I don&#39;t know which &quot;they&quot;=
 you&#39;re referring to: designated initializers or brace elision. I&#39;m=
 going to assume that you mean to say that designated initializers should b=
e restricted to function calls, without explicit braced-init-lists. If that=
&#39;s not the case, then just ignore this section.<br><br>Given that, I li=
ke it even less now. You&#39;re devising very special-case syntax when ther=
e&#39;s no real need for it. Plus even though you&#39;re initializing an ob=
ject, you explicitly <i>cannot</i> use uniform initialization syntax for it=
..<br><br>You&#39;re making uniform initialization even less uniform than it=
 already was. Do we really need to do that?<br><br>I think your idea is imp=
osing limitations on this functionality that just don&#39;t need to exist. =
Just provide designated initializers in C++ aggregate initialization syntax=
, period. Since NSDMIs in C++14 don&#39;t prevent something from being an a=
ggregate or undergoing aggregate initialization, just proceed forward from =
there. Not only do you get something like named parameters, you also get ge=
neralized designated initalizers for aggregate initialization.<br><br>Oh su=
re, you&#39;ll still need the braces: `f({...})`. But that&#39;s fine, sinc=
e it makes it clear to the user exactly what you&#39;re doing.<br><br>By re=
quiring the braces, by making the object initialization more clear, it <i>a=
lso</i> solves the function overloading problem, since generalized designat=
ed initializer syntax would give you the ability to specify which set of pa=
rameters to use:<br><br><div class=3D"prettyprint" style=3D"background-colo=
r: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: soli=
d; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><=
div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">f</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">param_=
set1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{...})=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>f</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">param_set2</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">{...});</span></div></c=
ode></div><br>I don&#39;t like the idea of hacking up a &quot;solution&quot=
; to named parameters this way (admittedly, a solution that many other lang=
uages use). But I&#39;d be much happier with this if such a solution was ju=
st a natural outgrowth of a generally useful feature like designated aggreg=
ate initializers.<br><br>That is, you get designated initializers, which <i=
>could</i> be used for named parameters, rather than getting named paramete=
rs by a very restricted use of designated initializers.<br><br>It feels les=
s like a hack that way.<br><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div style=3D"word-wrap:break-word"><div></div><div>The problem with=
 adding designated initializers alone is that they enhance aggregates but n=
ot classes with constructors. This impedes refactoring an aggregate into a =
non-aggregate, which is a very common operation.</div></div></blockquote><d=
iv><br>That is something of a danger, yes. But I would rather find a way to=
 mitigate <i>that</i> problem than to deliberately gimp the functionality.<=
br><br>Here&#39;s a possible solution:<br><br>If the initializer list conta=
ins designated initializers, then it will attempt to use aggregate initiali=
zation on the target object type. If the target object is not an aggregate,=
 then it will check all of the constructors for the target. If it finds a c=
onstructor that takes only one parameter (minus defaults of course) which <=
i>is</i> an aggregate, then it will initialize an aggregate and pass it to =
that constructor.<br><br>You could even recursively apply those rules. If a=
 constructor takes one argument that has a constructor that takes one argum=
ent that has a constructor that takes one argument that is an aggregate, th=
en the initializer list constructs that type, passes it to the next object,=
 then passes the result to the next, and so on.<br><br>That way, when you r=
efactor an aggregate into a non-aggregate, all you need to do is create a t=
hrowaway aggregate that matches the old aggregate, which your now-non-aggre=
gate type uses for named parameter object initialization.<br><br>Thus, <i>a=
ny</i> non-aggregate could be initialized like this:<br><br><div class=3D"p=
rettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rg=
b(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-=
word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">non_aggregate nagg </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{.</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">param1 </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">20</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">param3 </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">50</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">};</span></div></code></div><br>Yeah, this su=
ggestion effectively uses brace elision, which I despise. But it does solve=
 the problem, and it gives us nice functionality that your more limited app=
roach would not have provided.</div>

<p></p>

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

------=_Part_7377_1367054356.1440079031472--
------=_Part_7376_339109379.1440079031471--

.

--Apple-Mail=_4C4F226E-788E-48CC-B289-7B288E6A70A2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9308=E2=80=9320, at 9:57 PM, Nicol Bolas <jmckesson@gmail.c=
om <mailto:jmckesson@gmail.com>> wrote:
>=20
> Thus, this proposal must include designated initializers for aggregates.

Or wait for someone else to propose designated initializers.

> And they specifically don=E2=80=99t apply under brace (uniform) initializ=
ation.
>=20
> I don't know which "they" you're referring to: designated initializers or=
 brace elision.

=E2=80=9CThey=E2=80=9D are implicit braces. Designated initializers and bra=
ce elision only work inside braces, and it should be obvious that I=E2=80=
=99m not trying to throw away everything.

> I'm going to assume that you mean to say that designated initializers sho=
uld be restricted to function calls, without explicit braced-init-lists. If=
 that's not the case, then just ignore this section.

The suggestion is that, given a workable proposal for designated initialize=
rs (inside braced-init-lists) reflecting the implementation consensus, we s=
olve the issue of providing designators to constructors and ordinary functi=
ons (inside parens) by adding implicit braces immediately inside the parens=
..

> I don't like the idea of hacking up a "solution" to named parameters this=
 way (admittedly, a solution that many other languages use). But I'd be muc=
h happier with this if such a solution was just a natural outgrowth of a ge=
nerally useful feature like designated aggregate initializers.

My recollection is that there=E2=80=99s committee resistance to adding feat=
ures to aggregates but not to constructors. I=E2=80=99ve not reviewed the m=
inutes to verify this, but that=E2=80=99s the direction I=E2=80=99m coming =
from. Personally, I also feel that designated initializers are already over=
due for C++ standardization, but a broader proposal stands better chances b=
y addressing such concerns.

> Here's a possible solution:
>=20
> If the initializer list contains designated initializers, then it will at=
tempt to use aggregate initialization on the target object type. If the tar=
get object is not an aggregate, then it will check all of the constructors =
for the target. If it finds a constructor that takes only one parameter (mi=
nus defaults of course) which is an aggregate, then it will initialize an a=
ggregate and pass it to that constructor.

This occurred to me too, but

1. It allows conversion to look just like direct-initialization. It require=
s that a constructor call look like aggregate initialization, which I belie=
ve should be discouraged.

2. It=E2=80=99s essentially a brace elision rule, and as you mentioned that=
 area is already complicated. Specifically, it=E2=80=99s a rule for omittin=
g one outer level of braces, but the existing elision rule is based on desc=
ending immediately to the innermost level.

3. It doesn=E2=80=99t address named function arguments, which is really the=
 more common request.

> You could even recursively apply those rules. If a constructor takes one =
argument that has a constructor that takes one argument that has a construc=
tor that takes one argument that is an aggregate, then the initializer list=
 constructs that type, passes it to the next object, then passes the result=
 to the next, and so on.

C++ doesn=E2=80=99t usually allow chained conversions. The programmer can e=
asily generate a combinatorial explosion, if each potential step of the cha=
in has multiple converting constructors.

--=20

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

--Apple-Mail=_4C4F226E-788E-48CC-B289-7B288E6A70A2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"><meta http-equiv=3D"Content-Type" content=3D"text/html charset=3D=
utf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: spac=
e; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><div c=
lass=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=
=80=9308=E2=80=9320, at 9:57 PM, Nicol Bolas &lt;<a href=3D"mailto:jmckesso=
n@gmail.com" class=3D"">jmckesson@gmail.com</a>&gt; wrote:</div><br class=
=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">Thus, this p=
roposal <i class=3D"">must include</i> designated initializers for aggregat=
es.<br class=3D""></div></div></blockquote><div class=3D""><br class=3D""><=
/div><div class=3D"">Or wait for someone else to propose designated initial=
izers.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div class=
=3D""><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:=
break-word" class=3D""><div class=3D"">And they specifically don=E2=80=99t =
apply under brace (uniform) initialization.</div></div></blockquote><div cl=
ass=3D""><br class=3D"">I don't know which "they" you're referring to: desi=
gnated initializers or brace elision. </div></div></blockquote><div class=
=3D""><br class=3D""></div><div class=3D"">=E2=80=9CThey=E2=80=9D are impli=
cit braces. Designated initializers and brace elision&nbsp;<i class=3D"">on=
ly</i>&nbsp;work inside braces, and it should be obvious that I=E2=80=99m n=
ot trying to throw away everything.</div><br class=3D""><blockquote type=3D=
"cite" class=3D""><div class=3D""><div class=3D"">I'm going to assume that =
you mean to say that designated initializers should be restricted to functi=
on calls, without explicit braced-init-lists. If that's not the case, then =
just ignore this section.<br class=3D""></div></div></blockquote><div class=
=3D""><br class=3D""></div><div class=3D"">The suggestion is that, given a =
workable proposal for designated initializers (inside braced-init-lists) re=
flecting the implementation consensus, we solve the issue of providing desi=
gnators to constructors and ordinary functions (inside parens) by adding im=
plicit braces immediately inside the parens.</div><br class=3D""><blockquot=
e type=3D"cite" class=3D""><div class=3D""><div class=3D"">I don't like the=
 idea of hacking up a "solution" to named parameters this way (admittedly, =
a solution that many other languages use). But I'd be much happier with thi=
s if such a solution was just a natural outgrowth of a generally useful fea=
ture like designated aggregate initializers.<br class=3D""></div></div></bl=
ockquote><div class=3D""><br class=3D""></div><div class=3D"">My recollecti=
on is that there=E2=80=99s committee resistance to adding features to aggre=
gates but not to constructors. I=E2=80=99ve not reviewed the minutes to ver=
ify this, but that=E2=80=99s the direction I=E2=80=99m coming from. Persona=
lly, I also feel that designated initializers are already overdue for C++ s=
tandardization, but a broader proposal stands better chances by addressing =
such concerns.</div><br class=3D""><blockquote type=3D"cite" class=3D""><di=
v class=3D""><div class=3D"">Here's a possible solution:</div><div class=3D=
""><br class=3D"">If the initializer list contains designated initializers,=
 then it will attempt to use aggregate initialization on the target object =
type. If the target object is not an aggregate, then it will check all of t=
he constructors for the target. If it finds a constructor that takes only o=
ne parameter (minus defaults of course) which <i class=3D"">is</i> an aggre=
gate, then it will initialize an aggregate and pass it to that constructor.=
<br class=3D""></div></div></blockquote><div class=3D""><br class=3D""></di=
v><div class=3D"">This occurred to me too, but</div><div class=3D""><br cla=
ss=3D""></div><div class=3D"">1. It allows conversion to look just like dir=
ect-initialization. It requires that a constructor call look like aggregate=
 initialization, which I believe should be discouraged.</div><div class=3D"=
"><br class=3D""></div><div class=3D"">2. It=E2=80=99s essentially a brace =
elision rule, and as you mentioned that area is already complicated. Specif=
ically, it=E2=80=99s a rule for omitting one outer level of braces, but the=
 existing elision rule is based on descending immediately to the innermost =
level.</div><div class=3D""><br class=3D""></div><div class=3D"">3. It does=
n=E2=80=99t address named function arguments, which is really the more comm=
on request.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div c=
lass=3D""><div class=3D"">You could even recursively apply those rules. If =
a constructor takes one argument that has a constructor that takes one argu=
ment that has a constructor that takes one argument that is an aggregate, t=
hen the initializer list constructs that type, passes it to the next object=
, then passes the result to the next, and so on.<br class=3D""></div></div>=
</blockquote><div class=3D""><br class=3D""></div><div class=3D"">C++ doesn=
=E2=80=99t usually allow chained conversions. The programmer can easily gen=
erate a combinatorial explosion, if each potential step of the chain has mu=
ltiple converting constructors.</div></div><br class=3D""></body></html>

<p></p>

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

--Apple-Mail=_4C4F226E-788E-48CC-B289-7B288E6A70A2--

.

------=_Part_183_1689897880.1440126802365
Content-Type: multipart/alternative;
 boundary="----=_Part_184_522610569.1440126802365"

------=_Part_184_522610569.1440126802365
Content-Type: text/plain; charset=UTF-8

Elegant. I'm tired of function overload permutations and work-around tricks
like chained setters or passing structures, when all I really want
sometimes is the default value of a defaultable parameter which isn't the
last parameter. It's nice to see that two other people have independently
come to the same idea, you and Daniel Gutson
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1466.pdf). While
named parameters may be *even* nicer in general, the two proposals are not
mutually exclusive.

For example, when I need to update the formatting where most of the
parameters are defaultable, I can just say:

    ChangeFormat(
        L"Segoe UI"
        );

But that one time I actually need to set an explicit stretch, then I need
to specify all the parameters before it: :/

    ChangeFormat(
        L"Segoe UI",
        DWRITE_FONT_WEIGHT_NORMAL,
        DWRITE_FONT_STYLE_NORMAL,
        DWRITE_FONT_STRETCH_CONDENSED
        );

When what I really want is simply:

    ChangeFormat(
        L"Segoe UI",
        default,
        default,
        DWRITE_FONT_STRETCH_CONDENSED
        );

You could even combine named parameters with default values (again, they
are not mutually exclusive proposals):

    ChangeFormat(
        fontFamily: L"Segoe UI",
        fontWeight: default,
        fontSlope: default,
        fontStretch: DWRITE_FONT_STRETCH_CONDENSED
        );

--

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

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

<div dir=3D"ltr"><div>Elegant. I&#39;m tired of function overload permutati=
ons and work-around tricks like chained setters or passing structures, when=
 all I really want sometimes is the default value of a defaultable paramete=
r which isn&#39;t the last parameter. It&#39;s nice to see that two other p=
eople have independently come to the same idea, you and Daniel Gutson (http=
://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1466.pdf). While named=
 parameters may be <i>even</i> nicer in general, the two proposals are not =
mutually exclusive.</div><div><br></div><div>For example, when I need to up=
date the formatting where most of the parameters are defaultable, I can jus=
t say:</div><div><br></div><div><div><font face=3D"courier new,monospace">=
=C2=A0=C2=A0=C2=A0 ChangeFormat(<br>=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 L=
&quot;Segoe UI&quot;</font><br></div><div><font face=3D"courier new,monospa=
ce">=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 );</font></div><div><br></div><di=
v>But that one time I actually need to set an explicit stretch, then I need=
 to specify all the parameters before it: :/</div><div><br></div></div><div=
><font face=3D"courier new,monospace">=C2=A0=C2=A0=C2=A0 ChangeFormat(<br>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 L&quot;Segoe UI&quot;,<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DWRITE_FONT_WEIGHT_NORMAL,<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DWRITE_FONT_STYLE_NORMAL,<br>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DWRITE_FONT_STRETCH_CONDENSED</font></div=
><div><font face=3D"courier new,monospace">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 );</font><br></div><div><br></div><div>When what I really want=
 is simply:</div><div><br></div><div><div><font face=3D"courier new,monospa=
ce">=C2=A0=C2=A0=C2=A0 ChangeFormat(<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 L&quot;Segoe UI&quot;,<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 default,<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 default,<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DWRITE_FONT_STRETCH_CONDENSED</font=
></div><div><font face=3D"courier new,monospace">=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 );</font></div><div><font face=3D"arial,sans-serif"><br>=
</font></div><div>You could even=C2=A0combine named parameters with default=
 values (again, they are not mutually exclusive proposals):</div><div><br><=
/div><div><div><font face=3D"courier new,monospace">=C2=A0=C2=A0=C2=A0 Chan=
geFormat(<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fontFamily: L&quot;=
Segoe UI&quot;,<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fontWeight: d=
efault,<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fontSlope: default,<b=
r>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fontStretch: DWRITE_FONT_STRET=
CH_CONDENSED</font></div><div><font face=3D"courier new,monospace">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 );</font></div></div></div></div>

<p></p>

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

------=_Part_184_522610569.1440126802365--
------=_Part_183_1689897880.1440126802365--

.

------=_Part_8194_1804401893.1440127027338
Content-Type: multipart/alternative;
 boundary="----=_Part_8195_622584004.1440127027339"

------=_Part_8195_622584004.1440127027339
Content-Type: text/plain; charset=UTF-8

Nice read. Wish this or something similar (I might choose something other
than angle brackets for overload disambiguation) had been voted in years
ago.

--

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

------=_Part_8195_622584004.1440127027339
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><div>Nice read. Wish this or something similar (I might choose something other than angle brackets for overload disambiguation) had been voted in years ago.<br></div>

</div>

<p></p>

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

------=_Part_8195_622584004.1440127027339--
------=_Part_8194_1804401893.1440127027338--

.

------=_Part_166_403342614.1440407583493
Content-Type: multipart/alternative;
 boundary="----=_Part_167_920914323.1440407583493"

------=_Part_167_920914323.1440407583493
Content-Type: text/plain; charset=UTF-8

Hi everyone,
I believe that this proposal, however small it is should be voted into C++,
and judging by the comments here, it can safely be said that most people
see value in it.
Could some committee member clarify with me what should happen next?

Thank you.

--

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

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

<div dir=3D"ltr">Hi everyone,<br>I believe that this proposal, however smal=
l it is should be voted into C++, and judging by the comments here, it can =
safely be said that most people see value in it. <br>Could some committee m=
ember clarify with me what should happen next?<br><br>Thank you.<br></div>

<p></p>

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

------=_Part_167_920914323.1440407583493--
------=_Part_166_403342614.1440407583493--

.

2015-08-24 11:13 GMT+02:00 Arthur Tchaikovsky <atch.cpp@gmail.com>:
> Hi everyone,
> I believe that this proposal, however small it is should be voted into C++,
> and judging by the comments here, it can safely be said that most people see
> value in it.
> Could some committee member clarify with me what should happen next?

I'm not a committee member, but I can ensure you that if you want to
get progress here, the right way is to submit a paper targetting

Programming Language C++, Evolution Working Group

(because it describes a new feature to the core language).

For general guidance please take a look at

https://isocpp.org/std/submit-a-proposal

The paper should be send to the lwgchair address (use the email
address mentioned in the header of
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html). Any
further procedural questions should also be send to the lwgchair
address (Presumably it's me who responds, nonetheless please send the
email always to the lwgchair address, not to my personal email
address).

Please note that the next mailing deadline (always from this page:
http://www.open-std.org/jtc1/sc22/wg21/) is 2015-09-25.

Thanks,

- Daniel

--

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

.

------=_Part_1968_399858254.1440410622133
Content-Type: multipart/alternative;
 boundary="----=_Part_1969_1550073825.1440410622134"

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

Thanks Daniel
Will do my best.

Regards

On Monday, 24 August 2015 10:25:42 UTC+1, Daniel Kr=C3=BCgler wrote:
>
> 2015-08-24 11:13 GMT+02:00 Arthur Tchaikovsky <atch...@gmail.com=20
> <javascript:>>:=20
> > Hi everyone,=20
> > I believe that this proposal, however small it is should be voted into=
=20
> C++,=20
> > and judging by the comments here, it can safely be said that most peopl=
e=20
> see=20
> > value in it.=20
> > Could some committee member clarify with me what should happen next?=20
>
> I'm not a committee member, but I can ensure you that if you want to=20
> get progress here, the right way is to submit a paper targetting=20
>
> Programming Language C++, Evolution Working Group=20
>
> (because it describes a new feature to the core language).=20
>
> For general guidance please take a look at=20
>
> https://isocpp.org/std/submit-a-proposal=20
>
> The paper should be send to the lwgchair address (use the email=20
> address mentioned in the header of=20
> http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html). Any=20
> further procedural questions should also be send to the lwgchair=20
> address (Presumably it's me who responds, nonetheless please send the=20
> email always to the lwgchair address, not to my personal email=20
> address).=20
>
> Please note that the next mailing deadline (always from this page:=20
> http://www.open-std.org/jtc1/sc22/wg21/) is 2015-09-25.=20
>
> Thanks,=20
>
> - Daniel=20
>

--=20

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

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

<div dir=3D"ltr">Thanks Daniel<br>Will do my best.<br><br>Regards<br><br>On=
 Monday, 24 August 2015 10:25:42 UTC+1, Daniel Kr=C3=BCgler  wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">2015-08-24 11:13 GMT+02:00 Arthur Tcha=
ikovsky &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"pp6Zfz6rBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return =
true;">atch...@gmail.com</a>&gt;:
<br>&gt; Hi everyone,
<br>&gt; I believe that this proposal, however small it is should be voted =
into C++,
<br>&gt; and judging by the comments here, it can safely be said that most =
people see
<br>&gt; value in it.
<br>&gt; Could some committee member clarify with me what should happen nex=
t?
<br>
<br>I&#39;m not a committee member, but I can ensure you that if you want t=
o
<br>get progress here, the right way is to submit a paper targetting
<br>
<br>Programming Language C++, Evolution Working Group
<br>
<br>(because it describes a new feature to the core language).
<br>
<br>For general guidance please take a look at
<br>
<br><a href=3D"https://isocpp.org/std/submit-a-proposal" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url=
?q\75https%3A%2F%2Fisocpp.org%2Fstd%2Fsubmit-a-proposal\46sa\75D\46sntz\075=
1\46usg\75AFQjCNGlLyCIYYQUZNTTJdUEpCYxvwG8Ig&#39;;return true;" onclick=3D"=
this.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fisocpp.org%2F=
std%2Fsubmit-a-proposal\46sa\75D\46sntz\0751\46usg\75AFQjCNGlLyCIYYQUZNTTJd=
UEpCYxvwG8Ig&#39;;return true;">https://isocpp.org/std/submit-<wbr>a-propos=
al</a>
<br>
<br>The paper should be send to the lwgchair address (use the email
<br>address mentioned in the header of
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html"=
 target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://=
www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2=
Fdocs%2Flwg-active.html\46sa\75D\46sntz\0751\46usg\75AFQjCNEV9q2WysPC8vFEEB=
oFwqlex0UdXw&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.goog=
le.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2F=
lwg-active.html\46sa\75D\46sntz\0751\46usg\75AFQjCNEV9q2WysPC8vFEEBoFwqlex0=
UdXw&#39;;return true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/lw=
g-active.html</a><wbr>). Any
<br>further procedural questions should also be send to the lwgchair
<br>address (Presumably it&#39;s me who responds, nonetheless please send t=
he
<br>email always to the lwgchair address, not to my personal email
<br>address).
<br>
<br>Please note that the next mailing deadline (always from this page:
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/" target=3D"_blank" r=
el=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q=
\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2F\46sa\75D\46sntz\07=
51\46usg\75AFQjCNEDzTC8Ry9aTHT3x4t5uwkCZP6E8A&#39;;return true;" onclick=3D=
"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.o=
rg%2Fjtc1%2Fsc22%2Fwg21%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNEDzTC8Ry9aTHT=
3x4t5uwkCZP6E8A&#39;;return true;">http://www.open-std.org/jtc1/<wbr>sc22/w=
g21/</a>) is 2015-09-25.
<br>
<br>Thanks,
<br>
<br>- Daniel
<br></blockquote></div>

<p></p>

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

------=_Part_1969_1550073825.1440410622134--
------=_Part_1968_399858254.1440410622133--

.