Topic: Designated initializer list status?
Author: landeholm@gmail.com
Date: Sat, 21 Nov 2015 06:11:37 -0800 (PST)
Raw View
------=_Part_218_916151047.1448115097199
Content-Type: multipart/alternative;
boundary="----=_Part_219_2026389371.1448115097199"
------=_Part_219_2026389371.1448115097199
Content-Type: text/plain; charset=UTF-8
Coming from Golang and C I was saddened by the fact that standard C++ lacks
(JSON-esque) designated initializer list support.
Some pragmatic reasons to support it:
1. It seem to be some interest in this feature, e.g. 33
votes: http://stackoverflow.com/questions/18731707
2. It's makes C++ more compatible with C99.
3. Many compilers already seem have support for it. I realized it wasn't in
C++ when I turned on --pedantic.
A contrived example:
// ...
class Link {
public:
int bw;
Coord wr_c;
Coord bl_c;
int src;
int mtime;
Computer* dst;
int u;
};
// ...
int main() {
// ...
std::vector<Link> links(m);
for (int i = 0; i < m; i++) {
int a, b, c;
std::cin >> a >> b >> c;
links[i] = {c, Coord(), Coord(), a, 0, &comps[b]}; //
Non-designated
links[i] = {.src = a, .dst = &comps[b], .bw = c}; // Designated
}
// ...
}
Some (likely highly subjective) problems with the non-designated syntax:
1. Order dependent (harder to read).
2. Does not scale well, parameter ordering is increasingly difficult to
track when more fields are added.
3. Does not allow explicit initialization of a partial set of fields.
(harder to read, annoying to write)
1, 2: Understanding the designated initializer list assignment requires no
declaration or parameter order knowledge so the grammar is more context
free and therefore easier to read.
3: You are forced to write an explicit constructor or enumerate defaults
for all fields. An explicit constructor would require extra boilerplate and
introduce another independent order you have to track (more context).
Writing a constructor for a specific way you want to initialize a class
seems like code smell.
So I hope this feature would become standardized. Thank you for reading my
humble opinion.
--
---
You received this message because you are subscribed to the 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_219_2026389371.1448115097199
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Coming from Golang and C I was saddened by the fact t=
hat standard C++ lacks (JSON-esque) designated initializer list support.<br=
></div><div><br></div><div>Some pragmatic reasons to support it:</div><div>=
1. It seem to be some interest in this feature, e.g. 33 votes:=C2=A0http://=
stackoverflow.com/questions/18731707</div><div>2. It's makes C++ more c=
ompatible with C99.</div><div>3. Many compilers already seem have support f=
or it. I realized it wasn't in C++ when I turned on --pedantic.</div><d=
iv><br></div><div>A contrived example:</div><div><br></div><div><div><font =
face=3D"courier new, monospace">=C2=A0 =C2=A0 // ...</font></div><div><font=
face=3D"courier new, monospace"><br></font></div><div><font face=3D"courie=
r new, monospace">=C2=A0 =C2=A0 class Link {</font></div><div><font face=3D=
"courier new, monospace">=C2=A0 =C2=A0 public:</font></div><div><font face=
=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int bw;</font></div=
><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 Coo=
rd wr_c;</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Coord bl_c;</font></div><div><font face=3D"courier new, m=
onospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int src;</font></div><div><font face=
=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int mtime;</font></=
div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
Computer* dst;</font></div><div><font face=3D"courier new, monospace">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 int u;</font></div><div><font face=3D"courier new,=
monospace">=C2=A0 =C2=A0 };</font></div><div><font face=3D"courier new, mo=
nospace"><br></font></div><div><font face=3D"courier new, monospace">=C2=A0=
=C2=A0 // ...</font></div><div><font face=3D"courier new, monospace"><br><=
/font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 int ma=
in() {</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0=
=C2=A0 =C2=A0 // ...</font></div><div><font face=3D"courier new, monospace=
">=C2=A0 =C2=A0 =C2=A0 =C2=A0 std::vector<Link> links(m);</font></div=
><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 for=
(int i =3D 0; i < m; i++) {</font></div><div><font face=3D"courier new,=
monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int a, b, c;</font></=
div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 std::cin >> a >> b >> c;</font></div><div><=
font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 links[i] =3D {c, Coord(), Coord(), a, 0, &comps[b]}; // Non-designa=
ted</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 links[i] =3D {.src =3D a, .dst =3D &comps[b=
], .bw =3D c}; =C2=A0// Designated</font></div><div><font face=3D"courier n=
ew, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 }</font></div><div><font face=3D=
"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 // ...</font></div><di=
v><font face=3D"courier new, monospace">=C2=A0 =C2=A0 }</font></div></div><=
div><br></div><div>Some (likely highly subjective) problems with the non-de=
signated syntax:<br></div><div>1. Order dependent (harder to read).</div><d=
iv>2. Does not scale well, parameter ordering is increasingly difficult to =
track when more fields are added.</div><span style=3D"font-family: arial, s=
ans-serif;">3. Does not allow explicit initialization of a partial set of f=
ields. (harder to read, annoying to write)</span><div><br></div><div>1, 2: =
Understanding the designated initializer list assignment requires no declar=
ation or parameter order knowledge so the grammar is more context free and =
therefore easier to read.<font face=3D"arial, sans-serif"><br></font></div>=
<div><br></div><div>3: You are forced to write an explicit constructor or e=
numerate defaults for all fields. An explicit constructor would require ext=
ra boilerplate and introduce another independent order you have to track (m=
ore context). Writing a constructor for a specific way you want to initiali=
ze a class seems like code smell.</div><div><br></div><div><font face=3D"ar=
ial, sans-serif">So=C2=A0</font>I hope this feature would become standardiz=
ed. Thank you for reading my humble opinion.</div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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_219_2026389371.1448115097199--
------=_Part_218_916151047.1448115097199--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sat, 21 Nov 2015 16:22:34 +0100
Raw View
--001a1148e93ebbb6d705250e8fdb
Content-Type: text/plain; charset=UTF-8
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/IgDFqKjKlRs
On Sat, Nov 21, 2015 at 3:11 PM, <landeholm@gmail.com> wrote:
> Coming from Golang and C I was saddened by the fact that standard C++
> lacks (JSON-esque) designated initializer list support.
>
> Some pragmatic reasons to support it:
> 1. It seem to be some interest in this feature, e.g. 33 votes:
> http://stackoverflow.com/questions/18731707
> 2. It's makes C++ more compatible with C99.
> 3. Many compilers already seem have support for it. I realized it wasn't
> in C++ when I turned on --pedantic.
>
> A contrived example:
>
> // ...
>
> class Link {
> public:
> int bw;
> Coord wr_c;
> Coord bl_c;
> int src;
> int mtime;
> Computer* dst;
> int u;
> };
>
> // ...
>
> int main() {
> // ...
> std::vector<Link> links(m);
> for (int i = 0; i < m; i++) {
> int a, b, c;
> std::cin >> a >> b >> c;
> links[i] = {c, Coord(), Coord(), a, 0, &comps[b]}; //
> Non-designated
> links[i] = {.src = a, .dst = &comps[b], .bw = c}; //
> Designated
> }
> // ...
> }
>
> Some (likely highly subjective) problems with the non-designated syntax:
> 1. Order dependent (harder to read).
> 2. Does not scale well, parameter ordering is increasingly difficult to
> track when more fields are added.
> 3. Does not allow explicit initialization of a partial set of fields.
> (harder to read, annoying to write)
>
> 1, 2: Understanding the designated initializer list assignment requires no
> declaration or parameter order knowledge so the grammar is more context
> free and therefore easier to read.
>
> 3: You are forced to write an explicit constructor or enumerate defaults
> for all fields. An explicit constructor would require extra boilerplate and
> introduce another independent order you have to track (more context).
> Writing a constructor for a specific way you want to initialize a class
> seems like code smell.
>
> So I hope this feature would become standardized. Thank you for reading
> my humble opinion.
>
> --
>
> ---
> You received this message because you are subscribed to the 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/.
--001a1148e93ebbb6d705250e8fdb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><a href=3D"https://groups.google.com/a/isocpp.org/forum/#!=
topic/std-proposals/IgDFqKjKlRs">https://groups.google.com/a/isocpp.org/for=
um/#!topic/std-proposals/IgDFqKjKlRs</a><br></div><div class=3D"gmail_extra=
"><br><div class=3D"gmail_quote">On Sat, Nov 21, 2015 at 3:11 PM, <span di=
r=3D"ltr"><<a href=3D"mailto:landeholm@gmail.com" target=3D"_blank">land=
eholm@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div>Coming from Golang and C I was saddened by the fact that=
standard C++ lacks (JSON-esque) designated initializer list support.<br></=
div><div><br></div><div>Some pragmatic reasons to support it:</div><div>1. =
It seem to be some interest in this feature, e.g. 33 votes:=C2=A0<a href=3D=
"http://stackoverflow.com/questions/18731707" target=3D"_blank">http://stac=
koverflow.com/questions/18731707</a></div><div>2. It's makes C++ more c=
ompatible with C99.</div><div>3. Many compilers already seem have support f=
or it. I realized it wasn't in C++ when I turned on --pedantic.</div><d=
iv><br></div><div>A contrived example:</div><div><br></div><div><div><font =
face=3D"courier new, monospace">=C2=A0 =C2=A0 // ...</font></div><div><font=
face=3D"courier new, monospace"><br></font></div><div><font face=3D"courie=
r new, monospace">=C2=A0 =C2=A0 class Link {</font></div><div><font face=3D=
"courier new, monospace">=C2=A0 =C2=A0 public:</font></div><div><font face=
=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int bw;</font></div=
><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 Coo=
rd wr_c;</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Coord bl_c;</font></div><div><font face=3D"courier new, m=
onospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int src;</font></div><div><font face=
=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int mtime;</font></=
div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
Computer* dst;</font></div><div><font face=3D"courier new, monospace">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 int u;</font></div><div><font face=3D"courier new,=
monospace">=C2=A0 =C2=A0 };</font></div><div><font face=3D"courier new, mo=
nospace"><br></font></div><div><font face=3D"courier new, monospace">=C2=A0=
=C2=A0 // ...</font></div><div><font face=3D"courier new, monospace"><br><=
/font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 int ma=
in() {</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0=
=C2=A0 =C2=A0 // ...</font></div><div><font face=3D"courier new, monospace=
">=C2=A0 =C2=A0 =C2=A0 =C2=A0 std::vector<Link> links(m);</font></div=
><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 for=
(int i =3D 0; i < m; i++) {</font></div><div><font face=3D"courier new,=
monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int a, b, c;</font></=
div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 std::cin >> a >> b >> c;</font></div><div><=
font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 links[i] =3D {c, Coord(), Coord(), a, 0, &comps[b]}; // Non-designa=
ted</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 links[i] =3D {.src =3D a, .dst =3D &comps[b=
], .bw =3D c}; =C2=A0// Designated</font></div><div><font face=3D"courier n=
ew, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 }</font></div><div><font face=3D=
"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 // ...</font></div><di=
v><font face=3D"courier new, monospace">=C2=A0 =C2=A0 }</font></div></div><=
div><br></div><div>Some (likely highly subjective) problems with the non-de=
signated syntax:<br></div><div>1. Order dependent (harder to read).</div><d=
iv>2. Does not scale well, parameter ordering is increasingly difficult to =
track when more fields are added.</div><span style=3D"font-family:arial,san=
s-serif">3. Does not allow explicit initialization of a partial set of fiel=
ds. (harder to read, annoying to write)</span><div><br></div><div>1, 2: Und=
erstanding the designated initializer list assignment requires no declarati=
on or parameter order knowledge so the grammar is more context free and the=
refore easier to read.<font face=3D"arial, sans-serif"><br></font></div><di=
v><br></div><div>3: You are forced to write an explicit constructor or enum=
erate defaults for all fields. An explicit constructor would require extra =
boilerplate and introduce another independent order you have to track (more=
context). Writing a constructor for a specific way you want to initialize =
a class seems like code smell.</div><div><br></div><div><font face=3D"arial=
, sans-serif">So=C2=A0</font>I hope this feature would become standardized.=
Thank you for reading my humble opinion.</div><span class=3D"HOEnZb"><font=
color=3D"#888888"><div><br></div></font></span></div><span class=3D"HOEnZb=
"><font color=3D"#888888">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--001a1148e93ebbb6d705250e8fdb--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 21 Nov 2015 07:27:50 -0800 (PST)
Raw View
------=_Part_76_1345468402.1448119670499
Content-Type: multipart/alternative;
boundary="----=_Part_77_842237397.1448119670500"
------=_Part_77_842237397.1448119670500
Content-Type: text/plain; charset=UTF-8
On Saturday, November 21, 2015 at 9:11:37 AM UTC-5, land...@gmail.com wrote:
>
> Coming from Golang and C I was saddened by the fact that standard C++
> lacks (JSON-esque) designated initializer list support.
>
> Some pragmatic reasons to support it:
> 1. It seem to be some interest in this feature, e.g. 33 votes:
> http://stackoverflow.com/questions/18731707
>
.... and?
> 2. It's makes C++ more compatible with C99.
>
That's not a good reason for anything. C and C++ are different languages,
with divergent goals.
> 3. Many compilers already seem have support for it. I realized it wasn't
> in C++ when I turned on --pedantic.
>
That's the best reason you've given thus far, but it's still pretty weak.
> A contrived example:
>
> // ...
>
> class Link {
> public:
> int bw;
> Coord wr_c;
> Coord bl_c;
> int src;
> int mtime;
> Computer* dst;
> int u;
> };
>
> // ...
>
> int main() {
> // ...
> std::vector<Link> links(m);
> for (int i = 0; i < m; i++) {
> int a, b, c;
> std::cin >> a >> b >> c;
> links[i] = {c, Coord(), Coord(), a, 0, &comps[b]}; //
> Non-designated
> links[i] = {.src = a, .dst = &comps[b], .bw = c}; //
> Designated
> }
> // ...
> }
>
> Some (likely highly subjective) problems with the non-designated syntax:
> 1. Order dependent (harder to read).
> 2. Does not scale well, parameter ordering is increasingly difficult to
> track when more fields are added.
> 3. Does not allow explicit initialization of a partial set of fields.
> (harder to read, annoying to write)
>
Says who? C++11 has always allowed it (the remainder are either value or
default initialized, I forget which). And C++14 made it so that if you use
default member initializers, they will be used if you don't specialize an
initializer with braced-init-syntax <http://ideone.com/c1ubCd>:
struct A
{
int foo;
int bar = 7;
float jay = 12.784f;
};
A a{5, 11};
a.jay == 12.784f;
1, 2: Understanding the designated initializer list assignment requires no
> declaration or parameter order knowledge so the grammar is more context
> free and therefore easier to read.
>
> 3: You are forced to write an explicit constructor or enumerate defaults
> for all fields. An explicit constructor would require extra boilerplate and
> introduce another independent order you have to track (more context).
> Writing a constructor for a specific way you want to initialize a class
> seems like code smell.
>
And what about the rest of the idea? braced-init-lists in C++ don't work
like they do in C, after all. You can use them in contexts where you select
between different function overloads, picking the overload that has a
constructor that matches the provided elements. How does that work with
your designated initializers?
> So I hope this feature would become standardized. Thank you for reading
> my humble opinion.
>
I hope you don't think that merely making a post to a mailing list will get
it standardized.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_77_842237397.1448119670500
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, November 21, 2015 at 9:11:37 AM UTC-5, land...@gmail.com wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Coming =
from Golang and C I was saddened by the fact that standard C++ lacks (JSON-=
esque) designated initializer list support.<br></div><div><br></div><div>So=
me pragmatic reasons to support it:</div><div>1. It seem to be some interes=
t in this feature, e.g. 33 votes:=C2=A0<a href=3D"http://stackoverflow.com/=
questions/18731707" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.=
href=3D'http://www.google.com/url?q\75http%3A%2F%2Fstackoverflow.com%2F=
questions%2F18731707\46sa\75D\46sntz\0751\46usg\75AFQjCNGSAI1bt4jlJ_iMsoGLy=
6Bkwic8Qw';return true;" onclick=3D"this.href=3D'http://www.google.=
com/url?q\75http%3A%2F%2Fstackoverflow.com%2Fquestions%2F18731707\46sa\75D\=
46sntz\0751\46usg\75AFQjCNGSAI1bt4jlJ_iMsoGLy6Bkwic8Qw';return true;">h=
ttp://stackoverflow.<wbr>com/questions/18731707</a></div></div></blockquote=
><div><br>... and?<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div>2. It's makes C++ more compatible with C99.=
</div></div></blockquote><div><br>That's not a good reason for anything=
.. C and C++ are different languages, with divergent goals.<br>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>3. Many c=
ompilers already seem have support for it. I realized it wasn't in C++ =
when I turned on --pedantic.</div></div></blockquote><div><br>That's th=
e best reason you've given thus far, but it's still pretty weak.<br=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div></div><div>A contrived example:</div><div><br></div><div><div><font fa=
ce=3D"courier new, monospace">=C2=A0 =C2=A0 // ...</font></div><div><font f=
ace=3D"courier new, monospace"><br></font></div><div><font face=3D"courier =
new, monospace">=C2=A0 =C2=A0 class Link {</font></div><div><font face=3D"c=
ourier new, monospace">=C2=A0 =C2=A0 public:</font></div><div><font face=3D=
"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int bw;</font></div><d=
iv><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 Coord =
wr_c;</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 Coord bl_c;</font></div><div><font face=3D"courier new, monos=
pace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int src;</font></div><div><font face=3D"c=
ourier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int mtime;</font></div><=
div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 Compu=
ter* dst;</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 int u;</font></div><div><font face=3D"courier new, monosp=
ace">=C2=A0 =C2=A0 };</font></div><div><font face=3D"courier new, monospace=
"><br></font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0=
// ...</font></div><div><font face=3D"courier new, monospace"><br></font><=
/div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 int main() {<=
/font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0=
=C2=A0 // ...</font></div><div><font face=3D"courier new, monospace">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 std::vector<Link> links(m);</font></div><div=
><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 for (int=
i =3D 0; i < m; i++) {</font></div><div><font face=3D"courier new, mono=
space">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int a, b, c;</font></div><=
div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 std::cin >> a >> b >> c;</font></div><div><fon=
t face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
links[i] =3D {c, Coord(), Coord(), a, 0, &comps[b]}; // Non-designated=
</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 links[i] =3D {.src =3D a, .dst =3D &comps[b], =
..bw =3D c}; =C2=A0// Designated</font></div><div><font face=3D"courier new,=
monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 }</font></div><div><font face=3D"co=
urier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 // ...</font></div><div><=
font face=3D"courier new, monospace">=C2=A0 =C2=A0 }</font></div></div><div=
><br></div><div>Some (likely highly subjective) problems with the non-desig=
nated syntax:<br></div><div>1. Order dependent (harder to read).</div><div>=
2. Does not scale well, parameter ordering is increasingly difficult to tra=
ck when more fields are added.</div><span style=3D"font-family:arial,sans-s=
erif">3. Does not allow explicit initialization of a partial set of fields.=
(harder to read, annoying to write)</span></div></blockquote><div><br>Says=
who? C++11 has always allowed it (the remainder are either value or defaul=
t initialized, I forget which). And C++14 made it so that if you use defaul=
t member initializers, <a href=3D"http://ideone.com/c1ubCd">they will be us=
ed if you don't specialize an initializer with braced-init-syntax</a>:<=
br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, =
250); border-color: rgb(187, 187, 187); border-style: solid; border-width: =
1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subp=
rettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">struc=
t</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> A<br></s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> bar </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-prett=
ify">7</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">float</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> jay </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">12.784f</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br><br>A a</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">{</span><span style=3D"color: #066;" class=3D"styled-by-pretti=
fy">5</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #066;" class=3D"styled-by-prettify">11</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br>a</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">jay </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">=3D=3D</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prett=
ify">12.784f</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan></div></code></div><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"ltr"><div></div><div>1, 2: Understanding the designated init=
ializer list assignment requires no declaration or parameter order knowledg=
e so the grammar is more context free and therefore easier to read.<font fa=
ce=3D"arial, sans-serif"><br></font></div><div><br></div><div>3: You are fo=
rced to write an explicit constructor or enumerate defaults for all fields.=
An explicit constructor would require extra boilerplate and introduce anot=
her independent order you have to track (more context). Writing a construct=
or for a specific way you want to initialize a class seems like code smell.=
</div></div></blockquote><div><br>And what about the rest of the idea? brac=
ed-init-lists in C++ don't work like they do in C, after all. You can u=
se them in contexts where you select between different function overloads, =
picking the overload that has a constructor that matches the provided eleme=
nts. How does that work with your designated initializers?<br>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><di=
v><font face=3D"arial, sans-serif">So=C2=A0</font>I hope this feature would=
become standardized. Thank you for reading my humble opinion.</div></div><=
/blockquote><div><br>I hope you don't think that merely making a post t=
o a mailing list will get it standardized.</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_77_842237397.1448119670500--
------=_Part_76_1345468402.1448119670499--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sat, 21 Nov 2015 16:43:59 +0100
Raw View
--047d7ba97530529cac05250edc7e
Content-Type: text/plain; charset=UTF-8
On Sat, Nov 21, 2015 at 4:27 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Saturday, November 21, 2015 at 9:11:37 AM UTC-5, land...@gmail.com
> wrote:
>>
>> Coming from Golang and C I was saddened by the fact that standard C++
>> lacks (JSON-esque) designated initializer list support.
>>
>> Some pragmatic reasons to support it:
>> 1. It seem to be some interest in this feature, e.g. 33 votes:
>> http://stackoverflow.com/questions/18731707
>>
>
> ... and?
>
>
>> 2. It's makes C++ more compatible with C99.
>>
>
> That's not a good reason for anything. C and C++ are different languages,
> with divergent goals.
>
C compatibility is very important for C++. The fact that designated
initializer lists have existing practice, especially in C, is a strong
point in favor of the feature as a C++ feature. It's not the only point
considered though.
So I hope this feature would become standardized. Thank you for reading my
>> humble opinion.
>>
>
> I hope you don't think that merely making a post to a mailing list will
> get it standardized.
>
> Right. This is at the stage where someone needs to write a detailed
proposal and have it presented and discussed at a meeting. Daryl Walker
drafted one in 2013, but I don't think it was submitted and/or presented.
One of the things I've been thinking about is that we could have a
std::designated_initializer_list unit type (no member functions) - and for
aggregate class types a constructor taking such a type is generated. A
constructor taking such a type could also be explicitly defaulted. We
could then have a syntactic construct designated-init-list.
For example:
struct S {
S(std::designated_initializer_list) = default; // implicit for
aggregate class types
int x, y, z;
}
S s = {.x = 1, .y = 2, .z = 3};
void f(S s);
int main() { f({.x = 1, .y = 2, .z = 3}); }
--
---
You received this message because you are subscribed to the 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/.
--047d7ba97530529cac05250edc7e
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 Sat, Nov 21, 2015 at 4:27 PM, Nicol Bolas <span dir=3D"ltr"><<a h=
ref=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a=
>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex"><span class=3D"">On Saturday, Novem=
ber 21, 2015 at 9:11:37 AM UTC-5, <a href=3D"mailto:land...@gmail.com" targ=
et=3D"_blank">land...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:=
rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"=
><div>Coming from Golang and C I was saddened by the fact that standard C++=
lacks (JSON-esque) designated initializer list support.<br></div><div><br>=
</div><div>Some pragmatic reasons to support it:</div><div>1. It seem to be=
some interest in this feature, e.g. 33 votes:=C2=A0<a href=3D"http://stack=
overflow.com/questions/18731707" rel=3D"nofollow" target=3D"_blank">http://=
stackoverflow.com/questions/18731707</a></div></div></blockquote></span><di=
v><br>... and?<br>=C2=A0</div><span class=3D""><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c=
olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D=
"ltr"><div>2. It's makes C++ more compatible with C99.</div></div></blo=
ckquote></span><div><br>That's not a good reason for anything. C and C+=
+ are different languages, with divergent goals.<br></div></blockquote><div=
><br></div><div>C compatibility is very important for C++.=C2=A0 The fact t=
hat designated initializer lists have existing practice, especially in C, i=
s a strong point in favor of the feature as a C++ feature.=C2=A0 It's n=
ot the only point considered though.</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><font face=3D"arial=
, sans-serif">So=C2=A0</font>I hope this feature would become standardized.=
Thank you for reading my humble opinion.<br></div></div></blockquote></spa=
n><div><br>I hope you don't think that merely making a post to a mailin=
g list will get it standardized.</div><div class=3D""><div class=3D"h5">
<p></p></div></div></blockquote></div>Right.=C2=A0 This is at the stage whe=
re someone needs to write a detailed proposal and have it presented and dis=
cussed at a meeting.=C2=A0 Daryl Walker drafted one in 2013, but I don'=
t think it was submitted and/or presented.</div><div class=3D"gmail_extra">=
<br></div><div class=3D"gmail_extra">One of the things I've been thinki=
ng about is that we could have a std::designated_initializer_list unit type=
(no member functions) - and for aggregate class types a constructor taking=
such a type is generated.=C2=A0 A constructor taking such a type could als=
o be explicitly defaulted.=C2=A0 We could then have a syntactic construct d=
esignated-init-list.</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">For example:</div><div class=3D"gmail_extra"><br></div><di=
v class=3D"gmail_extra">=C2=A0 =C2=A0struct S {</div><div class=3D"gmail_ex=
tra">=C2=A0 =C2=A0 =C2=A0S(std::designated_initializer_list) =3D default; /=
/ implicit for aggregate class types</div><div class=3D"gmail_extra"><br></=
div><div class=3D"gmail_extra">=C2=A0 =C2=A0 =C2=A0int x, y, z;</div><div c=
lass=3D"gmail_extra">=C2=A0 =C2=A0}</div><div class=3D"gmail_extra"><br></d=
iv><div class=3D"gmail_extra">=C2=A0 =C2=A0S s =3D {.x =3D 1, .y =3D 2, .z =
=3D 3};</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra=
">=C2=A0 =C2=A0void f(S s);</div><div class=3D"gmail_extra"><br></div><div =
class=3D"gmail_extra">=C2=A0 =C2=A0int main() { f({.x =3D 1, .y =3D 2, .z =
=3D 3}); }</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ex=
tra">=C2=A0 =C2=A0 =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" 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 />
--047d7ba97530529cac05250edc7e--
.
Author: landeholm@gmail.com
Date: Sat, 21 Nov 2015 08:15:50 -0800 (PST)
Raw View
------=_Part_277_434509793.1448122550927
Content-Type: multipart/alternative;
boundary="----=_Part_278_1409114390.1448122550928"
------=_Part_278_1409114390.1448122550928
Content-Type: text/plain; charset=UTF-8
On Saturday, November 21, 2015 at 4:27:50 PM UTC+1, Nicol Bolas wrote:
>
> On Saturday, November 21, 2015 at 9:11:37 AM UTC-5, land...@gmail.com
> wrote:
>>
>> Some (likely highly subjective) problems with the non-designated syntax:
>> 1. Order dependent (harder to read).
>> 2. Does not scale well, parameter ordering is increasingly difficult to
>> track when more fields are added.
>> 3. Does not allow explicit initialization of a partial set of fields.
>> (harder to read, annoying to write)
>>
>
> Says who? C++11 has always allowed it (the remainder are either value or
> default initialized, I forget which). And C++14 made it so that if you use
> default member initializers, they will be used if you don't specialize an
> initializer with braced-init-syntax <http://ideone.com/c1ubCd>:
>
Yes that's great, I actually do that in my example: "u" is not specified in
the non-designated syntax. But the "partial set" I mention could be fields
that are not a prefix of the fields declared in the class so there is no
suffix "reminder". E.g. you declare fields {0, 1, 2 .. 23} and you want to
explicitly initialize the fields {14, 17, 23}.
On Saturday, November 21, 2015 at 4:44:03 PM UTC+1, Andrew Tomazos wrote:
>
> One of the things I've been thinking about is that we could have a
> std::designated_initializer_list unit type (no member functions) - and for
> aggregate class types a constructor taking such a type is generated. A
> constructor taking such a type could also be explicitly defaulted. We
> could then have a syntactic construct designated-init-list.
>
> For example:
>
> struct S {
> S(std::designated_initializer_list) = default; // implicit for
> aggregate class types
>
> int x, y, z;
> }
>
> S s = {.x = 1, .y = 2, .z = 3};
>
> void f(S s);
>
> int main() { f({.x = 1, .y = 2, .z = 3}); }
>
I like this 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_278_1409114390.1448122550928
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br>On Saturday, November 21, 2015 at 4:27:50 PM UTC+1, Nicol Bolas wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border=
-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style:=
solid; padding-left: 1ex;">On Saturday, November 21, 2015 at 9:11:37 AM UT=
C-5,=C2=A0<a>land...@gmail.com</a>=C2=A0wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-lef=
t-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">=
<div dir=3D"ltr"><div>Some (likely highly subjective) problems with the non=
-designated syntax:<br></div><div>1. Order dependent (harder to read).</div=
><div>2. Does not scale well, parameter ordering is increasingly difficult =
to track when more fields are added.</div><span style=3D"font-family: arial=
, sans-serif;">3. Does not allow explicit initialization of a partial set o=
f fields. (harder to read, annoying to write)</span></div></blockquote><div=
><br>Says who? C++11 has always allowed it (the remainder are either value =
or default initialized, I forget which). And C++14 made it so that if you u=
se default member initializers,=C2=A0<a href=3D"http://ideone.com/c1ubCd" t=
arget=3D"_blank" rel=3D"nofollow">they will be used if you don't specia=
lize an initializer with braced-init-syntax</a>:</div></blockquote><div><br=
></div><div>Yes that's great, I actually do that in my example: "u=
" is not specified in the non-designated syntax. But the "partial=
set" I mention could be fields that are not a prefix of the fields de=
clared in the class so there is no suffix "reminder". E.g. you de=
clare fields {0, 1, 2 .. 23} and you want to explicitly initialize the fiel=
ds {14, 17, 23}.</div><br>On Saturday, November 21, 2015 at 4:44:03 PM UTC+=
1, Andrew Tomazos wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div>One of the things I've been thinking about is that we c=
ould have a std::designated_initializer_<wbr>list unit type (no member func=
tions) - and for aggregate class types a constructor taking such a type is =
generated.=C2=A0 A constructor taking such a type could also be explicitly =
defaulted.=C2=A0 We could then have a syntactic construct designated-init-l=
ist.<br></div><div><br></div><div>For example:</div><div><br></div><div>=C2=
=A0 =C2=A0struct S {</div><div>=C2=A0 =C2=A0 =C2=A0S(std::designated_<wbr>i=
nitializer_list) =3D default; // implicit for aggregate class types</div><d=
iv><br></div><div>=C2=A0 =C2=A0 =C2=A0int x, y, z;</div><div>=C2=A0 =C2=A0}=
</div><div><br></div><div>=C2=A0 =C2=A0S s =3D {.x =3D 1, .y =3D 2, .z =3D =
3};</div><div><br></div><div>=C2=A0 =C2=A0void f(S s);</div><div><br></div>=
<div>=C2=A0 =C2=A0int main() { f({.x =3D 1, .y =3D 2, .z =3D 3}); }</div><d=
iv></div></div></blockquote><div><br></div><div>I like this idea.</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_278_1409114390.1448122550928--
------=_Part_277_434509793.1448122550927--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 21 Nov 2015 09:56:48 -0800 (PST)
Raw View
------=_Part_1997_1226780297.1448128608863
Content-Type: multipart/alternative;
boundary="----=_Part_1998_1233067313.1448128608864"
------=_Part_1998_1233067313.1448128608864
Content-Type: text/plain; charset=UTF-8
On Saturday, November 21, 2015 at 10:44:03 AM UTC-5, Andrew Tomazos wrote:
>
> On Sat, Nov 21, 2015 at 4:27 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Saturday, November 21, 2015 at 9:11:37 AM UTC-5, land...@gmail.com
>> wrote:
>>>
>>> Coming from Golang and C I was saddened by the fact that standard C++
>>> lacks (JSON-esque) designated initializer list support.
>>>
>>> Some pragmatic reasons to support it:
>>> 1. It seem to be some interest in this feature, e.g. 33 votes:
>>> http://stackoverflow.com/questions/18731707
>>>
>>
>> ... and?
>>
>>
>>> 2. It's makes C++ more compatible with C99.
>>>
>>
>> That's not a good reason for anything. C and C++ are different languages,
>> with divergent goals.
>>
>
> C compatibility is very important for C++.
>
The committee doesn't seem to think so. Or at least, not compatibility with
features that aren't in C89. They don't want to have syntax step on each
other, but they don't want to adopt features from C99/11 directly into C++
either.
The fact that designated initializer lists have existing practice,
> especially in C, is a strong point in favor of the feature as a C++ feature.
>
Only to the extent that it proves that the feature is viable. Which,
admittedly, is a very useful thing to have.
> It's not the only point considered though.
>
> So I hope this feature would become standardized. Thank you for reading
>>> my humble opinion.
>>>
>>
>> I hope you don't think that merely making a post to a mailing list will
>> get it standardized.
>>
>> Right. This is at the stage where someone needs to write a detailed
> proposal and have it presented and discussed at a meeting. Daryl Walker
> drafted one in 2013, but I don't think it was submitted and/or presented.
>
It also wasn't particularly detailed
<https://raw.githubusercontent.com/CTMacUser/multiarray-iso-proposal/master/designation-proposal.html>.
Or at least, not very well written; the details were all in spec-language
wording rather than a human-readable explanation.
I would also suggest that any such proposal not have "improve parity with
C" as its primary motivation (or in the case of the above, *only*
motivation). More convincing motivations should revolve around using it in
C++ code. What can you do with it that you can't do without it. The fact
that it's in C is a good way to prove that the idea works, but that alone
is hardly sufficient motivation for a C++ feature.
For example, there was a discussion awhile back about named parameters
<https://groups.google.com/a/isocpp.org/d/msg/std-proposals/3iegpTsMuT0/hgmDlYkWIgAJ>.
It lead to the revelation that, if you have designated initializers, you
can more or less get that. The function would take a single struct type,
and you would call it with `funcName({.param1 = X, .param2 = Y, etc})`.
Naturally, they wanted to add language functionality to remove the parens,
but that's unnecessary. The main point is to give people an easy way to
pass named parameters to a function, and designated initializers would
allow precisely that.
Oh, and for someone coming up with such a proposal, don't forget that in
C++17, types with base classes that have variables will *also* be
considered aggregates. So you'll need to come up with a way to use them
with designated initializers too.
Good luck solving *that* one ;)
> One of the things I've been thinking about is that we could have a
> std::designated_initializer_list unit type (no member functions) - and for
> aggregate class types a constructor taking such a type is generated. A
> constructor taking such a type could also be explicitly defaulted. We
> could then have a syntactic construct designated-init-list.
>
I don't see the purpose of this. Generally speaking, most types that have
constructors have invariants, so their data members are private, so you
can't name them.
So when would you need such a constructor? Just say that if the
braced-init-list contains designated initializers, it uses aggregate
initialization instead of calling a constructor. And if the type is one
that cannot use aggregate initialization, then it's a compiler error.
The only place where I see this being useful is for a type that makes
everything public, but also provides constructors (and therefore can't use
aggregate initialization). Is that a sufficiently common usage scenario for
these? The point of a constructor is to provide and protect some kind of
invariant; we have default member initializers for simply setting default
values. So what was the point of providing that type with a constructor?
And don't forget: the last time we made special rules for how
braced-init-lists call constructors, we got screwed with the
`vector<int>/initializer_list<int>` problem. We shouldn't be making more
rules that break uniformity farther than it already has been.
--
---
You received this message because you are subscribed to the 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_1998_1233067313.1448128608864
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, November 21, 2015 at 10:44:03 AM UTC-5, Andrew Tomazos wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div clas=
s=3D"gmail_quote">On Sat, Nov 21, 2015 at 4:27 PM, Nicol Bolas <span dir=3D=
"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"CTKFlBSUBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascri=
pt:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;">jmck...@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On=
Saturday, November 21, 2015 at 9:11:37 AM UTC-5, <a>land...@gmail.com</a> =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex"><div dir=3D"ltr"><div>Coming from Golang and C I was=
saddened by the fact that standard C++ lacks (JSON-esque) designated initi=
alizer list support.<br></div><div><br></div><div>Some pragmatic reasons to=
support it:</div><div>1. It seem to be some interest in this feature, e.g.=
33 votes:=C2=A0<a href=3D"http://stackoverflow.com/questions/18731707" rel=
=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.=
google.com/url?q\75http%3A%2F%2Fstackoverflow.com%2Fquestions%2F18731707\46=
sa\75D\46sntz\0751\46usg\75AFQjCNGSAI1bt4jlJ_iMsoGLy6Bkwic8Qw';return t=
rue;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%=
2Fstackoverflow.com%2Fquestions%2F18731707\46sa\75D\46sntz\0751\46usg\75AFQ=
jCNGSAI1bt4jlJ_iMsoGLy6Bkwic8Qw';return true;">http://stackoverflow.<wb=
r>com/questions/18731707</a></div></div></blockquote></span><div><br>... an=
d?<br>=C2=A0</div><span><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>2. It's =
makes C++ more compatible with C99.</div></div></blockquote></span><div><br=
>That's not a good reason for anything. C and C++ are different languag=
es, with divergent goals.<br></div></blockquote><div><br></div><div>C compa=
tibility is very important for C++.</div></div></div></div></blockquote><di=
v><br>The committee doesn't seem to think so. Or at least, not compatib=
ility with features that aren't in C89. They don't want to have syn=
tax step on each other, but they don't want to adopt features from C99/=
11 directly into C++ either.<br><br></div><blockquote class=3D"gmail_quote"=
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>The fact =
that designated initializer lists have existing practice, especially in C, =
is a strong point in favor of the feature as a C++ feature.</div></div></di=
v></div></blockquote><div><br>Only to the extent that it proves that the fe=
ature is viable. Which, admittedly, is a very useful thing to have.<br>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
><div class=3D"gmail_quote"><div>=C2=A0 It's not the only point conside=
red though.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;padding-left:1ex"><span><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><di=
v dir=3D"ltr"><div><font face=3D"arial, sans-serif">So=C2=A0</font>I hope t=
his feature would become standardized. Thank you for reading my humble opin=
ion.<br></div></div></blockquote></span><div><br>I hope you don't think=
that merely making a post to a mailing list will get it standardized.</div=
><div><div>
<p></p></div></div></blockquote></div>Right.=C2=A0 This is at the stage whe=
re someone needs to write a detailed proposal and have it presented and dis=
cussed at a meeting.=C2=A0 Daryl Walker drafted one in 2013, but I don'=
t think it was submitted and/or presented.</div></div></blockquote><div><br=
>It also wasn't <a href=3D"https://raw.githubusercontent.com/CTMacUser/=
multiarray-iso-proposal/master/designation-proposal.html">particularly deta=
iled</a>. Or at least, not very well written; the details were all in spec-=
language wording rather than a human-readable explanation.<br><br>I would a=
lso suggest that any such proposal not have "improve parity with C&quo=
t; as its primary motivation (or in the case of the above, <i>only</i> moti=
vation). More convincing motivations should revolve around using it in C++ =
code. What can you do with it that you can't do without it. The fact th=
at it's in C is a good way to prove that the idea works, but that alone=
is hardly sufficient motivation for a C++ feature.<br><br>For example, the=
re was a <a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-propos=
als/3iegpTsMuT0/hgmDlYkWIgAJ">discussion awhile back about named parameters=
</a>. It lead to the revelation that, if you have designated initializers, =
you can more or less get that. The function would take a single struct type=
, and you would call it with `funcName({.param1 =3D X, .param2 =3D Y, etc})=
`. Naturally, they wanted to add language functionality to remove the paren=
s, but that's unnecessary. The main point is to give people an easy way=
to pass named parameters to a function, and designated initializers would =
allow precisely that.<br><br>Oh, and for someone coming up with such a prop=
osal, don't forget that in C++17, types with base classes that have var=
iables will <i>also</i> be considered aggregates. So you'll need to com=
e up with a way to use them with designated initializers too.<br><br>Good l=
uck solving <i>that</i> one ;)<br>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div>One of the things I've been think=
ing about is that we could have a std::designated_initializer_<wbr>list uni=
t type (no member functions) - and for aggregate class types a constructor =
taking such a type is generated.=C2=A0 A constructor taking such a type cou=
ld also be explicitly defaulted.=C2=A0 We could then have a syntactic const=
ruct designated-init-list.</div></div></blockquote><div><br>I don't see=
the purpose of this. Generally speaking, most types that have constructors=
have invariants, so their data members are private, so you can't name =
them.<br><br>So when would you need such a constructor? Just say that if th=
e braced-init-list contains designated initializers, it uses aggregate init=
ialization instead of calling a constructor. And if the type is one that ca=
nnot use aggregate initialization, then it's a compiler error.<br><br>T=
he only place where I see this being useful is for a type that makes everyt=
hing public, but also provides constructors (and therefore can't use ag=
gregate initialization). Is that a sufficiently common usage scenario for t=
hese? The point of a constructor is to provide and protect some kind of inv=
ariant; we have default member initializers for simply setting default valu=
es. So what was the point of providing that type with a constructor?<br><br=
>And don't forget: the last time we made special rules for how braced-i=
nit-lists call constructors, we got screwed with the `vector<int>/ini=
tializer_list<int>` problem. We shouldn't be making more rules th=
at break uniformity farther than it already has been.</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_1998_1233067313.1448128608864--
------=_Part_1997_1226780297.1448128608863--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sat, 21 Nov 2015 19:37:26 +0100
Raw View
--047d7bb70c7e9e5d8b0525114801
Content-Type: text/plain; charset=UTF-8
On Sat, Nov 21, 2015 at 6:56 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> Oh, and for someone coming up with such a proposal, don't forget that in
> C++17, types with base classes that have variables will *also* be
> considered aggregates. So you'll need to come up with a way to use them
> with designated initializers too.
>
> Good luck solving *that* one ;)
>
The simplest way would be to say that the base classes are default
constructed and the designated initializer list can only refer to the most
derived members.
struct D : B { int x; }
D d = { .x = 42}; // ok, B default constructed
Even simpler would say that the designated initializer list constructor is
only generated for classes without base classes.
struct D : B { int x; }
D d = { .x = 42}; // ill-formed
Another solution would be to allow .BaseType as a key in a designated
initializer list.
struct B { int y; }
struct D : B { int x; }
D d = { .B = {.y = 43}, .x = 42}; // ok
Another solution would be to roll up the base object graph into a single
list of members and the designated initializer list addresses only member
subobjects (and not base subobjects).
struct B { int y; }
struct D : B { int x; }
D d = { .x = 42, .y = 43}; // ok
The third and forth solutions are forward-compatible with the first and
second solutions.
>
>> One of the things I've been thinking about is that we could have a
>> std::designated_initializer_list unit type (no member functions) - and for
>> aggregate class types a constructor taking such a type is generated. A
>> constructor taking such a type could also be explicitly defaulted. We
>> could then have a syntactic construct designated-init-list.
>>
>
> I don't see the purpose of this. Generally speaking, most types that have
> constructors have invariants, so their data members are private, so you
> can't name them.
>
Noone is suggesting being able to address private members. The reason I
suggest using a type, is for forwarding of designated initializer lists.
To actually consume them (as an endpoint) you need a compiler-generated
constructor - either implicitly or explicitly defaulted.
eg
struct S { int x,y; };
std::vector<S> v;
v.push_back({.x = 42, .y = 43});
So what was the point of providing that type with a constructor?
>
Apart from the above, its also so we can address the designated initializer
list constructor, to explicit default or explicitlty delete it.
> And don't forget: the last time we made special rules for how
> braced-init-lists call constructors, we got screwed with the
> `vector<int>/initializer_list<int>` problem. We shouldn't be making more
> rules that break uniformity farther than it already has been.
>
> I'm not sure what you mean by the "`vector<int>/initializer_list<int>`
problem".
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7bb70c7e9e5d8b0525114801
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, Nov 21, 2015 at 6:56 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div>Oh, and for someone coming up with suc=
h a proposal, don't forget that in C++17, types with base classes that =
have variables will <i>also</i> be considered aggregates. So you'll nee=
d to come up with a way to use them with designated initializers too.<br><b=
r>Good luck solving <i>that</i> one ;)<br></div></blockquote><div><br></div=
><div>The simplest way would be to say that the base classes are default co=
nstructed and the designated initializer list can only refer to the most de=
rived members.</div><div><br></div><div>struct D : B { int x; }</div><div>D=
d =3D { .x =3D 42}; // ok, B default constructed</div><div><br></div><div>=
Even simpler would say that the designated initializer list constructor is =
only generated for classes without base classes.</div><div><br></div><div><=
div>struct D : B { int x; }</div><div>D d =3D { .x =3D 42}; // ill-formed</=
div></div><div><br></div><div>Another solution would be to allow .BaseType =
as a key in a designated initializer list.</div><div><br></div><div>struct =
B { int y; }</div><div><div><div>struct D : B { int x; }</div><div>D d =3D =
{ .B =3D {.y =3D 43}, .x =3D 42}; // ok</div></div></div><div><br></div><di=
v>Another solution would be to roll up the base object graph into a single =
list of members and the designated initializer list addresses only member s=
ubobjects (and not base subobjects).</div><div><br></div><div>struct B { in=
t y; }</div><div>struct D : B { int x; }</div><div>D d =3D { .x =3D 42, .y =
=3D 43}; // ok</div><div>=C2=A0</div><div>The third and forth solutions are=
forward-compatible with the first and second solutions.</div><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex"><div>=C2=A0</div><span class=3D""><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-=
left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div =
dir=3D"ltr"><div>One of the things I've been thinking about is that we =
could have a std::designated_initializer_list unit type (no member function=
s) - and for aggregate class types a constructor taking such a type is gene=
rated.=C2=A0 A constructor taking such a type could also be explicitly defa=
ulted.=C2=A0 We could then have a syntactic construct designated-init-list.=
</div></div></blockquote></span><div><br>I don't see the purpose of thi=
s. Generally speaking, most types that have constructors have invariants, s=
o their data members are private, so you can't name them.<br></div></bl=
ockquote><div><br></div><div>Noone is suggesting being able to address priv=
ate members.=C2=A0 The reason I suggest using a type, is for forwarding of =
designated initializer lists.=C2=A0 To actually consume them (as an endpoin=
t) you need a compiler-generated constructor - either implicitly or explici=
tly defaulted.</div><div><br></div><div>eg</div><div><br></div><div>struct =
S { int x,y; };</div><div>std::vector<S> v;</div><div>v.push_back({.x=
=3D 42, .y =3D 43});</div><div><br></div><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:=
rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>So what was=
the point of providing that type with a constructor?<br></div></blockquote=
><div><br></div><div>Apart from the above, its also so we can address the d=
esignated initializer list constructor, to explicit default or explicitlty =
delete it.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex"><div>And don't forget=
: the last time we made special rules for how braced-init-lists call constr=
uctors, we got screwed with the `vector<int>/initializer_list<int&=
gt;` problem. We shouldn't be making more rules that break uniformity f=
arther than it already has been.</div><div class=3D""><div class=3D"h5">
<p></p></div></div></blockquote></div>I'm not sure what you mean by the=
=C2=A0"`vector<int>/initializer_list<int>` problem".=
</div><div class=3D"gmail_extra"><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--047d7bb70c7e9e5d8b0525114801--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sat, 21 Nov 2015 19:39:43 +0100
Raw View
--047d7bb70c7eca835e05251150e5
Content-Type: text/plain; charset=UTF-8
On Sat, Nov 21, 2015 at 7:37 PM, Andrew Tomazos <andrewtomazos@gmail.com>
wrote:
> On Sat, Nov 21, 2015 at 6:56 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>> Oh, and for someone coming up with such a proposal, don't forget that in
>> C++17, types with base classes that have variables will *also* be
>> considered aggregates. So you'll need to come up with a way to use them
>> with designated initializers too.
>>
>> Good luck solving *that* one ;)
>>
>
> The simplest way would be to say that the base classes are default
> constructed and the designated initializer list can only refer to the most
> derived members.
>
> struct D : B { int x; }
> D d = { .x = 42}; // ok, B default constructed
>
> Even simpler would say that the designated initializer list constructor is
> only generated for classes without base classes.
>
> struct D : B { int x; }
> D d = { .x = 42}; // ill-formed
>
> Another solution would be to allow .BaseType as a key in a designated
> initializer list.
>
> struct B { int y; }
> struct D : B { int x; }
> D d = { .B = {.y = 43}, .x = 42}; // ok
>
> Another solution would be to roll up the base object graph into a single
> list of members and the designated initializer list addresses only member
> subobjects (and not base subobjects).
>
> struct B { int y; }
> struct D : B { int x; }
> D d = { .x = 42, .y = 43}; // ok
>
> The third and forth solutions are forward-compatible with the first and
> second solutions.
>
>
>>
>>> One of the things I've been thinking about is that we could have a
>>> std::designated_initializer_list unit type (no member functions) - and for
>>> aggregate class types a constructor taking such a type is generated. A
>>> constructor taking such a type could also be explicitly defaulted. We
>>> could then have a syntactic construct designated-init-list.
>>>
>>
>> I don't see the purpose of this. Generally speaking, most types that have
>> constructors have invariants, so their data members are private, so you
>> can't name them.
>>
>
> Noone is suggesting being able to address private members. The reason I
> suggest using a type, is for forwarding of designated initializer lists.
> To actually consume them (as an endpoint) you need a compiler-generated
> constructor - either implicitly or explicitly defaulted.
>
> eg
>
> struct S { int x,y; };
> std::vector<S> v;
> v.push_back({.x = 42, .y = 43});
>
Sorry this is a bogus example. I meant something like:
struct S { int x,y; };
std::optional<S> s;
s.emplace({.x = 42, .y = 43});
> So what was the point of providing that type with a constructor?
>>
>
> Apart from the above, its also so we can address the designated
> initializer list constructor, to explicit default or explicitlty delete it.
>
>
>> And don't forget: the last time we made special rules for how
>> braced-init-lists call constructors, we got screwed with the
>> `vector<int>/initializer_list<int>` problem. We shouldn't be making more
>> rules that break uniformity farther than it already has been.
>>
>> I'm not sure what you mean by the "`vector<int>/initializer_list<int>`
> problem".
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7bb70c7eca835e05251150e5
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 Sat, Nov 21, 2015 at 7:37 PM, Andrew Tomazos <span dir=3D"ltr"><<=
a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@g=
mail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On Sat, N=
ov 21, 2015 at 6:56 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto=
:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty=
le:solid;padding-left:1ex"><div>Oh, and for someone coming up with such a p=
roposal, don't forget that in C++17, types with base classes that have =
variables will <i>also</i> be considered aggregates. So you'll need to =
come up with a way to use them with designated initializers too.<br><br>Goo=
d luck solving <i>that</i> one ;)<br></div></blockquote><div><br></div></sp=
an><div>The simplest way would be to say that the base classes are default =
constructed and the designated initializer list can only refer to the most =
derived members.</div><div><br></div><div>struct D : B { int x; }</div><div=
>D d =3D { .x =3D 42}; // ok, B default constructed</div><div><br></div><di=
v>Even simpler would say that the designated initializer list constructor i=
s only generated for classes without base classes.</div><div><br></div><div=
><div>struct D : B { int x; }</div><div>D d =3D { .x =3D 42}; // ill-formed=
</div></div><div><br></div><div>Another solution would be to allow .BaseTyp=
e as a key in a designated initializer list.</div><div><br></div><div>struc=
t B { int y; }</div><div><div><div>struct D : B { int x; }</div><div>D d =
=3D { .B =3D {.y =3D 43}, .x =3D 42}; // ok</div></div></div><div><br></div=
><div>Another solution would be to roll up the base object graph into a sin=
gle list of members and the designated initializer list addresses only memb=
er subobjects (and not base subobjects).</div><div><br></div><div>struct B =
{ int y; }</div><div>struct D : B { int x; }</div><div>D d =3D { .x =3D 42,=
.y =3D 43}; // ok</div><div>=C2=A0</div><div>The third and forth solutions=
are forward-compatible with the first and second solutions.</div><span cla=
ss=3D""><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex"><div>=C2=A0</div><span><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex"><div dir=3D"ltr"><div>One of the things I've been thinking about i=
s that we could have a std::designated_initializer_list unit type (no membe=
r functions) - and for aggregate class types a constructor taking such a ty=
pe is generated.=C2=A0 A constructor taking such a type could also be expli=
citly defaulted.=C2=A0 We could then have a syntactic construct designated-=
init-list.</div></div></blockquote></span><div><br>I don't see the purp=
ose of this. Generally speaking, most types that have constructors have inv=
ariants, so their data members are private, so you can't name them.<br>=
</div></blockquote><div><br></div></span><div>Noone is suggesting being abl=
e to address private members.=C2=A0 The reason I suggest using a type, is f=
or forwarding of designated initializer lists.=C2=A0 To actually consume th=
em (as an endpoint) you need a compiler-generated constructor - either impl=
icitly or explicitly defaulted.</div><div><br></div><div>eg</div><div><br><=
/div><div>struct S { int x,y; };</div><div>std::vector<S> v;</div><di=
v>v.push_back({.x =3D 42, .y =3D 43});</div></div></div></div></blockquote>=
<div><br></div><div>Sorry this is a bogus example.=C2=A0 I meant something =
like:</div><div><br></div><div><div>struct S { int x,y; };</div><div>std::o=
ptional<S> s;</div><div>s.emplace({.x =3D 42, .y =3D 43});</div></div=
><div><br></div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=
=3D""><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div>So what was the point of providing t=
hat type with a constructor?<br></div></blockquote><div><br></div></span><d=
iv>Apart from the above, its also so we can address the designated initiali=
zer list constructor, to explicit default or explicitlty delete it.</div><s=
pan class=3D""><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;padding-left:1ex"><div>And don't forget:=
the last time we made special rules for how braced-init-lists call constru=
ctors, we got screwed with the `vector<int>/initializer_list<int&g=
t;` problem. We shouldn't be making more rules that break uniformity fa=
rther than it already has been.</div><div><div>
<p></p></div></div></blockquote></span></div>I'm not sure what you mean=
by the =C2=A0"`vector<int>/initializer_list<int>` problem=
".</div><div class=3D"gmail_extra"><br></div></div>
</blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--047d7bb70c7eca835e05251150e5--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 21 Nov 2015 12:03:37 -0800 (PST)
Raw View
------=_Part_19_89712841.1448136217238
Content-Type: multipart/alternative;
boundary="----=_Part_20_1391629421.1448136217239"
------=_Part_20_1391629421.1448136217239
Content-Type: text/plain; charset=UTF-8
On Saturday, November 21, 2015 at 1:37:28 PM UTC-5, Andrew Tomazos wrote:
>
> On Sat, Nov 21, 2015 at 6:56 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> Oh, and for someone coming up with such a proposal, don't forget that in
>> C++17, types with base classes that have variables will *also* be
>> considered aggregates. So you'll need to come up with a way to use them
>> with designated initializers too.
>>
>> Good luck solving *that* one ;)
>>
>
> The simplest way would be to say that the base classes are default
> constructed and the designated initializer list can only refer to the most
> derived members.
>
....
>
Even simpler would say that the designated initializer list constructor is
> only generated for classes without base classes.
>
Those aren't solutions.The committee went through a bunch of effort to
allow braced-init-lists to work for aggregates with base class members.
Designated initializers are nothing more than a special form of aggregate
initialization. Why should they be any less functional than regular
aggregate initialization? You should not consider this case as something
you can choose not to cover.
Another solution would be to roll up the base object graph into a single
> list of members and the designated initializer list addresses only member
> subobjects (and not base subobjects).
>
And what if the base class has a member of the same name as a derived class
member?
>
>
>>
>>> One of the things I've been thinking about is that we could have a
>>> std::designated_initializer_list unit type (no member functions) - and for
>>> aggregate class types a constructor taking such a type is generated. A
>>> constructor taking such a type could also be explicitly defaulted. We
>>> could then have a syntactic construct designated-init-list.
>>>
>>
>> I don't see the purpose of this. Generally speaking, most types that have
>> constructors have invariants, so their data members are private, so you
>> can't name them.
>>
>
> Noone is suggesting being able to address private members. The reason I
> suggest using a type, is for forwarding of designated initializer lists.
> To actually consume them (as an endpoint) you need a compiler-generated
> constructor - either implicitly or explicitly defaulted.
>
OK, you're now talking about a whole new problem, one that is completely
unrelated to this one. Namely, solving perfect forwarding for *construction*
via uniform initialization syntax. Being able to pass a braced-init-list to
a (template) function, which will pass that braced-init-list to initialize
a type.
Designated initializers are not special in needing a solution here. We need
this for uniform initialization, whether designated or not. And designated
initializers themselves don't need a solution to this problem for them to
still be effective.
Focus on one problem at a time. You can't use braced-init-lists through
`emplace` currently for aggregate initialization, so there's no reason to
expect designated initializers to be able to work there either.
> So what was the point of providing that type with a constructor?
>>
>
> Apart from the above, its also so we can address the designated
> initializer list constructor, to explicit default or explicitlty delete it.
>
I think you have a different vision for this.
My vision for designated initializatizers is this: aggregate
initialization, where you can name the variable that gets a particular
value. You seem to want something esle.
You say that having a constructor allows you to declare it deleted, so as
to prevent using designated initializers for that type. Well... why would
you *want* to? What purpose does it serve, what problem does it solve? You
made your class members public. All designated initializer syntax is meant
to do is make it easy to fill those members in.
So why would you ever want to forbid users from using this syntax?
The only cases I can come up with where a "designated initialization
constructor" would be important would be a type that has both public
members *and* constructors. A type with constructors is by definition not
an aggregate and therefore cannot participate in aggregate initialization.
So if you want to use designated initializers with it, you need some other
way.
But there's a reason why we decided that types with constructors aren't
aggregates. Type constructors exist to ensure *invariants*, to ensure the
sanity of a type's interface and data. If all your members are public,
there are no invariants. Which means there is no need for constructors. Oh,
you might have some factory functions to make it easy to have different
sets of default data, or to specify some data while taking defaults from
elsewhere. Or whatever.
But if you're able to just initialize an object with whatever values you
like, if it's just a bundle of independent variables with no invariant,
then there is no point in that type having a constructor at all. So why
would it not be an aggregate?
Give me an example of a type who's members are public (and therefore you'd
want to use designated initializers) which also *needs* constructors. Or of
a type who's members are public and that there is a good reason to want to
forbid the use of designated initializers.
And don't forget: the last time we made special rules for how
>> braced-init-lists call constructors, we got screwed with the
>> `vector<int>/initializer_list<int>` problem. We shouldn't be making more
>> rules that break uniformity farther than it already has been.
>>
>> I'm not sure what you mean by the "`vector<int>/initializer_list<int>`
> problem".
>
I'm referring to the fact that `vector<std::string> s{5};` will construct a
vector with 5 empty strings, but `vector<int> s{5}` will construct a vector
with a single integer with the value 5. This is because braced-init-list
syntax prefers a matching `initializer_list` constructor over regular
constructors. Template code has problems effectively using
braced-init-lists because it can't know if it might call an
initializer_list constructor instead of a regular one.
Indeed, one of the explicit examples for constexpr_if was to have an easy
way to work around such issues, using braces or parenthesis on a type's
initialization depending on whether the type `is_constructible` with the
arguments.
As I said, the last time we started adding special rules for
braced-init-list with constructors, we made uniform initialization
non-uniform. Let's not do that again.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_20_1391629421.1448136217239
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Saturday, November 21, 2015 at 1:37:28 PM UTC-5, Andrew Tomazos =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><d=
iv class=3D"gmail_quote">On Sat, Nov 21, 2015 at 6:56 PM, Nicol Bolas <span=
dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"GdAfQYudBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;">jmck...@gmail.com</a>></span> wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><di=
v>Oh, and for someone coming up with such a proposal, don't forget that=
in C++17, types with base classes that have variables will <i>also</i> be =
considered aggregates. So you'll need to come up with a way to use them=
with designated initializers too.<br><br>Good luck solving <i>that</i> one=
;)<br></div></blockquote><div><br></div><div>The simplest way would be to =
say that the base classes are default constructed and the designated initia=
lizer list can only refer to the most derived members.</div></div></div></d=
iv></blockquote><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left=
: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote"><=
div>... <br></div></blockquote><blockquote style=3D"margin: 0px 0px 0px 0.8=
ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D=
"gmail_quote"><div>Even simpler would say that the designated initializer l=
ist constructor is only generated for classes without base classes. <br></d=
iv></blockquote><div><br>Those aren't solutions.The committee went thro=
ugh a bunch of effort to allow braced-init-lists to work for aggregates wit=
h base class members.<br><br>Designated initializers are nothing more than =
a special form of aggregate initialization. Why should they be any less fun=
ctional than regular aggregate initialization? You should not consider this=
case as something you can choose not to cover.<br><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div></div></div></div=
></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote"><div></div><div></div><div>Another solutio=
n would be to roll up the base object graph into a single list of members a=
nd the designated initializer list addresses only member subobjects (and no=
t base subobjects).</div></div></div></div></blockquote><div><br>And what i=
f the base class has a member of the same name as a derived class member?<b=
r>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote"><div><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>=C2=
=A0</div><span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>One of the things I&#=
39;ve been thinking about is that we could have a std::designated_initializ=
er_<wbr>list unit type (no member functions) - and for aggregate class type=
s a constructor taking such a type is generated.=C2=A0 A constructor taking=
such a type could also be explicitly defaulted.=C2=A0 We could then have a=
syntactic construct designated-init-list.</div></div></blockquote></span><=
div><br>I don't see the purpose of this. Generally speaking, most types=
that have constructors have invariants, so their data members are private,=
so you can't name them.<br></div></blockquote><div><br></div><div>Noon=
e is suggesting being able to address private members.=C2=A0 The reason I s=
uggest using a type, is for forwarding of designated initializer lists.=C2=
=A0 To actually consume them (as an endpoint) you need a compiler-generated=
constructor - either implicitly or explicitly defaulted.</div></div></div>=
</div></blockquote><div><br>OK, you're now talking about a whole new pr=
oblem, one that is completely unrelated to this one. Namely, solving perfec=
t forwarding for <i>construction</i> via uniform initialization syntax. Bei=
ng able to pass a braced-init-list to a (template) function, which will pas=
s that braced-init-list to initialize a type.<br><br>Designated initializer=
s are not special in needing a solution here. We need this for uniform init=
ialization, whether designated or not. And designated initializers themselv=
es don't need a solution to this problem for them to still be effective=
..<br><br>Focus on one problem at a time. You can't use braced-init-list=
s through `emplace` currently for aggregate initialization, so there's =
no reason to expect designated initializers to be able to work there either=
..<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div><div class=3D"gmail_quote"><div><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>So w=
hat was the point of providing that type with a constructor?<br></div></blo=
ckquote><div><br></div><div>Apart from the above, its also so we can addres=
s the designated initializer list constructor, to explicit default or expli=
citlty delete it.</div></div></div></div></blockquote><div><br>I think you =
have a different vision for this.<br><br>My vision for designated initializ=
atizers is this: aggregate initialization, where you can name the variable =
that gets a particular value. You seem to want something esle.<br><br>You s=
ay that having a constructor allows you to declare it deleted, so as to pre=
vent using designated initializers for that type. Well... why would you <i>=
want</i> to? What purpose does it serve, what problem does it solve? You ma=
de your class members public. All designated initializer syntax is meant to=
do is make it easy to fill those members in.<br><br>So why would you ever =
want to forbid users from using this syntax?<br><br>The only cases I can co=
me up with where a "designated initialization constructor" would =
be important would be a type that has both public members <i>and</i> constr=
uctors. A type with constructors is by definition not an aggregate and ther=
efore cannot participate in aggregate initialization. So if you want to use=
designated initializers with it, you need some other way.<br><br>But there=
's a reason why we decided that types with constructors aren't aggr=
egates. Type constructors exist to ensure <i>invariants</i>, to ensure the =
sanity of a type's interface and data. If all your members are public, =
there are no invariants. Which means there is no need for constructors. Oh,=
you might have some factory functions to make it easy to have different se=
ts of default data, or to specify some data while taking defaults from else=
where. Or whatever.<br><br>But if you're able to just initialize an obj=
ect with whatever values you like, if it's just a bundle of independent=
variables with no invariant, then there is no point in that type having a =
constructor at all. So why would it not be an aggregate?<br><br>Give me an =
example of a type who's members are public (and therefore you'd wan=
t to use designated initializers) which also <i>needs</i> constructors. Or =
of a type who's members are public and that there is a good reason to w=
ant to forbid the use of designated initializers.<br><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_=
quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:=
solid;padding-left:1ex"><div>And don't forget: the last time we made sp=
ecial rules for how braced-init-lists call constructors, we got screwed wit=
h the `vector<int>/initializer_list<<wbr>int>` problem. We shou=
ldn't be making more rules that break uniformity farther than it alread=
y has been.</div><div><div>
<p></p></div></div></blockquote></div>I'm not sure what you mean by the=
=C2=A0"`vector<int>/initializer_<wbr>list<int>` problem&q=
uot;.</div></div></blockquote><div><br>I'm referring to the fact that `=
vector<std::string> s{5};` will construct a vector with 5 empty strin=
gs, but `vector<int> s{5}` will construct a vector with a single inte=
ger with the value 5. This is because braced-init-list syntax prefers a mat=
ching `initializer_list` constructor over regular constructors. Template co=
de has problems effectively using braced-init-lists because it can't kn=
ow if it might call an initializer_list constructor instead of a regular on=
e.<br><br>Indeed, one of the explicit examples for constexpr_if was to have=
an easy way to work around such issues, using braces or parenthesis on a t=
ype's initialization depending on whether the type `is_constructible` w=
ith the arguments.<br><br>As I said, the last time we started adding specia=
l rules for braced-init-list with constructors, we made uniform initializat=
ion non-uniform. Let's not do that again.<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" 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_20_1391629421.1448136217239--
------=_Part_19_89712841.1448136217238--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sun, 22 Nov 2015 23:47:25 +0100
Raw View
--001a113d52e273fd69052528e413
Content-Type: text/plain; charset=UTF-8
> Designated initializers are nothing more than a special form of aggregate
> initialization.
>
That's a premature design decision. I agree generally it is desirable to
have consistency between { braced-init-list, std::initializer_list,
list-initialization } and { designated-init-list,
std::designated_initializer_list, designated-list-initialization }. It's
the proposal authors job to work out the details.
And what if the base class has a member of the same name as a derived class
> member?
>
One option would be ill-formed ambiguous. Another would be to favor the
derived class. Another (compatible with both previous) would be to allow
the name to be qualified by .base_type::member_name. It's a corner case
though. You shouldn't really "override" data members by name to begin with.
>>> One of the things I've been thinking about is that we could have a
>>>> std::designated_initializer_list unit type (no member functions) - and for
>>>> aggregate class types a constructor taking such a type is generated. A
>>>> constructor taking such a type could also be explicitly defaulted. We
>>>> could then have a syntactic construct designated-init-list.
>>>>
>>>
>>> I don't see the purpose of this. Generally speaking, most types that
>>> have constructors have invariants, so their data members are private, so
>>> you can't name them.
>>>
>>
>> Noone is suggesting being able to address private members. The reason I
>> suggest using a type, is for forwarding of designated initializer lists.
>> To actually consume them (as an endpoint) you need a compiler-generated
>> constructor - either implicitly or explicitly defaulted.
>>
>
> OK, you're now talking about a whole new problem, one that is completely
> unrelated to this one. Namely, solving perfect forwarding for
> *construction* via uniform initialization syntax. Being able to pass a
> braced-init-list to a (template) function, which will pass that
> braced-init-list to initialize a type.
>
That wasn't my intent. The intent was that the relationship between
braced-init-list and std::initializer_list be somehow similar to that
between designated-init-list and std::designated_initializer_list.
I see a braced-init-list as a compile-time ordered sequence (either
homogeneous or heterogeneous). It is the position index within the list
that is used as the key.
I see a designated-init-list as a compile-time associative array. It is
the explicit member name designated that is the key.
With that difference in mind, designated-init-list should generally be
integrated into the language in a similar way to how braced-init-list 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/.
--001a113d52e273fd69052528e413
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>Designated initializers are nothing mor=
e than a special form of aggregate initialization.</div></blockquote><div>=
=C2=A0</div><div>That's a premature design decision.=C2=A0 I agree gene=
rally it is desirable to have consistency between { braced-init-list, std::=
initializer_list, list-initialization } and { designated-init-list, std::de=
signated_initializer_list, designated-list-initialization }.=C2=A0 It's=
the proposal authors job to work out the details.</div><div><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div>And what if the base class has a member of =
the same name as a derived class member?<br></div></blockquote><div>=C2=A0<=
/div><div>One option would be ill-formed ambiguous.=C2=A0 Another would be =
to favor the derived class.=C2=A0 Another (compatible with both previous) w=
ould be to allow the name to be qualified by .base_type::member_name.=C2=A0=
It's a corner case though.=C2=A0 You shouldn't really "overri=
de" data members by name to begin with.</div><div><br></div><div><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><span class=3D""><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1=
ex"><div><br></div><span><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);=
border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>One of the =
things I've been thinking about is that we could have a std::designated=
_initializer_list unit type (no member functions) - and for aggregate class=
types a constructor taking such a type is generated.=C2=A0 A constructor t=
aking such a type could also be explicitly defaulted.=C2=A0 We could then h=
ave a syntactic construct designated-init-list.</div></div></blockquote></s=
pan><div><br>I don't see the purpose of this. Generally speaking, most =
types that have constructors have invariants, so their data members are pri=
vate, so you can't name them.<br></div></blockquote><div><br></div><div=
>Noone is suggesting being able to address private members.=C2=A0 The reaso=
n I suggest using a type, is for forwarding of designated initializer lists=
..=C2=A0 To actually consume them (as an endpoint) you need a compiler-gener=
ated constructor - either implicitly or explicitly defaulted.</div></div></=
div></blockquote></span><div><br>OK, you're now talking about a whole n=
ew problem, one that is completely unrelated to this one. Namely, solving p=
erfect forwarding for <i>construction</i> via uniform initialization syntax=
.. Being able to pass a braced-init-list to a (template) function, which wil=
l pass that braced-init-list to initialize a type.<br></div></blockquote><d=
iv><br></div><div>That wasn't my intent.=C2=A0 The intent was that the =
relationship between braced-init-list and std::initializer_list be somehow =
similar to that between designated-init-list and std::designated_initialize=
r_list.</div><div><br></div><div>I see a braced-init-list as a compile-time=
ordered sequence (either homogeneous or heterogeneous).=C2=A0 It is the po=
sition index within the list that is used as the key.</div><div><br></div><=
div>I see a designated-init-list as a compile-time associative array.=C2=A0=
It is the explicit member name designated that is the key.</div><div><br><=
/div><div>With that difference in mind, designated-init-list should general=
ly be integrated into the language in a similar way to how braced-init-list=
is.</div><div><br></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--001a113d52e273fd69052528e413--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 22 Nov 2015 18:54:27 -0800 (PST)
Raw View
------=_Part_4433_1057878580.1448247267422
Content-Type: multipart/alternative;
boundary="----=_Part_4434_1724884014.1448247267422"
------=_Part_4434_1724884014.1448247267422
Content-Type: text/plain; charset=UTF-8
On Sunday, November 22, 2015 at 5:47:26 PM UTC-5, Andrew Tomazos wrote:
>
>
> Designated initializers are nothing more than a special form of aggregate
>> initialization.
>>
>
> That's a premature design decision.
>
No it isn't. It is an answer to the question, "What do you think the
feature is?" That is the most important question that a proposal can answer.
Believing that this is a premature question is how you get scope creep.
It's how the pre-C++11 concepts kept accruing cruft until it grew so large
that it collapsed under its own weight. It's how P0057 transformed from
being a simple continuation mechanism into handing generators and even
things that have nothing at all to do with concurrency or scheduling.
That kind of thinking leads to unfocused features, things that you can do
"because they're kinda related" rather than because they're actually part
of the design. It's bad design.
That's not to say that you shouldn't entertain different ways of achieving
something. But every solution must ultimately match up with the question of
what the feature is meant to accomplish. Deciding what the feature is must
always be step #1.
> I agree generally it is desirable to have consistency between {
> braced-init-list, std::initializer_list, list-initialization } and {
> designated-init-list, std::designated_initializer_list,
> designated-list-initialization }. It's the proposal authors job to work
> out the details.
>
Or you could just... not do it this way. The feature of designated
initializers does not in any way require what you're talking about. If you
take away this and just make it a form of aggregate initialization, you
will have lost nothing *except* for the ability to forward this
initialization. Which, as previously stated, is a general problem with
braced-init-lists, which need not be solved here.
It's easy to say that a proposal should be much more complicated than it
needs to be, then say that it is someone else's job to figure out the
actual details to make it work.
And what if the base class has a member of the same name as a derived class
>> member?
>>
>
> One option would be ill-formed ambiguous. Another would be to favor the
> derived class. Another (compatible with both previous) would be to allow
> the name to be qualified by .base_type::member_name. It's a corner case
> though. You shouldn't really "override" data members by name to begin with.
>
You don't have to be overriding anything to get a conflict. Maybe the base
class just happened to use the same variable name you wanted to use in your
derived class. Or maybe you have two base classes that again just happen to
have variables with the same name.
It may be a corner case, but C++ is a language of corner cases. Just
because you don't like this case doesn't mean you can choose not to account
for it.
> One of the things I've been thinking about is that we could have a
>>>>> std::designated_initializer_list unit type (no member functions) - and for
>>>>> aggregate class types a constructor taking such a type is generated. A
>>>>> constructor taking such a type could also be explicitly defaulted. We
>>>>> could then have a syntactic construct designated-init-list.
>>>>>
>>>>
>>>> I don't see the purpose of this. Generally speaking, most types that
>>>> have constructors have invariants, so their data members are private, so
>>>> you can't name them.
>>>>
>>>
>>> Noone is suggesting being able to address private members. The reason I
>>> suggest using a type, is for forwarding of designated initializer lists.
>>> To actually consume them (as an endpoint) you need a compiler-generated
>>> constructor - either implicitly or explicitly defaulted.
>>>
>>
>> OK, you're now talking about a whole new problem, one that is completely
>> unrelated to this one. Namely, solving perfect forwarding for
>> *construction* via uniform initialization syntax. Being able to pass a
>> braced-init-list to a (template) function, which will pass that
>> braced-init-list to initialize a type.
>>
>
> That wasn't my intent. The intent was that the relationship between
> braced-init-list and std::initializer_list be somehow similar to that
> between designated-init-list and std::designated_initializer_list.
>
Then your design does not express your intent, since they are nothing at
all alike. An `initializer_list` is merely a pair of pointers to a specific
type, which is backed by a temporary array created by the compiler. A
`designated_initializer_list` isn't even a *list*. As you suggest, it's
more like a map. But as I'll explain, it isn't even that.
I see a braced-init-list as a compile-time ordered sequence (either
> homogeneous or heterogeneous). It is the position index within the list
> that is used as the key.
>
You may see it however you wish, but the actual standard does not agree. A
braced-init-list is not even an expression, let alone an ordered sequence
of values. It is a compile-time construct used to initialize a type, and it
does not exist any longer than that.
> I see a designated-init-list as a compile-time associative array. It is
> the explicit member name designated that is the key.
>
.... OK, I'll play along.
If the member name is the key, what is the "value" associated with that key?
Here's what I mean. Let's say I have this type:
struct T
{
string str;
vector<float> vec;
};
Which means I can do this:
T{.str = {"foo"}, .vec = {5, 0.3f}};
OK, now let's say I have some intermediate function:
void func(std::designated_initiailzer_list foo)
{
T t(foo);
}
func({.str = {"foo"}, .vec = {5, 0.3f}});
OK, so... what happens here? At the point of the call to `func`, the
compiler has no idea what `.str` and `.vec` refer to. And {"foo"} and {5,
0.3f} are braced-init-lists, which are neither values nor expressions. They
are compiler constructs used to initialize a type, but there is no type
associated with them. So... what gets stored in the
`designated_initializer_list`?
You can't have some API that allows you to access members of a
`designated_initializer_list` by name. Because that would require that you
could get a C++ value from them, and they don't necessarily contain values.
The only way for your `designated_initializer_list` type to work is by pure
compiler magic. That is, it's a completely opaque type, which at runtime
will be filled in by "some data". And therefore, the only way you could use
it is to pass it to someone else or to construct a type, as `func` does
above.
And that of course leaves open the question of what happens if the user
does this:
func({.str = {"foo"}, .vect = {5, 0.3f}});
T does not contain a `vect`. So... now what? Since `func` could be passed a
`designated_initializer_list` from anywhere, I guess this becomes some kind
of runtime exception thrown in compiler-generated code. But... that means
that the construction of `T` within `func` has to be a runtime
construction. That the compiler does not and cannot know what values get
filled in and which ones don't.
How would `func` go about verifying that it can actually construct a `T`
from a given `designated_initializer_list`? Would it have some API for
doing that, like `d_i_l.can_construct<T>();`? How expensive would that
function be? Almost certainly more expensive than regular old
`vector::emplace`.
Or... we could avoid solving any of those problems and just make designated
initialization a form of aggregate initialization.
--
---
You received this message because you are subscribed to the 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_4434_1724884014.1448247267422
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, November 22, 2015 at 5:47:26 PM UTC-5, Andrew T=
omazos wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<br><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Des=
ignated initializers are nothing more than a special form of aggregate init=
ialization.</div></blockquote><div>=C2=A0</div><div>That's a premature =
design decision.</div></div></div></div></blockquote><div><br>No it isn'=
;t. It is an answer to the question, "What do you think the feature is=
?" That is the most important question that a proposal can answer.<br>=
<br>Believing that this is a premature question is how you get scope creep.=
It's how the pre-C++11 concepts kept accruing cruft until it grew so l=
arge that it collapsed under its own weight. It's how P0057 transformed=
from being a simple continuation mechanism into handing generators and eve=
n things that have nothing at all to do with concurrency or scheduling.<br>=
<br>That kind of thinking leads to unfocused features, things that you can =
do "because they're kinda related" rather than because they&#=
39;re actually part of the design. It's bad design.<br><br>That's n=
ot to say that you shouldn't entertain different ways of achieving some=
thing. But every solution must ultimately match up with the question of wha=
t the feature is meant to accomplish. Deciding what the feature is must alw=
ays be step #1.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>I agree generally it=
is desirable to have consistency between { braced-init-list, std::initiali=
zer_list, list-initialization } and { designated-init-list, std::designated=
_initializer_<wbr>list, designated-list-initialization }.=C2=A0 It's th=
e proposal authors job to work out the details.</div></div></div></div></bl=
ockquote><div><br>Or you could just... not do it this way. The feature of d=
esignated initializers does not in any way require what you're talking =
about. If you take away this and just make it a form of aggregate initializ=
ation, you will have lost nothing <i>except</i> for the ability to forward =
this initialization. Which, as previously stated, is a general problem with=
braced-init-lists, which need not be solved here.<br><br>It's easy to =
say that a proposal should be much more complicated than it needs to be, th=
en say that it is someone else's job to figure out the actual details t=
o make it work.<br><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div>And what if the base class has a member of t=
he same name as a derived class member?<br></div></blockquote><div>=C2=A0</=
div><div>One option would be ill-formed ambiguous.=C2=A0 Another would be t=
o favor the derived class.=C2=A0 Another (compatible with both previous) wo=
uld be to allow the name to be qualified by .base_type::member_name.=C2=A0 =
It's a corner case though.=C2=A0 You shouldn't really "overrid=
e" data members by name to begin with.</div></div></div></div></blockq=
uote><div><br>You don't have to be overriding anything to get a conflic=
t. Maybe the base class just happened to use the same variable name you wan=
ted to use in your derived class. Or maybe you have two base classes that a=
gain just happen to have variables with the same name.<br><br>It may be a c=
orner case, but C++ is a language of corner cases. Just because you don'=
;t like this case doesn't mean you can choose not to account for it.<br=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex"><div></div><span><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div=
>One of the things I've been thinking about is that we could have a std=
::designated_initializer_<wbr>list unit type (no member functions) - and fo=
r aggregate class types a constructor taking such a type is generated.=C2=
=A0 A constructor taking such a type could also be explicitly defaulted.=C2=
=A0 We could then have a syntactic construct designated-init-list.</div></d=
iv></blockquote></span><div><br>I don't see the purpose of this. Genera=
lly speaking, most types that have constructors have invariants, so their d=
ata members are private, so you can't name them.<br></div></blockquote>=
<div><br></div><div>Noone is suggesting being able to address private membe=
rs.=C2=A0 The reason I suggest using a type, is for forwarding of designate=
d initializer lists.=C2=A0 To actually consume them (as an endpoint) you ne=
ed a compiler-generated constructor - either implicitly or explicitly defau=
lted.</div></div></div></blockquote></span><div><br>OK, you're now talk=
ing about a whole new problem, one that is completely unrelated to this one=
.. Namely, solving perfect forwarding for <i>construction</i> via uniform in=
itialization syntax. Being able to pass a braced-init-list to a (template) =
function, which will pass that braced-init-list to initialize a type.<br></=
div></blockquote><div><br></div><div>That wasn't my intent.=C2=A0 The i=
ntent was that the relationship between braced-init-list and std::initializ=
er_list be somehow similar to that between designated-init-list and std::de=
signated_initializer_<wbr>list.</div></div></div></div></blockquote><div><b=
r>Then your design does not express your intent, since they are nothing at =
all alike. An `initializer_list` is merely a pair of pointers to a specific=
type, which is backed by a temporary array created by the compiler. A `des=
ignated_initializer_list` isn't even a <i>list</i>. As you suggest, it&=
#39;s more like a map. But as I'll explain, it isn't even that.<br>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v><div class=3D"gmail_quote"><div>I see a braced-init-list as a compile-tim=
e ordered sequence (either homogeneous or heterogeneous).=C2=A0 It is the p=
osition index within the list that is used as the key.</div></div></div></d=
iv></blockquote><div><br>You may see it however you wish, but the actual st=
andard does not agree. A braced-init-list is not even an expression, let al=
one an ordered sequence of values. It is a compile-time construct used to i=
nitialize a type, and it does not exist any longer than that.<br>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div c=
lass=3D"gmail_quote"><div></div><div>I see a designated-init-list as a comp=
ile-time associative array.=C2=A0 It is the explicit member name designated=
that is the key.</div></div></div></div></blockquote><div><br>... OK, I=
9;ll play along.<br><br>If the member name is the key, what is the "va=
lue" associated with that key?<br><br>Here's what I mean. Let'=
s say I have this type:<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: #008;" class=3D"s=
tyled-by-prettify">struct</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> T<br></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 </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">string</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
str</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 vecto=
r</span><span style=3D"color: #080;" class=3D"styled-by-prettify"><float=
></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> vec</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">};</span></div></code></div=
><br>Which means I can do this:<br><br><div class=3D"prettyprint" style=3D"=
background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bor=
der-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{.</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">str </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><spa=
n style=3D"color: #080;" class=3D"styled-by-prettify">"foo"</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">},</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">vec </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: #660;" class=3D"styled-by=
-prettify">{</span><span style=3D"color: #066;" class=3D"styled-by-prettify=
">5</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #066;" class=3D"styled-by-prettify">0.3f</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">}};</span></div></code></div><b=
r>OK, now let's say I have some intermediate function:<br><br><div clas=
s=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-col=
or: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: =
break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> func</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">designated_initiailzer_list foo</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>=C2=A0 T t</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">foo</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>func</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">({.</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">str </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">{</span><span style=3D"color: #080;" class=
=3D"styled-by-prettify">"foo"</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">},</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">vec </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">5</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">0.3f</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">}});</span></div></code></div><br>OK, so... what happens here=
? At the point of the call to `func`, the compiler has no idea what `.str` =
and `.vec` refer to. And {"foo"} and {5, 0.3f} are braced-init-li=
sts, which are neither values nor expressions. They are compiler constructs=
used to initialize a type, but there is no type associated with them. So..=
.. what gets stored in the `designated_initializer_list`?<br><br>You can'=
;t have some API that allows you to access members of a `designated_initial=
izer_list` by name. Because that would require that you could get a C++ val=
ue from them, and they don't necessarily contain values.<br><br>The onl=
y way for your `designated_initializer_list` type to work is by pure compil=
er magic. That is, it's a completely opaque type, which at runtime will=
be filled in by "some data". And therefore, the only way you cou=
ld use it is to pass it to someone else or to construct a type, as `func` d=
oes above.<br><br>And that of course leaves open the question of what happe=
ns if the user does this:<br><br><div class=3D"prettyprint" style=3D"backgr=
ound-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-st=
yle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D=
"styled-by-prettify">func</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">({.</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">str </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span =
style=3D"color: #080;" class=3D"styled-by-prettify">"foo"</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">},</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">vect </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">{</span><span style=3D"color: #066;" class=3D"styled-by-prettify"=
>5</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #066;" class=3D"styled-by-prettify">0.3f</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">}});</span></div></code></div><b=
r>T does not contain a `vect`. So... now what? Since `func` could be passed=
a `designated_initializer_list` from anywhere, I guess this becomes some k=
ind of runtime exception thrown in compiler-generated code. But... that mea=
ns that the construction of `T` within `func` has to be a runtime construct=
ion. That the compiler does not and cannot know what values get filled in a=
nd which ones don't.<br><br>How would `func` go about verifying that it=
can actually construct a `T` from a given `designated_initializer_list`? W=
ould it have some API for doing that, like `d_i_l.can_construct<T>();=
`? How expensive would that function be? Almost certainly more expensive th=
an regular old `vector::emplace`.<br><br>Or... we could avoid solving any o=
f those problems and just make designated initialization a form of aggregat=
e initialization.<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" 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_4434_1724884014.1448247267422--
------=_Part_4433_1057878580.1448247267422--
.
Author: Hannes <landeholm@gmail.com>
Date: Mon, 23 Nov 2015 02:50:06 -0800 (PST)
Raw View
------=_Part_247_1465936213.1448275806319
Content-Type: multipart/alternative;
boundary="----=_Part_248_837006063.1448275806319"
------=_Part_248_837006063.1448275806319
Content-Type: text/plain; charset=UTF-8
On Monday, November 23, 2015 at 3:54:27 AM UTC+1, Nicol Bolas wrote:
>
>
> Or... we could avoid solving any of those problems and just make
> designated initialization a form of aggregate initialization.
>
Yeah, I feel like that would be the simplest way to go now. Essentially
making designated initialization syntactically equivalent to a (non-array)
aggregate initialization where the ordering of keys is flexible and
maintain the same C++14 behaviour as aggregate initialization for
non-specified fields (default initialization).
That would be useful enough IMO and very easy to explain to people. "Oh,
it's just aggregate initialization with some extra syntactic sugar."
--
---
You received this message because you are subscribed to the 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_248_837006063.1448275806319
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, November 23, 2015 at 3:54:27 AM UTC+1, Nicol Bo=
las 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"><di=
v><br>Or... we could avoid solving any of those problems and just make desi=
gnated initialization a form of aggregate initialization.<br></div></div></=
blockquote><div><br></div><div>Yeah, I feel like that would be the simplest=
way to go now. Essentially making designated initialization syntactically =
equivalent to a (non-array) aggregate initialization where the ordering of =
keys is flexible and maintain the same C++14=C2=A0behaviour as aggregate in=
itialization for non-specified fields (default initialization).</div><div><=
br></div><div>That would be useful enough IMO and very easy to explain to p=
eople. "Oh, it's just aggregate initialization with some extra syn=
tactic sugar."</div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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_248_837006063.1448275806319--
------=_Part_247_1465936213.1448275806319--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 23 Nov 2015 06:41:05 -0800 (PST)
Raw View
------=_Part_625_1576669658.1448289666037
Content-Type: multipart/alternative;
boundary="----=_Part_626_1540763382.1448289666038"
------=_Part_626_1540763382.1448289666038
Content-Type: text/plain; charset=UTF-8
On Monday, November 23, 2015 at 5:50:06 AM UTC-5, Hannes wrote:
>
> On Monday, November 23, 2015 at 3:54:27 AM UTC+1, Nicol Bolas wrote:
>>
>>
>> Or... we could avoid solving any of those problems and just make
>> designated initialization a form of aggregate initialization.
>>
>
> Yeah, I feel like that would be the simplest way to go now. Essentially
> making designated initialization syntactically equivalent to a (non-array)
> aggregate initialization where the ordering of keys is flexible and
> maintain the same C++14 behaviour as aggregate initialization for
> non-specified fields (default initialization).
>
> That would be useful enough IMO and very easy to explain to people. "Oh,
> it's just aggregate initialization with some extra syntactic sugar."
>
There are three areas of concern when it comes to designated initializers
in C++, which have to do with C++-specific features.
The first is base class member initialization. I think the best way to
handle it syntactically is like this:
{ .base_class = {.mem1 = 5, .mem2 = {init}}, .outer1 = {1, 2, 3} };
That is, each class level gets its own initializer list. I think this is
cleaner than doing `.base_class.mem1`, and it avoids the issue of classes
in the hierarchy with the same name. It also makes it clear that you're
setting members in a subobject.
Oh, and it allows you to initialize subobjects of the main class as you see
fit. We could have initialized `.base_class` without naming its members,
for example.
There is a downside to this approach. That downside is due to the second
issue: how designated initializers interact with non-designated
initializers in the same braced-init-list.
If you have this:
{3, "string", .member = 12};
How does that work? Do we initialize all of the designated members first,
then order the rest and initialize them if they were not initialized? How
does that interact with base class members?
I don't know much about designated initializers in C, so how do they handle
it?
The third issue is overloading. Consider the following code:
struct agg1
{
int i; float f;
};
struct agg2
{
std::string s; std::string g;
};
void func(agg1) {std::cout << "func1\n";}
void func(agg2) {std::cout << "func2\n";}
int main() {
func({5, 2.0f});
return 0;
}
Under C++14 rules, this will actually select the correct overload to call,
based on whether the type can be constructed given the braced-init-list.
Designated initializers should not change this. Which means they should
allow differentiation on the basis of member names:
struct agg1
{
int i; float f;
};
struct agg2
{
int i; float j;
};
void func(agg1) {std::cout << "func1\n";}
void func(agg2) {std::cout << "func2\n";}
int main() {
func({.i = 5, .j = 2.0f}); //Calls second overload.
return 0;
}
That's an extra bit of complexity.
--
---
You received this message because you are subscribed to the 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_626_1540763382.1448289666038
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, November 23, 2015 at 5:50:06 AM UTC-5, Hannes wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Monday, November 23, 2=
015 at 3:54:27 AM UTC+1, Nicol Bolas wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div><br>Or... we could avoid solving any of those=
problems and just make designated initialization a form of aggregate initi=
alization.<br></div></div></blockquote><div><br></div><div>Yeah, I feel lik=
e that would be the simplest way to go now. Essentially making designated i=
nitialization syntactically equivalent to a (non-array) aggregate initializ=
ation where the ordering of keys is flexible and maintain the same C++14=C2=
=A0behaviour as aggregate initialization for non-specified fields (default =
initialization).</div><div><br></div><div>That would be useful enough IMO a=
nd very easy to explain to people. "Oh, it's just aggregate initia=
lization with some extra syntactic sugar."</div></div></blockquote><di=
v><br>There are three areas of concern when it comes to designated initiali=
zers in C++, which have to do with C++-specific features.<br><br>The first =
is base class member initialization. I think the best way to handle it synt=
actically is like this:<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: #660;" class=3D"s=
tyled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">base_cla=
ss </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><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">mem1 </span><span style=3D"colo=
r: #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">5</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">mem2 </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">init</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">}},</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">outer1 </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: #660;" class=3D"styled-by-prettify">{</span><span st=
yle=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=3D"co=
lor: #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">2</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">3</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">};</span></div></code></div>=
<br>That is, each class level gets its own initializer list. I think this i=
s cleaner than doing `.base_class.mem1`, and it avoids the issue of classes=
in the hierarchy with the same name. It also makes it clear that you'r=
e setting members in a subobject.<br><br>Oh, and it allows you to initializ=
e subobjects of the main class as you see fit. We could have initialized `.=
base_class` without naming its members, for example.<br><br>There is a down=
side to this approach. That downside is due to the second issue: how design=
ated initializers interact with non-designated initializers in the same bra=
ced-init-list.<br><br>If you have this:<br><br><div class=3D"prettyprint" s=
tyle=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 1=
87); border-style: solid; border-width: 1px; word-wrap: break-word;"><code =
class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #=
660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #066;" cla=
ss=3D"styled-by-prettify">3</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: #080;" class=3D"styled-by-prettify">&=
quot;string"</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">member </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">12</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">};</span></div></code></div><br>How does that=
work? Do we initialize all of the designated members first, then order the=
rest and initialize them if they were not initialized? How does that inter=
act with base class members?<br><br>I don't know much about designated =
initializers in C, so how do they handle it?<br><br>The third issue is over=
loading. Consider the following code:<br><br><div class=3D"prettyprint" sty=
le=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187=
); border-style: solid; border-width: 1px; word-wrap: break-word;"><code cl=
ass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> agg1<br></span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> i</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">float<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> f</span><s=
pan 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"co=
lor: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> agg2<br></span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>=C2=A0 =C2=A0 std</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">::</span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">string</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> s</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">string</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> g</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> func</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">agg1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">cout </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify"><<</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"styl=
ed-by-prettify">"func1\n"</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;}</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> func</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">agg2</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">cout </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: #080;" class=3D"styled-by-prettify=
">"func2\n"</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">;}</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> main<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><s=
pan 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"><br>=C2=A0 =C2=A0 func</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">({</span><span style=3D"c=
olor: #066;" class=3D"styled-by-prettify">5</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">2.0f</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">});</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-=
prettify">return</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code></div>=
<br>Under C++14 rules, this will actually select the correct overload to ca=
ll, based on whether the type can be constructed given the braced-init-list=
.. Designated initializers should not change this. Which means they should a=
llow differentiation on the basis of member names:<br><br><div class=3D"pre=
ttyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(=
187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-wo=
rd;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> agg1<br></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"> i</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">float</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> agg2<br></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"> i</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">float</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> j</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> func</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">agg1</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">cout </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify"><<</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #080;" class=3D"styled-by-prettify">"func1\n"</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;}</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> func</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">agg2</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">)</span><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">std</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">cout </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: #080;" cla=
ss=3D"styled-by-prettify">"func2\n"</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">;}</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> main</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 func</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>({.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">i </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">5</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">j </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #066;" class=3D"styled-by-prettify">2.0f</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">});</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #800;" class=3D"styled-by-prettify">//Calls second overload.</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">return</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">}</span></div></code></div><br>That's an extra=
bit of complexity.<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" 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_626_1540763382.1448289666038--
------=_Part_625_1576669658.1448289666037--
.
Author: Sean Middleditch <sean.middleditch@gmail.com>
Date: Mon, 23 Nov 2015 09:05:28 -0800 (PST)
Raw View
------=_Part_268_685560010.1448298328971
Content-Type: multipart/alternative;
boundary="----=_Part_269_1113025328.1448298328971"
------=_Part_269_1113025328.1448298328971
Content-Type: text/plain; charset=UTF-8
On Monday, November 23, 2015 at 6:41:06 AM UTC-8, Nicol Bolas wrote:
>
> On Monday, November 23, 2015 at 5:50:06 AM UTC-5, Hannes wrote:
>>
>> On Monday, November 23, 2015 at 3:54:27 AM UTC+1, Nicol Bolas wrote:
>>>
>>>
>>> Or... we could avoid solving any of those problems and just make
>>> designated initialization a form of aggregate initialization.
>>>
>>
>> Yeah, I feel like that would be the simplest way to go now. Essentially
>> making designated initialization syntactically equivalent to a (non-array)
>> aggregate initialization where the ordering of keys is flexible and
>> maintain the same C++14 behaviour as aggregate initialization for
>> non-specified fields (default initialization).
>>
>> That would be useful enough IMO and very easy to explain to people. "Oh,
>> it's just aggregate initialization with some extra syntactic sugar."
>>
>
> There are three areas of concern when it comes to designated initializers
> in C++, which have to do with C++-specific features.
>
> The first is base class member initialization. I think the best way to
> handle it syntactically is like this:
>
> { .base_class = {.mem1 = 5, .mem2 = {init}}, .outer1 = {1, 2, 3} };
>
> That is, each class level gets its own initializer list. I think this is
> cleaner than doing `.base_class.mem1`, and it avoids the issue of classes
> in the hierarchy with the same name. It also makes it clear that you're
> setting members in a subobject.
>
What about base initializes for:
struct derived : base<int>, base<float> { ... };
You can't use the base type's name anymore as a disambiguator. Would the
initializer specification have to allow specifying the template
specialization?
Does the base initialization support aliased names?
>
> Oh, and it allows you to initialize subobjects of the main class as you
> see fit. We could have initialized `.base_class` without naming its
> members, for example.
>
> There is a downside to this approach. That downside is due to the second
> issue: how designated initializers interact with non-designated
> initializers in the same braced-init-list.
>
> If you have this:
>
> {3, "string", .member = 12};
>
> How does that work? Do we initialize all of the designated members first,
> then order the rest and initialize them if they were not initialized? How
> does that interact with base class members?
>
I would imagine it would work identically to defaulted function parameters
- they're just call-sight syntactical helpers and have no effect on the
callee's code at all.
Relatedly, think of constructors. A syntax that only works for initializing
a type with public members is not _that_ useful (though it's certainly not
useless). I think that we need to solve named parameters first (preferably
IMO using a similar syntax to C99's designated initializers) so that you
can use the exact same syntax for initializing a simple type as you do for
initializing a class with user-defined constructors.
I say that requires the default arguments solution because initializing a
class with constructors requires letting a class designer mark a
constructor's parameter names as being part of the API (because we
certainly don't want to do that always!), which is 99.98% the remaining
major design problem with named function parameters.
I'm currently a fan of just using the .name syntax in both the declaration
and call-site, which keeps syntactical parity with C99 designated
initializers, but there's still some hairier corners of C++ I haven't
thought through fully yet, so I'm not sure if that approach works.
It'd be "nice" IMO though to get:
(a) function(.foo = 1, .bar = "gaz"); // invoke a function
(b) constructor{.foo = 1, .bar = "gaz"); // construct a temporary
(c) type name = {.foo = 1, .bar = "gaz"}; // initialize a local
(d) void declaration(int .foo, string .bar); // declare a
function/constructor
I'm still rolling it around in my head, though.
> I don't know much about designated initializers in C, so how do they
> handle it?
>
> The third issue is overloading. Consider the following code:
>
Overloading is indeed the tricky bit that needs a lot of careful thought
and study from anyone planning to actually propose any of this.
--
---
You received this message because you are subscribed to the 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_269_1113025328.1448298328971
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, November 23, 2015 at 6:41:06 AM UTC-8, Nicol Bolas wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">On Monday, November 23, 2015 at 5:50:=
06 AM UTC-5, Hannes wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">On Monday, November 23, 2015 at 3:54:27 AM UTC+1, Nicol Bolas wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>Or... w=
e could avoid solving any of those problems and just make designated initia=
lization a form of aggregate initialization.<br></div></div></blockquote><d=
iv><br></div><div>Yeah, I feel like that would be the simplest way to go no=
w. Essentially making designated initialization syntactically equivalent to=
a (non-array) aggregate initialization where the ordering of keys is flexi=
ble and maintain the same C++14=C2=A0behaviour as aggregate initialization =
for non-specified fields (default initialization).</div><div><br></div><div=
>That would be useful enough IMO and very easy to explain to people. "=
Oh, it's just aggregate initialization with some extra syntactic sugar.=
"</div></div></blockquote><div><br>There are three areas of concern wh=
en it comes to designated initializers in C++, which have to do with C++-sp=
ecific features.<br><br>The first is base class member initialization. I th=
ink the best way to handle it syntactically is like this:<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:#660">{</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">.</span><span style=3D"color:#000">base_class </span><span style=
=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D=
"color:#660">{.</span><span style=3D"color:#000">mem1 </span><span style=3D=
"color:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D"co=
lor:#066">5</span><span style=3D"color:#660">,</span><span style=3D"color:#=
000"> </span><span style=3D"color:#660">.</span><span style=3D"color:#000">=
mem2 </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"=
> </span><span style=3D"color:#660">{</span><span style=3D"color:#000">init=
</span><span style=3D"color:#660">}},</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#660">.</span><span style=3D"color:#000">outer1 </=
span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#660">{</span><span style=3D"color:#066">1</span><sp=
an style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#066">2</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> </span><span style=3D"color:#066">3</span><span style=3D"c=
olor:#660">}</span><span style=3D"color:#000"> </span><span style=3D"color:=
#660">};</span></div></code></div><br>That is, each class level gets its ow=
n initializer list. I think this is cleaner than doing `.base_class.mem1`, =
and it avoids the issue of classes in the hierarchy with the same name. It =
also makes it clear that you're setting members in a subobject.<br></di=
v></blockquote><div><br></div><div>What about base initializes for:</div><d=
iv><br></div><div>=C2=A0 struct derived : base<int>, base<float>=
; { ... };</div><div><br></div><div>You can't use the base type's n=
ame anymore as a disambiguator. Would the initializer specification have to=
allow specifying the template specialization?</div><div><br></div><div>Doe=
s the base initialization support aliased names?</div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div><br>Oh, and it allows you to =
initialize subobjects of the main class as you see fit. We could have initi=
alized `.base_class` without naming its members, for example.<br><br>There =
is a downside to this approach. That downside is due to the second issue: h=
ow designated initializers interact with non-designated initializers in the=
same braced-init-list.<br><br>If you have this:<br><br><div style=3D"backg=
round-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:sol=
id;border-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#=
660">{</span><span style=3D"color:#066">3</span><span style=3D"color:#660">=
,</span><span style=3D"color:#000"> </span><span style=3D"color:#080">"=
;string"</span><span style=3D"color:#660">,</span><span style=3D"color=
:#000"> </span><span style=3D"color:#660">.</span><span style=3D"color:#000=
">member </span><span style=3D"color:#660">=3D</span><span style=3D"color:#=
000"> </span><span style=3D"color:#066">12</span><span style=3D"color:#660"=
>};</span></div></code></div><br>How does that work? Do we initialize all o=
f the designated members first, then order the rest and initialize them if =
they were not initialized? How does that interact with base class members?<=
br></div></blockquote><div><br></div><div>I would imagine it would work ide=
ntically to defaulted function parameters - they're just call-sight syn=
tactical helpers and have no effect on the callee's code at all.</div><=
div><br></div><div>Relatedly, think of constructors. A syntax that only wor=
ks for initializing a type with public members is not _that_ useful (though=
it's certainly not useless). I think that we need to solve named param=
eters first (preferably IMO using a similar syntax to C99's designated =
initializers) so that you can use the exact same syntax for initializing a =
simple type as you do for initializing a class with user-defined constructo=
rs.</div><div><br></div><div>I say that requires the default arguments solu=
tion because initializing a class with constructors requires letting a clas=
s designer mark a constructor's parameter names as being part of the AP=
I (because we certainly don't want to do that always!), which is 99.98%=
the remaining major design problem with named function parameters.</div><d=
iv><br></div><div>I'm currently a fan of just using the .name syntax in=
both the declaration and call-site, which keeps syntactical parity with C9=
9 designated initializers, but there's still some hairier corners of C+=
+ I haven't thought through fully yet, so I'm not sure if that appr=
oach works.</div><div><br></div><div>It'd be "nice" IMO thoug=
h to get:</div><div><br></div><div>(a) function(.foo =3D 1, .bar =3D "=
gaz"); // invoke a function</div><div>(b) constructor{.foo =3D 1, .bar=
=3D "gaz"); // construct a temporary</div><div>(c) type name =3D=
{.foo =3D 1, .bar =3D "gaz"}; // initialize a local</div><div>(d=
) void declaration(int .foo, string .bar); // declare a function/constructo=
r</div><div>=C2=A0</div><div>I'm still rolling it around in my head, th=
ough.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
><br>I don't know much about designated initializers in C, so how do th=
ey handle it?<br><br>The third issue is overloading. Consider the following=
code:<br></div></blockquote><div><br></div><div>Overloading is indeed the =
tricky bit that needs a lot of careful thought and study from anyone planni=
ng to actually propose any of this.</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_269_1113025328.1448298328971--
------=_Part_268_685560010.1448298328971--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 23 Nov 2015 11:04:20 -0800 (PST)
Raw View
------=_Part_5588_1903230112.1448305460497
Content-Type: multipart/alternative;
boundary="----=_Part_5589_508329734.1448305460498"
------=_Part_5589_508329734.1448305460498
Content-Type: text/plain; charset=UTF-8
On Monday, November 23, 2015 at 12:05:29 PM UTC-5, Sean Middleditch wrote:
>
> On Monday, November 23, 2015 at 6:41:06 AM UTC-8, Nicol Bolas wrote:
>>
>> On Monday, November 23, 2015 at 5:50:06 AM UTC-5, Hannes wrote:
>>>
>>> On Monday, November 23, 2015 at 3:54:27 AM UTC+1, Nicol Bolas wrote:
>>>>
>>>>
>>>> Or... we could avoid solving any of those problems and just make
>>>> designated initialization a form of aggregate initialization.
>>>>
>>>
>>> Yeah, I feel like that would be the simplest way to go now. Essentially
>>> making designated initialization syntactically equivalent to a (non-array)
>>> aggregate initialization where the ordering of keys is flexible and
>>> maintain the same C++14 behaviour as aggregate initialization for
>>> non-specified fields (default initialization).
>>>
>>> That would be useful enough IMO and very easy to explain to people. "Oh,
>>> it's just aggregate initialization with some extra syntactic sugar."
>>>
>>
>> There are three areas of concern when it comes to designated initializers
>> in C++, which have to do with C++-specific features.
>>
>> The first is base class member initialization. I think the best way to
>> handle it syntactically is like this:
>>
>> { .base_class = {.mem1 = 5, .mem2 = {init}}, .outer1 = {1, 2, 3} };
>>
>> That is, each class level gets its own initializer list. I think this is
>> cleaner than doing `.base_class.mem1`, and it avoids the issue of classes
>> in the hierarchy with the same name. It also makes it clear that you're
>> setting members in a subobject.
>>
>
> What about base initializes for:
>
> struct derived : base<int>, base<float> { ... };
>
> You can't use the base type's name anymore as a disambiguator. Would the
> initializer specification have to allow specifying the template
> specialization?
>
The type names for the base classes are `base<int>` and `base<float>`.
`base` itself is not a typename; it's the name of a template.
> Relatedly, think of constructors. A syntax that only works for
> initializing a type with public members is not _that_ useful (though it's
> certainly not useless). I think that we need to solve named parameters
> first (preferably IMO using a similar syntax to C99's designated
> initializers) so that you can use the exact same syntax for initializing a
> simple type as you do for initializing a class with user-defined
> constructors.
>
Perfect is the enemy of good. I don't see a *need* to make designated
initializers dependent on general named parameter solutions.
Besides, the committee seems to hate named parameters on general principle.
And there will be general resistance to designated initializers out of
fears that it will lead to de-facto named parameter usage by using structs
and designated initializers.
Our goal should be to avoid giving them that impression.
Also, we could add wording to allow brace elision to save you:
class SomeType
{
public:
struct ConstructorFields{ int foo; vector<int> bar; float def = 42.0f}
SomeType(ConstructorFields cf);
SomeType(int i);
private:
};
SomeType t = {.foo = 4, .bar = {1, 2, 3}};
Adding another set of braces would have allowed this to work. We just need
wording to make those braces unnecessary, if the braced-init-list doesn't
match up with `SomeType`'s argument list, but it does match up with one of
the single-argument constructors. And designated initializers by definition
cannot call a constructor, so they never match.
Then again, we could just make people use double braces, relying on
existing brace elision rules to get rid of them:
SomeType t1 = {{5}}; //Calls single integer constructor.
SomeType t2 = {{.foo = 4, .bar = {1, 2, 3}}}; //Calls named parameter
constructor.
--
---
You received this message because you are subscribed to the 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_5589_508329734.1448305460498
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, November 23, 2015 at 12:05:29 PM UTC-5, Sean Middleditch wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">On Monday, November 23, 2015 at=
6:41:06 AM UTC-8, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
">On Monday, November 23, 2015 at 5:50:06 AM UTC-5, Hannes wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr">On Monday, November 23, 2015=
at 3:54:27 AM UTC+1, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div><br>Or... we could avoid solving any of those pr=
oblems and just make designated initialization a form of aggregate initiali=
zation.<br></div></div></blockquote><div><br></div><div>Yeah, I feel like t=
hat would be the simplest way to go now. Essentially making designated init=
ialization syntactically equivalent to a (non-array) aggregate initializati=
on where the ordering of keys is flexible and maintain the same C++14=C2=A0=
behaviour as aggregate initialization for non-specified fields (default ini=
tialization).</div><div><br></div><div>That would be useful enough IMO and =
very easy to explain to people. "Oh, it's just aggregate initializ=
ation with some extra syntactic sugar."</div></div></blockquote><div><=
br>There are three areas of concern when it comes to designated initializer=
s in C++, which have to do with C++-specific features.<br><br>The first is =
base class member initialization. I think the best way to handle it syntact=
ically is like this:<br><br><div style=3D"background-color:rgb(250,250,250)=
;border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wra=
p:break-word"><code><div><span style=3D"color:#660">{</span><span style=3D"=
color:#000"> </span><span style=3D"color:#660">.</span><span style=3D"color=
:#000">base_class </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">{.</span><span style=3D"=
color:#000">mem1 </span><span style=3D"color:#660">=3D</span><span style=3D=
"color:#000"> </span><span style=3D"color:#066">5</span><span style=3D"colo=
r:#660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#66=
0">.</span><span style=3D"color:#000">mem2 </span><span style=3D"color:#660=
">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{=
</span><span style=3D"color:#000">init</span><span style=3D"color:#660">}},=
</span><span style=3D"color:#000"> </span><span style=3D"color:#660">.</spa=
n><span style=3D"color:#000">outer1 </span><span style=3D"color:#660">=3D</=
span><span style=3D"color:#000"> </span><span style=3D"color:#660">{</span>=
<span style=3D"color:#066">1</span><span style=3D"color:#660">,</span><span=
style=3D"color:#000"> </span><span style=3D"color:#066">2</span><span styl=
e=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"=
color:#066">3</span><span style=3D"color:#660">}</span><span style=3D"color=
:#000"> </span><span style=3D"color:#660">};</span></div></code></div><br>T=
hat is, each class level gets its own initializer list. I think this is cle=
aner than doing `.base_class.mem1`, and it avoids the issue of classes in t=
he hierarchy with the same name. It also makes it clear that you're set=
ting members in a subobject.<br></div></blockquote><div><br></div><div>What=
about base initializes for:</div><div><br></div><div>=C2=A0 struct derived=
: base<int>, base<float> { ... };</div><div><br></div><div>You=
can't use the base type's name anymore as a disambiguator. Would t=
he initializer specification have to allow specifying the template speciali=
zation?</div></blockquote><div><br>The type names for the base classes are =
`base<int>` and `base<float>`. `base` itself is not a typename;=
it's the name of a template.<br></div><div>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div></div><div>Relatedly, think of construct=
ors. A syntax that only works for initializing a type with public members i=
s not _that_ useful (though it's certainly not useless). I think that w=
e need to solve named parameters first (preferably IMO using a similar synt=
ax to C99's designated initializers) so that you can use the exact same=
syntax for initializing a simple type as you do for initializing a class w=
ith user-defined constructors.</div></blockquote><div><br>Perfect is the en=
emy of good. I don't see a <i>need</i> to make designated initializers =
dependent on general named parameter solutions.<br><br>Besides, the committ=
ee seems to hate named parameters on general principle. And there will be g=
eneral resistance to designated initializers out of fears that it will lead=
to de-facto named parameter usage by using structs and designated initiali=
zers.<br><br>Our goal should be to avoid giving them that impression.<br><b=
r>Also, we could add wording to allow brace elision to save you:<br><br><di=
v class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bord=
er-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-=
wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint=
"><span style=3D"color: #008;" class=3D"styled-by-prettify">class</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">SomeType</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">public</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">struct</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettif=
y">ConstructorFields</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: #008;" class=3D"styled-by-prettify">int</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> vector</span><span style=3D=
"color: #080;" class=3D"styled-by-prettify"><int></span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> bar</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">float</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">def</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #066;" class=3D"styled-by-prettify">42.0f</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"col=
or: #606;" class=3D"styled-by-prettify">SomeType</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #606;" =
class=3D"styled-by-prettify">ConstructorFields</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> cf</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 </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">SomeType</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> i</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">private</s=
pan><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><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color:=
#606;" class=3D"styled-by-prettify">SomeType</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> t </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">{.</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">foo </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">4</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">bar </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">=3D</span><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: #066;" class=3D"styled-by-prettify">1</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #066;" class=3D"styled-by-prettify">2</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"style=
d-by-prettify">3</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">}};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span></div></code></div><br>Adding another set of braces would have al=
lowed this to work. We just need wording to make those braces unnecessary, =
if the braced-init-list doesn't match up with `SomeType`'s argument=
list, but it does match up with one of the single-argument constructors. A=
nd designated initializers by definition cannot call a constructor, so they=
never match.<br><br>Then again, we could just make people use double brace=
s, relying on existing brace elision rules to get rid of them:<br><br><div =
class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border=
-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wr=
ap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #606;" class=3D"styled-by-prettify">SomeType</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> t1 </span><span st=
yle=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: #6=
60;" class=3D"styled-by-prettify">{{</span><span style=3D"color: #066;" cla=
ss=3D"styled-by-prettify">5</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">}};</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>//Calls single integer constructor.</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">SomeType</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> t2 </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{{.<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">foo </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #066;" class=3D"styled-by-prettify">4</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">bar </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: #660;" class=3D"styled-by-prettify">{</span><span st=
yle=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=3D"co=
lor: #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">2</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">3</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">}}};</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">//Calls named parameter con=
structor.</span></div></code></div><br><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"></blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_5589_508329734.1448305460498--
------=_Part_5588_1903230112.1448305460497--
.
Author: Hannes Landeholm <landeholm@gmail.com>
Date: Mon, 23 Nov 2015 20:14:20 +0100
Raw View
--001a114b2e60426dda05253a0865
Content-Type: text/plain; charset=UTF-8
On 23 November 2015 at 15:41, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> There are three areas of concern when it comes to designated initializers
> in C++, which have to do with C++-specific features.
>
> The first is base class member initialization. I think the best way to
> handle it syntactically is like this:
>
> { .base_class = {.mem1 = 5, .mem2 = {init}}, .outer1 = {1, 2, 3} };
>
> That is, each class level gets its own initializer list. I think this is
> cleaner than doing `.base_class.mem1`, and it avoids the issue of classes
> in the hierarchy with the same name. It also makes it clear that you're
> setting members in a subobject.
>
> Oh, and it allows you to initialize subobjects of the main class as you
> see fit. We could have initialized `.base_class` without naming its
> members, for example.
>
> There is a downside to this approach. That downside is due to the second
> issue: how designated initializers interact with non-designated
> initializers in the same braced-init-list.
>
> If you have this:
>
> {3, "string", .member = 12};
>
> How does that work? Do we initialize all of the designated members first,
> then order the rest and initialize them if they were not initialized? How
> does that interact with base class members?
>
> I don't know much about designated initializers in C, so how do they
> handle it?
>
Per http://www.compsci.hunter.cuny.edu/~sweiss/resources/c11standard.pdf,
6.7.9 Initialization:
17 Each brace-enclosed initializer list has an associated current object.
> When no designations are present, subobjects of the current object are
> initialized in order according to the type of the current object: array
> elements in increasing subscript order, structure members in declaration
> order, and the first named member of a union.148) In contrast, a
> designation causes the following initializer to begin initialization of the
> subobject described by the designator. Initialization then continues
> forward in order, beginning with the next subobject after that described by
> the designator.149)
>
> 18 Each designator list begins its description with the current object
> associated with the closest surrounding brace pair. Each item in the
> designator list (in order) specifies a particular member of its current
> object and changes the current object for the next designator (if any) to
> be that member.150) The current object that results at the end of the
> designator list is the subobject to be initialized by the following
> initializer.
>
> 19 The initialization shall occur in initializer list order, each
> initializer provided for a particular subobject overriding any previously
> listed initializer for the same subobject;151) all subobjects that are not
> initialized explicitly shall be initialized implicitly the same as objects
> that have static storage duration.
Essentially C has a "current object" that starts at the first declared
member of a struct or the first named member of a union. The "current
object" is then incremented forward for each non-designated item in the
initialization list. In contrast, a designated item overrides that "current
object". If this cases a member to be initialized twice it is well defined
per (19) that the later initializer overrides the previous one even though
a later rule states that the evaluation order of the statements are
undefined (23).
However compilers prints a warning if you are overriding previously
initialized fields (clang: -Winitializer-overrides) so this is likely
frowned upon even if it's well defined behaviour. I don't see any benefit
in having C++ support this.
--
---
You received this message because you are subscribed to the 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/.
--001a114b2e60426dda05253a0865
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 23 November 2015 at 15:41, Nicol Bolas <span dir=3D"ltr"><<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></=
span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><div>There are three areas of concern when it =
comes to designated initializers in C++, which have to do with C++-specific=
features.<br><br>The first is base class member initialization. I think th=
e best way to handle it syntactically is like this:<br><br><div style=3D"bo=
rder:1px solid rgb(187,187,187);word-wrap:break-word;background-color:rgb(2=
50,250,250)"><code><div><span style=3D"color:rgb(102,102,0)">{</span><span =
style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">.</=
span><span style=3D"color:rgb(0,0,0)">base_class </span><span style=3D"colo=
r:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> </span><span =
style=3D"color:rgb(102,102,0)">{.</span><span style=3D"color:rgb(0,0,0)">me=
m1 </span><span style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"col=
or:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,102,102)">5</span><span s=
tyle=3D"color:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> </s=
pan><span style=3D"color:rgb(102,102,0)">.</span><span style=3D"color:rgb(0=
,0,0)">mem2 </span><span style=3D"color:rgb(102,102,0)">=3D</span><span sty=
le=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">{</spa=
n><span style=3D"color:rgb(0,0,0)">init</span><span style=3D"color:rgb(102,=
102,0)">}},</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"c=
olor:rgb(102,102,0)">.</span><span style=3D"color:rgb(0,0,0)">outer1 </span=
><span style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,=
0,0)"> </span><span style=3D"color:rgb(102,102,0)">{</span><span style=3D"c=
olor:rgb(0,102,102)">1</span><span style=3D"color:rgb(102,102,0)">,</span><=
span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,102,102)=
">2</span><span style=3D"color:rgb(102,102,0)">,</span><span style=3D"color=
:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,102,102)">3</span><span sty=
le=3D"color:rgb(102,102,0)">}</span><span style=3D"color:rgb(0,0,0)"> </spa=
n><span style=3D"color:rgb(102,102,0)">};</span></div></code></div><br>That=
is, each class level gets its own initializer list. I think this is cleane=
r than doing `.base_class.mem1`, and it avoids the issue of classes in the =
hierarchy with the same name. It also makes it clear that you're settin=
g members in a subobject.<br><br>Oh, and it allows you to initialize subobj=
ects of the main class as you see fit. We could have initialized `.base_cla=
ss` without naming its members, for example.<br><br>There is a downside to =
this approach. That downside is due to the second issue: how designated ini=
tializers interact with non-designated initializers in the same braced-init=
-list.<br><br>If you have this:<br><br><div style=3D"border:1px solid rgb(1=
87,187,187);word-wrap:break-word;background-color:rgb(250,250,250)"><code><=
div><span style=3D"color:rgb(102,102,0)">{</span><span style=3D"color:rgb(0=
,102,102)">3</span><span style=3D"color:rgb(102,102,0)">,</span><span style=
=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,136,0)">"stri=
ng"</span><span style=3D"color:rgb(102,102,0)">,</span><span style=3D"=
color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">.</span><spa=
n style=3D"color:rgb(0,0,0)">member </span><span style=3D"color:rgb(102,102=
,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"colo=
r:rgb(0,102,102)">12</span><span style=3D"color:rgb(102,102,0)">};</span></=
div></code></div><br>How does that work? Do we initialize all of the design=
ated members first, then order the rest and initialize them if they were no=
t initialized? How does that interact with base class members?<br><br>I don=
't know much about designated initializers in C, so how do they handle =
it?<br></div></blockquote><div><br></div><div><br></div><div>Per=C2=A0<a hr=
ef=3D"http://www.compsci.hunter.cuny.edu/~sweiss/resources/c11standard.pdf"=
target=3D"_blank">http://www.compsci.hunter.cuny.edu/~sweiss/resources/c11=
standard.pdf</a>, 6.7.9 Initialization:<br></div><div><br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:=
1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left=
:1ex">17 Each brace-enclosed initializer list has an associated current obj=
ect. When no designations are present, subobjects of the current object are=
initialized in order according to the type of the current object: array el=
ements in increasing subscript order, structure members in declaration orde=
r, and the first named member of a union.148) In contrast, a designation ca=
uses the following initializer to begin initialization of the subobject des=
cribed by the designator. Initialization then continues forward in order, b=
eginning with the next subobject after that described by the designator.149=
)<br><br>18 Each designator list begins its description with the current ob=
ject associated with the closest surrounding brace pair. Each item in the d=
esignator list (in order) specifies a particular member of its current obje=
ct and changes the current object for the next designator (if any) to be th=
at member.150) The current object that results at the end of the designator=
list is the subobject to be initialized by the following initializer.=C2=
=A0<br><br>19 The initialization shall occur in initializer list order, eac=
h initializer provided for a particular subobject overriding any previously=
listed initializer for the same subobject;151) all subobjects that are not=
initialized explicitly shall be initialized implicitly the same as objects=
that have static storage duration.</blockquote><div><br></div><div>Essenti=
ally C has a "current object" that starts at the first declared m=
ember of a struct or the first named member of a union. The "current o=
bject" is then incremented forward for each non-designated item in the=
initialization list. In contrast, a designated item overrides that "c=
urrent object". If this cases a member to be initialized twice it is w=
ell defined per (19) that the later initializer overrides the previous one =
even though a later rule states that the evaluation order of the statements=
are undefined (23).</div><div><br></div><div>However compilers prints a wa=
rning if you are overriding previously initialized fields (clang: -Winitial=
izer-overrides) so this is likely frowned upon even if it's well define=
d behaviour. I don't see any benefit in having C++ support this.</div>
<div><br></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--001a114b2e60426dda05253a0865--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 23 Nov 2015 21:17:24 +0200
Raw View
On 23 November 2015 at 21:04, Nicol Bolas <jmckesson@gmail.com> wrote:
> Besides, the committee seems to hate named parameters on general principle.
Correction: the committee has multiple times rejected proposals that don't work.
The parameter names in the library are unspecified, which means that none
of the proposals seen thus far would work with the library. Various aspiring
proposal authors continue to cite e.g. Common Lisp and Python as examples
where named parameters "just work". The difference there is three-fold:
1) in those languages, the library parameter names are well-specified
2) those languages do not suffer from preprocessor macros leaking into
the library implementation, whether standard library or not
3) library authors, even authors of non-standard libraries, have reservations
of having to start supporting stable names once the names become part
of the interface.
All proposals for named parameters have thus far failed to reconcile
those concerns,
regardless of the actual syntax they have proposed.
--
---
You received this message because you are subscribed to the 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/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 23 Nov 2015 12:33:58 -0800 (PST)
Raw View
------=_Part_1099_683761489.1448310838365
Content-Type: multipart/alternative;
boundary="----=_Part_1100_283387253.1448310838365"
------=_Part_1100_283387253.1448310838365
Content-Type: text/plain; charset=UTF-8
On Monday, November 23, 2015 at 2:14:21 PM UTC-5, Hannes Landeholm wrote:
>
>
> On 23 November 2015 at 15:41, Nicol Bolas <jmck...@gmail.com <javascript:>
> > wrote:
>>
>> There are three areas of concern when it comes to designated initializers
>> in C++, which have to do with C++-specific features.
>>
>> The first is base class member initialization. I think the best way to
>> handle it syntactically is like this:
>>
>> { .base_class = {.mem1 = 5, .mem2 = {init}}, .outer1 = {1, 2, 3} };
>>
>> That is, each class level gets its own initializer list. I think this is
>> cleaner than doing `.base_class.mem1`, and it avoids the issue of classes
>> in the hierarchy with the same name. It also makes it clear that you're
>> setting members in a subobject.
>>
>> Oh, and it allows you to initialize subobjects of the main class as you
>> see fit. We could have initialized `.base_class` without naming its
>> members, for example.
>>
>> There is a downside to this approach. That downside is due to the second
>> issue: how designated initializers interact with non-designated
>> initializers in the same braced-init-list.
>>
>> If you have this:
>>
>> {3, "string", .member = 12};
>>
>> How does that work? Do we initialize all of the designated members first,
>> then order the rest and initialize them if they were not initialized? How
>> does that interact with base class members?
>>
>> I don't know much about designated initializers in C, so how do they
>> handle it?
>>
>
>
> Per http://www.compsci.hunter.cuny.edu/~sweiss/resources/c11standard.pdf,
> 6.7.9 Initialization:
>
> 17 Each brace-enclosed initializer list has an associated current object.
>> When no designations are present, subobjects of the current object are
>> initialized in order according to the type of the current object: array
>> elements in increasing subscript order, structure members in declaration
>> order, and the first named member of a union.148) In contrast, a
>> designation causes the following initializer to begin initialization of the
>> subobject described by the designator. Initialization then continues
>> forward in order, beginning with the next subobject after that described by
>> the designator.149)
>>
>> 18 Each designator list begins its description with the current object
>> associated with the closest surrounding brace pair. Each item in the
>> designator list (in order) specifies a particular member of its current
>> object and changes the current object for the next designator (if any) to
>> be that member.150) The current object that results at the end of the
>> designator list is the subobject to be initialized by the following
>> initializer.
>>
>> 19 The initialization shall occur in initializer list order, each
>> initializer provided for a particular subobject overriding any previously
>> listed initializer for the same subobject;151) all subobjects that are not
>> initialized explicitly shall be initialized implicitly the same as objects
>> that have static storage duration.
>
>
> Essentially C has a "current object" that starts at the first declared
> member of a struct or the first named member of a union. The "current
> object" is then incremented forward for each non-designated item in the
> initialization list. In contrast, a designated item overrides that "current
> object". If this cases a member to be initialized twice it is well defined
> per (19) that the later initializer overrides the previous one even though
> a later rule states that the evaluation order of the statements are
> undefined (23).
>
> However compilers prints a warning if you are overriding previously
> initialized fields (clang: -Winitializer-overrides) so this is likely
> frowned upon even if it's well defined behaviour. I don't see any benefit
> in having C++ support this.
>
C++ most assuredly should make multiple initializations to the same field
be an error. That being said, I like the idea of the "current object"
increment. It makes it clear how designated initializers work with normal
aggregate initialization, as well as allowing default member initializers
to still work if you jump around them.
--
---
You received this message because you are subscribed to the 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_1100_283387253.1448310838365
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, November 23, 2015 at 2:14:21 PM UTC-5, Hannes Landeholm wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br><div c=
lass=3D"gmail_quote">On 23 November 2015 at 15:41, Nicol Bolas <span dir=3D=
"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"19kCv7c8BgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascri=
pt:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;">jmck...@gmail.com</a>></span> wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co=
lor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>There a=
re three areas of concern when it comes to designated initializers in C++, =
which have to do with C++-specific features.<br><br>The first is base class=
member initialization. I think the best way to handle it syntactically is =
like this:<br><br><div style=3D"border:1px solid rgb(187,187,187);word-wrap=
:break-word;background-color:rgb(250,250,250)"><code><div><span style=3D"co=
lor:rgb(102,102,0)">{</span><span style=3D"color:rgb(0,0,0)"> </span><span =
style=3D"color:rgb(102,102,0)">.</span><span style=3D"color:rgb(0,0,0)">bas=
e_class </span><span style=3D"color:rgb(102,102,0)">=3D</span><span style=
=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">{.</span=
><span style=3D"color:rgb(0,0,0)">mem1 </span><span style=3D"color:rgb(102,=
102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"c=
olor:rgb(0,102,102)">5</span><span style=3D"color:rgb(102,102,0)">,</span><=
span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)=
">.</span><span style=3D"color:rgb(0,0,0)">mem2 </span><span style=3D"color=
:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> </span><span s=
tyle=3D"color:rgb(102,102,0)">{</span><span style=3D"color:rgb(0,0,0)">init=
</span><span style=3D"color:rgb(102,102,0)">}},</span><span style=3D"color:=
rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">.</span><span styl=
e=3D"color:rgb(0,0,0)">outer1 </span><span style=3D"color:rgb(102,102,0)">=
=3D</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb=
(102,102,0)">{</span><span style=3D"color:rgb(0,102,102)">1</span><span sty=
le=3D"color:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> </spa=
n><span style=3D"color:rgb(0,102,102)">2</span><span style=3D"color:rgb(102=
,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"co=
lor:rgb(0,102,102)">3</span><span style=3D"color:rgb(102,102,0)">}</span><s=
pan style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)"=
>};</span></div></code></div><br>That is, each class level gets its own ini=
tializer list. I think this is cleaner than doing `.base_class.mem1`, and i=
t avoids the issue of classes in the hierarchy with the same name. It also =
makes it clear that you're setting members in a subobject.<br><br>Oh, a=
nd it allows you to initialize subobjects of the main class as you see fit.=
We could have initialized `.base_class` without naming its members, for ex=
ample.<br><br>There is a downside to this approach. That downside is due to=
the second issue: how designated initializers interact with non-designated=
initializers in the same braced-init-list.<br><br>If you have this:<br><br=
><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;backg=
round-color:rgb(250,250,250)"><code><div><span style=3D"color:rgb(102,102,0=
)">{</span><span style=3D"color:rgb(0,102,102)">3</span><span style=3D"colo=
r:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> </span><span st=
yle=3D"color:rgb(0,136,0)">"string"</span><span style=3D"color:rg=
b(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> </span><span style=
=3D"color:rgb(102,102,0)">.</span><span style=3D"color:rgb(0,0,0)">member <=
/span><span style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:r=
gb(0,0,0)"> </span><span style=3D"color:rgb(0,102,102)">12</span><span styl=
e=3D"color:rgb(102,102,0)">};</span></div></code></div><br>How does that wo=
rk? Do we initialize all of the designated members first, then order the re=
st and initialize them if they were not initialized? How does that interact=
with base class members?<br><br>I don't know much about designated ini=
tializers in C, so how do they handle it?<br></div></blockquote><div><br></=
div><div><br></div><div>Per=C2=A0<a href=3D"http://www.compsci.hunter.cuny.=
edu/~sweiss/resources/c11standard.pdf" target=3D"_blank" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fw=
ww.compsci.hunter.cuny.edu%2F~sweiss%2Fresources%2Fc11standard.pdf\46sa\75D=
\46sntz\0751\46usg\75AFQjCNFy4qbNChVsKSqFRwHl16qcatP_0g';return true;" =
onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.=
compsci.hunter.cuny.edu%2F~sweiss%2Fresources%2Fc11standard.pdf\46sa\75D\46=
sntz\0751\46usg\75AFQjCNFy4qbNChVsKSqFRwHl16qcatP_0g';return true;">htt=
p://www.compsci.hunter.<wbr>cuny.edu/~sweiss/resources/<wbr>c11standard.pdf=
</a>, 6.7.9 Initialization:<br></div><div><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">17 Eac=
h brace-enclosed initializer list has an associated current object. When no=
designations are present, subobjects of the current object are initialized=
in order according to the type of the current object: array elements in in=
creasing subscript order, structure members in declaration order, and the f=
irst named member of a union.148) In contrast, a designation causes the fol=
lowing initializer to begin initialization of the subobject described by th=
e designator. Initialization then continues forward in order, beginning wit=
h the next subobject after that described by the designator.149)<br><br>18 =
Each designator list begins its description with the current object associa=
ted with the closest surrounding brace pair. Each item in the designator li=
st (in order) specifies a particular member of its current object and chang=
es the current object for the next designator (if any) to be that member.15=
0) The current object that results at the end of the designator list is the=
subobject to be initialized by the following initializer.=C2=A0<br><br>19 =
The initialization shall occur in initializer list order, each initializer =
provided for a particular subobject overriding any previously listed initia=
lizer for the same subobject;151) all subobjects that are not initialized e=
xplicitly shall be initialized implicitly the same as objects that have sta=
tic storage duration.</blockquote><div><br></div><div>Essentially C has a &=
quot;current object" that starts at the first declared member of a str=
uct or the first named member of a union. The "current object" is=
then incremented forward for each non-designated item in the initializatio=
n list. In contrast, a designated item overrides that "current object&=
quot;. If this cases a member to be initialized twice it is well defined pe=
r (19) that the later initializer overrides the previous one even though a =
later rule states that the evaluation order of the statements are undefined=
(23).</div><div><br></div><div>However compilers prints a warning if you a=
re overriding previously initialized fields (clang: -Winitializer-overrides=
) so this is likely frowned upon even if it's well defined behaviour. I=
don't see any benefit in having C++ support this.</div>
</div></div></div></blockquote><div><br>C++ most assuredly should make mult=
iple initializations to the same field be an error. That being said, I like=
the idea of the "current object" increment. It makes it clear ho=
w designated initializers work with normal aggregate initialization, as wel=
l as allowing default member initializers to still work if you jump around =
them.<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" 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_1100_283387253.1448310838365--
------=_Part_1099_683761489.1448310838365--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 23 Nov 2015 12:34:27 -0800 (PST)
Raw View
------=_Part_5503_495297068.1448310867924
Content-Type: multipart/alternative;
boundary="----=_Part_5504_1937590043.1448310867924"
------=_Part_5504_1937590043.1448310867924
Content-Type: text/plain; charset=UTF-8
On Monday, November 23, 2015 at 2:17:27 PM UTC-5, Ville Voutilainen wrote:
>
> On 23 November 2015 at 21:04, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> > Besides, the committee seems to hate named parameters on general
> principle.
>
> Correction: the committee has multiple times rejected proposals that don't
> work.
> The parameter names in the library are unspecified, which means that none
> of the proposals seen thus far would work with the library. Various
> aspiring
> proposal authors continue to cite e.g. Common Lisp and Python as examples
> where named parameters "just work". The difference there is three-fold:
> 1) in those languages, the library parameter names are well-specified
> 2) those languages do not suffer from preprocessor macros leaking into
> the library implementation, whether standard library or not
> 3) library authors, even authors of non-standard libraries, have
> reservations
> of having to start supporting stable names once the names become part
> of the interface.
>
> All proposals for named parameters have thus far failed to reconcile
> those concerns,
> regardless of the actual syntax they have proposed.
>
Six on one hand, half-a-dozen on the other. Having named parameters means
parameter names are part of a function's interface. So if people are
against that, then they're against named parameters.
That being said, I cannot verify if any of the named parameter proposals
were ever opt-in. That is, that a function declaration had to use specific
syntax to allow itself to be used with named parameters. All of the ones I
found seem to assume that any function that gives its parameters names must
be callable with named parameters.
Requiring opt-in on a per-function basis would seem to satisfy #3: each
library author decides if they want to allow the use of named parameters
for each function. And if they do, then it is their responsibility to keep
the names legitimate.
#2 is hardly a fair concern to castigate named parameters over. Macro
leakage potentially hurts lots of things, from uses of user-defined
literals to many other features. Modules will do what can be done to
prevent this, but we shouldn't avoid features out of fear of what macro
leakage will cause.
--
---
You received this message because you are subscribed to the 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_5504_1937590043.1448310867924
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, November 23, 2015 at 2:17:27 PM UTC-5, Ville Voutilainen wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">On 23 November 2015 at 21:04, N=
icol Bolas <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"zGlT5OI8BgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javas=
cript:';return true;" onclick=3D"this.href=3D'javascript:';retu=
rn true;">jmck...@gmail.com</a>> wrote:
<br>> Besides, the committee seems to hate named parameters on general p=
rinciple.
<br>
<br>Correction: the committee has multiple times rejected proposals that do=
n't work.
<br>The parameter names in the library are unspecified, which means that no=
ne
<br>of the proposals seen thus far would work with the library. Various asp=
iring
<br>proposal authors continue to cite e.g. Common Lisp and Python as exampl=
es
<br>where named parameters "just work". The difference there is t=
hree-fold:
<br>1) in those languages, the library parameter names are well-specified
<br>2) those languages do not suffer from preprocessor macros leaking into
<br>the library implementation, whether standard library or not
<br>3) library authors, even authors of non-standard libraries, have reserv=
ations
<br>of having to start supporting stable names once the names become part
<br>of the interface.
<br>
<br>All proposals for named parameters have thus far failed to reconcile
<br>those concerns,
<br>regardless of the actual syntax they have proposed.
<br></blockquote><div><br>Six on one hand, half-a-dozen on the other. Havin=
g named parameters means parameter names are part of a function's inter=
face. So if people are against that, then they're against named paramet=
ers.<br><br>That being said, I cannot verify if any of the named parameter =
proposals were ever opt-in. That is, that a function declaration had to use=
specific syntax to allow itself to be used with named parameters. All of t=
he ones I found seem to assume that any function that gives its parameters =
names must be callable with named parameters.<br><br>Requiring opt-in on a =
per-function basis would seem to satisfy #3: each library author decides if=
they want to allow the use of named parameters for each function. And if t=
hey do, then it is their responsibility to keep the names legitimate.<br><b=
r>#2 is hardly a fair concern to castigate named parameters over. Macro lea=
kage potentially hurts lots of things, from uses of user-defined literals t=
o many other features. Modules will do what can be done to prevent this, bu=
t we shouldn't avoid features out of fear of what macro leakage will ca=
use.<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" 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_5504_1937590043.1448310867924--
------=_Part_5503_495297068.1448310867924--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 23 Nov 2015 15:33:52 -0800
Raw View
On Monday 23 November 2015 12:34:27 Nicol Bolas wrote:
> Six on one hand, half-a-dozen on the other. Having named parameters means
> parameter names are part of a function's interface. So if people are
> against that, then they're against named parameters.
They're against making the ugly parameters currently used for various reasons
become API.
Examples:
libstdc++:
basic_string(const basic_string& __str, size_type __pos,
size_type __n, const _Alloc& __a)
libc++:
basic_string(const basic_string& __str, size_type __pos, size_type __n =
npos,
const allocator_type& __a = allocator_type());
MSVC (Dinkumware):
basic_string(const _Myt& _Right, size_type _Roff, size_type _Count,
const _Alloc& _Al)
Note how all three implementations use names reserved to the compiler (double
underscore or underscore + capital) to avoid someone #define'ing them and
causing problems.
This code does not compile on Solaris:
int sun, mercury, venus, earth, mars, jupiter, saturn, uranus, neptune;
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the 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/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 23 Nov 2015 15:48:07 -0800
Raw View
On Monday 23 November 2015 20:14:20 Hannes Landeholm wrote:
> Essentially C has a "current object" that starts at the first declared
> member of a struct or the first named member of a union. The "current
> object" is then incremented forward for each non-designated item in the
> initialization list. In contrast, a designated item overrides that "current
> object". If this cases a member to be initialized twice it is well defined
> per (19) that the later initializer overrides the previous one even though
> a later rule states that the evaluation order of the statements are
> undefined (23).
That means in the following:
struct S { int i; };
struct S s = { .i = f(1), .i = f(2) };
It is undefined in which order the function f() will be called, but it will be
called twice and the value of s.i will be the result of f(2).
Since all types in C are POD, double assignment can be eliminated.
I believe it follows that using the object being initialised in the
initialiser list is undefined behaviour. That is:
struct T { int i, j; };
struct T s = { 1, f(s.i) };
Though I can't actually put my finger on what the cause of UB is. It could be
just reading from an uninitialised variable, which is just implementation-
defined behaviour up until C++14.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the 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/.
.
Author: Bryce Glover <randomdsdevel@gmail.com>
Date: Mon, 23 Nov 2015 18:59:30 -0500
Raw View
--Apple-Mail=_166AF26E-A476-4199-A064-BFA580D46B6A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Whoops, I gave my e-mail the wrong subject, thereby separating it from=
its intended target thread! Let=E2=80=99s try that again, shall we? =20
=E2=80=94=E2=80=89Bryce Glover
=E3=80=80=E2=80=89RandomDSdevel@gmail.com
> On Nov 23, 2015, at 5:37 PM, Bryce Glover <randomdsdevel@gmail.com> wrote=
:
>=20
>> On Nov 21, 2015, at 3:12 PM, std-proposals@isocpp.org <mailto:std-propos=
als@isocpp.org> wrote:
>>=20
>> std-proposals@isocpp.org <https://groups.google.com/a/isocpp.org/forum/?=
utm_source=3Ddigest&utm_medium=3Demail#!forum/std-proposals/topics> Google =
Groups <https://groups.google.com/a/isocpp.org/forum/?utm_source=3Ddigest&u=
tm_medium=3Demail/#!overview> <https://groups.google.com/a/isocpp.org/foru=
m/?utm_source=3Ddigest&utm_medium=3Demail/#!overview> =20
>> Topic digest <>
>> View all topics <https://groups.google.com/a/isocpp.org/forum/?utm_sourc=
e=3Ddigest&utm_medium=3Demail#!forum/std-proposals/topics>
>> Designated initializer list status? <x-msg://3/#group_thread_0> - 9 Upda=
tes
>> (snipped=E2=80=A6)
>> <>Designated initializer list status? <http://groups.google.com/a/=
isocpp.org/group/std-proposals/t/f3be47f4496485dc?utm_source=3Ddigest&utm_m=
edium=3Demail> =20
>> (snipped)
>> Nicol Bolas <jmckesson@gmail.com <mailto:jmckesson@gmail.com>>: Nov 21 0=
9:56AM -0800=20
>>=20
>> (snipped)
>> =E2=8B=AE
>>=20
>> I would also suggest that any such proposal not have "improve parity wit=
h=20
>> C" as its primary motivation (or in the case of the above, *only*=20
>> motivation). More convincing motivations should revolve around using it =
in=20
>> C++ code. What can you do with it that you can't do without it. The fact=
=20
>> that it's in C is a good way to prove that the idea works, but that alon=
e=20
>> is hardly sufficient motivation for a C++ feature.
>> =20
>> For example, there was a discussion awhile back about named parameters=
=20
>> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/3iegpTsMuT0/=
hgmDlYkWIgAJ <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/3i=
egpTsMuT0/hgmDlYkWIgAJ>>.=20
>> It lead to the revelation that, if you have designated initializers, you=
=20
>> can more or less get that. The function would take a single struct type,=
=20
>> and you would call it with `funcName({.param1 =3D X, .param2 =3D Y, etc}=
)`.=20
>> Naturally, they wanted to add language functionality to remove the paren=
s,=20
>> but that's unnecessary. The main point is to give people an easy way to=
=20
>> pass named parameters to a function, and designated initializers would=
=20
>> allow precisely that. =20
>>=20
>> =E2=8B=AE
>>=20
>> (snipped)
>> =E2=8B=AE
>>=20
>> (snipped)
>> Back to top <x-msg://3/#digest_top>
>> You received this digest because you're subscribed to updates for this g=
roup. You can change your settings on the group membership page <https://gr=
oups.google.com/a/isocpp.org/forum/?utm_source=3Ddigest&utm_medium=3Demail#=
!forum/std-proposals/join>.
>> To unsubscribe from this group and stop receiving emails from it send an=
email to std-proposals+unsubscribe@isocpp.org <mailto:std-proposals+unsubs=
cribe@isocpp.org>.
>=20
> Even though I=E2=80=99m only speaking about this from an end-user pe=
rspective, I agree with the points that Nicol Bolas made in the part of tha=
t e-mail of his which I quoted above. In particular, I agree that a formal=
proposal to add C99=E2=80=99s designated initializers into C++(17?) should=
dress the concerns that he raised in the first paragraph I quoted. One of=
the examples that this paper could use to indicate possible use cases coul=
d indeed be the one that he referenced in his second paragraph, but the pro=
posal=E2=80=99s author might also want to mention that, if I understand and=
remember correctly, there is already a workaround for this in the form of =
method chaining. That technique, however, seems to be a bit of kludge to m=
e, especially since it takes an entity emitted from an initial function cal=
l and performs one or more transformations on it using more functions when =
a programmer may really have intended to pass multiple arguments to a singl=
e function, thus avoiding the expenses involved in setting up and tearing d=
own multiple stack frames. =20
>=20
> =E2=80=94=E2=80=89Bryce Glover
> =E3=80=80=E2=80=89RandomDSdevel@gmail.com <mailto:RandomDSdevel@gmail.com=
>
--=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=_166AF26E-A476-4199-A064-BFA580D46B6A
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"">&n=
bsp; Whoops, I gave my e-mail the wrong subject, thereby separ=
ating it from its intended target thread! Let=E2=80=99s try that agai=
n, shall we? </div><div class=3D""><br class=3D""></div><div class=3D=
""><div class=3D"">=E2=80=94=E2=80=89Bryce Glover</div><div class=3D"">=E3=
=80=80=E2=80=89<a href=3D"mailto:RandomDSdevel@gmail.com" class=3D"">Random=
DSdevel@gmail.com</a></div></div><br class=3D""><div><blockquote type=3D"ci=
te" class=3D""><div class=3D"">On Nov 23, 2015, at 5:37 PM, Bryce Glover &l=
t;<a href=3D"mailto:randomdsdevel@gmail.com" class=3D"">randomdsdevel@gmail=
..com</a>> wrote:</div><br class=3D"Apple-interchange-newline"><div class=
=3D""><meta http-equiv=3D"Content-Type" content=3D"text/html charset=3Dutf-=
8" class=3D""><div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space=
; -webkit-line-break: after-white-space;" class=3D""><div class=3D""><block=
quote type=3D"cite" class=3D""><div class=3D"">On Nov 21, 2015, at 3:12 PM,=
<a href=3D"mailto:std-proposals@isocpp.org" class=3D"">std-proposals@isocp=
p.org</a> wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D=
"">
<div style=3D"border: 1px solid rgb(211, 211, 211); max-width: 850px; font-=
family: Arial, sans-serif;" class=3D"">
<div style=3D"background-color:#f5f5f5;padding:10px 20px" class=3D"">
<table cellpadding=3D"0" cellspacing=3D"0" style=3D"width:100%" class=
=3D"">
<tbody class=3D"">
<tr class=3D"">
<td style=3D"width:70%" class=3D"">
<span style=3D"font:18px/20px arial;color:#333333" class=3D"">
<a href=3D"https://groups.google.com/a/isocpp.org/forum/?utm_=
source=3Ddigest&utm_medium=3Demail#!forum/std-proposals/topics" style=
=3D"text-decoration:none; color:#333333" class=3D"">
std-proposals@isocpp.org</a>
</span>
</td>
<td style=3D"text-align:right;width:30%" class=3D"">
<span style=3D"font:20px/24px arial" class=3D""><a style=3D"col=
or:#dd4b39; text-decoration:none;" href=3D"https://groups.google.com/a/isoc=
pp.org/forum/?utm_source=3Ddigest&utm_medium=3Demail/#!overview" target=
=3D"_blank" class=3D"">Google Groups</a></span>
</td>
<td style=3D"width:32px;" class=3D"">
<a href=3D"https://groups.google.com/a/isocpp.org/forum/?utm_so=
urce=3Ddigest&utm_medium=3Demail/#!overview" target=3D"_blank" class=3D=
""><img style=3D"border:0;vertical-align:middle" src=3D"http://www.google.c=
om/images/icons/product/groups-32.png" class=3D""></a>
</td>
</tr>
</tbody>
</table>
</div>
<div style=3D"padding:20px; background-color: #f5f5f5;" class=3D"">
<div style=3D"font-family: arial; color: #222222; padding: 0px" class=3D"">
<a name=3D"digest_top" style=3D"font-size:21px;" class=3D"">
=20
=20
Topic digest
=20
</a><br class=3D"">
<span style=3D"font-size:11px" class=3D"">
<a style=3D"color:#1155cc;text-decoration:none" href=3D"https://groups.=
google.com/a/isocpp.org/forum/?utm_source=3Ddigest&utm_medium=3Demail#!=
forum/std-proposals/topics" class=3D"">View all topics</a>
</span>
</div>
<div style=3D"font: 13px/18px arial; color:#222222; padding: 0px; margin-bo=
ttom:30px" class=3D"">
<ul style=3D"margin-left:3px; padding-left:0px" class=3D"">
=20
<li class=3D"">
<a style=3D"color:#1155cc;text-decoration:none" href=3D"x-msg://3/#gr=
oup_thread_0" class=3D"">
Designated initializer list status?</a> -
<span style=3D"color:#777777" class=3D"">9 Updates</span></li></ul></=
div></div></div></div></blockquote><blockquote type=3D"cite" class=3D"">(sn=
ipped=E2=80=A6)<br class=3D""></blockquote><blockquote type=3D"cite" class=
=3D""><div style=3D"border: 1px solid rgb(211, 211, 211); max-width: 850px;=
font-family: Arial, sans-serif;" class=3D""><div style=3D"padding:20px; ba=
ckground-color: #f5f5f5;" class=3D""><div style=3D"font: 13px/18px arial; c=
olor:#222222; padding: 0px; margin-bottom:30px" class=3D""><ul style=3D"mar=
gin-left:3px; padding-left:0px" class=3D"">
=20
</ul>
</div>
=20
<a name=3D"group_thread_0" class=3D""></a>
<div style=3D"display:inline-block; font-family: arial; padding: 4px 0 5p=
x 0px;" class=3D"">
=20
<a target=3D"_blank" href=3D"http://groups.google.com/a/isocpp.org/grou=
p/std-proposals/t/f3be47f4496485dc?utm_source=3Ddigest&utm_medium=3Dema=
il" style=3D"font-size:21px; color:#1155CC; text-decoration:none" class=3D"=
">
Designated initializer list status?
</a>
=20
</div>
<table style=3D"border-collapse: collapse; width: 100%" class=3D"">
=20
<tbody class=3D""><tr class=3D""><td style=3D"background-color: rgb(2=
55, 255, 255); font-family: arial; padding: 10px 15px; border: 1px solid rg=
b(211, 211, 211);" class=3D""><font color=3D"#b1b0b0" class=3D""><span styl=
e=3D"font-size: 15px;" class=3D"">(snipped)</span></font></td></tr>
=20
<tr class=3D""><td style=3D"background-color: #FFFFFF; color:#2E2E2E;=
font-family: arial; padding:10px 15px; border:1px solid #d3d3d3;" class=3D=
"">
<span style=3D"color:#B1B0B0; font-size: 15px;" class=3D"">
Nicol Bolas <<a href=3D"mailto:jmckesson@gmail.com" class=3D""=
>jmckesson@gmail.com</a>>: Nov 21 09:56AM -0800
</span>
<br class=3D""><br class=3D"">(snipped)<br class=3D"">=E2=8B=AE<br =
class=3D""><br class=3D"">I would also suggest that any such proposal not h=
ave "improve parity with <br class=3D"">
C" as its primary motivation (or in the case of the above, *only* <br class=
=3D"">
motivation). More convincing motivations should revolve around using it in =
<br class=3D"">
C++ code. What can you do with it that you can't do without it. The fact <b=
r class=3D"">
that it's in C is a good way to prove that the idea works, but that alone <=
br class=3D"">
is hardly sufficient motivation for a C++ feature.<br class=3D"">
<br class=3D"">
For example, there was a discussion awhile back about named parameters <br =
class=3D"">
<<a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/3=
iegpTsMuT0/hgmDlYkWIgAJ" class=3D"">https://groups.google.com/a/isocpp.org/=
d/msg/std-proposals/3iegpTsMuT0/hgmDlYkWIgAJ</a>>. <br class=3D"">
It lead to the revelation that, if you have designated initializers, you <b=
r class=3D"">
can more or less get that. The function would take a single struct type, <b=
r class=3D"">
and you would call it with `funcName({.param1 =3D X, .param2 =3D Y, etc})`.=
<br class=3D"">
Naturally, they wanted to add language functionality to remove the parens, =
<br class=3D"">
but that's unnecessary. The main point is to give people an easy way to <br=
class=3D"">
pass named parameters to a function, and designated initializers would <br =
class=3D"">
allow precisely that. <br class=3D"">
<br class=3D"">=E2=8B=AE<br class=3D""><br class=3D"">(snipped)</td></tr>
=20
<tr class=3D""><td style=3D"background-color: rgb(255, 255, 255); fon=
t-family: arial; padding: 10px 15px; border: 1px solid rgb(211, 211, 211);"=
class=3D""><font color=3D"#b1b0b0" class=3D""><span style=3D"font-size: 15=
px;" class=3D"">=E2=8B=AE<br class=3D""><br class=3D"">(snipped)</span></fo=
nt></td></tr>
=20
</tbody></table>
<div style=3D"align:right; font-size:11px; margin-bottom: 40px; margin-to=
p:5px;" class=3D"">
<a style=3D"color:#1155cc;text-decoration:none" href=3D"x-msg://3/#dige=
st_top" class=3D"">Back to top</a></div></div><div style=3D"background-colo=
r: #f5f5f5;padding: 5px 20px;" class=3D""><table cellpadding=3D"0" cellspac=
ing=3D"0" style=3D"width:100%" class=3D"">
<tbody class=3D""><tr class=3D"">
<td style=3D"padding-top:4px;font-family:arial,sans-serif;color:#636363=
;font-size:11px" class=3D"">
=20
You received this digest because you're subscribed to updates for thi=
s group. You can change your settings on the <a href=3D"https://groups.goog=
le.com/a/isocpp.org/forum/?utm_source=3Ddigest&utm_medium=3Demail#!foru=
m/std-proposals/join" style=3D"color:#1155cc;text-decoration:none" class=3D=
"">group membership page</a>.<br class=3D"">
To unsubscribe from this group and stop receiving emails from it send=
an email to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" class=
=3D"">std-proposals+unsubscribe@isocpp.org</a>.
</td>
</tr></tbody>
</table>
</div>
</div>
</blockquote></div><br class=3D""><div class=3D""> Even =
though I=E2=80=99m only speaking about this from an end-user perspective, I=
agree with the points that Nicol Bolas made in the part of that e-mail of =
his which I quoted above. In particular, I agree that a formal propos=
al to add C99=E2=80=99s designated initializers into C++(17?) should dress =
the concerns that he raised in the first paragraph I quoted. One of t=
he examples that this paper could use to indicate possible use cases could =
indeed be the one that he referenced in his second paragraph, but the propo=
sal=E2=80=99s author might also want to mention that, if I understand and r=
emember correctly, there is already a workaround for this in the form of me=
thod chaining. That technique, however, seems to be a bit of kludge t=
o me, especially since it takes an entity emitted from an initial function =
call and performs one or more transformations on it using more functions wh=
en a programmer may really have intended to pass multiple arguments to a <i=
class=3D"">single</i> function, thus avoiding the expenses involved i=
n setting up and tearing down multiple stack frames. </div><div class=
=3D""><br class=3D"webkit-block-placeholder"></div><div apple-content-edite=
d=3D"true" class=3D"">
<div style=3D"letter-spacing: normal; orphans: auto; text-align: start; tex=
t-indent: 0px; text-transform: none; white-space: normal; widows: auto; wor=
d-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -web=
kit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=3D""><d=
iv style=3D"letter-spacing: normal; orphans: auto; text-align: start; text-=
indent: 0px; text-transform: none; white-space: normal; widows: auto; word-=
spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webki=
t-nbsp-mode: space; -webkit-line-break: after-white-space;" class=3D""><div=
class=3D"">=E2=80=94=E2=80=89Bryce Glover</div><div class=3D"">=E3=80=80=
=E2=80=89<a href=3D"mailto:RandomDSdevel@gmail.com" class=3D"">RandomDSdeve=
l@gmail.com</a></div></div></div></div></div></div></blockquote></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" 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=_166AF26E-A476-4199-A064-BFA580D46B6A--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 23 Nov 2015 19:47:38 -0800 (PST)
Raw View
------=_Part_3207_1939297602.1448336859056
Content-Type: multipart/alternative;
boundary="----=_Part_3208_890026841.1448336859056"
------=_Part_3208_890026841.1448336859056
Content-Type: text/plain; charset=UTF-8
On Monday, November 23, 2015 at 6:33:59 PM UTC-5, Thiago Macieira wrote:
>
> On Monday 23 November 2015 12:34:27 Nicol Bolas wrote:
> > Six on one hand, half-a-dozen on the other. Having named parameters
> means
> > parameter names are part of a function's interface. So if people are
> > against that, then they're against named parameters.
>
> They're against making the ugly parameters currently used for various
> reasons
> become API.
>
But as has been previously stated, the standard doesn't define those
parameter names. So they wouldn't be able to become part of the API. They
would be implementation defined, rather than standard defined.
And I'd point out that that nobody seems to be willing to stop concepts
from getting into C++17 just because it hasn't been applied to the standard
library.
But then again, the whole named parameters discussion is off-topic: this is
about designated initializers, which should not be conflated with named
parameters. After all, structure member names are already part of a
struct's API.
--
---
You received this message because you are subscribed to the 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_3208_890026841.1448336859056
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, November 23, 2015 at 6:33:59 PM UTC-5, Thiago M=
acieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Monday 23 Nov=
ember 2015 12:34:27 Nicol Bolas wrote:
<br>> Six on one hand, half-a-dozen on the other. Having named parameter=
s means=20
<br>> parameter names are part of a function's interface. So if peop=
le are=20
<br>> against that, then they're against named parameters.
<br>
<br>They're against making the ugly parameters currently used for vario=
us reasons=20
<br>become API.<br></blockquote><div><br>But as has been previously stated,=
the standard doesn't define those parameter names. So they wouldn'=
t be able to become part of the API. They would be implementation defined, =
rather than standard defined.<br><br>And I'd point out that that nobody=
seems to be willing to stop concepts from getting into C++17 just because =
it hasn't been applied to the standard library.<br><br>But then again, =
the whole named parameters discussion is off-topic: this is about designate=
d initializers, which should not be conflated with named parameters. After =
all, structure member names are already part of a struct's API.<br></di=
v></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_3208_890026841.1448336859056--
------=_Part_3207_1939297602.1448336859056--
.
Author: Sean Middleditch <sean.middleditch@gmail.com>
Date: Mon, 23 Nov 2015 20:03:32 -0800
Raw View
--001a114b3774ded7fd0525416cfb
Content-Type: text/plain; charset=UTF-8
On Nov 23, 2015 7:47 PM, "Nicol Bolas" <jmckesson@gmail.com> wrote:
>
> But then again, the whole named parameters discussion is off-topic: this
is about designated initializers, which should not be conflated with named
parameters. After all, structure member names are already part of a
struct's API.
They are intimately related because of constructors.
You can't have good C++-y designated initializers supporting user-designed
classes without dealing with constructor parameters and their names at some
level.
>
> --
>
> ---
> 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/875H9Elkhdw/unsubscribe
..
> To unsubscribe from this group and all its topics, send an email to
std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a114b3774ded7fd0525416cfb
Content-Type: text/html; charset=UTF-8
<p dir="ltr">On Nov 23, 2015 7:47 PM, "Nicol Bolas" <<a href="mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>> wrote:<br>
><br>
> But then again, the whole named parameters discussion is off-topic: this is about designated initializers, which should not be conflated with named parameters. After all, structure member names are already part of a struct's API.</p>
<p dir="ltr">They are intimately related because of constructors.</p>
<p dir="ltr">You can't have good C++-y designated initializers supporting user-designed classes without dealing with constructor parameters and their names at some level.</p>
<p dir="ltr">><br>
> -- <br>
><br>
> --- <br>
> You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this topic, visit <a href="https://groups.google.com/a/isocpp.org/d/topic/std-proposals/875H9Elkhdw/unsubscribe">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/875H9Elkhdw/unsubscribe</a>.<br>
> To unsubscribe from this group and all its topics, send an email to <a href="mailto:std-proposals%2Bunsubscribe@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>
</p>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an 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 />
--001a114b3774ded7fd0525416cfb--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 23 Nov 2015 20:47:47 -0800 (PST)
Raw View
------=_Part_6005_857769852.1448340467455
Content-Type: multipart/alternative;
boundary="----=_Part_6006_259701444.1448340467456"
------=_Part_6006_259701444.1448340467456
Content-Type: text/plain; charset=UTF-8
On Monday, November 23, 2015 at 11:03:35 PM UTC-5, Sean Middleditch wrote:
>
> On Nov 23, 2015 7:47 PM, "Nicol Bolas" <jmck...@gmail.com <javascript:>>
> wrote:
> >
> > But then again, the whole named parameters discussion is off-topic: this
> is about designated initializers, which should not be conflated with named
> parameters. After all, structure member names are already part of a
> struct's API.
>
> They are intimately related because of constructors.
>
> You can't have good C++-y designated initializers supporting user-designed
> classes without dealing with constructor parameters and their names at some
> level.
>
Why not? I already explained how to get the equivalent behavior without
having actual named parameters (have the type take a struct and use an
extra set of braces).
Designated initializers name fields in data structures, not parameters for
constructors. They're not the same thing, and I see no reason to hold up a
genuinely useful feature like designated initailizers just because it
doesn't cover a particular case as nicely as you would prefer.
--
---
You received this message because you are subscribed to the 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_6006_259701444.1448340467456
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Monday, November 23, 2015 at 11:03:35 PM UTC-5, Sean Middleditch=
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">On Nov 2=
3, 2015 7:47 PM, "Nicol Bolas" <<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"ELcM4phZBgAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hre=
f=3D'javascript:';return true;">jmck...@gmail.com</a>> wrote:<br=
>
><br>
> But then again, the whole named parameters discussion is off-topic: th=
is is about designated initializers, which should not be conflated with nam=
ed parameters. After all, structure member names are already part of a stru=
ct's API.</p>
<p dir=3D"ltr">They are intimately related because of constructors.</p>
<p dir=3D"ltr">You can't have good C++-y designated initializers suppor=
ting user-designed classes without dealing with constructor parameters and =
their names at some level.</p></blockquote><div><br>Why not? I already expl=
ained how to get the equivalent behavior without having actual named parame=
ters (have the type take a struct and use an extra set of braces).<br><br>D=
esignated initializers name fields in data structures, not parameters for c=
onstructors. They're not the same thing, and I see no reason to hold up=
a genuinely useful feature like designated initailizers just because it do=
esn't cover a particular case as nicely as you would prefer.<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" 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_6006_259701444.1448340467456--
------=_Part_6005_857769852.1448340467455--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 23 Nov 2015 20:54:14 -0800
Raw View
On Monday 23 November 2015 19:47:38 Nicol Bolas wrote:
> > They're against making the ugly parameters currently used for various
> > reasons
> > become API.
>
> But as has been previously stated, the standard doesn't define those
> parameter names. So they wouldn't be able to become part of the API. They
> would be implementation defined, rather than standard defined.
The standard doesn't define, but all implementations have parameter names for
at least every parameter that is actually used in inline implementations. If
the proposal for designated initialisers will not require an a specialised
syntax for parameter names, then the existing, ugly names will be available
for library users.
> And I'd point out that that nobody seems to be willing to stop concepts
> from getting into C++17 just because it hasn't been applied to the standard
> library.
That's only analogous to the case where designated initialisers for parameter
names requires a new syntax: until the library implementations "opt in" to the
parameter names, they can't be used.
> But then again, the whole named parameters discussion is off-topic: this is
> about designated initializers, which should not be conflated with named
> parameters. After all, structure member names are already part of a
> struct's API.
I consider this very much on topic. In C++, most useful aggregates have
constructors and unless we come up with a way for designating parameters to
constructors, designated initialisers will have a somewhat limited use for us.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the 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/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 23 Nov 2015 21:11:53 -0800
Raw View
On Monday 23 November 2015 20:47:47 Nicol Bolas wrote:
> Why not? I already explained how to get the equivalent behavior without
> having actual named parameters (have the type take a struct and use an
> extra set of braces).
It's not as efficient and is much more limited.
Suppose these two constructor examples:
struct S
{
S(int n);
S(int n, std::tuple<std::string, std::vector<int>> data);
};
vs
struct S
{
struct ConstructorArguments {
std::tuple<std::string, std::vector<int>> data;
int n;
};
S(ConstructorArguments);
};
The first thing to note is that we cannot create an overload, as otherwise
that would necessitate an ugly syntax specifying the structure type, as in:
S{(ConstructWithLength){ .n = 1 }};
S((ConstructWithLengthAndData){ .n = 1, .data = {"", {}}};
that is very C-like and C++-unlike.
The second thing is that, since we cannot create overloads, we conclude all
types in the constructor aggregates must be initialised before the constructor
itself is called. As the example shows, this makes it impossible to optimise
for a case where such a parameter isn't needed.
The third thing is that, with the lack of overloads, it's impossible to have
constructors with different behaviours. Think of these std::string
constructors:
basic_string(const value_type* s, size_type n, const allocator_type& a =
allocator_type());
basic_string(size_type n, value_type c, const allocator_type& a =
allocator_type());
The aggregate would need to contain both s and c, so how can the called
constructor know which of the two was actually intended to be used?
Finally, there's also the issue of efficiency for non-inline calls. Take again
the case of std::string with the second constructor above. The size_type and
value_type types are PODs and allocator_type is an empty type, so quite a few
ABIs simply pass the three values in plain registers. If you replace that with
an aggregate, those ABIs will need to spill the primitive values to a
temporary in the stack and pass that temporary's address to the constructor.
The same thing also prevents tail-call optimisations when you need to call a
function with a different object.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the 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/.
.
Author: Hannes <landeholm@gmail.com>
Date: Tue, 24 Nov 2015 02:58:00 -0800 (PST)
Raw View
------=_Part_192_434867318.1448362680358
Content-Type: multipart/alternative;
boundary="----=_Part_193_1266982095.1448362680359"
------=_Part_193_1266982095.1448362680359
Content-Type: text/plain; charset=UTF-8
On Tuesday, November 24, 2015 at 6:11:57 AM UTC+1, Thiago Macieira wrote:
>
> On Monday 23 November 2015 20:47:47 Nicol Bolas wrote:
> > Why not? I already explained how to get the equivalent behavior without
> > having actual named parameters (have the type take a struct and use an
> > extra set of braces).
>
> It's not as efficient and is much more limited.
>
> Suppose these two constructor examples:
>
> struct S
> {
> S(int n);
> S(int n, std::tuple<std::string, std::vector<int>> data);
> };
>
> vs
>
> struct S
> {
> struct ConstructorArguments {
> std::tuple<std::string, std::vector<int>> data;
> int n;
> };
> S(ConstructorArguments);
> };
>
> The first thing to note is that we cannot create an overload, as otherwise
> that would necessitate an ugly syntax specifying the structure type, as
> in:
> S{(ConstructWithLength){ .n = 1 }};
> S((ConstructWithLengthAndData){ .n = 1, .data = {"", {}}};
> that is very C-like and C++-unlike.
>
I just noted that anonymous struct declaration is currently not allowed by
the language as parameter types. The proposal could allow them in the
specific case when you have constructors that only accept them in a single
argument. A designated aggregate initialization would only be able to call
this new allowed parameter form to prevent name leakage:
struct S {
// Constructor 1
S(struct {
int n;
});
// Constructor 2
S(struct {
std::tuple<std::string, std::vector<int>> data;
int n;
});
};
S v{3} // Constructor 1 (classic aggregate initialization)
S v{3, {"foo", {4, 2}}} // Constructor 2 (classic aggregate initialization)
S v{n: 3} // Constructor 1 (designated aggregate
initialization)
S v{n: 3, {"foo", {4, 2}}} // Constructor 2 (designated aggregate
initialization)
S v(3) // Constructor 1 (backwards-compatible)
S v(3, {"foo", {4, 2}}) // Constructor 2 (backwards-compatible)
The syntax would be completely analogous to having normal parameter lists
in terms of overloading priority. The only "quirk" would be the fact that
it wouldn't be a true anonymous struct because the constructor declaration
would be considered equivalent as long as it had the same members in the
anonymous struct with the same types but that would still be analogous with
normal parameter lists.
This would also solve your second and third concern (performance and
different behaviours). This could be argued to be a completely separate
feature though but it would be introduced at the same time to allow the
benefit of designated initilization in higher C++ as well.
> Finally, there's also the issue of efficiency for non-inline calls. Take
> again
> the case of std::string with the second constructor above. The size_type
> and
> value_type types are PODs and allocator_type is an empty type, so quite a
> few
> ABIs simply pass the three values in plain registers. If you replace that
> with
> an aggregate, those ABIs will need to spill the primitive values to a
> temporary in the stack and pass that temporary's address to the
> constructor.
>
Are those ABIs major ABIs? You make quite a few assumptions here about
modern ABIs. Just because you wrap a value in a POD doesn't mean it spills
to the stack.
Code (C):
typedef struct {
int a;
int b;
} t;
t foo() {
return (t) {.a = 1, .b = 2};
}
x86: (no stack)
foo():
movabsq $8589934593, %rax
ret
ARM64: (no stack)
foo():
mov x0, 0
mov x1, 1
bfi x0, x1, 0, 32
mov x1, 2
bfi x0, x1, 32, 32
ret
ARM: (no stack)
foo():
mov r2, r0
movw r3, #:lower16:.LANCHOR0
movt r3, #:upper16:.LANCHOR0
ldmia r3, {r0, r1}
stmia r2, {r0, r1}
mov r0, r2
bx lr
The same thing also prevents tail-call optimisations when you need to call
> a
> function with a different object.
>
How? The parameters you call a function with is irrelevant for TCO, even if
they spill onto the stack or change. The important part is that you return
the same type so that you can just overwrite the return pointer.
--
---
You received this message because you are subscribed to the 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_193_1266982095.1448362680359
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, November 24, 2015 at 6:11:57 AM UTC+1, Thiago Macieira wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">On Monday 23 November 2015 20:47=
:47 Nicol Bolas wrote:
<br>> Why not? I already explained how to get the equivalent behavior wi=
thout=20
<br>> having actual named parameters (have the type take a struct and us=
e an=20
<br>> extra set of braces).
<br>
<br>It's not as efficient and is much more limited.
<br>
<br>Suppose these two constructor examples:
<br>
<br>struct S
<br>{
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0S(int n);
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0S(int n, std::tuple<=
std::string, std::vector<int>> data);
<br>};
<br>
<br>vs
<br>
<br>struct S
<br>{
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0struct ConstructorArgum=
ents {=20
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0std::tuple<<wbr>std::string, std::vector<i=
nt>> data;=20
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0int n;=20
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0};
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0S(<wbr>ConstructorArgum=
ents);
<br>};
<br>
<br>The first thing to note is that we cannot create an overload, as otherw=
ise=20
<br>that would necessitate an ugly syntax specifying the structure type, as=
in:
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0S{(<wbr>ConstructWithLe=
ngth){ .n =3D 1 }};
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0S((<wbr>ConstructWithLe=
ngthAndData){ .n =3D 1, .data =3D {"", {}}};
<br>that is very C-like and C++-unlike.
<br></blockquote><div><br></div><div>I just noted that anonymous struct dec=
laration is currently not allowed by the language as parameter types. The p=
roposal could allow them in the specific case when you have constructors th=
at only accept them in a single argument. A designated aggregate initializa=
tion would only be able to call this new allowed parameter form to prevent =
name leakage:</div><div><div><br></div><div><font face=3D"courier new, mono=
space">struct S {</font></div><div><font face=3D"courier new, monospace">=
=C2=A0 =C2=A0 // Constructor 1</font></div><div><font face=3D"courier new, =
monospace">=C2=A0 =C2=A0 S(struct {</font></div><div><font face=3D"courier =
new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int n;</font></div><div><font f=
ace=3D"courier new, monospace">=C2=A0 =C2=A0 });</font></div><div><font fac=
e=3D"courier new, monospace">=C2=A0 =C2=A0 // Constructor 2</font></div><di=
v><font face=3D"courier new, monospace">=C2=A0 =C2=A0 S(struct {</font></di=
v><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 st=
d::tuple<std::string, std::vector<int>> data;</font></div><div>=
<font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int n;</f=
ont></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 });</fon=
t></div><div><font face=3D"courier new, monospace">};</font></div><div><fon=
t face=3D"courier new, monospace"><br></font></div><div><font face=3D"couri=
er new, monospace">S v{3} =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0// Constructor 1 (classic aggregate initialization)</font></di=
v><div><font face=3D"courier new, monospace">S v{3, {"foo", {4, 2=
}}} // Constructor 2 (classic=C2=A0</font><span style=3D"font-family: '=
courier new', monospace;">aggregate</span><font face=3D"courier new, mo=
nospace">=C2=A0initialization)</font></div><div><font face=3D"courier new, =
monospace"><br></font></div><div><font face=3D"courier new, monospace">S v{=
n: 3} =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Cons=
tructor 1 (designated=C2=A0</font><span style=3D"font-family: 'courier =
new', monospace;">aggregate</span><font face=3D"courier new, monospace"=
>=C2=A0initialization)</font></div><div><font face=3D"courier new, monospac=
e">S v{n: 3, {"foo", {4, 2}}} // Constructor 2 (designated=C2=A0<=
/font><span style=3D"font-family: 'courier new', monospace;">aggreg=
ate</span><font face=3D"courier new, monospace">=C2=A0initialization)</font=
></div><div><font face=3D"courier new, monospace"><br></font></div><div><fo=
nt face=3D"courier new, monospace">S v(3) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Constructor 1 (backwards-compatible)</fon=
t></div><div><font face=3D"courier new, monospace">S v(3, {"foo",=
{4, 2}}) // Constructor 2 (backwards-compatible)</font></div></div><div><b=
r></div><div><br></div><div>The syntax would be completely analogous to hav=
ing normal parameter lists in terms of overloading priority. The only "=
;quirk" would be the fact that it wouldn't be a true anonymous str=
uct because the constructor declaration would be considered equivalent as l=
ong as it had the same members in the anonymous struct with the same types =
but that would still be analogous with normal parameter lists.</div><div><b=
r></div><div>This would also solve your second and third concern (performan=
ce and different behaviours). This could be argued to be a completely separ=
ate feature though but it would be introduced at the same time to allow the=
benefit of designated initilization in higher C++ as well.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Finally, there's =
also the issue of efficiency for non-inline calls. Take again=20
<br>the case of std::string with the second constructor above. The size_typ=
e and=20
<br>value_type types are PODs and allocator_type is an empty type, so quite=
a few=20
<br>ABIs simply pass the three values in plain registers. If you replace th=
at with=20
<br>an aggregate, those ABIs will need to spill the primitive values to a=
=20
<br>temporary in the stack and pass that temporary's address to the con=
structor.
<br></blockquote><div><br></div><div>Are those ABIs major ABIs? You make qu=
ite a few assumptions here about modern ABIs. Just because you wrap a value=
in a POD doesn't mean it spills to the stack.</div><div><br></div><div=
>Code (C):</div><div><div><br></div><div><font face=3D"courier new, monospa=
ce">typedef struct {</font></div><div><font face=3D"courier new, monospace"=
><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>int a;</f=
ont></div><div><font face=3D"courier new, monospace">=C2=A0 <span class=3D"=
Apple-tab-span" style=3D"white-space:pre"> </span>int b;</font></div><div><=
font face=3D"courier new, monospace">} t;</font></div><div><font face=3D"co=
urier new, monospace"><br></font></div><div><font face=3D"courier new, mono=
space">t foo() {</font></div><div><font face=3D"courier new, monospace">=C2=
=A0 return (t) {.a =3D 1, .b =3D 2};</font></div><div><font face=3D"courier=
new, monospace">}</font></div><div><br></div></div><div>x86: (no stack)</d=
iv><div><div><br></div><div><font face=3D"courier new, monospace">foo():</f=
ont></div><div><font face=3D"courier new, monospace"><span class=3D"Apple-t=
ab-span" style=3D"white-space:pre"> </span>movabsq<span class=3D"Apple-tab-=
span" style=3D"white-space:pre"> </span>$8589934593, %rax</font></div><div>=
<font face=3D"courier new, monospace"><span class=3D"Apple-tab-span" style=
=3D"white-space:pre"> </span>ret</font></div></div><div><br></div><div>ARM6=
4: (no stack)</div><div><br></div><div><div><font face=3D"courier new, mono=
space">foo():</font></div><div><font face=3D"courier new, monospace"><span =
class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>mov<span class=
=3D"Apple-tab-span" style=3D"white-space:pre"> </span>x0, 0</font></div><di=
v><font face=3D"courier new, monospace"><span class=3D"Apple-tab-span" styl=
e=3D"white-space:pre"> </span>mov<span class=3D"Apple-tab-span" style=3D"wh=
ite-space:pre"> </span>x1, 1</font></div><div><font face=3D"courier new, mo=
nospace"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>b=
fi<span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>x0, x1, =
0, 32</font></div><div><font face=3D"courier new, monospace"><span class=3D=
"Apple-tab-span" style=3D"white-space:pre"> </span>mov<span class=3D"Apple-=
tab-span" style=3D"white-space:pre"> </span>x1, 2</font></div><div><font fa=
ce=3D"courier new, monospace"><span class=3D"Apple-tab-span" style=3D"white=
-space:pre"> </span>bfi<span class=3D"Apple-tab-span" style=3D"white-space:=
pre"> </span>x0, x1, 32, 32</font></div><div><font face=3D"courier new, mon=
ospace"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>re=
t</font></div></div><div><br></div><div>ARM: (no stack)</div><div><font fac=
e=3D"courier new, monospace"><br></font></div><div><div><font face=3D"couri=
er new, monospace">foo():</font></div><div><font face=3D"courier new, monos=
pace"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>mov<=
span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>r2, r0</fon=
t></div><div><font face=3D"courier new, monospace"><span class=3D"Apple-tab=
-span" style=3D"white-space:pre"> </span>movw<span class=3D"Apple-tab-span"=
style=3D"white-space:pre"> </span>r3, #:lower16:.LANCHOR0</font></div><div=
><font face=3D"courier new, monospace"><span class=3D"Apple-tab-span" style=
=3D"white-space:pre"> </span>movt<span class=3D"Apple-tab-span" style=3D"wh=
ite-space:pre"> </span>r3, #:upper16:.LANCHOR0</font></div><div><font face=
=3D"courier new, monospace"><span class=3D"Apple-tab-span" style=3D"white-s=
pace:pre"> </span>ldmia<span class=3D"Apple-tab-span" style=3D"white-space:=
pre"> </span>r3, {r0, r1}</font></div><div><font face=3D"courier new, monos=
pace"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>stmi=
a<span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>r2, {r0, =
r1}</font></div><div><font face=3D"courier new, monospace"><span class=3D"A=
pple-tab-span" style=3D"white-space:pre"> </span>mov<span class=3D"Apple-ta=
b-span" style=3D"white-space:pre"> </span>r0, r2</font></div><div><font fac=
e=3D"courier new, monospace"><span class=3D"Apple-tab-span" style=3D"white-=
space:pre"> </span>bx<span class=3D"Apple-tab-span" style=3D"white-space:pr=
e"> </span>lr</font></div></div><div><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">The same thing also prevents tail-call optimisations when =
you need to call a=20
<br>function with a different object.<br></blockquote><div><br></div><div>H=
ow? The parameters you call a function with is irrelevant for TCO, even if =
they spill onto the stack or change. The important part is that you return =
the same type so that you can just overwrite the return pointer.</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_193_1266982095.1448362680359--
------=_Part_192_434867318.1448362680358--
.
Author: Hannes <landeholm@gmail.com>
Date: Tue, 24 Nov 2015 03:00:16 -0800 (PST)
Raw View
------=_Part_2385_62594316.1448362816214
Content-Type: multipart/alternative;
boundary="----=_Part_2386_1192730626.1448362816215"
------=_Part_2386_1192730626.1448362816215
Content-Type: text/plain; charset=UTF-8
Oops, bogus example, constructor 2 should be:
// Constructor 2
S(struct {
int n;
std::tuple<std::string, std::vector<int>> data;
});
--
---
You received this message because you are subscribed to the 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_2386_1192730626.1448362816215
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Oops, bogus example, constructor 2 should be:<div><div><fo=
nt face=3D"courier new, monospace"><br class=3D"Apple-interchange-newline">=
=C2=A0 =C2=A0 // Constructor 2</font></div><div><font face=3D"courier new, =
monospace">=C2=A0 =C2=A0 S(struct {</font></div><div class=3D"IVILX2C-Db-b"=
><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int=
n;</font></div><span style=3D"font-family: 'courier new', monospac=
e;">=C2=A0 =C2=A0 =C2=A0 =C2=A0 std::tuple<std::string, std::vector<i=
nt>> data;</span></div><div><font face=3D"courier new, monospace">=C2=
=A0 =C2=A0 });</font></div></div><div><font face=3D"courier new, monospace"=
><br></font></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" 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_2386_1192730626.1448362816215--
------=_Part_2385_62594316.1448362816214--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 24 Nov 2015 07:12:01 -0800 (PST)
Raw View
------=_Part_238_1320700308.1448377921207
Content-Type: multipart/alternative;
boundary="----=_Part_239_1450055698.1448377921207"
------=_Part_239_1450055698.1448377921207
Content-Type: text/plain; charset=UTF-8
On Tuesday, November 24, 2015 at 12:11:57 AM UTC-5, Thiago Macieira wrote:
>
> On Monday 23 November 2015 20:47:47 Nicol Bolas wrote:
> > Why not? I already explained how to get the equivalent behavior without
> > having actual named parameters (have the type take a struct and use an
> > extra set of braces).
>
> It's not as efficient and is much more limited.
>
.... so?
Designated initializers exist to make aggregates work better and nicer.
They are *not* a way to back-door named parameters into the language, nor
are they an attempt to make constructors work with them.
The fact that they don't solve something that they're not actually supposed
to solve is *not* a problem with the feature. It's a problem with your
expectations and desires projected onto the feature.
--
---
You received this message because you are subscribed to the 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_239_1450055698.1448377921207
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, November 24, 2015 at 12:11:57 AM UTC-5, Thiago=
Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Monday 23 N=
ovember 2015 20:47:47 Nicol Bolas wrote:
<br>> Why not? I already explained how to get the equivalent behavior wi=
thout=20
<br>> having actual named parameters (have the type take a struct and us=
e an=20
<br>> extra set of braces).
<br>
<br>It's not as efficient and is much more limited.<br></blockquote><di=
v><br>... so?<br><br>Designated initializers exist to make aggregates work =
better and nicer. They are <i>not</i> a way to back-door named parameters i=
nto the language, nor are they an attempt to make constructors work with th=
em.<br><br>The fact that they don't solve something that they're no=
t actually supposed to solve is <i>not</i> a problem with the feature. It&#=
39;s a problem with your expectations and desires projected onto the featur=
e.</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" 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_239_1450055698.1448377921207--
------=_Part_238_1320700308.1448377921207--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 24 Nov 2015 07:22:25 -0800
Raw View
On Tuesday 24 November 2015 07:12:01 Nicol Bolas wrote:
> On Tuesday, November 24, 2015 at 12:11:57 AM UTC-5, Thiago Macieira wrote:
> > On Monday 23 November 2015 20:47:47 Nicol Bolas wrote:
> > > Why not? I already explained how to get the equivalent behavior without
> > > having actual named parameters (have the type take a struct and use an
> > > extra set of braces).
> >
> > It's not as efficient and is much more limited.
>
> ... so?
>
> Designated initializers exist to make aggregates work better and nicer.
> They are *not* a way to back-door named parameters into the language, nor
> are they an attempt to make constructors work with them.
>
> The fact that they don't solve something that they're not actually supposed
> to solve is *not* a problem with the feature. It's a problem with your
> expectations and desires projected onto the feature.
I'm merely pointing out that you can't say that designated initialisers are a
replacement for function parameter initialisers. They are not.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the 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/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 24 Nov 2015 07:38:53 -0800
Raw View
On Tuesday 24 November 2015 02:58:00 Hannes wrote:
> > struct S
> > {
> > struct ConstructorArguments {
> > std::tuple<std::string, std::vector<int>> data;
> > int n;
> > };
> > S(ConstructorArguments);
> > };
> >
> > The first thing to note is that we cannot create an overload, as otherwise
> > that would necessitate an ugly syntax specifying the structure type, as
> >
> > in:
> > S{(ConstructWithLength){ .n = 1 }};
> > S((ConstructWithLengthAndData){ .n = 1, .data = {"", {}}};
> >
> > that is very C-like and C++-unlike.
>
> I just noted that anonymous struct declaration is currently not allowed by
> the language as parameter types. The proposal could allow them in the
> specific case when you have constructors that only accept them in a single
> argument.
I don't think anonymous structs are required. The point is that you should
never have to name them, so whether they are anonymous or not is entirely
orthogonal to the issue.
That said, I don't think your solution will work:
> A designated aggregate initialization would only be able to call
> this new allowed parameter form to prevent name leakage:
>
> struct S {
> // Constructor 1
> S(struct {
> int n;
> });
> // Constructor 2
> S(struct {
// corrected:
> int n;
> std::tuple<std::string, std::vector<int>> data;
> });
> };
>
> S v{3} // Constructor 1 (classic aggregate initialization)
> S v{3, {"foo", {4, 2}}} // Constructor 2 (classic aggregate initialization)
>
> S v{n: 3} // Constructor 1 (designated aggregate
> initialization)
> S v{n: 3, {"foo", {4, 2}}} // Constructor 2 (designated aggregate
> initialization)
>
> S v(3) // Constructor 1 (backwards-compatible)
> S v(3, {"foo", {4, 2}}) // Constructor 2 (backwards-compatible)
Doesn't all first entries in each pair cause an ambiguous overload resolution?
The parameter n appears in both structures and both structures have an
integral as their first argument.
> > Finally, there's also the issue of efficiency for non-inline calls. Take
> > again
> > the case of std::string with the second constructor above. The size_type
> > and
> > value_type types are PODs and allocator_type is an empty type, so quite a
> > few
> > ABIs simply pass the three values in plain registers. If you replace that
> > with
> > an aggregate, those ABIs will need to spill the primitive values to a
> > temporary in the stack and pass that temporary's address to the
> > constructor.
>
> Are those ABIs major ABIs? You make quite a few assumptions here about
> modern ABIs. Just because you wrap a value in a POD doesn't mean it spills
> to the stack.
Try with three parameters instead of two. Try with any non-trivial type too.
And even with two, like in your example, note how the two ints got compressed
into one register, instead of being each passed in a register. This means the
callee has a more complex code path to work with each.
> > The same thing also prevents tail-call optimisations when you need to call
> > a
> > function with a different object.
>
> How? The parameters you call a function with is irrelevant for TCO, even if
> they spill onto the stack or change. The important part is that you return
> the same type so that you can just overwrite the return pointer.
TCO requires that the callee can pop the stack of the caller. That cannot
happen if the caller had to allocate space for the parameters on the stack.
struct S { int a, b, c; };
void f(S);
void g(int a, int b, int c)
{
f({a, b, c});
}
The above on x86-64 requires spilling to the stack.
The point is simply that using a struct in lieu of actual parameters is not
guaranteed to have the same ABI calling conventions, which may prevent TCO
from happening and quite often will have worse performance for one reason or
another.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the 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/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 24 Nov 2015 08:07:14 -0800 (PST)
Raw View
------=_Part_6706_1867808796.1448381234710
Content-Type: multipart/alternative;
boundary="----=_Part_6707_210099493.1448381234710"
------=_Part_6707_210099493.1448381234710
Content-Type: text/plain; charset=UTF-8
On Monday, November 23, 2015 at 11:54:19 PM UTC-5, Thiago Macieira wrote:
>
> On Monday 23 November 2015 19:47:38 Nicol Bolas wrote:
> > > They're against making the ugly parameters currently used for various
> > > reasons
> > > become API.
> >
> > But as has been previously stated, the standard doesn't define those
> > parameter names. So they wouldn't be able to become part of the API.
> They
> > would be implementation defined, rather than standard defined.
>
> The standard doesn't define, but all implementations have parameter names
> for
> at least every parameter that is actually used in inline implementations.
> If
> the proposal for designated initialisers will not require an a specialised
> syntax for parameter names, then the existing, ugly names will be
> available
> for library users.
>
I'm going to pretend you said "named parameters" instead of "designated
initializers", since they're *two different features*, no matter how much
you wish to conflate them.
Implementations often export symbols that they don't intend for users to
use. You can find things in `std::__detail` namespaces or whatever that you
could start making your program rely on.
That doesn't make it standard-protected behavior for you to rely on them.
If a user starts using parameter names that are not defined by the
standard, then it's no different from them poking at things in the
`std::__detail` namespace. In both cases, they are relying on
implementation-defined behavior.
> > And I'd point out that that nobody seems to be willing to stop concepts
> > from getting into C++17 just because it hasn't been applied to the
> standard
> > library.
>
> That's only analogous to the case where designated initialisers for
> parameter
> names requires a new syntax: until the library implementations "opt in" to
> the
> parameter names, they can't be used.
>
If the names aren't defined by the standard, then you're not allowed to
rely on them, per the above.
> > But then again, the whole named parameters discussion is off-topic: this
> is
> > about designated initializers, which should not be conflated with named
> > parameters. After all, structure member names are already part of a
> > struct's API.
>
> I consider this very much on topic.
I can't stop you from considering it whatever you like. But as far as
designated initializers as a feature is concerned, it is only about
aggregate initialization. It has nothing to do with function parameter
names and named parameters.
> In C++, most useful aggregates have
> constructors
No useful aggregates with constructors exist because, by C++'s definition,
an aggregate cannot have a constructor
<http://en.cppreference.com/w/cpp/language/aggregate_initialization>.
However, I'll pretend you used the right terminology there (classes, not
aggregates). The Core C++ Guidelines seem to disagree with you.
Constructors exist to protect invariants. And not all compilations of types
need invariants. Indeed, the inference from the guidelines is that you are
intended to write types that have the minimal invariant possible. Which
means that, if you have a type that contains two types, but doesn't have
any invariant between them, then what you have is a struct that has two
types.
An aggregate.
> and unless we come up with a way for designating parameters to
> constructors, designated initialisers will have a somewhat limited use for
> us.
>
Just because it doesn't solve every problem doesn't mean we shouldn't have
it. It solve actual, useful problems for people as 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_6707_210099493.1448381234710
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, November 23, 2015 at 11:54:19 PM UTC-5, Thiago Macieira wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">On Monday 23 November 2015 19:47=
:38 Nicol Bolas wrote:
<br>> > They're against making the ugly parameters currently used=
for various
<br>> > reasons
<br>> > become API.
<br>>=20
<br>> But as has been previously stated, the standard doesn't define=
those
<br>> parameter names. So they wouldn't be able to become part of th=
e API. They
<br>> would be implementation defined, rather than standard defined.
<br>
<br>The standard doesn't define, but all implementations have parameter=
names for=20
<br>at least every parameter that is actually used in inline implementation=
s. If=20
<br>the proposal for designated initialisers will not require an a speciali=
sed=20
<br>syntax for parameter names, then the existing, ugly names will be avail=
able=20
<br>for library users.<br></blockquote><div><br>I'm going to pretend yo=
u said "named parameters" instead of "designated initializer=
s", since they're <i>two different features</i>, no matter how muc=
h you wish to conflate them.<br><br>Implementations often export symbols th=
at they don't intend for users to use. You can find things in `std::__d=
etail` namespaces or whatever that you could start making your program rely=
on.<br><br>That doesn't make it standard-protected behavior for you to=
rely on them.<br><br>If a user starts using parameter names that are not d=
efined by the standard, then it's no different from them poking at thin=
gs in the `std::__detail` namespace. In both cases, they are relying on imp=
lementation-defined behavior.<br>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;">
> And I'd point out that that nobody seems to be willing to stop con=
cepts
<br>> from getting into C++17 just because it hasn't been applied to=
the standard
<br>> library.
<br>
<br>That's only analogous to the case where designated initialisers for=
parameter=20
<br>names requires a new syntax: until the library implementations "op=
t in" to the=20
<br>parameter names, they can't be used.<br></blockquote><div><br>If th=
e names aren't defined by the standard, then you're not allowed to =
rely on them, per the above.<br>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;">
> But then again, the whole named parameters discussion is off-topic: th=
is is
<br>> about designated initializers, which should not be conflated with =
named
<br>> parameters. After all, structure member names are already part of =
a
<br>> struct's API.
<br>
<br>I consider this very much on topic.</blockquote><div><br>I can't st=
op you from considering it whatever you like. But as far as designated init=
ializers as a feature is concerned, it is only about aggregate initializati=
on. It has nothing to do with function parameter names and named parameters=
..<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;">In C++, most =
useful aggregates have=20
<br>constructors</blockquote><div><br>No useful aggregates with constructor=
s exist because, by C++'s definition, an <a href=3D"http://en.cpprefere=
nce.com/w/cpp/language/aggregate_initialization">aggregate cannot have a co=
nstructor</a>.<br><br>However, I'll pretend you used the right terminol=
ogy there (classes, not aggregates). The Core C++ Guidelines seem to disagr=
ee with you. Constructors exist to protect invariants. And not all compilat=
ions of types need invariants. Indeed, the inference from the guidelines is=
that you are intended to write types that have the minimal invariant possi=
ble. Which means that, if you have a type that contains two types, but does=
n't have any invariant between them, then what you have is a struct tha=
t has two types.<br><br>An aggregate.<br>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;">and unless we come up with a way for designating par=
ameters to=20
<br>constructors, designated initialisers will have a somewhat limited use =
for us.
<br></blockquote><br>Just because it doesn't solve every problem doesn&=
#39;t mean we shouldn't have it. It solve actual, useful problems for p=
eople as is.<br>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_6707_210099493.1448381234710--
------=_Part_6706_1867808796.1448381234710--
.
Author: Hannes <landeholm@gmail.com>
Date: Tue, 24 Nov 2015 09:13:27 -0800 (PST)
Raw View
------=_Part_7147_1069415346.1448385207122
Content-Type: multipart/alternative;
boundary="----=_Part_7148_439324555.1448385207122"
------=_Part_7148_439324555.1448385207122
Content-Type: text/plain; charset=UTF-8
On Tuesday, November 24, 2015 at 4:38:58 PM UTC+1, Thiago Macieira wrote:
>
> I don't think anonymous structs are required. The point is that you should
> never have to name them, so whether they are anonymous or not is entirely
> orthogonal to the issue.
>
It solves the problem where the library would be forced to expose a new
standardized aggregate type name in the API to application code. Allowing
anonymous structs would allow the library to force the application code to
use unnamed initializer lists.
> Doesn't all first entries in each pair cause an ambiguous overload
> resolution?
> The parameter n appears in both structures and both structures have an
> integral as their first argument.
>
Yes, this is currently ambiguous with aggregate initialization. However the
idea was to introduce more overloading priority rules to make it analogous
to parameter overloading, e.g. select the anonymous struct with the fewest
unspecified/default fields.
That said the anonymous struct thing is just a silly idea I had. Personally
I completely agree with Nicol that designated initializers should just be
considered an extension to aggregate initialization and has nothing to do
with this named parameter business.
TCO requires that the callee can pop the stack of the caller. That cannot
> happen if the caller had to allocate space for the parameters on the
> stack.
>
You're right, I made a premature assumption that the memory was owned by
the callee but I now realize that would always force memory copy and thus
be inefficient.
> The point is simply that using a struct in lieu of actual parameters is
> not
> guaranteed to have the same ABI calling conventions, which may prevent TCO
> from happening and quite often will have worse performance for one reason
> or
> another.
>
This is getting really off-topic now IMO but my counterpoint to that would
be that if someone is concerned with the performance loss from some stack
spillage they should consider link-time optimization anyway which makes the
ABI irrelevant.
--
---
You received this message because you are subscribed to the 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_7148_439324555.1448385207122
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Tuesday, November 24, 2015 at 4:38:58 PM UTC+1, Thi=
ago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I don't=
think anonymous structs are required. The point is that you should=20
<br>never have to name them, so whether they are anonymous or not is entire=
ly=20
<br>orthogonal to the issue.
<br></blockquote><div><br></div><div>It solves the problem where the librar=
y would be forced to expose a new standardized aggregate type name in the A=
PI to application code. Allowing anonymous structs would allow the library =
to force the application code to use unnamed initializer lists.</div><div><=
br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Does=
n't all first entries in each pair cause an ambiguous overload resoluti=
on?=20
<br>The parameter n appears in both structures and both structures have an=
=20
<br>integral as their first argument.
<br></blockquote><div><br></div><div>Yes, this is currently ambiguous with =
aggregate initialization. However the idea was to introduce more overloadin=
g priority rules to make it analogous to parameter overloading, e.g. select=
the anonymous struct with the fewest unspecified/default fields.</div><div=
><br></div><div>That said the anonymous struct thing is just a silly idea I=
had. Personally I completely agree with Nicol that designated initializers=
should just be considered an extension to aggregate initialization and has=
nothing to do with this named parameter business.</div><div><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">TCO requires that the callee can p=
op the stack of the caller. That cannot=20
<br>happen if the caller had to allocate space for the parameters on the st=
ack.
<br></blockquote><div><br></div><div>You're right, I made a premature a=
ssumption that the memory was owned by the callee but I now realize that wo=
uld always force memory copy and thus be inefficient.</div><div><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">
<br>The point is simply that using a struct in lieu of actual parameters is=
not=20
<br>guaranteed to have the same ABI calling conventions, which may prevent =
TCO=20
<br>from happening and quite often will have worse performance for one reas=
on or=20
<br>another.
<br></blockquote><div><br></div><div>This is getting really off-topic now I=
MO but my counterpoint to that would be that if someone is concerned with t=
he performance loss from some stack spillage they should consider link-time=
optimization anyway which makes the ABI irrelevant.<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" 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_7148_439324555.1448385207122--
------=_Part_7147_1069415346.1448385207122--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 24 Nov 2015 22:05:39 +0200
Raw View
On 24 November 2015 at 05:47, Nicol Bolas <jmckesson@gmail.com> wrote:
> And I'd point out that that nobody seems to be willing to stop concepts from
> getting into C++17 just because it hasn't been applied to the standard
> library.
You have a funny definition of "nobody". It seems a definition so anecdotal that
it defeats the meaning of the word.
--
---
You received this message because you are subscribed to the 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/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 24 Nov 2015 13:58:07 -0800
Raw View
On Tuesday 24 November 2015 09:13:27 Hannes wrote:
> That said the anonymous struct thing is just a silly idea I had. Personally
> I completely agree with Nicol that designated initializers should just be
> considered an extension to aggregate initialization and has nothing to do
> with this named parameter business.
I'm not disputing that.
I'm simply saying that it will have limited use because the interesting
aggregates in C++ have non-trivial default constructors, which removes the
ability to use designated initialisers.
If, however, designated parameters were implemented, it would apply to
constructors too and seamlessly remove the limitation.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the 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/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 24 Nov 2015 14:15:39 -0800
Raw View
On Tuesday 24 November 2015 08:07:14 Nicol Bolas wrote:
> I'm going to pretend you said "named parameters" instead of "designated
> initializers", since they're *two different features*, no matter how much
> you wish to conflate them.
Yes, I used the wrong term there.
> Implementations often export symbols that they don't intend for users to
> use. You can find things in `std::__detail` namespaces or whatever that you
> could start making your program rely on.
>
> That doesn't make it standard-protected behavior for you to rely on them.
I agree with you that people shouldn't rely on them, but it may still be the
fear of library developers that users may start depending on unspecified parts
of the API.
> > In C++, most useful aggregates have
> > constructors
>
> No useful aggregates with constructors exist because, by C++'s definition,
> an aggregate cannot have a constructor
> <http://en.cppreference.com/w/cpp/language/aggregate_initialization>.
Sorry, I misused the term. I wanted to use something that encompassed both
"class" and "struct", so I opted for "aggregate", which does have the meaning
I meant in C and includes the other type of designated initialisers we're
talking about. In C11 6.2.5 Types, paragraph 21:
Arithmetic types and pointer types are collectively called scalar types.
Array and structure types are collectively called aggregate types.
Obviously C doesn't need the distinction that dcl.init.aggr p1 makes, since C
has no constructor or access level. I had just never realised C++ had the
distinction.
> However, I'll pretend you used the right terminology there (classes, not
> aggregates). The Core C++ Guidelines seem to disagree with you.
> Constructors exist to protect invariants.
The guidelines are irrelevant to me, since they do not apply to the library I
mostly work on.
> > and unless we come up with a way for designating parameters to
> > constructors, designated initialisers will have a somewhat limited use for
> > us.
>
> Just because it doesn't solve every problem doesn't mean we shouldn't have
> it. It solve actual, useful problems for people as is.
Not disputing that it solves problems. I'm saying simply that I wish we went
further and enabled a whole set of new and more common uses.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the 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/.
.