There are two extra requirements for the C++ version of the feature that don't
exist in C99:
 1) initialisers must appear in the order of declaration
 2) nesting not permitted.

That means you cannot write:

time_t now = time(nullptr);
struct stat stbuf = {
 .st_dev = 0,
 .st_ino = 0,
 .st_mode = S_IFREG | 0644,
 .st_nlink = 1,
 .st_uid = 0,
 .st_gid = 0,
 .st_rdev = 0,
 .st_size = 123,
 .st_atime = now,
 .st_mtime = now,
 .st_ctime = now,
 .st_blocksize = 512,
 .st_blocks = 1
};

Even though I followed the POSIX documentation
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html

The above has both problems:
1) the order of the fields is not the same in all OSes, not even in the
multiple architectures of a given OS. On Linux, for example, the order of
st_mode and st_nlink is reversed on x86 32-bit and both st_blocksize and
st_blocks occur before the time fields

2) the three time fields are actually macros:
# define st_atime st_atim.tv_sec /* Backward compatibility.  */
# define st_mtime st_mtim.tv_sec
# define st_ctime st_ctim.tv_sec

The code above works fine for C99 but not C++.

That means designated initialisers cannot be used on structures you don't
control, since the order may vary from implementation to implementation. And
this trick of #defining the name of a member to point to a sub-field is actually
very common, sometimes taken to an extreme, like in siginfo_t.

So, to keep compatibility with C99, can we relax both rules for (at least)
trivial types?

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

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

.

On 2017/7/26 12:24, Thiago Macieira wrote:
> There are two extra requirements for the C++ version of the feature that don't
> exist in C99:
>   1) initialisers must appear in the order of declaration
>   2) nesting not permitted.
>
> That means you cannot write:
>
> time_t now = time(nullptr);
> struct stat stbuf = {
>  .st_dev = 0,
>  .st_ino = 0,
>  .st_mode = S_IFREG | 0644,
>  .st_nlink = 1,
>  .st_uid = 0,
>  .st_gid = 0,
>  .st_rdev = 0,
>  .st_size = 123,
>  .st_atime = now,
>  .st_mtime = now,
>  .st_ctime = now,
>  .st_blocksize = 512,
>  .st_blocks = 1
> };
>
> Even though I followed the POSIX documentation
> http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html
>
> The above has both problems:
> 1) the order of the fields is not the same in all OSes, not even in the
> multiple architectures of a given OS. On Linux, for example, the order of
> st_mode and st_nlink is reversed on x86 32-bit and both st_blocksize and
> st_blocks occur before the time fields >
> 2) the three time fields are actually macros:
> # define st_atime st_atim.tv_sec /* Backward compatibility.  */
> # define st_mtime st_mtim.tv_sec
> # define st_ctime st_ctim.tv_sec
>
> The code above works fine for C99 but not C++.

Given that `.d { .d2 = 2 },` is allowed in the proposal (p5), I don't
see the reason why `.e.a = 2,` is forbidden (p2).

But except for the case here, nesting designators seems to make code
hard to read. (But this is a coding convention matter.)

>
> That means designated initialisers cannot be used on structures you don't
> control, since the order may vary from implementation to implementation. And
> this trick of #defining the name of a member to point to a sub-field is actually
> very common, sometimes taken to an extreme, like in siginfo_t.
>
> So, to keep compatibility with C99, can we relax both rules for (at least)
> trivial types?
>
Not for the compatibility with C99, but I still agree that the rule #1
should be relaxed.

For trivial types it should be straightforward.

I also think we may further allow the initialization order to be
inconsistent with declaration order of the data members (while keep the
evaluation order from left to right), as it's already allowed today in
constructor' member initializer list (*), and thus relax rule #1 for
non-trivial types.

We might also introduce new attribute `[[unordered_init]]` or something
alike to suppress warnings the compiler issues when initialization order
is not consistent with the declaration order.

---

*: But still there is a difference that when writing constructor's
member initializer list, the definition of the class in question is
controlled by us, while when using designator initializers the structure
to be initialized may be defined by third parties.

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

.

On Tue, Jul 25, 2017 at 11:24 PM, Thiago Macieira <thiago@macieira.org> wrote:
> So, to keep compatibility with C99, can we relax both rules for (at least)
> trivial types?
>

The authors considered this option, but do not
feel this is a viable choice.

First, the motivation seems not strong enough to
us.  If the struct itself is already trivial, using the
traditional value-init + assignment approach

  stat buf{};
  buf.atime = now;
  ...

can expect a codegen that is identical to using
designated initializers.  At least that's what gcc
does; if you found that your compiler produces
different code and one of which is suboptimal,
you should file a bug to the vendor.

Second, relaxing these rules to trivial types can
bring some negative consequences.  Consider
that you shipped a library with an option struct,
initially a trivial type, an innocent user in his/her
code initialized an object of such a type using
unordered designators, in next version of the
library you appended a `std::string` field to that
struct, then the user's code breaks.  Designated
initializers intend to establish a way to reduce
such breakage caused by library evolving, but
relaxing the rules to trivial types can defeat such
a purpose.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________

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

.

On Wed, Jul 26, 2017 at 2:39 AM, d25fe0be@outlook.com
<d25fe0be@outlook.com> wrote:
> For trivial types it should be straightforward.
>

No, explained in the previous email.  It
makes the language harder to use.

> I also think we may further allow the initialization order to be
> inconsistent with declaration order of the data members (while keep the
> evaluation order from left to right), as it's already allowed today in
> constructor' member initializer list (*), and thus relax rule #1 for
> non-trivial types.

First, mem-init-clauses are evaluated in the
member declaration orders rather than the
written order.  It's a design mistake and let's
not repeat that.  The approach you implied,
thus, allowing the evaluation order diverges
from the initialization order, will make this
feature not pay-for-what-you-use.  These
are already explained in the paper.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________

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

.

On 2017/7/26 16:12, Zhihao Yuan wrote:
> On Wed, Jul 26, 2017 at 2:39 AM, d25fe0be@outlook.com
> <d25fe0be@outlook.com> wrote:
>> For trivial types it should be straightforward.
>>
>
> No, explained in the previous email.  It
> makes the language harder to use.
>
>> I also think we may further allow the initialization order to be
>> inconsistent with declaration order of the data members (while keep the
>> evaluation order from left to right), as it's already allowed today in
>> constructor' member initializer list (*), and thus relax rule #1 for
>> non-trivial types.
>
> First, mem-init-clauses are evaluated in the
> member declaration orders rather than the
> written order.  It's a design mistake and let's
> not repeat that.  The approach you implied,
> thus, allowing the evaluation order diverges
> from the initialization order, will make this
> feature not pay-for-what-you-use.  These
> are already explained in the paper.
>

I think I expressed my thoughts wrong.

By "initialization order", I was trying to mean "the order the
designated initializers are listed", not "the order the class' member
variables are initialized". Sorry for the misleading term.

What I tried to mean is that we can "repeat the mistake" and initialize
the object using the order its members are declared, regardless the
order the designated initializers are listed, and leaves the compiler to
warn the user if appropriate. We can also allow the user to suppress the
warning using some attribute on his will.

Still, even if it's a mistake for mem-init-clause, for the third party
structures whose definition cannot be controlled by us, the "severity of
the mistake" is mitigated. Personally I do not take it as a "mistake" as
there's otherwise no easy way to initialize those "weird" third party
structures (*) other than falls back to what we have today.

Also, in this way, there should be no temporary involved.
("pay-for-what-you-use")

---

*: Those whose definitions are changing from OS to OS, from ISA to ISA
(as in Thiago's post), or not declared in a logical order (presumbly due
to backward compatibility -- New fields can only be added at the end of
the structure).

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

.

On quarta-feira, 26 de julho de 2017 00:50:59 PDT Zhihao Yuan wrote:
> First, the motivation seems not strong enough to
> us.  If the struct itself is already trivial, using the
> traditional value-init + assignment approach
>
>   stat buf{};
>   buf.atime = now;
>   ...

It's not equivalent if I'm trying to have a static const variable. Taking an
example from Linux kernel's source code:

static const struct xattr_handler shmem_security_xattr_handler = {
        .prefix = XATTR_SECURITY_PREFIX,
        .get = shmem_xattr_handler_get,
        .set = shmem_xattr_handler_set,
};

A lot of this is done for virtual tables, but we are faced with this in C++
code as well when interfacing with C libraries. Examples from Qt source code:

http://code.qt.io/cgit/qt/qtwayland.git/tree/src/client/
qwaylanddisplay.cpp#n349
http://code.qt.io/cgit/qt/qtwayland.git/tree/src/hardwareintegration/client/
brcm-egl/qwaylandbrcmeglwindow.cpp#n83
http://code.qt.io/cgit/qt/qtwayland.git/tree/tests/auto/client/client/
mockcompositor.cpp#n321
http://code.qt.io/cgit/qt/qtwayland.git/tree/tests/auto/client/client/
mockshell.cpp#n149
http://code.qt.io/cgit/qt/qtwayland.git/tree/tests/auto/client/client/
mockshell.cpp#n171

We are forced to use non-designated initialisation, which means we could end
up with:

static const struct operations ops = {
 nullptr,
 nullptr,
 nullptr,
 nullptr,
 do_open,
 nullptr,
 nullptr,
 noop,
 nullptr,
 do_close
};


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

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

.

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

On Wed, Jul 26, 2017 at 11:53 AM, Thiago Macieira <thiago@macieira.org>
wrote:

> On quarta-feira, 26 de julho de 2017 00:50:59 PDT Zhihao Yuan wrote:
> > First, the motivation seems not strong enough to
> > us.  If the struct itself is already trivial, using the
> > traditional value-init + assignment approach
> >
> >   stat buf{};
> >   buf.atime = now;
> >   ...
>
> It's not equivalent if I'm trying to have a static const variable.


IIUC, you can still get constant initialization and also avoid dependence
on member order even in that case. It doesn't require designated
initializers:

https://godbolt.org/g/nSk8cr

-- Matt Calabrese

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

--f403045fbfc476e72705553ad1f4
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 W=
ed, Jul 26, 2017 at 11:53 AM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span=
 class=3D"gmail-">On quarta-feira, 26 de julho de 2017 00:50:59 PDT Zhihao =
Yuan wrote:<br>
&gt; First, the motivation seems not strong enough to<br>
&gt; us.=C2=A0 If the struct itself is already trivial, using the<br>
&gt; traditional value-init + assignment approach<br>
&gt;<br>
&gt;=C2=A0 =C2=A0stat buf{};<br>
&gt;=C2=A0 =C2=A0buf.atime =3D now;<br>
&gt;=C2=A0 =C2=A0...<br>
<br>
</span>It&#39;s not equivalent if I&#39;m trying to have a static const var=
iable.</blockquote><div><div><br></div><div>IIUC, you can still get constan=
t initialization and also avoid dependence on member order even in that cas=
e. It doesn&#39;t require designated initializers:</div><div><br></div><div=
><a href=3D"https://godbolt.org/g/nSk8cr">https://godbolt.org/g/nSk8cr</a><=
/div></div><div><br></div><div>-- Matt Calabrese</div></div></div></div>

<p></p>

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

--f403045fbfc476e72705553ad1f4--

.

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

On Jul 26, 2017 5:18 AM, "d25fe0be@outlook.com" <d25fe0be@outlook.com>
wrote:


By "initialization order", I was trying to mean "the order the
designated initializers are listed", not "the order the class' member
variables are initialized". Sorry for the misleading term.

What I tried to mean is that we can "repeat the mistake" and initialize
the object using the order its members are declared, regardless the
order the designated initializers are listed, and leaves the compiler to
warn the user if appropriate. We can also allow the user to suppress the
warning using some attribute on his will.

Still, even if it's a mistake for mem-init-clause, for the third party
structures whose definition cannot be controlled by us, the "severity of
the mistake" is mitigated.


The severity of the mistake is increased.
You essentially get a feature to
encourage silently breaking users'
legitimate code which relies on a
specific evaluation order of the
initializers by changing the member
declaration order at the library side.

--
Zhihao

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

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

<div dir=3D"auto"><div><div class=3D"gmail_extra"><div class=3D"gmail_quote=
">On Jul 26, 2017 5:18 AM, &quot;<a href=3D"mailto:d25fe0be@outlook.com">d2=
5fe0be@outlook.com</a>&quot; &lt;<a href=3D"mailto:d25fe0be@outlook.com">d2=
5fe0be@outlook.com</a>&gt; wrote:<blockquote class=3D"quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"quo=
ted-text"><br></div>
By &quot;initialization order&quot;, I was trying to mean &quot;the order t=
he<br>
designated initializers are listed&quot;, not &quot;the order the class&#39=
; member<br>
variables are initialized&quot;. Sorry for the misleading term.<br>
<br>
What I tried to mean is that we can &quot;repeat the mistake&quot; and init=
ialize<br>
the object using the order its members are declared, regardless the<br>
order the designated initializers are listed, and leaves the compiler to<br=
>
warn the user if appropriate. We can also allow the user to suppress the<br=
>
warning using some attribute on his will.<br>
<br>
Still, even if it&#39;s a mistake for mem-init-clause, for the third party<=
br>
structures whose definition cannot be controlled by us, the &quot;severity =
of<br>
the mistake&quot; is mitigated.</blockquote></div></div></div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">The severity of the mistake is increased.<=
/div><div dir=3D"auto">You essentially get a feature to</div><div dir=3D"au=
to">encourage silently breaking users&#39;</div><div dir=3D"auto">legitimat=
e code which relies on a</div><div dir=3D"auto">specific evaluation order o=
f the</div><div dir=3D"auto">initializers by changing the member</div><div =
dir=3D"auto">declaration order at the library side.</div><div dir=3D"auto">=
<br></div><div dir=3D"auto">--</div><div dir=3D"auto">Zhihao</div><div dir=
=3D"auto"></div></div>

<p></p>

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

--001a114718d4e9618b05553b857e--

.

------=_Part_3512_1575275533.1501091360807
Content-Type: multipart/alternative;
 boundary="----=_Part_3513_1907833215.1501091360807"

------=_Part_3513_1907833215.1501091360807
Content-Type: text/plain; charset="UTF-8"



On Wednesday, July 26, 2017 at 1:10:26 PM UTC-4, Zhihao Yuan wrote:
>
> On Jul 26, 2017 5:18 AM, "d25f...@outlook.com <javascript:>" <
> d25f...@outlook.com <javascript:>> wrote:
>
>
> By "initialization order", I was trying to mean "the order the
> designated initializers are listed", not "the order the class' member
> variables are initialized". Sorry for the misleading term.
>
> What I tried to mean is that we can "repeat the mistake" and initialize
> the object using the order its members are declared, regardless the
> order the designated initializers are listed, and leaves the compiler to
> warn the user if appropriate. We can also allow the user to suppress the
> warning using some attribute on his will.
>
> Still, even if it's a mistake for mem-init-clause, for the third party
> structures whose definition cannot be controlled by us, the "severity of
> the mistake" is mitigated.
>
>
> The severity of the mistake is increased.
> You essentially get a feature to
> encourage silently breaking users'
> legitimate code which relies on a
> specific evaluation order of the
> initializers by changing the member
> declaration order at the library side.
>
>
I think another way to look at it is this. Designated initializers are just
a convenience form of aggregate initialization (one that notably allows you
to skip members and let them be initialized via their default member
initializers). If you couldn't guarantee the order of the items in the
struct, then you couldn't use aggregate initialization to begin with.  And
thus, you shouldn't be surprised that you can't use designated initializers.

Initializing members out-of-order through aggregate initialization would be
a new thing, not a convenience 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ad912456-47bb-4775-bb49-8750682efd5d%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Wednesday, July 26, 2017 at 1:10:26 PM UTC-4, Z=
hihao Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"a=
uto"><div><div><div class=3D"gmail_quote">On Jul 26, 2017 5:18 AM, &quot;<a=
 href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"N2DLlQxzAA=
AJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">d25f...=
@outlook.com</a>&quot; &lt;<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"N2DLlQxzAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">d25f...@outlook.com</a>&gt; wrote:<blockquote style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br=
></div>
By &quot;initialization order&quot;, I was trying to mean &quot;the order t=
he<br>
designated initializers are listed&quot;, not &quot;the order the class&#39=
; member<br>
variables are initialized&quot;. Sorry for the misleading term.<br>
<br>
What I tried to mean is that we can &quot;repeat the mistake&quot; and init=
ialize<br>
the object using the order its members are declared, regardless the<br>
order the designated initializers are listed, and leaves the compiler to<br=
>
warn the user if appropriate. We can also allow the user to suppress the<br=
>
warning using some attribute on his will.<br>
<br>
Still, even if it&#39;s a mistake for mem-init-clause, for the third party<=
br>
structures whose definition cannot be controlled by us, the &quot;severity =
of<br>
the mistake&quot; is mitigated.</blockquote></div></div></div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">The severity of the mistake is increased.<=
/div><div dir=3D"auto">You essentially get a feature to</div><div dir=3D"au=
to">encourage silently breaking users&#39;</div><div dir=3D"auto">legitimat=
e code which relies on a</div><div dir=3D"auto">specific evaluation order o=
f the</div><div dir=3D"auto">initializers by changing the member</div><div =
dir=3D"auto">declaration order at the library side.</div><br></div></blockq=
uote><div><br>I think another way to look at it is this. Designated initial=
izers are just a convenience form of aggregate=20
initialization (one that notably allows you to skip members and let them
 be initialized via their default member initializers). If you couldn&#39;t=
 guarantee the order of the items in the struct, then you couldn&#39;t use =
aggregate initialization to begin with.=C2=A0 And thus, you shouldn&#39;t b=
e surprised that you can&#39;t use designated initializers.<br><br>Initiali=
zing members out-of-order through aggregate initialization would be a new t=
hing, not a convenience feature.<br></div></div>

<p></p>

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

------=_Part_3513_1907833215.1501091360807--

------=_Part_3512_1575275533.1501091360807--

.

------=_Part_5596_88912465.1501091436360
Content-Type: multipart/alternative;
 boundary="----=_Part_5597_1055867100.1501091436360"

------=_Part_5597_1055867100.1501091436360
Content-Type: text/plain; charset="UTF-8"

On Wednesday, July 26, 2017 at 1:49:20 PM UTC-4, Nicol Bolas wrote:
>
> On Wednesday, July 26, 2017 at 1:10:26 PM UTC-4, Zhihao Yuan wrote:
>>
>> On Jul 26, 2017 5:18 AM, "d25f...@outlook.com" <d25f...@outlook.com>
>> wrote:
>>
>>
>> By "initialization order", I was trying to mean "the order the
>> designated initializers are listed", not "the order the class' member
>> variables are initialized". Sorry for the misleading term.
>>
>> What I tried to mean is that we can "repeat the mistake" and initialize
>> the object using the order its members are declared, regardless the
>> order the designated initializers are listed, and leaves the compiler to
>> warn the user if appropriate. We can also allow the user to suppress the
>> warning using some attribute on his will.
>>
>> Still, even if it's a mistake for mem-init-clause, for the third party
>> structures whose definition cannot be controlled by us, the "severity of
>> the mistake" is mitigated.
>>
>>
>> The severity of the mistake is increased.
>> You essentially get a feature to
>> encourage silently breaking users'
>> legitimate code which relies on a
>> specific evaluation order of the
>> initializers by changing the member
>> declaration order at the library side.
>>
>>
> I think another way to look at it is this. Designated initializers are
> just a convenience form of aggregate initialization (one that notably
> allows you to skip members and let them be initialized via their default
> member initializers). If you couldn't guarantee the order of the items in
> the struct, then you couldn't use aggregate initialization to begin with.
> And thus, you shouldn't be surprised that you can't use designated
> initializers.
>
> Initializing members out-of-order through aggregate initialization would
> be a new thing, not a convenience feature.
>

But at least with designated initializers, if you initialize them
out-of-order, then at least you get a compile error, so that you can fix
your code. With regular aggregate initialization, you wouldn't even get
that.

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

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

<div dir=3D"ltr">On Wednesday, July 26, 2017 at 1:49:20 PM UTC-4, Nicol Bol=
as 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 W=
ednesday, July 26, 2017 at 1:10:26 PM UTC-4, Zhihao Yuan 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"auto"><div><div><div class=3D"gmail=
_quote">On Jul 26, 2017 5:18 AM, &quot;<a rel=3D"nofollow">d25f...@outlook.=
com</a>&quot; &lt;<a rel=3D"nofollow">d25f...@outlook.com</a>&gt; wrote:<bl=
ockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div><br></div>
By &quot;initialization order&quot;, I was trying to mean &quot;the order t=
he<br>
designated initializers are listed&quot;, not &quot;the order the class&#39=
; member<br>
variables are initialized&quot;. Sorry for the misleading term.<br>
<br>
What I tried to mean is that we can &quot;repeat the mistake&quot; and init=
ialize<br>
the object using the order its members are declared, regardless the<br>
order the designated initializers are listed, and leaves the compiler to<br=
>
warn the user if appropriate. We can also allow the user to suppress the<br=
>
warning using some attribute on his will.<br>
<br>
Still, even if it&#39;s a mistake for mem-init-clause, for the third party<=
br>
structures whose definition cannot be controlled by us, the &quot;severity =
of<br>
the mistake&quot; is mitigated.</blockquote></div></div></div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">The severity of the mistake is increased.<=
/div><div dir=3D"auto">You essentially get a feature to</div><div dir=3D"au=
to">encourage silently breaking users&#39;</div><div dir=3D"auto">legitimat=
e code which relies on a</div><div dir=3D"auto">specific evaluation order o=
f the</div><div dir=3D"auto">initializers by changing the member</div><div =
dir=3D"auto">declaration order at the library side.</div><br></div></blockq=
uote><div><br>I think another way to look at it is this. Designated initial=
izers are just a convenience form of aggregate=20
initialization (one that notably allows you to skip members and let them
 be initialized via their default member initializers). If you couldn&#39;t=
 guarantee the order of the items in the struct, then you couldn&#39;t use =
aggregate initialization to begin with.=C2=A0 And thus, you shouldn&#39;t b=
e surprised that you can&#39;t use designated initializers.<br><br>Initiali=
zing members out-of-order through aggregate initialization would be a new t=
hing, not a convenience feature.<br></div></div></blockquote><div><br>But a=
t least with designated initializers, if you initialize them out-of-order, =
then at least you get a compile error, so that you can fix your code. With =
regular aggregate initialization, you wouldn&#39;t even get that. <br></div=
></div>

<p></p>

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

------=_Part_5597_1055867100.1501091436360--

------=_Part_5596_88912465.1501091436360--

.

On Wed, Jul 26, 2017 at 12:49 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> Designated initializers are just
> a convenience form of aggregate initialization (one that notably allows you
> to skip members and let them be initialized via their default member
> initializers).

That's exactly how we model this feature
when we were designing it; stated as the 2nd
motivation in the paper.

> Initializing members out-of-order through aggregate initialization would be
> a new thing, not a convenience feature.

Well, we tried very hard on that, though it's not
a part of the motivation, but nothing really works
so far.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________

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

.

------=_Part_3867_311372374.1501500489083
Content-Type: multipart/alternative;
 boundary="----=_Part_3868_1178471150.1501500489083"

------=_Part_3868_1178471150.1501500489083
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I support Thiago. This valid C99/11 code should also be valid =D0=A1++:

#include<time.h>

struct timespec1 { time_t tv_sec; long tv_nsec; };
struct timespec2 { long tv_nsec; time_t tv_sec; };
struct timespec3 { time_t tv_sec; long tv_nsec; int extra_field; };

struct timespec1 t1 =3D { .tv_sec =3D 1, .tv_nsec =3D 0 };
struct timespec2 t2 =3D { .tv_sec =3D 1, .tv_nsec =3D 0 };
struct timespec3 t3 =3D { .tv_sec =3D 1, .tv_nsec =3D 0 };

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/772cf8d1-4709-4d8a-a053-02c037520d32%40isocpp.or=
g.

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

<div dir=3D"ltr"><div style=3D"color: #000000;background-color: #fffffe;fon=
t-family: Fira Mono;font-weight: normal;font-size: 14px;line-height: 19px;w=
hite-space: pre;">I support Thiago. This valid C99/11 code should also be v=
alid =D0=A1++:<br><br><div style=3D"color: #000000;background-color: #fffff=
e;font-family: Fira Mono;font-weight: normal;font-size: 14px;line-height: 1=
9px;white-space: pre;"><div><span style=3D"color: #0000ff;">#include</span>=
<span style=3D"color: #000000;">&lt;time.h&gt;</span></div><br><div><span s=
tyle=3D"color: #0000ff;">struct</span><span style=3D"color: #000000;"> time=
spec1 { time_t tv_sec; </span><span style=3D"color: #0000ff;">long</span><s=
pan style=3D"color: #000000;"> tv_nsec; };</span></div><div><span style=3D"=
color: #0000ff;">struct</span><span style=3D"color: #000000;"> timespec2 { =
</span><span style=3D"color: #0000ff;">long</span><span style=3D"color: #00=
0000;"> tv_nsec; time_t tv_sec; };</span></div><div style=3D"color: #000000=
;background-color: #fffffe;font-family: Fira Mono;font-weight: normal;font-=
size: 14px;line-height: 19px;white-space: pre;"><div><span style=3D"color: =
#0000ff;">struct</span><span style=3D"color: #000000;"> timespec3 { time_t =
tv_sec; </span><span style=3D"color: #0000ff;">long</span><span style=3D"co=
lor: #000000;"> tv_nsec; </span><span style=3D"color: #0000ff;">int</span><=
span style=3D"color: #000000;"> extra_field; };</span></div><br></div><div>=
<span style=3D"color: #0000ff;">struct</span><span style=3D"color: #000000;=
"> timespec1 t1 =3D { .tv_sec =3D </span><span style=3D"color: #09885a;">1<=
/span><span style=3D"color: #000000;">, .tv_nsec =3D </span><span style=3D"=
color: #09885a;">0</span><span style=3D"color: #000000;"> };</span></div><d=
iv><span style=3D"color: #0000ff;">struct</span><span style=3D"color: #0000=
00;"> timespec2 t2 =3D { .tv_sec =3D </span><span style=3D"color: #09885a;"=
>1</span><span style=3D"color: #000000;">, .tv_nsec =3D </span><span style=
=3D"color: #09885a;">0</span><span style=3D"color: #000000;"> };<br></span>=
<div><span style=3D"color: #0000ff;">struct</span><span style=3D"color: #00=
0000;"> timespec3 t3 =3D { .tv_sec =3D </span><span style=3D"color: #09885a=
;">1</span><span style=3D"color: #000000;">, .tv_nsec =3D </span><span styl=
e=3D"color: #09885a;">0</span><span style=3D"color: #000000;"> };</span></d=
iv></div></div></div></div>

<p></p>

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

------=_Part_3868_1178471150.1501500489083--

------=_Part_3867_311372374.1501500489083--

.

On Monday, 31 July 2017 04:28:08 PDT Victor Dyachenko wrote:
> I support Thiago. This valid C99/11 code should also be valid =D0=A1++:
>=20
> #include<time.h>
>=20
> struct timespec1 { time_t tv_sec; long tv_nsec; };
> struct timespec2 { long tv_nsec; time_t tv_sec; };
> struct timespec3 { time_t tv_sec; long tv_nsec; int extra_field; };
>=20
> struct timespec1 t1 =3D { .tv_sec =3D 1, .tv_nsec =3D 0 };
> struct timespec2 t2 =3D { .tv_sec =3D 1, .tv_nsec =3D 0 };
> struct timespec3 t3 =3D { .tv_sec =3D 1, .tv_nsec =3D 0 };

Something I found over the weekend:

https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#Common-Type-=
Attributes

designated_init

    This attribute may only be applied to structure types. It indicates tha=
t=20
any initialization of an object of this type must use designated initialize=
rs=20
rather than positional initializers. The intent of this attribute is to all=
ow=20
the programmer to indicate that a structure=E2=80=99s layout may change, an=
d that=20
therefore relying on positional initialization will result in future breaka=
ge.

    GCC emits warnings based on this attribute by default; use -Wno-
designated-init to suppress them.

So GCC devs have already foreseen the need for types that may change order =
in=20
the future.

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

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

.

------=_Part_4287_1555164981.1501524309986
Content-Type: multipart/alternative;
 boundary="----=_Part_4288_962743056.1501524309987"

------=_Part_4288_962743056.1501524309987
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Monday, July 31, 2017 at 12:41:13 PM UTC-4, Thiago Macieira wrote:
>
> On Monday, 31 July 2017 04:28:08 PDT Victor Dyachenko wrote:=20
> > I support Thiago. This valid C99/11 code should also be valid =D0=A1++:=
=20
> >=20
> > #include<time.h>=20
> >=20
> > struct timespec1 { time_t tv_sec; long tv_nsec; };=20
> > struct timespec2 { long tv_nsec; time_t tv_sec; };=20
> > struct timespec3 { time_t tv_sec; long tv_nsec; int extra_field; };=20
> >=20
> > struct timespec1 t1 =3D { .tv_sec =3D 1, .tv_nsec =3D 0 };=20
> > struct timespec2 t2 =3D { .tv_sec =3D 1, .tv_nsec =3D 0 };=20
> > struct timespec3 t3 =3D { .tv_sec =3D 1, .tv_nsec =3D 0 };=20
>
> Something I found over the weekend:=20
>
>
> https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#Common-Typ=
e-Attributes=20
>
> designated_init=20
>
>     This attribute may only be applied to structure types. It indicates=
=20
> that=20
> any initialization of an object of this type must use designated=20
> initializers=20
> rather than positional initializers. The intent of this attribute is to=
=20
> allow=20
> the programmer to indicate that a structure=E2=80=99s layout may change, =
and that=20
> therefore relying on positional initialization will result in future=20
> breakage.=20
>
>     GCC emits warnings based on this attribute by default; use -Wno-=20
> designated-init to suppress them.=20
>
> So GCC devs have already foreseen the need for types that may change orde=
r=20
> in=20
> the future.=20
>

Well, the C++ language doesn't work well with that, since members must be=
=20
initialized in the order they're presented in the class definition. In C++,=
=20
changing the order of members is not a backwards-incompatible change, and=
=20
designated initializers will not change that.

Here's the question I have with list and aggregate initialization. Is this=
=20
well-defined, currently:

struct Agg
{
  int x, y;
};

Agg a{5, a.x};

In a braced-init-list, the initializing expressions are evaluated in the=20
order they appear. So it could be that the initialization of `a.x` happens=
=20
before the expression to start initializing `a.y`. If that is the case,=20
then it's basically impossible to do this out-of-order. Even for trivial=20
types, the initializers could depend on each other in very funky ways.

Personally, I hope that it is not well-defined.


--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1aa71e66-0261-48e2-870a-46f12e84a9a6%40isocpp.or=
g.

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

<div dir=3D"ltr">On Monday, July 31, 2017 at 12:41:13 PM UTC-4, Thiago Maci=
eira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Monday, 31 July =
2017 04:28:08 PDT Victor Dyachenko wrote:
<br>&gt; I support Thiago. This valid C99/11 code should also be valid =D0=
=A1++:
<br>&gt;=20
<br>&gt; #include&lt;time.h&gt;
<br>&gt;=20
<br>&gt; struct timespec1 { time_t tv_sec; long tv_nsec; };
<br>&gt; struct timespec2 { long tv_nsec; time_t tv_sec; };
<br>&gt; struct timespec3 { time_t tv_sec; long tv_nsec; int extra_field; }=
;
<br>&gt;=20
<br>&gt; struct timespec1 t1 =3D { .tv_sec =3D 1, .tv_nsec =3D 0 };
<br>&gt; struct timespec2 t2 =3D { .tv_sec =3D 1, .tv_nsec =3D 0 };
<br>&gt; struct timespec3 t3 =3D { .tv_sec =3D 1, .tv_nsec =3D 0 };
<br>
<br>Something I found over the weekend:
<br>
<br><a href=3D"https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.ht=
ml#Common-Type-Attributes" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.=
org%2Fonlinedocs%2Fgcc%2FCommon-Type-Attributes.html%23Common-Type-Attribut=
es\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEEqiy4XsFNjYTOhXmNsE9Dy4Ui_A&#39=
;;return true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3=
dhttps%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc%2FCommon-Type-Attributes.html=
%23Common-Type-Attributes\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEEqiy4XsF=
NjYTOhXmNsE9Dy4Ui_A&#39;;return true;">https://gcc.gnu.org/<wbr>onlinedocs/=
gcc/Common-Type-<wbr>Attributes.html#Common-Type-<wbr>Attributes</a>
<br>
<br>designated_init
<br>
<br>=C2=A0 =C2=A0 This attribute may only be applied to structure types. It=
 indicates that=20
<br>any initialization of an object of this type must use designated initia=
lizers=20
<br>rather than positional initializers. The intent of this attribute is to=
 allow=20
<br>the programmer to indicate that a structure=E2=80=99s layout may change=
, and that=20
<br>therefore relying on positional initialization will result in future br=
eakage.
<br>
<br>=C2=A0 =C2=A0 GCC emits warnings based on this attribute by default; us=
e -Wno-
<br>designated-init to suppress them.
<br>
<br>So GCC devs have already foreseen the need for types that may change or=
der in=20
<br>the future.
<br></blockquote><div><br>Well, the C++ language doesn&#39;t work well with=
 that, since members must be initialized in the order they&#39;re presented=
 in the class definition. In C++, changing the order of members is not a ba=
ckwards-incompatible change, and designated initializers will not change th=
at.<br><br>Here&#39;s the question I have with list and aggregate initializ=
ation. Is this well-defined, currently:<br><br><div style=3D"background-col=
or: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: sol=
id; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><c=
ode class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" cla=
ss=3D"styled-by-prettify">Agg</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> y</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: #606;" class=
=3D"styled-by-prettify">Agg</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> a</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">{</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"> a</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">x</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">};</span></div></code></div><br>In a braced-=
init-list, the initializing expressions are evaluated in the order they app=
ear. So it could be that the initialization of `a.x` happens before the exp=
ression to start initializing `a.y`. If that is the case, then it&#39;s bas=
ically impossible to do this out-of-order. Even for trivial types, the init=
ializers could depend on each other in very funky ways.<br><br>Personally, =
I hope that it is not well-defined.<br><br><br></div></div>

<p></p>

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

------=_Part_4288_962743056.1501524309987--

------=_Part_4287_1555164981.1501524309986--

.

On segunda-feira, 31 de julho de 2017 11:05:09 PDT Nicol Bolas wrote:
> Well, the C++ language doesn't work well with that, since members must be
> initialized in the order they're presented in the class definition. In C++,
> changing the order of members is not a backwards-incompatible change, and
> designated initializers will not change that.

Only because we say it is. There's nothing else preventing initialisation in
any order for trivial types.

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

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

.

------=_Part_4191_573151425.1501526044868
Content-Type: multipart/alternative;
 boundary="----=_Part_4192_950874656.1501526044868"

------=_Part_4192_950874656.1501526044868
Content-Type: text/plain; charset="UTF-8"

On Monday, July 31, 2017 at 2:24:46 PM UTC-4, Thiago Macieira wrote:
>
> On segunda-feira, 31 de julho de 2017 11:05:09 PDT Nicol Bolas wrote:
> > Well, the C++ language doesn't work well with that, since members must
> be
> > initialized in the order they're presented in the class definition. In
> C++,
> > changing the order of members is not a backwards-incompatible change,
> and
> > designated initializers will not change that.
>
> Only because we say it is. There's nothing else preventing initialisation
> in
> any order for trivial types.
>

Well, there's the question I just posted. Do you know if that code is legal
at present? If it is legal, then that would most assuredly prevent
arbitrary initialization ordering for members, even for trivial types.

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

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

<div dir=3D"ltr">On Monday, July 31, 2017 at 2:24:46 PM UTC-4, Thiago Macie=
ira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On segunda-feira, 31=
 de julho de 2017 11:05:09 PDT Nicol Bolas wrote:
<br>&gt; Well, the C++ language doesn&#39;t work well with that, since memb=
ers must be
<br>&gt; initialized in the order they&#39;re presented in the class defini=
tion. In C++,
<br>&gt; changing the order of members is not a backwards-incompatible chan=
ge, and
<br>&gt; designated initializers will not change that.
<br>
<br>Only because we say it is. There&#39;s nothing else preventing initiali=
sation in=20
<br>any order for trivial types.
<br></blockquote><div><br>Well, there&#39;s the question I just posted. Do =
you know if that code is legal at present? If it is legal, then that would =
most assuredly prevent arbitrary initialization ordering for members, even =
for trivial types.<br></div></div>

<p></p>

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

------=_Part_4192_950874656.1501526044868--

------=_Part_4191_573151425.1501526044868--

.

On segunda-feira, 31 de julho de 2017 11:34:04 PDT Nicol Bolas wrote:
> Well, there's the question I just posted. Do you know if that code is legal
> at present? If it is legal, then that would most assuredly prevent
> arbitrary initialization ordering for members, even for trivial types.

I don't know if it is. It definitely isn't for non-trivial types, but I don't
know if it should be allowed for trivial ones. The question to be answered is
whether the evaluation of a.x happens before the assignment of 5 to it in the
brace initialiser.

If we say that in a trivial type's brace initialisation each type is
initialised left-to-right and evaluation happens independently, then it would
be valid.

I don't think we want to say that. That would be supported by the fact that
P0329 also disallows reusing a member in the expression for initialisation of
another type (which C99 allows and I'm not asking for).

Either way, that doesn't stop us from allowing:

 Agg a { .y = 5, .x = 5 };

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

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

.

------=_Part_4556_1431543901.1501533412009
Content-Type: multipart/alternative;
 boundary="----=_Part_4557_1035457983.1501533412009"

------=_Part_4557_1035457983.1501533412009
Content-Type: text/plain; charset="UTF-8"


>
> Here's the question I have with list and aggregate initialization. Is this
> well-defined, currently:
>
> struct Agg
> {
>   int x, y;
> };
>
> Agg a{5, a.x};
>
> In a braced-init-list, the initializing expressions are evaluated in the
> order they appear. So it could be that the initialization of `a.x` happens
> before the expression to start initializing `a.y`. If that is the case,
> then it's basically impossible to do this out-of-order. Even for trivial
> types, the initializers could depend on each other in very funky ways.
>
> Personally, I hope that it is not well-defined.
>
>
I think that's well-formed. Each element's initialization is sequenced
before the next element's initialization
(http://eel.is/c++draft/dcl.init.aggr#6), so we'd copy-initialize a.x from
5 and then copy-initialize a.y from a.x.

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

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

<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>Here&#39=
;s the question I have with list and aggregate initialization. Is this well=
-defined, currently:<br><br><div style=3D"background-color:rgb(250,250,250)=
;border-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><=
div><span style=3D"color:#008">struct</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#606">Agg</span><span style=3D"color:#000"><br></s=
pan><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=
=A0 </span><span style=3D"color:#008">int</span><span style=3D"color:#000">=
 x</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> y</=
span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br></sp=
an><span style=3D"color:#660">};</span><span style=3D"color:#000"><br><br><=
/span><span style=3D"color:#606">Agg</span><span style=3D"color:#000"> a</s=
pan><span style=3D"color:#660">{</span><span style=3D"color:#066">5</span><=
span style=3D"color:#660">,</span><span style=3D"color:#000"> a</span><span=
 style=3D"color:#660">.</span><span style=3D"color:#000">x</span><span styl=
e=3D"color:#660">};</span></div></code></div><br>In a braced-init-list, the=
 initializing expressions are evaluated in the order they appear. So it cou=
ld be that the initialization of `a.x` happens before the expression to sta=
rt initializing `a.y`. If that is the case, then it&#39;s basically impossi=
ble to do this out-of-order. Even for trivial types, the initializers could=
 depend on each other in very funky ways.<br><br>Personally, I hope that it=
 is not well-defined.<br><br></div></div></blockquote><div><br></div><div>I=
 think that&#39;s well-formed. Each element&#39;s initialization is sequenc=
ed before the next element&#39;s initialization (http://eel.is/c++draft/dcl=
..init.aggr#6), so we&#39;d copy-initialize a.x from 5 and then copy-initial=
ize a.y from a.x.=C2=A0</div>

<p></p>

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

------=_Part_4557_1035457983.1501533412009--

------=_Part_4556_1431543901.1501533412009--

.

------=_Part_4577_1855405726.1501535282258
Content-Type: multipart/alternative;
 boundary="----=_Part_4578_1764620003.1501535282258"

------=_Part_4578_1764620003.1501535282258
Content-Type: text/plain; charset="UTF-8"



On Monday, July 31, 2017 at 4:36:52 PM UTC-4, Barry Revzin wrote:
>
> Here's the question I have with list and aggregate initialization. Is this
>> well-defined, currently:
>>
>> struct Agg
>> {
>>   int x, y;
>> };
>>
>> Agg a{5, a.x};
>>
>> In a braced-init-list, the initializing expressions are evaluated in the
>> order they appear. So it could be that the initialization of `a.x` happens
>> before the expression to start initializing `a.y`. If that is the case,
>> then it's basically impossible to do this out-of-order. Even for trivial
>> types, the initializers could depend on each other in very funky ways.
>>
>> Personally, I hope that it is not well-defined.
>>
>>
> I think that's well-formed. Each element's initialization is sequenced
> before the next element's initialization (
> http://eel.is/c++draft/dcl.init.aggr#6), so we'd copy-initialize a.x from
> 5 and then copy-initialize a.y from a.x.
>

That must be a very recent change, because N4659 doesn't say that
<https://timsong-cpp.github.io/cppwp/n4659/dcl.init.aggr>. I wonder where
that line came from. For the sake of clarity, [dcl.init.aggr]/6 says:

> The initializations of the elements of the aggregate are evaluated in the
element order. That is, all value computations and side effects associated
with a given element are sequenced before those of any element that follows
it in order.


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

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

<div dir=3D"ltr"><br><br>On Monday, July 31, 2017 at 4:36:52 PM UTC-4, Barr=
y Revzin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr"><div>Here&#39;s the question I ha=
ve with list and aggregate initialization. Is this well-defined, currently:=
<br><br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(18=
7,187,187);border-style:solid;border-width:1px"><code><div><span style=3D"c=
olor:#008">struct</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#606">Agg</span><span style=3D"color:#000"><br></span><span style=3D"c=
olor:#660">{</span><span style=3D"color:#000"><br>=C2=A0 </span><span style=
=3D"color:#008">int</span><span style=3D"color:#000"> x</span><span style=
=3D"color:#660">,</span><span style=3D"color:#000"> y</span><span style=3D"=
color:#660">;</span><span style=3D"color:#000"><br></span><span style=3D"co=
lor:#660">};</span><span style=3D"color:#000"><br><br></span><span style=3D=
"color:#606">Agg</span><span style=3D"color:#000"> a</span><span style=3D"c=
olor:#660">{</span><span style=3D"color:#066">5</span><span style=3D"color:=
#660">,</span><span style=3D"color:#000"> a</span><span style=3D"color:#660=
">.</span><span style=3D"color:#000">x</span><span style=3D"color:#660">};<=
/span></div></code></div><br>In a braced-init-list, the initializing expres=
sions are evaluated in the order they appear. So it could be that the initi=
alization of `a.x` happens before the expression to start initializing `a.y=
`. If that is the case, then it&#39;s basically impossible to do this out-o=
f-order. Even for trivial types, the initializers could depend on each othe=
r in very funky ways.<br><br>Personally, I hope that it is not well-defined=
..<br><br></div></div></blockquote><div><br></div><div>I think that&#39;s we=
ll-formed. Each element&#39;s initialization is sequenced before the next e=
lement&#39;s initialization (<a href=3D"http://eel.is/c++draft/dcl.init.agg=
r#6" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;htt=
p://www.google.com/url?q\x3dhttp%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fdcl.init.a=
ggr%236\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEf8Af8__RrmBrkds4P2ODxPePyx=
Q&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?=
q\x3dhttp%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fdcl.init.aggr%236\x26sa\x3dD\x26s=
ntz\x3d1\x26usg\x3dAFQjCNEf8Af8__RrmBrkds4P2ODxPePyxQ&#39;;return true;">ht=
tp://eel.is/c++draft/dcl.<wbr>init.aggr#6</a>), so we&#39;d copy-initialize=
 a.x from 5 and then copy-initialize a.y from a.x.=C2=A0</div></blockquote>=
<div><br>That must be a very recent change, because <a href=3D"https://tims=
ong-cpp.github.io/cppwp/n4659/dcl.init.aggr">N4659 doesn&#39;t say that</a>=
.. I wonder where that line came from. For the sake of clarity, [dcl.init.ag=
gr]/6 says:<br><br>&gt; The initializations of the elements of the aggregat=
e are evaluated in the element order. That is, all value computations and s=
ide effects associated with a given element are sequenced before those of a=
ny element that follows it in order.<br><br><br></div></div>

<p></p>

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

------=_Part_4578_1764620003.1501535282258--

------=_Part_4577_1855405726.1501535282258--

.

2017-07-31 23:08 GMT+02:00 Nicol Bolas <jmckesson@gmail.com>:
> On Monday, July 31, 2017 at 4:36:52 PM UTC-4, Barry Revzin wrote:
>> I think that's well-formed. Each element's initialization is sequenced
>> before the next element's initialization
>> (http://eel.is/c++draft/dcl.init.aggr#6), so we'd copy-initialize a.x from 5
>> and then copy-initialize a.y from a.x.
>
> That must be a very recent change, because N4659 doesn't say that. I wonder
> where that line came from.

It was part starting from the first p0329 wording,

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0329r2.pdf

and was voted in by acceptance of p0329r4 during the Toronto meeting
(Soon visible in the publication list).

- Daniel

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

.

------=_Part_4689_607017994.1501536617204
Content-Type: multipart/alternative;
 boundary="----=_Part_4690_1587485540.1501536617205"

------=_Part_4690_1587485540.1501536617205
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Monday, July 31, 2017 at 5:23:47 PM UTC-4, Daniel Kr=C3=BCgler wrote:
>
> 2017-07-31 23:08 GMT+02:00 Nicol Bolas <jmck...@gmail.com <javascript:>>:=
=20
> > On Monday, July 31, 2017 at 4:36:52 PM UTC-4, Barry Revzin wrote:=20
> >> I think that's well-formed. Each element's initialization is sequenced=
=20
> >> before the next element's initialization=20
> >> (http://eel.is/c++draft/dcl.init.aggr#6), so we'd copy-initialize a.x=
=20
> from 5=20
> >> and then copy-initialize a.y from a.x.=20
> >=20
> > That must be a very recent change, because N4659 doesn't say that. I=20
> wonder=20
> > where that line came from.=20
>
> It was part starting from the first p0329 wording,=20
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0329r2.pdf=20
>
> and was voted in by acceptance of p0329r4 during the Toronto meeting=20
> (Soon visible in the publication list).
>

Oh, so that's not actually part of C++17. Well, that changes things.

The point of the question was to determine if it was legal for people to=20
write code where the initialization expressions could rely on=20
initialization order. If that wasn't the case, then we could have unordered=
=20
designated initializers (for trivial types only) by specifying that the=20
expressions are resolved in the order of the braced-init-list, but they=20
initialize the objects in the order they appear in the aggregate. This=20
would allow the "as if" rule to come into play, allowing implementations to=
=20
do what they like, while still allowing us to know that subobjects are=20
initialized in order.

The goal was to avoid doing what Thaigo's suggestion would require:=20
completely redefining member subobject initialization order rules.

So long as we make it undefined again before C++20 comes out, then we can=
=20
take the quick route to doing so.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/486a9a6d-85c2-484b-9f1a-628bf66059f6%40isocpp.or=
g.

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

<div dir=3D"ltr">On Monday, July 31, 2017 at 5:23:47 PM UTC-4, Daniel Kr=C3=
=BCgler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">2017-07-31 23:08=
 GMT+02:00 Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"vur9IPGRBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">jmck...@gmail.com</a>&gt;:
<br>&gt; On Monday, July 31, 2017 at 4:36:52 PM UTC-4, Barry Revzin wrote:
<br>&gt;&gt; I think that&#39;s well-formed. Each element&#39;s initializat=
ion is sequenced
<br>&gt;&gt; before the next element&#39;s initialization
<br>&gt;&gt; (<a href=3D"http://eel.is/c++draft/dcl.init.aggr#6" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fdcl.init.aggr%236\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEf8Af8__RrmBrkds4P2ODxPePyxQ&#39;;return t=
rue;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F=
%2Feel.is%2Fc%2B%2Bdraft%2Fdcl.init.aggr%236\x26sa\x3dD\x26sntz\x3d1\x26usg=
\x3dAFQjCNEf8Af8__RrmBrkds4P2ODxPePyxQ&#39;;return true;">http://eel.is/c++=
draft/dcl.<wbr>init.aggr#6</a>), so we&#39;d copy-initialize a.x from 5
<br>&gt;&gt; and then copy-initialize a.y from a.x.
<br>&gt;
<br>&gt; That must be a very recent change, because N4659 doesn&#39;t say t=
hat. I wonder
<br>&gt; where that line came from.
<br>
<br>It was part starting from the first p0329 wording,
<br>
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p032=
9r2.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39=
;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22=
%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0329r2.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg=
\x3dAFQjCNE2XCQifxuu4NtLI-daqvyDT33HjA&#39;;return true;" onclick=3D"this.h=
ref=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fj=
tc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0329r2.pdf\x26sa\x3dD\x26sntz\x=
3d1\x26usg\x3dAFQjCNE2XCQifxuu4NtLI-daqvyDT33HjA&#39;;return true;">http://=
www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2016/<wbr>p0329r2.pdf</a>
<br>
<br>and was voted in by acceptance of p0329r4 during the Toronto meeting
<br>(Soon visible in the publication list).<br></blockquote><div><br>Oh, so=
 that&#39;s not actually part of C++17. Well, that changes things.<br><br>T=
he point of the question was to determine if it was legal for people to wri=
te code where the initialization expressions could rely on initialization o=
rder. If that wasn&#39;t the case, then we could have unordered designated =
initializers (for trivial types only) by specifying that the expressions ar=
e resolved in the order of the=20
braced-init-list, but they initialize the objects in the order they=20
appear in the aggregate. This would allow the &quot;as if&quot; rule to com=
e into=20
play, allowing implementations to do what they like, while still allowing u=
s to know that subobjects are initialized in order.<br><br>The goal was to =
avoid doing what Thaigo&#39;s suggestion would require: completely redefini=
ng member subobject=20
initialization order rules.<br><br>So long as we make it undefined again be=
fore C++20 comes out, then we can take the quick route to doing so.<br></di=
v></div>

<p></p>

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

------=_Part_4690_1587485540.1501536617205--

------=_Part_4689_607017994.1501536617204--

.

------=_Part_2190_1282343732.1501542454380
Content-Type: multipart/alternative;
 boundary="----=_Part_2191_458982960.1501542454380"

------=_Part_2191_458982960.1501542454380
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


My suggestion would be that designated initializers can be written in any=
=20
order, but are executed in the order of the struct declaration. As an extra=
=20
rule the compiler can (must?) check that members are not refered before=20
they are initialized.

I really dislike the idea of forcing users to write designated initializers=
=20
in the same order as the struct declaration have them, not only as the=20
library writer may change the order but more importantly that designated=20
initializers are most useful when you have many members and only initialize=
=20
a few with non-default values and remembering the order in this case is=20
much harder than remembering the names.

Are there other problems with allowing any order of designated initializers=
=20
besides checking that not yet initialized members are not referred? In my=
=20
experience initiing one member from another is very rarely useful, so even=
=20
if reordering the fields of the struct has a potential to cause compiler=20
errors when compiling users of the struct I don't think this would case=20
very many real problems. If this is the concern I would rather forbid=20
refering to other members from initializers if there are any designators in=
=20
the initializer.

Den m=C3=A5ndag 31 juli 2017 kl. 23:30:17 UTC+2 skrev Nicol Bolas:
>
> On Monday, July 31, 2017 at 5:23:47 PM UTC-4, Daniel Kr=C3=BCgler wrote:
>>
>> 2017-07-31 23:08 GMT+02:00 Nicol Bolas <jmck...@gmail.com>:=20
>> > On Monday, July 31, 2017 at 4:36:52 PM UTC-4, Barry Revzin wrote:=20
>> >> I think that's well-formed. Each element's initialization is sequence=
d=20
>> >> before the next element's initialization=20
>> >> (http://eel.is/c++draft/dcl.init.aggr#6), so we'd copy-initialize a.x=
=20
>> from 5=20
>> >> and then copy-initialize a.y from a.x.=20
>> >=20
>> > That must be a very recent change, because N4659 doesn't say that. I=
=20
>> wonder=20
>> > where that line came from.=20
>>
>> It was part starting from the first p0329 wording,=20
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0329r2.pdf=20
>>
>> and was voted in by acceptance of p0329r4 during the Toronto meeting=20
>> (Soon visible in the publication list).
>>
>
> Oh, so that's not actually part of C++17. Well, that changes things.
>
> The point of the question was to determine if it was legal for people to=
=20
> write code where the initialization expressions could rely on=20
> initialization order. If that wasn't the case, then we could have unorder=
ed=20
> designated initializers (for trivial types only) by specifying that the=
=20
> expressions are resolved in the order of the braced-init-list, but they=
=20
> initialize the objects in the order they appear in the aggregate. This=20
> would allow the "as if" rule to come into play, allowing implementations =
to=20
> do what they like, while still allowing us to know that subobjects are=20
> initialized in order.
>
> The goal was to avoid doing what Thaigo's suggestion would require:=20
> completely redefining member subobject initialization order rules.
>
> So long as we make it undefined again before C++20 comes out, then we can=
=20
> take the quick route to doing so.
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/877324f2-db4b-4fb4-b707-12c5601a0a79%40isocpp.or=
g.

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

<div dir=3D"ltr"><div><font color=3D"#666600" face=3D"monospace"><br></font=
></div><div>My suggestion would be that designated initializers can be writ=
ten in any order, but are executed in the order of the struct declaration. =
As an extra rule the compiler can (must?) check that members are not refere=
d before they are initialized.</div><div><br></div><div>I really dislike th=
e idea of forcing users to write designated initializers in the same order =
as the struct declaration have them, not only as the library writer may cha=
nge the order but more importantly that designated initializers are most us=
eful when you have many members and only initialize a few with non-default =
values and remembering the order in this case is much harder than rememberi=
ng the names.</div><div><br></div><div>Are there other problems with allowi=
ng any order of designated initializers besides checking that not yet initi=
alized members are not referred? In my experience initiing one member from =
another is very rarely useful, so even if reordering the fields of the stru=
ct has a potential to cause compiler errors when compiling users of the str=
uct I don&#39;t think this would case very many real problems. If this is t=
he concern I would rather forbid refering to other members from initializer=
s if there are any designators in the initializer.</div><div><br>Den m=C3=
=A5ndag 31 juli 2017 kl. 23:30:17 UTC+2 skrev Nicol Bolas:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr">On Monday, July 31, 2017 at 5:=
23:47 PM UTC-4, Daniel Kr=C3=BCgler wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">2017-07-31 23:08 GMT+02:00 Nicol Bolas &lt;<a rel=3D"nofollow">jmck.=
...@gmail.com</a>&gt;:
<br>&gt; On Monday, July 31, 2017 at 4:36:52 PM UTC-4, Barry Revzin wrote:
<br>&gt;&gt; I think that&#39;s well-formed. Each element&#39;s initializat=
ion is sequenced
<br>&gt;&gt; before the next element&#39;s initialization
<br>&gt;&gt; (<a href=3D"http://eel.is/c++draft/dcl.init.aggr#6" rel=3D"nof=
ollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fdcl.init.aggr%236\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEf8Af8__RrmBrkds4P2ODxPePyxQ&#39;;return t=
rue;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F=
%2Feel.is%2Fc%2B%2Bdraft%2Fdcl.init.aggr%236\x26sa\x3dD\x26sntz\x3d1\x26usg=
\x3dAFQjCNEf8Af8__RrmBrkds4P2ODxPePyxQ&#39;;return true;">http://eel.is/c++=
draft/dcl.<wbr>init.aggr#6</a>), so we&#39;d copy-initialize a.x from 5
<br>&gt;&gt; and then copy-initialize a.y from a.x.
<br>&gt;
<br>&gt; That must be a very recent change, because N4659 doesn&#39;t say t=
hat. I wonder
<br>&gt; where that line came from.
<br>
<br>It was part starting from the first p0329 wording,
<br>
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p032=
9r2.pdf" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39=
;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22=
%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0329r2.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg=
\x3dAFQjCNE2XCQifxuu4NtLI-daqvyDT33HjA&#39;;return true;" onclick=3D"this.h=
ref=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fj=
tc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0329r2.pdf\x26sa\x3dD\x26sntz\x=
3d1\x26usg\x3dAFQjCNE2XCQifxuu4NtLI-daqvyDT33HjA&#39;;return true;">http://=
www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2016/<wbr>p0329r2.pdf</a>
<br>
<br>and was voted in by acceptance of p0329r4 during the Toronto meeting
<br>(Soon visible in the publication list).<br></blockquote><div><br>Oh, so=
 that&#39;s not actually part of C++17. Well, that changes things.<br><br>T=
he point of the question was to determine if it was legal for people to wri=
te code where the initialization expressions could rely on initialization o=
rder. If that wasn&#39;t the case, then we could have unordered designated =
initializers (for trivial types only) by specifying that the expressions ar=
e resolved in the order of the=20
braced-init-list, but they initialize the objects in the order they=20
appear in the aggregate. This would allow the &quot;as if&quot; rule to com=
e into=20
play, allowing implementations to do what they like, while still allowing u=
s to know that subobjects are initialized in order.<br><br>The goal was to =
avoid doing what Thaigo&#39;s suggestion would require: completely redefini=
ng member subobject=20
initialization order rules.<br><br>So long as we make it undefined again be=
fore C++20 comes out, then we can take the quick route to doing so.<br></di=
v></div></blockquote></div></div>

<p></p>

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

------=_Part_2191_458982960.1501542454380--

------=_Part_2190_1282343732.1501542454380--

.

On segunda-feira, 31 de julho de 2017 16:07:34 PDT Bengt Gustafsson wrote:
> Are there other problems with allowing any order of designated initializers
> besides checking that not yet initialized members are not referred? In my
> experience initiing one member from another is very rarely useful, so even
> if reordering the fields of the struct has a potential to cause compiler
> errors when compiling users of the struct I don't think this would case
> very many real problems. If this is the concern I would rather forbid
> refering to other members from initializers if there are any designators in
> the initializer.

For non-trivial, yes, there are issues. Take this example:

struct Agg
{
 SubObj1 a;
 SubObj2 b;
};

 Agg a = { .b = 1, .a = 2 };

What happens if b's constructor throws?

That's why I am asking for the any order permission to apply only to trivial
types. Which all structs defined in headers meant to be consumed by C are.

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

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

.

------=_Part_4632_1722305526.1501548584111
Content-Type: multipart/alternative;
 boundary="----=_Part_4633_882360961.1501548584111"

------=_Part_4633_882360961.1501548584111
Content-Type: text/plain; charset="UTF-8"

On Monday, July 31, 2017 at 7:07:34 PM UTC-4, Bengt Gustafsson wrote:
>
>
> My suggestion would be that designated initializers can be written in any
> order, but are executed in the order of the struct declaration. As an extra
> rule the compiler can (must?) check that members are not refered before
> they are initialized.
>
> I really dislike the idea of forcing users to write designated
> initializers in the same order as the struct declaration have them, not
> only as the library writer may change the order but more importantly that
> designated initializers are most useful when you have many members and only
> initialize a few with non-default values and remembering the order in this
> case is much harder than remembering the names.
>
> Are there other problems with allowing any order of designated
> initializers besides checking that not yet initialized members are not
> referred?
>

Yes.

Braced-init-lists have a very simple rule at present: the expressions are
executed in the order they appear. This will be true, whether they call a
constructor or initialize an aggregate.

What this will do is turn that rule into a much more complex one. To know
the order that those expressions will be executed in, you must look at
non-local code. And therefore, it becomes very possible to make two
expressions in a braced-init-list depend on the order of execution, but to
have that order no longer match the visible order of the expressions. Or
worse, that your code works fine at one point, but then a change to the
order of the members causes a silent breakage. With enforced ordering, it's
a noisy breakage.

This is the fundamental reason why allowing member initializers to work
this way was a bad idea. This will effectively lead to compilers having to
issue warnings about designated initializers being executed out of their
apparent order.


> In my experience initiing one member from another is very rarely useful,
> so even if reordering the fields of the struct has a potential to cause
> compiler errors when compiling users of the struct I don't think this would
> case very many real problems. If this is the concern I would rather forbid
> refering to other members from initializers if there are any designators in
> the initializer.
>

You cannot effectively forbid that sort of thing. You can always have one
initializer reference itself by getting a pointer and storing it locally,
then have another initializer expression read from that pointer. Or have
two functions which have some shared state, such that their order of
execution matters. And so forth.

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

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

<div dir=3D"ltr">On Monday, July 31, 2017 at 7:07:34 PM UTC-4, Bengt Gustaf=
sson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><d=
iv><font color=3D"#666600" face=3D"monospace"><br></font></div><div>My sugg=
estion would be that designated initializers can be written in any order, b=
ut are executed in the order of the struct declaration. As an extra rule th=
e compiler can (must?) check that members are not refered before they are i=
nitialized.</div><div><br></div><div>I really dislike the idea of forcing u=
sers to write designated initializers in the same order as the struct decla=
ration have them, not only as the library writer may change the order but m=
ore importantly that designated initializers are most useful when you have =
many members and only initialize a few with non-default values and remember=
ing the order in this case is much harder than remembering the names.</div>=
<div><br></div><div>Are there other problems with allowing any order of des=
ignated initializers besides checking that not yet initialized members are =
not referred?</div></div></blockquote><div><br>Yes.<br><br>Braced-init-list=
s have a very simple rule at present: the expressions are executed in the o=
rder they appear. This will be true, whether they call a constructor or ini=
tialize an aggregate.<br><br>What this will do is turn that rule into a muc=
h more complex one. To know the order that those expressions will be execut=
ed in, you must look at non-local code. And therefore, it becomes very poss=
ible to make two expressions in a braced-init-list depend on the order of e=
xecution, but to have that order no longer match the visible order of the e=
xpressions. Or worse, that your code works fine at one point, but then a ch=
ange to the order of the members causes a silent breakage. With enforced or=
dering, it&#39;s a noisy breakage.<br><br>This is the fundamental reason wh=
y allowing member initializers to work this way was a bad idea. This will e=
ffectively lead to compilers having to issue warnings about designated init=
ializers being executed out of their apparent order.<br>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>In my experienc=
e initiing one member from another is very rarely useful, so even if reorde=
ring the fields of the struct has a potential to cause compiler errors when=
 compiling users of the struct I don&#39;t think this would case very many =
real problems. If this is the concern I would rather forbid refering to oth=
er members from initializers if there are any designators in the initialize=
r.</div></div></blockquote><div><br>You cannot effectively forbid that sort=
 of thing. You can always have one initializer reference itself by getting =
a pointer and storing it locally, then have another initializer expression =
read from that pointer. Or have two functions which have some shared state,=
 such that their order of execution matters. And so forth.</div></div>

<p></p>

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

------=_Part_4633_882360961.1501548584111--

------=_Part_4632_1722305526.1501548584111--

.

On Mon, Jul 31, 2017 at 2:42 PM, Thiago Macieira <thiago@macieira.org> wrote:
> It definitely isn't for non-trivial types, but I don't
> know if it should be allowed for trivial ones.
>
> [...]
>
> Either way, that doesn't stop us from allowing:
>
>         Agg a { .y = 5, .x = 5 };
>

I've stated my concern with dividing the feature
into trivial types only and those not -- it brings
damage when the library evolves.

However, I feel it's more acceptable if we allocate
a syntax to let people opt-in.  I mean, what if
such a discrimination happens only when a
user asks for it by using the = { ... } initializer
(copy-init syntax)?  Examples:

  Agg a = { .y = 5, .x = 5 };  // ok
  Agg b { .y = 5, .x = 5 };  // no
  struct X { Agg a; };
  X c { { .a{ .y = 5, .x = 5 } };  // no
  X c { { .a = { .y = 5, .x = 5 } };  // ok

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________

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

.

------=_Part_76_1858211338.1501557189300
Content-Type: multipart/alternative;
 boundary="----=_Part_77_279750495.1501557189300"

------=_Part_77_279750495.1501557189300
Content-Type: text/plain; charset="UTF-8"

On Monday, July 31, 2017 at 10:28:55 PM UTC-4, Zhihao Yuan wrote:
>
> On Mon, Jul 31, 2017 at 2:42 PM, Thiago Macieira <thi...@macieira.org
> <javascript:>> wrote:
> > It definitely isn't for non-trivial types, but I don't
> > know if it should be allowed for trivial ones.
> >
> > [...]
> >
> > Either way, that doesn't stop us from allowing:
> >
> >         Agg a { .y = 5, .x = 5 };
> >
>
> I've stated my concern with dividing the feature
> into trivial types only and those not -- it brings
> damage when the library evolves.
>
> However, I feel it's more acceptable if we allocate
> a syntax to let people opt-in.  I mean, what if
> such a discrimination happens only when a
> user asks for it by using the = { ... } initializer
> (copy-init syntax)?


Right, because the thing we most need to do is make "uniform
initialization" *less uniform*.

No, having copy-list-initialization work (almost) exactly like
direct-list-initialization is one of the best aspects of
list-initialization. We should not undo that lightly.

If unordered designated initializers are dangerous enough to need their own
special syntax, then they're too dangerous for C++.

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

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

<div dir=3D"ltr">On Monday, July 31, 2017 at 10:28:55 PM UTC-4, Zhihao Yuan=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Mon, Jul 31, 2017 at=
 2:42 PM, Thiago Macieira &lt;<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"qUKfw5eiBAAJ" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;">thi...@macieira.org</a>&gt; wrote:
<br>&gt; It definitely isn&#39;t for non-trivial types, but I don&#39;t
<br>&gt; know if it should be allowed for trivial ones.
<br>&gt;
<br>&gt; [...]
<br>&gt;
<br>&gt; Either way, that doesn&#39;t stop us from allowing:
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 Agg a { .y =3D 5, .x =3D 5 };
<br>&gt;
<br>
<br>I&#39;ve stated my concern with dividing the feature
<br>into trivial types only and those not -- it brings
<br>damage when the library evolves.
<br>
<br>However, I feel it&#39;s more acceptable if we allocate
<br>a syntax to let people opt-in. =C2=A0I mean, what if
<br>such a discrimination happens only when a
<br>user asks for it by using the =3D { ... } initializer
<br>(copy-init syntax)?</blockquote><div><br>Right, because the thing we mo=
st need to do is make &quot;uniform initialization&quot; <i>less uniform</i=
>.<br><br>No, having copy-list-initialization work (almost) exactly like di=
rect-list-initialization is one of the best aspects of list-initialization.=
 We should not undo that lightly.<br><br>If unordered designated initialize=
rs are dangerous enough to need their own special syntax, then they&#39;re =
too dangerous for C++.</div></div>

<p></p>

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

------=_Part_77_279750495.1501557189300--

------=_Part_76_1858211338.1501557189300--

.

On segunda-feira, 31 de julho de 2017 19:28:51 PDT Zhihao Yuan wrote:
> > Either way, that doesn't stop us from allowing:
> >         Agg a { .y = 5, .x = 5 };
>
> I've stated my concern with dividing the feature
> into trivial types only and those not -- it brings
> damage when the library evolves.

Understood, but it cannot happen for C structures. C developers are the ones
who write structures without constructors and are used to designated
initialisers. It's their structures we have to worry about changing layout.

C++ developers usually add constructors.

> However, I feel it's more acceptable if we allocate
> a syntax to let people opt-in.  I mean, what if
> such a discrimination happens only when a
> user asks for it by using the = { ... } initializer
> (copy-init syntax)?  Examples:
>
>   Agg a = { .y = 5, .x = 5 };  // ok
>   Agg b { .y = 5, .x = 5 };  // no
>   struct X { Agg a; };
>   X c { { .a{ .y = 5, .x = 5 } };  // no
>   X c { { .a = { .y = 5, .x = 5 } };  // ok

How about:

 X = { .a.x = 5, .a.y = 5 }; // ok or not?


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

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

.

On Tue, Aug 1, 2017 at 12:15 AM, Thiago Macieira <thiago@macieira.org> wrote:
>
> C++ developers usually add constructors.
>

That will be too ideal.  There is a difference
between you break intentionally, and you
break without knowing...

>>   struct X { Agg a; };
>>   X c { { .a{ .y = 5, .x = 5 } };  // no
>>   X c { { .a = { .y = 5, .x = 5 } };  // ok
>
> How about:
>
>         X = { .a.x = 5, .a.y = 5 };     // ok or not?
>

I think yes.  But my idea seems lacking
support.  One of the co-authors does
not consider this subtle difference to be
teachable.  The last time we discriminated
= {} from {} to support "C-only" rules was
in C++11, to limit brace elision, but later
we just enabled it to {} as well :(

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________

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

.

On Wed, Jul 26, 2017 at 11:19 AM, 'Matt Calabrese' via ISO C++
Standard - Future Proposals <std-proposals@isocpp.org> wrote:
>
> IIUC, you can still get constant initialization and also avoid dependence on
> member order even in that case. It doesn't require designated initializers:
>
> https://godbolt.org/g/nSk8cr
>

This is such a kind of smart solution, which
I personally would be totally fine to practice,
but if being a leader on a team, I can't really
decide to make it into the coding style lol.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________

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

.

On segunda-feira, 31 de julho de 2017 22:36:07 PDT Zhihao Yuan wrote:
> > C++ developers usually add constructors.
>
> That will be too ideal.  There is a difference
> between you break intentionally, and you
> break without knowing...

By adding or replacing a meber with a non-trivial one or by adding an explicit
constructor, a lot of things change. For example, until we get destructive
moves, std::vector will suddenly become less efficient if you make your type
non-trivial. Developers have to, unfortunately, be quite aware of the issue.

Again, my worry is C developers who aren't used to C++ limitations.

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

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

.

------=_Part_4823_2061646543.1501572228124
Content-Type: multipart/alternative;
 boundary="----=_Part_4824_12583765.1501572228124"

------=_Part_4824_12583765.1501572228124
Content-Type: text/plain; charset="UTF-8"

On Monday, July 31, 2017 at 9:05:10 PM UTC+3, Nicol Bolas wrote:
>
> Well, the C++ language doesn't work well with that, since members must be
> initialized in the order they're presented in the class definition. In C++,
> changing the order of members is not a backwards-incompatible change, and
> designated initializers will not change that.
>

POSIX for example never specifies the order of members. Also it doesn't
specify full set of members, just required ones:

The *<time.h>* header shall declare the *timespec* structure, which shall
> include at least the following members:
>
> time_t  tv_sec    Seconds.
> long    tv_nsec   Nanoseconds.
>
>
So when we write cross-platform code we want sometimes use structure
initialization but don't want depend on members order and exact number of
them:

struct TimeSpec : public ::timespec
{
    constexpr TimeSpec(time_t sec, long nsec)
        : ::timespec{.tv_sec = sec, .tv_nsec = nsec} {}
};

The order of initialization must not change! There is the only
initialization order in C++: order of members declaration. The compiler can
emit warning as with constructor init-list. Can't we just adopt the same
rule as for constructor init-list? (And I don't think that this rule was a
mistake as it was stated above)

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

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

<div dir=3D"ltr">On Monday, July 31, 2017 at 9:05:10 PM UTC+3, Nicol Bolas =
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">Well, t=
he C++ language doesn&#39;t work well with that, since members must be init=
ialized in the order they&#39;re presented in the class definition. In C++,=
 changing the order of members is not a backwards-incompatible change, and =
designated initializers will not change that.</div></blockquote><div><br>PO=
SIX for example never specifies the order of members. Also it doesn&#39;t s=
pecify full set of members, just required ones:<br><br><blockquote class=3D=
"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rg=
b(204, 204, 204); padding-left: 1ex;"><p style=3D"color: rgb(0, 0, 0); font=
-family: Verdana,Arial,Helvetica,sans-serif; font-style: normal; font-varia=
nt-ligatures: normal; font-variant-caps: normal; font-weight: normal; lette=
r-spacing: normal; text-align: start; text-indent: 0px; text-transform: non=
e; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
background-color: rgb(255, 255, 255); text-decoration-style: initial; text-=
decoration-color: initial;"><font size=3D"2">The<span>=C2=A0</span><i>&lt;t=
ime.h&gt;</i><span>=C2=A0</span>header shall declare the<span>=C2=A0</span>=
<b>timespec</b><span>=C2=A0</span>structure, which shall include at least t=
he following members:</font></p><pre style=3D"font-family: monospace; color=
: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-va=
riant-caps: normal; font-weight: normal; letter-spacing: normal; text-align=
: start; text-indent: 0px; text-transform: none; word-spacing: 0px; -webkit=
-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decorat=
ion-style: initial; text-decoration-color: initial;"><font size=3D"2"><tt>t=
ime_t  tv_sec   </tt> Seconds. <tt>
long    tv_nsec  </tt> Nanoseconds. <tt>
</tt></font></pre></blockquote><br>So when we write cross-platform code we =
want sometimes use structure initialization but don&#39;t want depend on me=
mbers order and exact number of them:<br><br><span style=3D"font-family: co=
urier new,monospace;">struct TimeSpec : public ::timespec<br>{<br>=C2=A0=C2=
=A0=C2=A0 constexpr TimeSpec(time_t sec, long nsec)<br>=C2=A0 =C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 : ::timespec{.tv_sec =3D sec, .tv_nsec =3D nsec} {}<br>}=
;<br></span><br>The order of initialization must not change! There is the o=
nly initialization order in C++: order of members declaration. The compiler=
 can emit warning as with constructor init-list. Can&#39;t we just adopt th=
e same rule as for constructor init-list? (And I don&#39;t think that this =
rule was a mistake as it was stated above)<br class=3D"Apple-interchange-ne=
wline"></div></div>

<p></p>

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

------=_Part_4824_12583765.1501572228124--

------=_Part_4823_2061646543.1501572228124--

.

------=_Part_4529_2092042447.1501572734747
Content-Type: multipart/alternative;
 boundary="----=_Part_4530_433116809.1501572734747"

------=_Part_4530_433116809.1501572734747
Content-Type: text/plain; charset="UTF-8"

More examples

const ::iovec v[] =
{
    ::iovec{.iov_base = buf1, .iov_len = buf1_len },
    ::iovec{.iov_base = buf2, .iov_len = buf2_len }
};
::writev(fd, v, array_size(v));

constexpr sockaddr_in my_endpoint =
{
    .sin_family = AF_INET,
    .sin_port = htons(123),
    .sin_addr = INADDR_ANY
};

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

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

<div dir=3D"ltr">More examples<br><br><span style=3D"font-family: courier n=
ew,monospace;">const ::iovec v[] =3D<br>{<br>=C2=A0=C2=A0=C2=A0 ::iovec{.io=
v_base =3D buf1, .iov_len =3D buf1_len },<br>=C2=A0=C2=A0=C2=A0 ::iovec{.io=
v_base =3D buf2, .iov_len =3D buf2_len }<br>};<br>::writev(fd, v, array_siz=
e(v));<br></span><br><span style=3D"font-family: courier new,monospace;">co=
nstexpr sockaddr_in my_endpoint =3D<br>{<br>=C2=A0=C2=A0=C2=A0 .sin_family =
=3D AF_INET,<br>=C2=A0=C2=A0=C2=A0 .sin_port =3D htons(123),<br>=C2=A0=C2=
=A0=C2=A0 .sin_addr =3D <span style=3D"color: rgb(0, 0, 0); font-size: 13.3=
333px; font-style: normal; font-variant-ligatures: normal; font-variant-cap=
s: normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; word-spacing: =
0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); =
text-decoration-style: initial; text-decoration-color: initial; display: in=
line !important; float: none;">INADDR_ANY</span><br>};</span><br></div>

<p></p>

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

------=_Part_4530_433116809.1501572734747--

------=_Part_4529_2092042447.1501572734747--

.

On Tue, Aug 01, 2017 at 12:32:14AM -0700, Victor Dyachenko wrote:
> More examples
>
> const ::iovec v[] =
> {
>     ::iovec{.iov_base = buf1, .iov_len = buf1_len },
>     ::iovec{.iov_base = buf2, .iov_len = buf2_len }
> };
> ::writev(fd, v, array_size(v));
>
> constexpr sockaddr_in my_endpoint =
> {
>     .sin_family = AF_INET,
>     .sin_port = htons(123),
>     .sin_addr = INADDR_ANY
> };

System headers contains lots of insanity.
This is copied from Linux/glibc.

struct sigaction
  {
    /* Signal handler.  */
#ifdef __USE_POSIX199309
    union
      {
        /* Used if SA_SIGINFO is not set.  */
        __sighandler_t sa_handler;
        /* Used if SA_SIGINFO is set.  */
        void (*sa_sigaction) (int, siginfo_t *, void *);
      }
    __sigaction_handler;
# define sa_handler     __sigaction_handler.sa_handler
# define sa_sigaction   __sigaction_handler.sa_sigaction
#else
    __sighandler_t sa_handler;
#endif
    /* more members follows */
  };

This also talks against disallowing member.submember = value initialization
since it is quite reasonable to assume that

sigaction sa = { .sa_handler = &function };

should work.

/MF

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

.

------=_Part_4925_1559972688.1501598162899
Content-Type: multipart/alternative;
 boundary="----=_Part_4926_362926653.1501598162899"

------=_Part_4926_362926653.1501598162899
Content-Type: text/plain; charset="UTF-8"

On Tuesday, August 1, 2017 at 3:23:48 AM UTC-4, Victor Dyachenko wrote:
>
> On Monday, July 31, 2017 at 9:05:10 PM UTC+3, Nicol Bolas wrote:
>>
>> Well, the C++ language doesn't work well with that, since members must be
>> initialized in the order they're presented in the class definition. In C++,
>> changing the order of members is not a backwards-incompatible change, and
>> designated initializers will not change that.
>>
>
> POSIX for example never specifies the order of members. Also it doesn't
> specify full set of members, just required ones:
>
> The *<time.h>* header shall declare the *timespec* structure, which shall
>> include at least the following members:
>>
>> time_t  tv_sec    Seconds.
>> long    tv_nsec   Nanoseconds.
>>
>>
> So when we write cross-platform code we want sometimes use structure
> initialization but don't want depend on members order and exact number of
> them:
>
> struct TimeSpec : public ::timespec
> {
>     constexpr TimeSpec(time_t sec, long nsec)
>         : ::timespec{.tv_sec = sec, .tv_nsec = nsec} {}
> };
>
> The order of initialization must not change! There is the only
> initialization order in C++: order of members declaration. The compiler can
> emit warning as with constructor init-list. Can't we just adopt the same
> rule as for constructor init-list? (And I don't think that this rule was a
> mistake as it was stated above)
>

The proof that the rule was a mistake is that compilers warn about it. If
it wasn't something worth warning people about, they wouldn't put the
warning there. So there is clearly an intent that the writer of the
constructor *ought* to put them in the right order.

And the same goes here.People generally don't like to leave spurious
warnings in their code if they can help it (this is 90% of the impetus for
allowing `container::size_type` to be signed). So the only code where this
warning will crop up is code where the user *needs* to declare them out of
order (as in the POSIX case).

If it's something that shouldn't be done (hence the warning), then we
should forbid it outright. And if it's something that should be done, then
we should do it in such a way that it does exactly what it looks like it
does.

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

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

<div dir=3D"ltr">On Tuesday, August 1, 2017 at 3:23:48 AM UTC-4, Victor Dya=
chenko 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">=
On Monday, July 31, 2017 at 9:05:10 PM UTC+3, Nicol Bolas wrote:<blockquote=
 class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr">Well, the C++ language doesn&=
#39;t work well with that, since members must be initialized in the order t=
hey&#39;re presented in the class definition. In C++, changing the order of=
 members is not a backwards-incompatible change, and designated initializer=
s will not change that.</div></blockquote><div><br>POSIX for example never =
specifies the order of members. Also it doesn&#39;t specify full set of mem=
bers, just required ones:<br><br><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><p style=3D"color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sa=
ns-serif;font-style:normal;font-weight:normal;letter-spacing:normal;text-al=
ign:start;text-indent:0px;text-transform:none;white-space:normal;word-spaci=
ng:0px;background-color:rgb(255,255,255)"><font size=3D"2">The<span>=C2=A0<=
/span><i>&lt;time.h&gt;</i><span>=C2=A0</span>header shall declare the<span=
>=C2=A0</span><b>timespec</b><span>=C2=A0</span>structure, which shall incl=
ude at least the following members:</font></p><pre style=3D"font-family:mon=
ospace;color:rgb(0,0,0);font-style:normal;font-weight:normal;letter-spacing=
:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0=
px;background-color:rgb(255,255,255)"><font size=3D"2"><tt>time_t  tv_sec  =
 </tt> Seconds. <tt>
long    tv_nsec  </tt> Nanoseconds. <tt>
</tt></font></pre></blockquote><br>So when we write cross-platform code we =
want sometimes use structure initialization but don&#39;t want depend on me=
mbers order and exact number of them:<br><br><span style=3D"font-family:cou=
rier new,monospace">struct TimeSpec : public ::timespec<br>{<br>=C2=A0=C2=
=A0=C2=A0 constexpr TimeSpec(time_t sec, long nsec)<br>=C2=A0 =C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 : ::timespec{.tv_sec =3D sec, .tv_nsec =3D nsec} {}<br>}=
;<br></span><br>The order of initialization must not change! There is the o=
nly initialization order in C++: order of members declaration. The compiler=
 can emit warning as with constructor init-list. Can&#39;t we just adopt th=
e same rule as for constructor init-list? (And I don&#39;t think that this =
rule was a mistake as it was stated above)<br></div></div></blockquote><div=
><br>The proof that the rule was a mistake is that compilers warn about it.=
 If it wasn&#39;t something worth warning people about, they wouldn&#39;t p=
ut the warning there. So there is clearly an intent that the writer of the =
constructor <i>ought</i> to put them in the right order.<br><br>And the sam=
e goes here.People generally don&#39;t like to leave spurious warnings in t=
heir code if they can help it (this is 90% of the impetus for allowing `con=
tainer::size_type` to be signed). So the only code where this warning will =
crop up is code where the user <i>needs</i> to declare them out of order (a=
s in the POSIX case).<br><br>If it&#39;s something that shouldn&#39;t be do=
ne (hence the warning), then we should forbid it outright. And if it&#39;s =
something that should be done, then we should do it in such a way that it d=
oes exactly what it looks like it does.<br></div></div>

<p></p>

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

------=_Part_4926_362926653.1501598162899--

------=_Part_4925_1559972688.1501598162899--

.

------=_Part_5068_1186613802.1501600320467
Content-Type: multipart/alternative;
 boundary="----=_Part_5069_1922102393.1501600320467"

------=_Part_5069_1922102393.1501600320467
Content-Type: text/plain; charset="UTF-8"

On Tuesday, August 1, 2017 at 5:36:03 PM UTC+3, Nicol Bolas wrote:
>
> The proof that the rule was a mistake is that compilers warn about it. If
> it wasn't something worth warning people about, they wouldn't put the
> warning there. So there is clearly an intent that the writer of the
> constructor *ought* to put them in the right order.
>

Again. The intention was to keep the simple and  universal rule:

*Initialization order always defined by members declaration order*

We don't want to change this rule with introducing one more initialization
style.

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

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

<div dir=3D"ltr">On Tuesday, August 1, 2017 at 5:36:03 PM UTC+3, Nicol Bola=
s 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">The p=
roof that the rule was a mistake is that compilers warn about it. If it was=
n&#39;t something worth warning people about, they wouldn&#39;t put the war=
ning there. So there is clearly an intent that the writer of the constructo=
r <i>ought</i> to put them in the right order.</div></blockquote><div><br>A=
gain. The intention was to keep the simple and=C2=A0 universal rule: <br><b=
r><b>Initialization order always defined by members declaration order</b><b=
r><br>We don&#39;t want to change this rule with introducing one more initi=
alization style.<br><br></div></div>

<p></p>

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

------=_Part_5069_1922102393.1501600320467--

------=_Part_5068_1186613802.1501600320467--

.

------=_Part_1034_330552509.1501602428207
Content-Type: multipart/alternative;
 boundary="----=_Part_1035_529750125.1501602428207"

------=_Part_1035_529750125.1501602428207
Content-Type: text/plain; charset="UTF-8"



On Tuesday, August 1, 2017 at 11:12:00 AM UTC-4, Victor Dyachenko wrote:
>
> On Tuesday, August 1, 2017 at 5:36:03 PM UTC+3, Nicol Bolas wrote:
>>
>> The proof that the rule was a mistake is that compilers warn about it. If
>> it wasn't something worth warning people about, they wouldn't put the
>> warning there. So there is clearly an intent that the writer of the
>> constructor *ought* to put them in the right order.
>>
>
> Again. The intention was to keep the simple and  universal rule:
>
> *Initialization order always defined by members declaration order*
>
> We don't want to change this rule with introducing one more initialization
> style.
>

But if you allow designated initializers to be specified out of member
declaration order, it now stops on another "simple and universal rule":

*Expression in braced-init-lists are sequenced in the order they appear*

So, if you allow unordered designated initializers, which rule wins? Either
the members will be initialized out of order, or the expressions will be
evaluated out of order.

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

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

<div dir=3D"ltr"><br><br>On Tuesday, August 1, 2017 at 11:12:00 AM UTC-4, V=
ictor Dyachenko 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 Tuesday, August 1, 2017 at 5:36:03 PM UTC+3, Nicol Bolas wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">The proof that the=
 rule was a mistake is that compilers warn about it. If it wasn&#39;t somet=
hing worth warning people about, they wouldn&#39;t put the warning there. S=
o there is clearly an intent that the writer of the constructor <i>ought</i=
> to put them in the right order.</div></blockquote><div><br>Again. The int=
ention was to keep the simple and=C2=A0 universal rule: <br><br><b>Initiali=
zation order always defined by members declaration order</b><br><br>We don&=
#39;t want to change this rule with introducing one more initialization sty=
le.<br></div></div></blockquote><div><br>But if you allow designated initia=
lizers to be specified out of member declaration order, it now stops on ano=
ther &quot;simple and universal rule&quot;:<br><br><b>Expression in braced-=
init-lists are sequenced in the order they appear</b> <br><br>So, if you al=
low unordered designated initializers, which rule wins? Either the members =
will be initialized out of order, or the expressions will be evaluated out =
of order.<br></div></div>

<p></p>

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

------=_Part_1035_529750125.1501602428207--

------=_Part_1034_330552509.1501602428207--

.

------=_Part_3212_1799356069.1501602650964
Content-Type: multipart/alternative;
 boundary="----=_Part_3213_1532223145.1501602650964"

------=_Part_3213_1532223145.1501602650964
Content-Type: text/plain; charset="UTF-8"

On Tuesday, August 1, 2017 at 6:47:08 PM UTC+3, Nicol Bolas wrote:
>
> But if you allow designated initializers to be specified out of member
> declaration order, it now stops on another "simple and universal rule":
>
> *Expression in braced-init-lists are sequenced in the order they appear*
>
> So, if you allow unordered designated initializers, which rule wins?
> Either the members will be initialized out of order, or the expressions
> will be evaluated out of order.
>

Which rule wins now  in case of constructors init-list? Apply the same rule
here.

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

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

<div dir=3D"ltr">On Tuesday, August 1, 2017 at 6:47:08 PM UTC+3, Nicol Bola=
s wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>=
But if you allow designated initializers to be specified out of member decl=
aration order, it now stops on another &quot;simple and universal rule&quot=
;:<br><br><b>Expression in braced-init-lists are sequenced in the order the=
y appear</b> <br><br>So, if you allow unordered designated initializers, wh=
ich rule wins? Either the members will be initialized out of order, or the =
expressions will be evaluated out of order.<br></div></div></blockquote><di=
v><br>Which rule wins now=C2=A0 in case of constructors init-list? Apply th=
e same rule here.<br></div></div>

<p></p>

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

------=_Part_3213_1532223145.1501602650964--

------=_Part_3212_1799356069.1501602650964--

.

------=_Part_1040_936716138.1501602947487
Content-Type: multipart/alternative;
 boundary="----=_Part_1041_1182851968.1501602947487"

------=_Part_1041_1182851968.1501602947487
Content-Type: text/plain; charset="UTF-8"

On Tuesday, August 1, 2017 at 11:50:51 AM UTC-4, Victor Dyachenko wrote:
>
> On Tuesday, August 1, 2017 at 6:47:08 PM UTC+3, Nicol Bolas wrote:
>>
>> But if you allow designated initializers to be specified out of member
>> declaration order, it now stops on another "simple and universal rule":
>>
>> *Expression in braced-init-lists are sequenced in the order they appear*
>>
>> So, if you allow unordered designated initializers, which rule wins?
>> Either the members will be initialized out of order, or the expressions
>> will be evaluated out of order.
>>
>
> Which rule wins now  in case of constructors init-list? Apply the same
> rule here.
>

Member initializers don't follow braced-init-list rules, and they never
did. My point is that "apply the same rule here" is to *violate* the
braced-init-list rule. Member initializers never had a contrary rule to be
broken.

You're going to have to break one rule or the other, and I don't see why we
should want either to be violated.

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

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

<div dir=3D"ltr">On Tuesday, August 1, 2017 at 11:50:51 AM UTC-4, Victor Dy=
achenko wrote:<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"=
>On Tuesday, August 1, 2017 at 6:47:08 PM UTC+3, Nicol Bolas wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>But if you allow desi=
gnated initializers to be specified out of member declaration order, it now=
 stops on another &quot;simple and universal rule&quot;:<br><br><b>Expressi=
on in braced-init-lists are sequenced in the order they appear</b> <br><br>=
So, if you allow unordered designated initializers, which rule wins? Either=
 the members will be initialized out of order, or the expressions will be e=
valuated out of order.<br></div></div></blockquote><div><br>Which rule wins=
 now=C2=A0 in case of constructors init-list? Apply the same rule here.<br>=
</div></div></blockquote><div><br>Member initializers don&#39;t follow brac=
ed-init-list rules, and they never did. My point is that &quot;apply the sa=
me rule here&quot; is to <i>violate</i> the braced-init-list rule. Member i=
nitializers never had a contrary rule to be broken.<br><br>You&#39;re going=
 to have to break one rule or the other, and I don&#39;t see why we should =
want either to be violated.<br></div></div>

<p></p>

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

------=_Part_1041_1182851968.1501602947487--

------=_Part_1040_936716138.1501602947487--

.

------=_Part_5202_1982896404.1501603357061
Content-Type: multipart/alternative;
 boundary="----=_Part_5203_1800679802.1501603357062"

------=_Part_5203_1800679802.1501603357062
Content-Type: text/plain; charset="UTF-8"

If sequencing of initializers evaluation order the only issue here, I'm OK
with allowing only initializers w/o side effects.

I strongly consider this feature as "named vs positional parameters". It is
absolutely useless if we can't use it in order to not depend on declaration
order and presence of unexpected members.

Code like

struct C { int a, b, c; };
C c{.c =1, a. = 2};

must "just work"

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

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

<div dir=3D"ltr">If sequencing of initializers evaluation order the only is=
sue here, I&#39;m OK with allowing only initializers w/o side effects.<br><=
br>I strongly consider this feature as &quot;named vs positional parameters=
&quot;. It is absolutely useless if we can&#39;t use it in order to not dep=
end on declaration order and presence of unexpected members.<br><br>Code li=
ke<br><br>struct C { int a, b, c; };<br>C c{.c =3D1, a. =3D 2};<br><br>must=
 &quot;just work&quot;<br></div>

<p></p>

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

------=_Part_5203_1800679802.1501603357062--

------=_Part_5202_1982896404.1501603357061--

.

------=_Part_5176_907005108.1501603769835
Content-Type: multipart/alternative;
 boundary="----=_Part_5177_948088030.1501603769835"

------=_Part_5177_948088030.1501603769835
Content-Type: text/plain; charset="UTF-8"

On Tuesday, August 1, 2017 at 7:02:37 PM UTC+3, Victor Dyachenko wrote:
>
> If sequencing of initializers evaluation order the only issue here, I'm OK
> with allowing only initializers w/o side effects.
>
> I strongly consider this feature as "named vs positional parameters". It
> is absolutely useless if we can't use it in order to not depend on
> declaration order and presence of unexpected members.
>
> Code like
>
> struct C { int a, b, c; };
> C c{.c =1, a. = 2};
>
> must "just work"
>

As one can see, all my examples are related to communication with C-world,
i.e. used only with POD-structs. For C++ we usually can add constructor
with predefined parameters order not related to the struct layout. So for
me it's enough.

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

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

<div dir=3D"ltr">On Tuesday, August 1, 2017 at 7:02:37 PM UTC+3, Victor Dya=
chenko 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">=
If sequencing of initializers evaluation order the only issue here, I&#39;m=
 OK with allowing only initializers w/o side effects.<br><br>I strongly con=
sider this feature as &quot;named vs positional parameters&quot;. It is abs=
olutely useless if we can&#39;t use it in order to not depend on declaratio=
n order and presence of unexpected members.<br><br>Code like<br><br>struct =
C { int a, b, c; };<br>C c{.c =3D1, a. =3D 2};<br><br>must &quot;just work&=
quot;<br></div></blockquote><div><br>As one can see, all my examples are re=
lated to communication with C-world, i.e. used only with POD-structs. For C=
++ we usually can add constructor with predefined parameters order not rela=
ted to the struct layout. So for me it&#39;s enough.<br></div></div>

<p></p>

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

------=_Part_5177_948088030.1501603769835--

------=_Part_5176_907005108.1501603769835--

.

------=_Part_3710_1078271880.1501603970106
Content-Type: multipart/alternative;
 boundary="----=_Part_3711_514845679.1501603970106"

------=_Part_3711_514845679.1501603970106
Content-Type: text/plain; charset="UTF-8"

On Tuesday, August 1, 2017 at 12:02:37 PM UTC-4, Victor Dyachenko wrote:
>
> If sequencing of initializers evaluation order the only issue here, I'm OK
> with allowing only initializers w/o side effects.
>

I'm not. "side effects" is a *very* broad term, and they can happen due to
pretty much anything. You're effectively saying that you can't have
designated initializers to call any function (that isn't `constexpr`). Even
a seemingly innocuous expression like `a + b` could have an overloaded
operator+ that isn't `constexpr` that could have a side effect.

Don't look at this feature from just the perspective of initializing a
bunch of integers for some POSIX interface.

I strongly consider this feature as "named vs positional parameters". It is
> absolutely useless if we can't use it in order to not depend on declaration
> order and presence of unexpected members.
>
> Code like
>
> struct C { int a, b, c; };
> C c{.c =1, a. = 2};
>
> must "just work"
>

The problem with positional arguments is the question of what the argument
means, not the fact that it has a fixed position. By attaching a name to
the argument, you now have given some semantic meaning to it. This is true
*regardless* of whether you have to give such arguments in a specific order.

So I strongly disagree that this feature is "useless" without the ability
to change the argument's position.

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

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

<div dir=3D"ltr">On Tuesday, August 1, 2017 at 12:02:37 PM UTC-4, Victor Dy=
achenko wrote:<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"=
>If sequencing of initializers evaluation order the only issue here, I&#39;=
m OK with allowing only initializers w/o side effects.<br></div></blockquot=
e><div><br>I&#39;m not. &quot;side effects&quot; is a <i>very</i> broad ter=
m, and they can happen due to pretty much anything. You&#39;re effectively =
saying that you can&#39;t have designated initializers to call any function=
 (that isn&#39;t `constexpr`). Even a seemingly innocuous expression like `=
a + b` could have an overloaded operator+ that isn&#39;t `constexpr` that c=
ould have a side effect.<br><br>Don&#39;t look at this feature from just th=
e perspective of initializing a bunch of integers for some POSIX interface.=
<br><br></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"=
>I strongly consider this feature as &quot;named vs positional parameters&q=
uot;. It is absolutely useless if we can&#39;t use it in order to not depen=
d on declaration order and presence of unexpected members.<br><br>Code like=
<br><br>struct C { int a, b, c; };<br>C c{.c =3D1, a. =3D 2};<br><br>must &=
quot;just work&quot;<br></div></blockquote><div><br>The problem with positi=
onal arguments is the question of what the argument means, not the fact tha=
t it has a fixed position. By attaching a name to the argument, you now hav=
e given some semantic meaning to it. This is true <i>regardless</i> of whet=
her you have to give such arguments in a specific order.<br><br>So I strong=
ly disagree that this feature is &quot;useless&quot; without the ability to=
 change the argument&#39;s position.<br></div></div>

<p></p>

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

------=_Part_3711_514845679.1501603970106--

------=_Part_3710_1078271880.1501603970106--

.

------=_Part_5193_1060757293.1501606886920
Content-Type: multipart/alternative;
 boundary="----=_Part_5194_994891124.1501606886920"

------=_Part_5194_994891124.1501606886920
Content-Type: text/plain; charset="UTF-8"

On Tuesday, August 1, 2017 at 7:12:50 PM UTC+3, Nicol Bolas wrote:
>
> Don't look at this feature from just the perspective of initializing a
> bunch of integers for some POSIX interface.
>

I would say  "OS interfaces". They almost always use C. Also system
libraries intended to be used not only from C++ (they even can be written
in C++ but expose only C interface like ZeroMQ).
C is a *lingua franca* of computer languages.

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

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

<div dir=3D"ltr">On Tuesday, August 1, 2017 at 7:12:50 PM UTC+3, Nicol Bola=
s 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">Don&#=
39;t look at this feature from just the perspective of initializing a bunch=
 of integers for some POSIX interface.<br></div></blockquote><div><br>I wou=
ld say=C2=A0 &quot;OS interfaces&quot;. They almost always use C. Also syst=
em libraries intended to be used not only from C++ (they even can be writte=
n in C++ but expose only C interface like ZeroMQ).<br>C is a <i>lingua fran=
ca</i> of computer languages.<br></div></div>

<p></p>

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

------=_Part_5194_994891124.1501606886920--

------=_Part_5193_1060757293.1501606886920--

.

------=_Part_5357_358117160.1501609973066
Content-Type: multipart/alternative;
 boundary="----=_Part_5358_1216874746.1501609973067"

------=_Part_5358_1216874746.1501609973067
Content-Type: text/plain; charset="UTF-8"

On Tuesday, August 1, 2017 at 1:01:27 PM UTC-4, Victor Dyachenko wrote:
>
> On Tuesday, August 1, 2017 at 7:12:50 PM UTC+3, Nicol Bolas wrote:
>>
>> Don't look at this feature from just the perspective of initializing a
>> bunch of integers for some POSIX interface.
>>
>
> I would say  "OS interfaces". They almost always use C.
>

But they "almost always" consider the order of their struct members to be
part of their interface. That's why I listed POSIX explicitly: it doesn't
specify a required order (or apparently, an exhaustive parameter list at
all).

Also system libraries intended to be used not only from C++ (they even can
> be written in C++ but expose only C interface like ZeroMQ).
>

Does ZeroMQ consider the sequence of elements in structs to be mutable, yet
still expect such changes to be backwards compatible? If not, then it's
irrelevant.

This isn't about C interfaces. It's about *stupid* C interfaces (or more
charitably, C interfaces that have specification deficiencies). That is a
(very narrow) subset of C interfaces.

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

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

<div dir=3D"ltr">On Tuesday, August 1, 2017 at 1:01:27 PM UTC-4, Victor Dya=
chenko 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">=
On Tuesday, August 1, 2017 at 7:12:50 PM UTC+3, Nicol Bolas wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Don&#39;t look at this feat=
ure from just the perspective of initializing a bunch of integers for some =
POSIX interface.<br></div></blockquote><div><br>I would say=C2=A0 &quot;OS =
interfaces&quot;. They almost always use C.</div></div></blockquote><div>=
=C2=A0</div><div>But they &quot;almost always&quot; consider the order of t=
heir struct members to be part of their interface. That&#39;s why I listed =
POSIX explicitly: it doesn&#39;t specify a required order (or apparently, a=
n exhaustive parameter list at all).<br><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><div>Also system libraries intended to=
 be used not only from C++ (they even can be written in C++ but expose only=
 C interface like ZeroMQ).<br></div></div></blockquote><div><br>Does ZeroMQ=
 consider the sequence of elements in structs to be mutable, yet still expe=
ct such changes to be backwards compatible? If not, then it&#39;s irrelevan=
t.<br><br>This isn&#39;t about C interfaces. It&#39;s about <i>stupid</i> C=
 interfaces (or more charitably, C interfaces that have specification defic=
iencies). That is a (very narrow) subset of C interfaces.</div><br></div>

<p></p>

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

------=_Part_5358_1216874746.1501609973067--

------=_Part_5357_358117160.1501609973066--

.

On ter=C3=A7a-feira, 1 de agosto de 2017 10:52:53 PDT Nicol Bolas wrote:
> On Tuesday, August 1, 2017 at 1:01:27 PM UTC-4, Victor Dyachenko wrote:
> > On Tuesday, August 1, 2017 at 7:12:50 PM UTC+3, Nicol Bolas wrote:
> >> Don't look at this feature from just the perspective of initializing a
> >> bunch of integers for some POSIX interface.
> >=20
> > I would say  "OS interfaces". They almost always use C.
>=20
> But they "almost always" consider the order of their struct members to be
> part of their interface. That's why I listed POSIX explicitly: it doesn't
> specify a required order (or apparently, an exhaustive parameter list at
> all).

Not really. Have you seen how many stat() implementations Linux has? If you=
=20
didn't know there was more than one, you've made my point.

 https://code.woboq.org/linux/linux/arch/x86/include/uapi/asm/stat.h.html

[I'm not counting the new statx(2) syscall and struct.]

Did you also know that the sigaction is different between glibc and the=20
kernel, so that glibc can change it if it needs to?

 https://code.woboq.org/userspace/glibc/sysdeps/unix/sysv/linux/bits/
sigaction.h.html#24
 https://code.woboq.org/userspace/glibc/sysdeps/unix/sysv/linux/
kernel_sigaction.h.html#14
(oh, there's also an "old_kernel_sigaction"!)

> > Also system libraries intended to be used not only from C++ (they even =
can
> > be written in C++ but expose only C interface like ZeroMQ).

As well as the entire C library in MSVC 2015 and up and most of the macOS b=
ase=20
libraries.

> Does ZeroMQ consider the sequence of elements in structs to be mutable, y=
et
> still expect such changes to be backwards compatible? If not, then it's
> irrelevant.

No more than we do in C++, with inline namespaces. The use of inline=20
namespaces for *versioning* causes the same kind of problems.

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

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

.

------=_Part_5478_1114588391.1501614745550
Content-Type: multipart/alternative;
 boundary="----=_Part_5479_881726407.1501614745551"

------=_Part_5479_881726407.1501614745551
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tuesday, August 1, 2017 at 2:06:50 PM UTC-4, Thiago Macieira wrote:
>
> On ter=C3=A7a-feira, 1 de agosto de 2017 10:52:53 PDT Nicol Bolas wrote:=
=20
> > On Tuesday, August 1, 2017 at 1:01:27 PM UTC-4, Victor Dyachenko wrote:=
=20
> > > On Tuesday, August 1, 2017 at 7:12:50 PM UTC+3, Nicol Bolas wrote:=20
> > >> Don't look at this feature from just the perspective of initializing=
=20
> a=20
> > >> bunch of integers for some POSIX interface.=20
> > >=20
> > > I would say  "OS interfaces". They almost always use C.=20
> >=20
> > But they "almost always" consider the order of their struct members to=
=20
> be=20
> > part of their interface. That's why I listed POSIX explicitly: it=20
> doesn't=20
> > specify a required order (or apparently, an exhaustive parameter list a=
t=20
> > all).=20
>
> Not really. Have you seen how many stat() implementations Linux has? If=
=20
> you=20
> didn't know there was more than one, you've made my point.=20
>
>  https://code.woboq.org/linux/linux/arch/x86/include/uapi/asm/stat.h.html=
=20
>
> [I'm not counting the new statx(2) syscall and struct.]=20
>
> Did you also know that the sigaction is different between glibc and the=
=20
> kernel, so that glibc can change it if it needs to?=20
>
>  https://code.woboq.org/userspace/glibc/sysdeps/unix/sysv/linux/bits/=20
> sigaction.h.html#24=20
>  https://code.woboq.org/userspace/glibc/sysdeps/unix/sysv/linux/=20
> kernel_sigaction.h.html#14=20
> (oh, there's also an "old_kernel_sigaction"!)=20
>
> > > Also system libraries intended to be used not only from C++ (they eve=
n=20
> can=20
> > > be written in C++ but expose only C interface like ZeroMQ).=20
>
> As well as the entire C library in MSVC 2015 and up and most of the macOS=
=20
> base=20
> libraries.
>

So what? Are you telling me that Microsoft is free to arbitrarily change=20
the order of the elements in such structs? If not, then bringing them up is=
=20
*irrelevant*.

Remember: the primary motivation for this feature is having to deal with=20
structs where member order is not well specified. Microsoft's libraries=20
specify member order for structs; they are a fundamental part of the ABI=20
for their APIs. They will no more change that order than they will remove=
=20
Win32.

And there are many other C APIs that work the same way. Vulkan for example;=
=20
the order of members in that API is a fundamental part of its ABI. It will=
=20
never change, and therefore it can be relied upon.

The only C APIs that are relevant to this discussion are those where the=20
API says that it is free to change the order of the structures at any time.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/4974cd64-a185-4ec4-8fbb-6ca67c8bd4cb%40isocpp.or=
g.

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

<div dir=3D"ltr">On Tuesday, August 1, 2017 at 2:06:50 PM UTC-4, Thiago Mac=
ieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On ter=C3=A7a-feir=
a, 1 de agosto de 2017 10:52:53 PDT Nicol Bolas wrote:
<br>&gt; On Tuesday, August 1, 2017 at 1:01:27 PM UTC-4, Victor Dyachenko w=
rote:
<br>&gt; &gt; On Tuesday, August 1, 2017 at 7:12:50 PM UTC+3, Nicol Bolas w=
rote:
<br>&gt; &gt;&gt; Don&#39;t look at this feature from just the perspective =
of initializing a
<br>&gt; &gt;&gt; bunch of integers for some POSIX interface.
<br>&gt; &gt;=20
<br>&gt; &gt; I would say =C2=A0&quot;OS interfaces&quot;. They almost alwa=
ys use C.
<br>&gt;=20
<br>&gt; But they &quot;almost always&quot; consider the order of their str=
uct members to be
<br>&gt; part of their interface. That&#39;s why I listed POSIX explicitly:=
 it doesn&#39;t
<br>&gt; specify a required order (or apparently, an exhaustive parameter l=
ist at
<br>&gt; all).
<br>
<br>Not really. Have you seen how many stat() implementations Linux has? If=
 you=20
<br>didn&#39;t know there was more than one, you&#39;ve made my point.
<br>
<br>=C2=A0<a href=3D"https://code.woboq.org/linux/linux/arch/x86/include/ua=
pi/asm/stat.h.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.=
href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.woboq.org%2F=
linux%2Flinux%2Farch%2Fx86%2Finclude%2Fuapi%2Fasm%2Fstat.h.html\x26sa\x3dD\=
x26sntz\x3d1\x26usg\x3dAFQjCNGTUGlTIobWDb5Wy1ksxqiyDk-Rfg&#39;;return true;=
" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2=
Fcode.woboq.org%2Flinux%2Flinux%2Farch%2Fx86%2Finclude%2Fuapi%2Fasm%2Fstat.=
h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGTUGlTIobWDb5Wy1ksxqiyDk-Rfg=
&#39;;return true;">https://code.woboq.org/linux/<wbr>linux/arch/x86/includ=
e/uapi/<wbr>asm/stat.h.html</a>
<br>
<br>[I&#39;m not counting the new statx(2) syscall and struct.]
<br>
<br>Did you also know that the sigaction is different between glibc and the=
=20
<br>kernel, so that glibc can change it if it needs to?
<br>
<br>=C2=A0<a href=3D"https://code.woboq.org/userspace/glibc/sysdeps/unix/sy=
sv/linux/bits/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.woboq.org%2Fuser=
space%2Fglibc%2Fsysdeps%2Funix%2Fsysv%2Flinux%2Fbits%2F\x26sa\x3dD\x26sntz\=
x3d1\x26usg\x3dAFQjCNEPK8argygh4uDA-A7HYeiNTZ-ZzQ&#39;;return true;" onclic=
k=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.wo=
boq.org%2Fuserspace%2Fglibc%2Fsysdeps%2Funix%2Fsysv%2Flinux%2Fbits%2F\x26sa=
\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEPK8argygh4uDA-A7HYeiNTZ-ZzQ&#39;;return=
 true;">https://code.woboq.org/<wbr>userspace/glibc/sysdeps/unix/<wbr>sysv/=
linux/bits/</a>
<br>sigaction.h.html#24
<br>=C2=A0<a href=3D"https://code.woboq.org/userspace/glibc/sysdeps/unix/sy=
sv/linux/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.woboq.org%2Fuserspace=
%2Fglibc%2Fsysdeps%2Funix%2Fsysv%2Flinux%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNE_88fNDX8IBdd1WnYuh1oBAZP6lw&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.woboq.org%2Fus=
erspace%2Fglibc%2Fsysdeps%2Funix%2Fsysv%2Flinux%2F\x26sa\x3dD\x26sntz\x3d1\=
x26usg\x3dAFQjCNE_88fNDX8IBdd1WnYuh1oBAZP6lw&#39;;return true;">https://cod=
e.woboq.org/<wbr>userspace/glibc/sysdeps/unix/<wbr>sysv/linux/</a>
<br>kernel_sigaction.h.html#14
<br>(oh, there&#39;s also an &quot;old_kernel_sigaction&quot;!)
<br>
<br>&gt; &gt; Also system libraries intended to be used not only from C++ (=
they even can
<br>&gt; &gt; be written in C++ but expose only C interface like ZeroMQ).
<br>
<br>As well as the entire C library in MSVC 2015 and up and most of the mac=
OS base=20
<br>libraries.<br></blockquote><div><br>So what? Are you telling me that Mi=
crosoft is free to arbitrarily change the order of the elements in such str=
ucts? If not, then bringing them up is <i>irrelevant</i>.<br><br>Remember: =
the primary motivation for this feature is having to deal with structs wher=
e member order is not well specified. Microsoft&#39;s libraries specify mem=
ber order for structs; they are a fundamental part of the ABI for their API=
s. They will no more change that order than they will remove Win32.<br><br>=
And there are many other C APIs that work the same way. Vulkan for example;=
 the order of members in that API is a fundamental part of its ABI. It will=
 never change, and therefore it can be relied upon.<br><br>The only C APIs =
that are relevant to this discussion are those where the API says that it i=
s free to change the order of the structures at any time.</div></div>

<p></p>

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

------=_Part_5479_881726407.1501614745551--

------=_Part_5478_1114588391.1501614745550--

.

On ter=C3=A7a-feira, 1 de agosto de 2017 12:12:25 PDT Nicol Bolas wrote:
> > > > Also system libraries intended to be used not only from C++ (they e=
ven
> > > > can
> > > > be written in C++ but expose only C interface like ZeroMQ).
> >=20
> > As well as the entire C library in MSVC 2015 and up and most of the mac=
OS
> > base
> > libraries.
>=20
> So what? Are you telling me that Microsoft is free to arbitrarily change
> the order of the elements in such structs? If not, then bringing them up =
is
> *irrelevant*.

They used to do that with EVERY release of their compiler up until MSVC 201=
5,=20
when they made a commitment to retain binary compatibility.

Even the official Win32 API has such shenanigans, like this:

https://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-headers/
include/iptypes.h#l107

In this case, one of the structs is a prefix of the other, but they could=
=20
easily be distinguished by the Length member.

> Remember: the primary motivation for this feature is having to deal with
> structs where member order is not well specified. Microsoft's libraries
> specify member order for structs; they are a fundamental part of the ABI
> for their APIs. They will no more change that order than they will remove
> Win32.

See above.

> The only C APIs that are relevant to this discussion are those where the
> API says that it is free to change the order of the structures at any tim=
e.

Or the way that glibc has done it: the struct *and* the function that takes=
 it=20
change in lockstep. They've done it before. And help from the ELF versionin=
g=20
system, you will not notice which of the two versions of the function you'r=
e=20
calling (that's the part that is like the C++11 inline namespaces).

That is binary incompatible if you pass that struct between two libraries o=
f=20
yours that don't update in lockstep. Just like C++11 inline namespaces.

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

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

.

------=_Part_4801_914322773.1501620657150
Content-Type: multipart/alternative;
 boundary="----=_Part_4802_2016595749.1501620657150"

------=_Part_4802_2016595749.1501620657150
Content-Type: text/plain; charset="UTF-8"

@Nicol: Your argument that "so far brace initializers have always had their
expression evaluated in order" is irrelevant as it is just as true to say
that "so far initializers have always had their expressions evalutated in
member declaration order" as both orders are the same as long as we don't
have designators! We have one precedent for what rule to use when the
members are named: member initializer lists in constructors. Here the rule
is that the expressions run in member declaration order, regardless of
which order they are written. Not making these orders the same issues a
warning in some compiler due to the same fear that you have: someone will
at some point use an uninitialized member to initialize another member
having *forgotten* the rules of the language.

For the designator case you want to strengthen this rule into a mandatory
error if designators are placed in a different order than the member
declarations. Firstly I see this as a bad idea just because it causes the
two ways to initiate members to work differently.

As for the "arbitrarily complex expressions" that would prevent the
compiler from finding a reference to a member later in the list I don't see
this as plausible as it would require sending the whole object to a
function in the midst of its initialization or sending the forward refered
member itself to a function, which is as easily detected. Maybe if you take
the address of the forward refered member and send it to a function that
defers it, but that's piling two unlikely construct on top of each other.

Further, here are a couple of observations:

1) using one member to initiate another is very seldom useful as doing so
would more or less indicate that you store the same thing twice. In
practice I know that I need this extremely seldom, except for giving the
address of one member to the constructor of another for future reference.
Much more common is to send "this" itself to some member's constructor,
which has its own caveats but which no initiation order limitation can
alleviate.

2) Making sure that the member init list is in the same order as the member
declarations is very tedious and causes lots of warnings especially when
adding members. The programmer time spent on doing this tedious work is
likely to be many times more than the time lost in finding those rare bugs
that thinking that members are initialized in the order that expressions
are written would have caused. I think this is safe to say given the
extremely low frequency of usage of member a to init member b. Many
programmers don't even know that you can do this, as they never needed it.

3) Even with the same initialization order it is easy to make a mistake
once you start using one member's value in another members initializer
expression either because you didin't think about the ordering or because
you re-sorted the members without thinking about it, just reordering the
ctor expressions mechanically to silence the warnings.

4) The order of members in a constructor's member initializer list is much
closer to the member declaration list and thus easier to maintain than
initializers at arbitrary distance from the struct declaration.

While we should of course try to prevent likely bugs with the language
rules, I'm convinced that this feature would be much less convenient with
this strict ordering rule, while at the same time catching *very few* bugs.

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

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

<div dir=3D"ltr">@Nicol: Your argument that &quot;so far brace initializers=
 have always had their expression evaluated in order&quot; is irrelevant as=
 it is just as true to say that &quot;so far initializers have always had t=
heir expressions evalutated in member declaration order&quot; as both order=
s are the same as long as we don&#39;t have designators! We have one preced=
ent for what rule to use when the members are named: member initializer lis=
ts in constructors. Here the rule is that the expressions run in member dec=
laration order, regardless of which order they are written. Not making thes=
e orders the same issues a warning in some compiler due to the same fear th=
at you have: someone will at some point use an uninitialized member to init=
ialize another member having *forgotten* the rules of the language.<div><br=
></div><div>For the designator case you want to strengthen this rule into a=
 mandatory error if designators are placed in a different order than the me=
mber declarations. Firstly I see this as a bad idea just because it causes =
the two ways to initiate members to work differently.</div><div><br></div><=
div>As for the &quot;arbitrarily complex expressions&quot; that would preve=
nt the compiler from finding a reference to a member later in the list I do=
n&#39;t see this as plausible as it would require sending the whole object =
to a function in the midst of its initialization or sending the forward ref=
ered member itself to a function, which is as easily detected. Maybe if you=
 take the address of the forward refered member and send it to a function t=
hat defers it, but that&#39;s piling two unlikely construct on top of each =
other.</div><div><br></div><div>Further, here are a couple of observations:=
</div><div><br></div><div>1) using one member to initiate another is very s=
eldom useful as doing so would more or less indicate that you store the sam=
e thing twice. In practice I know that I need this extremely seldom, except=
 for giving the address of one member to the constructor of another for fut=
ure reference. Much more common is to send &quot;this&quot; itself to some =
member&#39;s constructor, which has its own caveats but which no initiation=
 order limitation can alleviate.</div><div><br></div><div>2) Making sure th=
at the member init list is in the same order as the member declarations is =
very tedious and causes lots of warnings especially when adding members. Th=
e programmer time spent on doing this tedious work is likely to be many tim=
es more than the time lost in finding those rare bugs that thinking that me=
mbers are initialized in the order that expressions are written would have =
caused. I think this is safe to say given the extremely low frequency of us=
age of member a to init member b. Many programmers don&#39;t even know that=
 you can do this, as they never needed it.</div><div><br></div><div>3) Even=
 with the same initialization order it is easy to make a mistake once you s=
tart using one member&#39;s value in another members initializer expression=
 either because you didin&#39;t think about the ordering or because you re-=
sorted the members without thinking about it, just reordering the ctor expr=
essions mechanically to silence the warnings.</div><div><br></div><div>4) T=
he order of members in a constructor&#39;s member initializer list is much =
closer to the member declaration list and thus easier to maintain than init=
ializers at arbitrary distance from the struct declaration.</div><div><br><=
/div><div>While we should of course try to prevent likely bugs with the lan=
guage rules, I&#39;m convinced that this feature would be much less conveni=
ent with this strict ordering rule, while at the same time catching *very f=
ew* bugs.</div></div>

<p></p>

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

------=_Part_4802_2016595749.1501620657150--

------=_Part_4801_914322773.1501620657150--

.

------=_Part_5595_1244506471.1501624388180
Content-Type: multipart/alternative;
 boundary="----=_Part_5596_373596617.1501624388181"

------=_Part_5596_373596617.1501624388181
Content-Type: text/plain; charset="UTF-8"

On Tuesday, August 1, 2017 at 4:50:57 PM UTC-4, Bengt Gustafsson wrote:
>
> @Nicol: Your argument that "so far brace initializers have always had
> their expression evaluated in order" is irrelevant as it is just as true to
> say that "so far initializers have always had their expressions evalutated
> in member declaration order" as both orders are the same as long as we
> don't have designators! We have one precedent for what rule to use when the
> members are named: member initializer lists in constructors. Here the rule
> is that the expressions run in member declaration order, regardless of
> which order they are written. Not making these orders the same issues a
> warning in some compiler due to the same fear that you have: someone will
> at some point use an uninitialized member to initialize another member
> having *forgotten* the rules of the language.
>
> For the designator case you want to strengthen this rule into a mandatory
> error if designators are placed in a different order than the member
> declarations.
>

I contest your analogy. As stated by the paper itself, designated
initializers is an extension of aggregate initialization, a convenience
feature. Changing the order of either the evaluation of the expressions or
the order of initialization takes it into the territory of a new feature,
not a convenient shortcut.

Firstly I see this as a bad idea just because it causes the two ways to
> initiate members to work differently.
>

To the extent that your analogy makes sense, I see your idea as bad because
it causes two braced-init-lists to evaluate their expressions in different
orders.

It's all a question of whose rules you consider sacrosanct.

As for the "arbitrarily complex expressions" that would prevent the
> compiler from finding a reference to a member later in the list I don't see
> this as plausible as it would require sending the whole object to a
> function in the midst of its initialization or sending the forward refered
> member itself to a function, which is as easily detected. Maybe if you take
> the address of the forward refered member and send it to a function that
> defers it, but that's piling two unlikely construct on top of each other.
>
> Further, here are a couple of observations:
>
> 1) using one member to initiate another is very seldom useful as doing so
> would more or less indicate that you store the same thing twice. In
> practice I know that I need this extremely seldom, except for giving the
> address of one member to the constructor of another for future reference.
> Much more common is to send "this" itself to some member's constructor,
> which has its own caveats but which no initiation order limitation can
> alleviate.
>

While the use of a member in another member's initializer is one problem,
it is not the *only* problem that evaluation order matters for.

Remember: braced-init-lists are one of the very few places where C++
guarantees that the *visible* order of expressions represents the *actual*
order of their evaluation. As such, it is very easy to have two expressions
be dependent on each other.

Now granted, for designated initializers it's not nearly as easy to
accidentally rely on as with regular braced-init-lists (since you can't use
`...` pack expansion). But it is still very possible for you to rely on the
visible order of expressions, particularly deliberately. After all,
guaranteed evaluation order is a *feature* of braced-init-lists.

Another reason why I contest the member initializer comparison is because
of context. Member initializers can only appear in constructors. Indeed,
they appear before the actual constructor code. As such, you're fairly
limited as to what side-effects you can rely on. Dependency on order of
evaluation would thus be through side effects of function calls on
parameters, globals, and the state of other members.

By contrast, braced-init-lists can appear pretty much anywhere. As such,
there is a lot more local state to foil around with. It's very easy for you
to use `++` gymnastics on some local variable and create an ordering
dependency.

And remember: braced-init-lists guarantee order of evaluation, so right now:

int i = 20;
Agg a{++i, ++i};

That is completely, 100% well-defined. It does exactly what it says it
does, in exactly the order it appears to.

2) Making sure that the member init list is in the same order as the member
> declarations is very tedious and causes lots of warnings especially when
> adding members. The programmer time spent on doing this tedious work is
> likely to be many times more than the time lost in finding those rare bugs
> that thinking that members are initialized in the order that expressions
> are written would have caused. I think this is safe to say given the
> extremely low frequency of usage of member a to init member b. Many
> programmers don't even know that you can do this, as they never needed it.
>

Considering that compilers tend to warn about having an out-of-order member
initializer list, I contest this observation. If it were so safe and
normal, why would there be a warning about it?


> 3) Even with the same initialization order it is easy to make a mistake
> once you start using one member's value in another members initializer
> expression either because you didin't think about the ordering or because
> you re-sorted the members without thinking about it, just reordering the
> ctor expressions mechanically to silence the warnings.
>
> 4) The order of members in a constructor's member initializer list is much
> closer to the member declaration list and thus easier to maintain than
> initializers at arbitrary distance from the struct declaration.
>

That sounds like a really good justification *not* to do this. The order of
expression evaluation, while well-defined, cannot be *locally* known; it is
determined by code "at an arbitrary distance from" the actual object
initialization. Why is it a good thing to have the evaluation order of
local expression evaluation be controlled due to code contained so far away?

Given the following code:

int i = 20;
Agg a{.mem1 = ++i, .mem2 = ++i};

The way I see it, there are only two reasonable answers for what this code
does. Either the values of `mem1` and `mem2` are 21 and 22, or their values
are unspecified. That is, either the expressions evaluate in the order they
appear, or they evaluate in an order that is unspecified. C++ has lots of
places where evaluation order is unspecified, and it has lots of places
where evaluation order is locally specified.

But C++ only has one place where the evaluation order is
well-and-non-locally-specified. And it's a place that compilers *routinely
warn about*.

To have them evaluate in an order which is both well-defined *and* defined
non-locally is the wrong answer.

Now, if you want to say that the expressions evaluate in the order they
appear, but the members are *initialized* from those expressions in the
order they appear in the struct, that might be workable. Though you're
still going to have to explain how the possible conversions from the
expression type to the member type.

But those expressions should not be *evaluated* in a
well-and-non-locally-defined order.

While we should of course try to prevent likely bugs with the language
> rules, I'm convinced that this feature would be much less convenient with
> this strict ordering rule, while at the same time catching *very few* bugs.
>

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

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

<div dir=3D"ltr">On Tuesday, August 1, 2017 at 4:50:57 PM UTC-4, Bengt Gust=
afsson 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">=
@Nicol: Your argument that &quot;so far brace initializers have always had =
their expression evaluated in order&quot; is irrelevant as it is just as tr=
ue to say that &quot;so far initializers have always had their expressions =
evalutated in member declaration order&quot; as both orders are the same as=
 long as we don&#39;t have designators! We have one precedent for what rule=
 to use when the members are named: member initializer lists in constructor=
s. Here the rule is that the expressions run in member declaration order, r=
egardless of which order they are written. Not making these orders the same=
 issues a warning in some compiler due to the same fear that you have: some=
one will at some point use an uninitialized member to initialize another me=
mber having *forgotten* the rules of the language.<div><br></div><div>For t=
he designator case you want to strengthen this rule into a mandatory error =
if designators are placed in a different order than the member declarations=
..</div></div></blockquote><div><br>I contest your analogy. As stated by the=
 paper itself, designated initializers is an extension of aggregate initial=
ization, a convenience feature. Changing the order of either the evaluation=
 of the expressions or the order of initialization takes it into the territ=
ory of a new feature, not a convenient shortcut.<br><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Firstly I see this as=
 a bad idea just because it causes the two ways to initiate members to work=
 differently.</div></div></blockquote><div><br>To the extent that your anal=
ogy makes sense, I see your idea as bad because it causes two braced-init-l=
ists to evaluate their expressions in different orders.<br><br>It&#39;s all=
 a question of whose rules you consider sacrosanct.<br><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>As for =
the &quot;arbitrarily complex expressions&quot; that would prevent the comp=
iler from finding a reference to a member later in the list I don&#39;t see=
 this as plausible as it would require sending the whole object to a functi=
on in the midst of its initialization or sending the forward refered member=
 itself to a function, which is as easily detected. Maybe if you take the a=
ddress of the forward refered member and send it to a function that defers =
it, but that&#39;s piling two unlikely construct on top of each other.</div=
><div><br></div><div>Further, here are a couple of observations:</div><div>=
<br></div><div>1) using one member to initiate another is very seldom usefu=
l as doing so would more or less indicate that you store the same thing twi=
ce. In practice I know that I need this extremely seldom, except for giving=
 the address of one member to the constructor of another for future referen=
ce. Much more common is to send &quot;this&quot; itself to some member&#39;=
s constructor, which has its own caveats but which no initiation order limi=
tation can alleviate.</div></div></blockquote><div><br>While the use of a m=
ember in another member&#39;s initializer is one problem, it is not the <i>=
only</i> problem that evaluation order matters for.<br><br>Remember: braced=
-init-lists are one of the very few places where C++ guarantees that the <i=
>visible</i> order of expressions represents the <i>actual</i> order of the=
ir evaluation. As such, it is very easy to have two expressions be dependen=
t on each other.<br><br>Now granted, for designated initializers it&#39;s n=
ot nearly as easy to accidentally rely on as with regular braced-init-lists=
 (since you can&#39;t use `...` pack expansion). But it is still very possi=
ble for you to rely on the visible order of expressions, particularly delib=
erately. After all, guaranteed evaluation order is a <i>feature</i> of brac=
ed-init-lists.<br><br>Another reason why I contest the member initializer c=
omparison is because of context. Member initializers can only appear in con=
structors. Indeed, they appear before the actual constructor code. As such,=
 you&#39;re fairly limited as to what side-effects you can rely on. Depende=
ncy on order of evaluation would thus be through side effects of function c=
alls on parameters, globals, and the state of other members.<br><br>By cont=
rast, braced-init-lists can appear pretty much anywhere. As such, there is =
a lot more local state to foil around with. It&#39;s very easy for you to u=
se `++` gymnastics on some local variable and create an ordering dependency=
..<br><br>And remember: braced-init-lists guarantee order of evaluation, so =
right now:<br><br><div style=3D"background-color: rgb(250, 250, 250); borde=
r-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; overfl=
ow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><di=
v class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-=
prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> i </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #066;" class=3D"styled-by-prettify">20</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #606=
;" class=3D"styled-by-prettify">Agg</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> a</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">{++</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">i</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 st=
yle=3D"color: #000;" class=3D"styled-by-prettify">i</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">};</span></div></code></div><br>Th=
at is completely, 100% well-defined. It does exactly what it says it does, =
in exactly the order it appears to.<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;"><div dir=3D"ltr"><div>2) Making sure that the member ini=
t list is in the same order as the member declarations is very tedious and =
causes lots of warnings especially when adding members. The programmer time=
 spent on doing this tedious work is likely to be many times more than the =
time lost in finding those rare bugs that thinking that members are initial=
ized in the order that expressions are written would have caused. I think t=
his is safe to say given the extremely low frequency of usage of member a t=
o init member b. Many programmers don&#39;t even know that you can do this,=
 as they never needed it.</div></div></blockquote><div><br>Considering that=
 compilers tend to warn about having an out-of-order member initializer lis=
t, I contest this observation. If it were so safe and normal, why would the=
re be a warning about it?<br>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><div></div><div>3) Even with the same initializ=
ation order it is easy to make a mistake once you start using one member&#3=
9;s value in another members initializer expression either because you didi=
n&#39;t think about the ordering or because you re-sorted the members witho=
ut thinking about it, just reordering the ctor expressions mechanically to =
silence the warnings.</div><div><br></div><div>4) The order of members in a=
 constructor&#39;s member initializer list is much closer to the member dec=
laration list and thus easier to maintain than initializers at arbitrary di=
stance from the struct declaration.</div></div></blockquote><div><br>That s=
ounds like a really good justification <i>not</i> to do this. The order of =
expression evaluation, while well-defined, cannot be <i>locally</i> known; =
it is determined by code &quot;at an arbitrary distance from&quot; the actu=
al object initialization. Why is it a good thing to have the evaluation ord=
er of local expression evaluation be controlled due to code contained so fa=
r away?<br><br>Given the following code:<br><br><div style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><=
code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> i </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: #066;" class=3D"styled-by-=
prettify">20</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><span style=3D"color: #606;" class=3D"styled-by-prettify">Agg</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> a</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{.</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">mem1 </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">++</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">i</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 sty=
le=3D"color: #000;" class=3D"styled-by-prettify">mem2 </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;" c=
lass=3D"styled-by-prettify">++</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">i</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">};</span></div></code></div><br>The way I see it, there are only=
 two reasonable answers for what this code does. Either the values of `mem1=
` and `mem2` are 21 and 22, or their values are unspecified. That is, eithe=
r the expressions evaluate in the order they appear, or they evaluate in an=
 order that is unspecified. C++ has lots of places where evaluation order i=
s unspecified, and it has lots of places where evaluation order is locally =
specified.<br><br>But C++ only has one place where the evaluation order is =
well-and-non-locally-specified. And it&#39;s a place that compilers <i>rout=
inely warn about</i>.<br><br>To have them evaluate in an order which is bot=
h well-defined <i>and</i> defined non-locally is the wrong answer.<br><br>N=
ow, if you want to say that the expressions evaluate in the order they appe=
ar, but the members are <i>initialized</i> from those expressions in the or=
der they appear in the struct, that might be workable. Though you&#39;re st=
ill going to have to explain how the possible conversions from the expressi=
on type to the member type.<br><br>But those expressions should not be <i>e=
valuated</i> in a well-and-non-locally-defined order.<br><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>While we should =
of course try to prevent likely bugs with the language rules, I&#39;m convi=
nced that this feature would be much less convenient with this strict order=
ing rule, while at the same time catching *very few* bugs.</div></div></blo=
ckquote></div>

<p></p>

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

------=_Part_5596_373596617.1501624388181--

------=_Part_5595_1244506471.1501624388180--

.

------=_Part_6188_462559311.1501688877890
Content-Type: multipart/alternative;
 boundary="----=_Part_6189_1339901186.1501688877890"

------=_Part_6189_1339901186.1501688877890
Content-Type: text/plain; charset="UTF-8"



Den tisdag 1 augusti 2017 kl. 23:53:08 UTC+2 skrev Nicol Bolas:
>
> On Tuesday, August 1, 2017 at 4:50:57 PM UTC-4, Bengt Gustafsson wrote:
>>
>> @Nicol: Your argument that "so far brace initializers have always had
>> their expression evaluated in order" is irrelevant as it is just as true to
>> say that "so far initializers have always had their expressions evalutated
>> in member declaration order" as both orders are the same as long as we
>> don't have designators! We have one precedent for what rule to use when the
>> members are named: member initializer lists in constructors. Here the rule
>> is that the expressions run in member declaration order, regardless of
>> which order they are written. Not making these orders the same issues a
>> warning in some compiler due to the same fear that you have: someone will
>> at some point use an uninitialized member to initialize another member
>> having *forgotten* the rules of the language.
>>
>> For the designator case you want to strengthen this rule into a mandatory
>> error if designators are placed in a different order than the member
>> declarations.
>>
>
> I contest your analogy. As stated by the paper itself, designated
> initializers is an extension of aggregate initialization, a convenience
> feature. Changing the order of either the evaluation of the expressions or
> the order of initialization takes it into the territory of a new feature,
> not a convenient shortcut.
>
That's all in the eye of the beholder. I don't care what you call it. I'm
just saying that we should give ease of use a little thought, not making
the feature harder to use than needed to avoid some tiny pitfall risk.

>
> Firstly I see this as a bad idea just because it causes the two ways to
>> initiate members to work differently.
>>
>
> To the extent that your analogy makes sense, I see your idea as bad
> because it causes two braced-init-lists to evaluate their expressions in
> different orders.
>
> It's all a question of whose rules you consider sacrosanct.
>

The fact is that in ALL places that members are initialized it is done in
declaration order today. The only place that the language allows the
textual order to diverge is in a member initializer list. To me designated
initializers seem very similar to member initializer list, so the rule
should be the same.


>
> As for the "arbitrarily complex expressions" that would prevent the
>> compiler from finding a reference to a member later in the list I don't see
>> this as plausible as it would require sending the whole object to a
>> function in the midst of its initialization or sending the forward refered
>> member itself to a function, which is as easily detected. Maybe if you take
>> the address of the forward refered member and send it to a function that
>> defers it, but that's piling two unlikely construct on top of each other.
>>
>> Further, here are a couple of observations:
>>
>> 1) using one member to initiate another is very seldom useful as doing so
>> would more or less indicate that you store the same thing twice. In
>> practice I know that I need this extremely seldom, except for giving the
>> address of one member to the constructor of another for future reference.
>> Much more common is to send "this" itself to some member's constructor,
>> which has its own caveats but which no initiation order limitation can
>> alleviate.
>>
>
> While the use of a member in another member's initializer is one problem,
> it is not the *only* problem that evaluation order matters for.
>
> Remember: braced-init-lists are one of the very few places where C++
> guarantees that the *visible* order of expressions represents the *actual*
> order of their evaluation. As such, it is very easy to have two expressions
> be dependent on each other.
>

> Now granted, for designated initializers it's not nearly as easy to
> accidentally rely on as with regular braced-init-lists (since you can't use
> `...` pack expansion). But it is still very possible for you to rely on the
> visible order of expressions, particularly deliberately. After all,
> guaranteed evaluation order is a *feature* of braced-init-lists.
>
> Another reason why I contest the member initializer comparison is because
> of context. Member initializers can only appear in constructors. Indeed,
> they appear before the actual constructor code. As such, you're fairly
> limited as to what side-effects you can rely on. Dependency on order of
> evaluation would thus be through side effects of function calls on
> parameters, globals, and the state of other members.
>
> By contrast, braced-init-lists can appear pretty much anywhere. As such,
> there is a lot more local state to foil around with. It's very easy for you
> to use `++` gymnastics on some local variable and create an ordering
> dependency.
>
And just about every style guide forbids doing that. What you are
advocatring is that everyone should learn to use ++ gymnastics in braced
init lists (but nowhere else) just because some incident or arcane rule
made the expression order mandated. To me it seems that this order
guarantee is a rule not worth learning.


>
> And remember: braced-init-lists guarantee order of evaluation, so right
> now:
>
> int i = 20;
> Agg a{++i, ++i};
>
> That is completely, 100% well-defined. It does exactly what it says it
> does, in exactly the order it appears to.
>
See above.

>
> 2) Making sure that the member init list is in the same order as the
>> member declarations is very tedious and causes lots of warnings especially
>> when adding members. The programmer time spent on doing this tedious work
>> is likely to be many times more than the time lost in finding those rare
>> bugs that thinking that members are initialized in the order that
>> expressions are written would have caused. I think this is safe to say
>> given the extremely low frequency of usage of member a to init member b.
>> Many programmers don't even know that you can do this, as they never needed
>> it.
>>
>
> Considering that compilers tend to warn about having an out-of-order
> member initializer list, I contest this observation. If it were so safe and
> normal, why would there be a warning about it?
>
I don't know. Because the world is full of people who think other people
can't learn how stuff works maybe? I maintain that this warning is
detrimental as it consumes more time to get rid of than is saved by helping
discover very few bugs.



>
>
>> 3) Even with the same initialization order it is easy to make a mistake
>> once you start using one member's value in another members initializer
>> expression either because you didin't think about the ordering or because
>> you re-sorted the members without thinking about it, just reordering the
>> ctor expressions mechanically to silence the warnings.
>>
>> 4) The order of members in a constructor's member initializer list is
>> much closer to the member declaration list and thus easier to maintain than
>> initializers at arbitrary distance from the struct declaration.
>>
>
> That sounds like a really good justification *not* to do this. The order
> of expression evaluation, while well-defined, cannot be *locally* known;
> it is determined by code "at an arbitrary distance from" the actual object
> initialization. Why is it a good thing to have the evaluation order of
> local expression evaluation be controlled due to code contained so far away?
>
Or just put in the style guide, if it is not already there: Don't rely on
the evaluation order of the individual expressions! Clear and simple rule.

>
> Given the following code:
>
> int i = 20;
> Agg a{.mem1 = ++i, .mem2 = ++i};
>
> The way I see it, there are only two reasonable answers for what this code
> does. Either the values of `mem1` and `mem2` are 21 and 22, or their values
> are unspecified. That is, either the expressions evaluate in the order they
> appear, or they evaluate in an order that is unspecified. C++ has lots of
> places where evaluation order is unspecified, and it has lots of places
> where evaluation order is locally specified.
>
I would not write this code. Nor would most programmers, with or without
designators. As stated above I think it is best to just forget that
evaluation order happens to be well defined (in the non-designator case at
least).


>
> But C++ only has one place where the evaluation order is
> well-and-non-locally-specified. And it's a place that compilers *routinely
> warn about*.
>
> To have them evaluate in an order which is both well-defined *and*
> defined non-locally is the wrong answer.
>
Just assume that evaluation order is undefined if there are any designators
then.

>
> Now, if you want to say that the expressions evaluate in the order they
> appear, but the members are *initialized* from those expressions in the
> order they appear in the struct, that might be workable. Though you're
> still going to have to explain how the possible conversions from the
> expression type to the member type.
>
No that would be complicating things unnecessarily.

>
>
>

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

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

<div dir=3D"ltr"><br><br>Den tisdag 1 augusti 2017 kl. 23:53:08 UTC+2 skrev=
 Nicol Bolas:<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">=
On Tuesday, August 1, 2017 at 4:50:57 PM UTC-4, Bengt Gustafsson wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">@Nicol: Your argument =
that &quot;so far brace initializers have always had their expression evalu=
ated in order&quot; is irrelevant as it is just as true to say that &quot;s=
o far initializers have always had their expressions evalutated in member d=
eclaration order&quot; as both orders are the same as long as we don&#39;t =
have designators! We have one precedent for what rule to use when the membe=
rs are named: member initializer lists in constructors. Here the rule is th=
at the expressions run in member declaration order, regardless of which ord=
er they are written. Not making these orders the same issues a warning in s=
ome compiler due to the same fear that you have: someone will at some point=
 use an uninitialized member to initialize another member having *forgotten=
* the rules of the language.<div><br></div><div>For the designator case you=
 want to strengthen this rule into a mandatory error if designators are pla=
ced in a different order than the member declarations.</div></div></blockqu=
ote><div><br>I contest your analogy. As stated by the paper itself, designa=
ted initializers is an extension of aggregate initialization, a convenience=
 feature. Changing the order of either the evaluation of the expressions or=
 the order of initialization takes it into the territory of a new feature, =
not a convenient shortcut.<br></div></div></blockquote><div>That&#39;s all =
in the eye of the beholder. I don&#39;t care what you call it. I&#39;m just=
 saying that we should give ease of use a little thought, not making the fe=
ature harder to use than needed to avoid some tiny pitfall risk.=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Firstly I =
see this as a bad idea just because it causes the two ways to initiate memb=
ers to work differently.</div></div></blockquote><div><br>To the extent tha=
t your analogy makes sense, I see your idea as bad because it causes two br=
aced-init-lists to evaluate their expressions in different orders.<br><br>I=
t&#39;s all a question of whose rules you consider sacrosanct.<br></div></d=
iv></blockquote><div><br></div><div>The fact is that in ALL places that mem=
bers are initialized it is done in declaration order today. The only place =
that the language allows the textual order to diverge is in a member initia=
lizer list. To me designated initializers seem very similar to member initi=
alizer list, so the rule should be the same.</div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><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></div><div>As for t=
he &quot;arbitrarily complex expressions&quot; that would prevent the compi=
ler from finding a reference to a member later in the list I don&#39;t see =
this as plausible as it would require sending the whole object to a functio=
n in the midst of its initialization or sending the forward refered member =
itself to a function, which is as easily detected. Maybe if you take the ad=
dress of the forward refered member and send it to a function that defers i=
t, but that&#39;s piling two unlikely construct on top of each other.</div>=
<div><br></div><div>Further, here are a couple of observations:</div><div><=
br></div><div>1) using one member to initiate another is very seldom useful=
 as doing so would more or less indicate that you store the same thing twic=
e. In practice I know that I need this extremely seldom, except for giving =
the address of one member to the constructor of another for future referenc=
e. Much more common is to send &quot;this&quot; itself to some member&#39;s=
 constructor, which has its own caveats but which no initiation order limit=
ation can alleviate.</div></div></blockquote><div><br>While the use of a me=
mber in another member&#39;s initializer is one problem, it is not the <i>o=
nly</i> problem that evaluation order matters for.<br><br>Remember: braced-=
init-lists are one of the very few places where C++ guarantees that the <i>=
visible</i> order of expressions represents the <i>actual</i> order of thei=
r evaluation. As such, it is very easy to have two expressions be dependent=
 on each other.=C2=A0</div></div></blockquote><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><br>Now granted, for designated initi=
alizers it&#39;s not nearly as easy to accidentally rely on as with regular=
 braced-init-lists (since you can&#39;t use `...` pack expansion). But it i=
s still very possible for you to rely on the visible order of expressions, =
particularly deliberately. After all, guaranteed evaluation order is a <i>f=
eature</i> of braced-init-lists.<br><br>Another reason why I contest the me=
mber initializer comparison is because of context. Member initializers can =
only appear in constructors. Indeed, they appear before the actual construc=
tor code. As such, you&#39;re fairly limited as to what side-effects you ca=
n rely on. Dependency on order of evaluation would thus be through side eff=
ects of function calls on parameters, globals, and the state of other membe=
rs.<br><br>By contrast, braced-init-lists can appear pretty much anywhere. =
As such, there is a lot more local state to foil around with. It&#39;s very=
 easy for you to use `++` gymnastics on some local variable and create an o=
rdering dependency.<br></div></div></blockquote><div>And just about every s=
tyle guide forbids doing that. What you are advocatring is that everyone sh=
ould learn to use ++ gymnastics in braced init lists (but nowhere else) jus=
t because some incident or arcane rule made the expression order mandated. =
To me it seems that this order guarantee is a rule not worth learning.</div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div><br>And remember: braced-init-lists guarantee order of evaluation=
, so right now:<br><br><div style=3D"background-color:rgb(250,250,250);bord=
er-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><div><=
span style=3D"color:#008">int</span><span style=3D"color:#000"> i </span><s=
pan style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span=
 style=3D"color:#066">20</span><span style=3D"color:#660">;</span><span sty=
le=3D"color:#000"><br></span><span style=3D"color:#606">Agg</span><span sty=
le=3D"color:#000"> a</span><span style=3D"color:#660">{++</span><span style=
=3D"color:#000">i</span><span style=3D"color:#660">,</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#660">++</span><span style=3D"color=
:#000">i</span><span style=3D"color:#660">};</span></div></code></div><br>T=
hat is completely, 100% well-defined. It does exactly what it says it does,=
 in exactly the order it appears to.<br></div></div></blockquote><div>See a=
bove.=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div>2) Making sure that the member init list is in the same order as the =
member declarations is very tedious and causes lots of warnings especially =
when adding members. The programmer time spent on doing this tedious work i=
s likely to be many times more than the time lost in finding those rare bug=
s that thinking that members are initialized in the order that expressions =
are written would have caused. I think this is safe to say given the extrem=
ely low frequency of usage of member a to init member b. Many programmers d=
on&#39;t even know that you can do this, as they never needed it.</div></di=
v></blockquote><div><br>Considering that compilers tend to warn about havin=
g an out-of-order member initializer list, I contest this observation. If i=
t were so safe and normal, why would there be a warning about it?<br></div>=
</div></blockquote><div>I don&#39;t know. Because the world is full of peop=
le who think other people can&#39;t learn how stuff works maybe? I maintain=
 that this warning is detrimental as it consumes more time to get rid of th=
an is saved by helping discover very few bugs.</div><div><br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
</div><div>3) Even with the same initialization order it is easy to make a =
mistake once you start using one member&#39;s value in another members init=
ializer expression either because you didin&#39;t think about the ordering =
or because you re-sorted the members without thinking about it, just reorde=
ring the ctor expressions mechanically to silence the warnings.</div><div><=
br></div><div>4) The order of members in a constructor&#39;s member initial=
izer list is much closer to the member declaration list and thus easier to =
maintain than initializers at arbitrary distance from the struct declaratio=
n.</div></div></blockquote><div><br>That sounds like a really good justific=
ation <i>not</i> to do this. The order of expression evaluation, while well=
-defined, cannot be <i>locally</i> known; it is determined by code &quot;at=
 an arbitrary distance from&quot; the actual object initialization. Why is =
it a good thing to have the evaluation order of local expression evaluation=
 be controlled due to code contained so far away?<br></div></div></blockquo=
te><div>Or just put in the style guide, if it is not already there: Don&#39=
;t rely on the evaluation order of the individual expressions! Clear and si=
mple rule.</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"lt=
r"><div><br>Given the following code:<br><br><div style=3D"background-color=
:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-w=
idth:1px"><code><div><span style=3D"color:#008">int</span><span style=3D"co=
lor:#000"> i </span><span style=3D"color:#660">=3D</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#066">20</span><span style=3D"color:#=
660">;</span><span style=3D"color:#000"><br></span><span style=3D"color:#60=
6">Agg</span><span style=3D"color:#000"> a</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:#660">++=
</span><span style=3D"color:#000">i</span><span style=3D"color:#660">,</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#660">.</span><sp=
an style=3D"color:#000">mem2 </span><span style=3D"color:#660">=3D</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#660">++</span><span =
style=3D"color:#000">i</span><span style=3D"color:#660">};</span></div></co=
de></div><br>The way I see it, there are only two reasonable answers for wh=
at this code does. Either the values of `mem1` and `mem2` are 21 and 22, or=
 their values are unspecified. That is, either the expressions evaluate in =
the order they appear, or they evaluate in an order that is unspecified. C+=
+ has lots of places where evaluation order is unspecified, and it has lots=
 of places where evaluation order is locally specified.<br></div></div></bl=
ockquote><div>I would not write this code. Nor would most programmers, with=
 or without designators. As stated above I think it is best to just forget =
that evaluation order happens to be well defined (in the non-designator cas=
e at least).</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div><br>But C++ only has one place where the evalua=
tion order is well-and-non-locally-<wbr>specified. And it&#39;s a place tha=
t compilers <i>routinely warn about</i>.<br><br>To have them evaluate in an=
 order which is both well-defined <i>and</i> defined non-locally is the wro=
ng answer.<br></div></div></blockquote><div>Just assume that evaluation ord=
er is undefined if there are any designators then.=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br>Now, if you want =
to say that the expressions evaluate in the order they appear, but the memb=
ers are <i>initialized</i> from those expressions in the order they appear =
in the struct, that might be workable. Though you&#39;re still going to hav=
e to explain how the possible conversions from the expression type to the m=
ember type.<br></div></div></blockquote><div>No that would be complicating =
things unnecessarily.=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"><br><br></div></blockquote></div>

<p></p>

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

------=_Part_6189_1339901186.1501688877890--

------=_Part_6188_462559311.1501688877890--

.

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

For what it's worth, in C, which also has designated initializers, the
standard says:


*    The evaluations of the initialization list expressions are
indeterminately sequenced with    respect to one another and thus the order
in which any side effects occur is unspecified.152)    152) In particular,
the evaluation order need not be the same as the order of subobject
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZzApzP8Q4vMv1ZNOXntRru%2BUAR1SL3ikhpoCiD6M7V7w%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra">For what it&#39;s worth, in C, =
which also has designated initializers, the standard says:<br><i>=C2=A0 =C2=
=A0 The evaluations of the initialization list expressions are indeterminat=
ely sequenced with<br>=C2=A0 =C2=A0 respect to one another and thus the ord=
er in which any side effects occur is unspecified.152)<br>=C2=A0 =C2=A0=C2=
=A0152) In particular, the evaluation order need not be the same as the ord=
er of subobject initialization.</i></div></div>

<p></p>

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

--001a11473a8ec5b23c0555c8af07--

.

------=_Part_3488_409858815.1501752183382
Content-Type: multipart/alternative;
 boundary="----=_Part_3489_1061062995.1501752183382"

------=_Part_3489_1061062995.1501752183382
Content-Type: text/plain; charset="UTF-8"

Thanks for that valuable piece of information. I think conforming to the
same feature in C is a very good idea. Especially as it is consistent with
my latest suggestion :-)



Den onsdag 2 augusti 2017 kl. 19:35:18 UTC+2 skrev Hyman Rosen:
>
> For what it's worth, in C, which also has designated initializers, the
> standard says:
>
>
> *    The evaluations of the initialization list expressions are
> indeterminately sequenced with    respect to one another and thus the order
> in which any side effects occur is unspecified.152)    152) In particular,
> the evaluation order need not be the same as the order of subobject
> 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/21a896d2-228d-44f5-a2d7-4dc79c9571be%40isocpp.org.

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

<div dir=3D"ltr">Thanks for that valuable piece of information. I think con=
forming to the same feature in C is a very good idea. Especially as it is c=
onsistent with my latest suggestion :-)<div><br><div><br><br>Den onsdag 2 a=
ugusti 2017 kl. 19:35:18 UTC+2 skrev Hyman Rosen:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div>For what it&#39;s worth, in C, whi=
ch also has designated initializers, the standard says:<br><i>=C2=A0 =C2=A0=
 The evaluations of the initialization list expressions are indeterminately=
 sequenced with<br>=C2=A0 =C2=A0 respect to one another and thus the order =
in which any side effects occur is unspecified.152)<br>=C2=A0 =C2=A0=C2=A01=
52) In particular, the evaluation order need not be the same as the order o=
f subobject initialization.</i></div></div>
</blockquote></div></div></div>

<p></p>

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

------=_Part_3489_1061062995.1501752183382--

------=_Part_3488_409858815.1501752183382--

.

On Thu, Aug 3, 2017 at 4:23 AM, Bengt Gustafsson
<bengt.gustafsson@beamways.com> wrote:
> Thanks for that valuable piece of information. I think conforming to the
> same feature in C is a very good idea. Especially as it is consistent with
> my latest suggestion :-)
>
> Den onsdag 2 augusti 2017 kl. 19:35:18 UTC+2 skrev Hyman Rosen:
>>
>> For what it's worth, in C, which also has designated initializers, the
>> standard says:
>>     The evaluations of the initialization list expressions are
>> indeterminately sequenced with
>>     respect to one another and thus the order in which any side effects
>> occur is unspecified.152)
>>     152) In particular, the evaluation order need not be the same as the
>> order of subobject initialization.

No thanks, that's a very bad idea.  When there
is a code, there is an order.  Innocent users may
embed orders in their code without realizing it,
and changing the member order at the library
side will remote control user code's logic.  We
are motivated by delivering features to support
sustainable libraries, not cursed libraries.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________

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

.

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

Based on examples provided by others, I don't see cursed libraries but
legacy systems (Posix, Win32...), which are industry standards for many
years and certainly will be around for many more.

Supporting -at least- this use case for POD-types by not enforcing order
would be beneficial both in developer productivity (don't have to deal with
ordering) and portability (among platforms order is irrelevant).

From a practical point of view, constraining designated initializer to
declaration order will be a burden and most likely won't be used as much.

Unless, that's the goal - being annoying to use by design. In this case, I
would rather not have it in the language.

On Fri, Aug 4, 2017 at 4:28 PM Zhihao Yuan <zy@miator.net> wrote:

> On Thu, Aug 3, 2017 at 4:23 AM, Bengt Gustafsson
> <bengt.gustafsson@beamways.com> wrote:
> > Thanks for that valuable piece of information. I think conforming to the
> > same feature in C is a very good idea. Especially as it is consistent
> with
> > my latest suggestion :-)
> >
> > Den onsdag 2 augusti 2017 kl. 19:35:18 UTC+2 skrev Hyman Rosen:
> >>
> >> For what it's worth, in C, which also has designated initializers, the
> >> standard says:
> >>     The evaluations of the initialization list expressions are
> >> indeterminately sequenced with
> >>     respect to one another and thus the order in which any side effects
> >> occur is unspecified.152)
> >>     152) In particular, the evaluation order need not be the same as the
> >> order of subobject initialization.
>
> No thanks, that's a very bad idea.  When there
> is a code, there is an order.  Innocent users may
> embed orders in their code without realizing it,
> and changing the member order at the library
> side will remote control user code's logic.  We
> are motivated by delivering features to support
> sustainable libraries, not cursed libraries.
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> _______________________________________________
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuDwzS%3DR8pjCoaiBU2GRDKh_%3D8_bdQ6aMGdHxaBcbNLehg%40mail.gmail.com
> .
>

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

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

<div><div dir=3D"auto">Based on examples provided by others, I don&#39;t se=
e cursed libraries but legacy systems (Posix, Win32...), which are industry=
 standards for many years and certainly will be around for many more.</div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">Supporting -at least- this us=
e case for POD-types by not enforcing order would be beneficial both in dev=
eloper productivity (don&#39;t have to deal with ordering) and portability =
(among platforms order is irrelevant).</div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">From a practical point of view, constraining designated init=
ializer to declaration order will be a burden and most likely won&#39;t be =
used as much.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Unless, th=
at&#39;s the goal - being annoying to use by design. In this case, I would =
rather not have it in the language.</div><div><br><div class=3D"gmail_quote=
"><div>On Fri, Aug 4, 2017 at 4:28 PM Zhihao Yuan &lt;<a href=3D"mailto:zy@=
miator.net">zy@miator.net</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">On Thu, Aug 3, 2017 at 4:23 AM, Bengt Gustafsson<br>
&lt;<a href=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_blank">beng=
t.gustafsson@beamways.com</a>&gt; wrote:<br>
&gt; Thanks for that valuable piece of information. I think conforming to t=
he<br>
&gt; same feature in C is a very good idea. Especially as it is consistent =
with<br>
&gt; my latest suggestion :-)<br>
&gt;<br>
&gt; Den onsdag 2 augusti 2017 kl. 19:35:18 UTC+2 skrev Hyman Rosen:<br>
&gt;&gt;<br>
&gt;&gt; For what it&#39;s worth, in C, which also has designated initializ=
ers, the<br>
&gt;&gt; standard says:<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0The evaluations of the initialization list expr=
essions are<br>
&gt;&gt; indeterminately sequenced with<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0respect to one another and thus the order in wh=
ich any side effects<br>
&gt;&gt; occur is unspecified.152)<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0152) In particular, the evaluation order need n=
ot be the same as the<br>
&gt;&gt; order of subobject initialization.<br>
<br>
No thanks, that&#39;s a very bad idea.=C2=A0 When there<br>
is a code, there is an order.=C2=A0 Innocent users may<br>
embed orders in their code without realizing it,<br>
and changing the member order at the library<br>
side will remote control user code&#39;s logic.=C2=A0 We<br>
are motivated by delivering features to support<br>
sustainable libraries, not cursed libraries.<br>
<br>
--<br>
Zhihao Yuan, ID lichray<br>
The best way to predict the future is to invent it.<br>
_______________________________________________<br>
<br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGsORuDwzS%3DR8pjCoaiBU2GRDKh_%3D8_b=
dQ6aMGdHxaBcbNLehg%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuDwzS%3DR=
8pjCoaiBU2GRDKh_%3D8_bdQ6aMGdHxaBcbNLehg%40mail.gmail.com</a>.<br>
</blockquote></div></div></div>

<p></p>

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

--001a11456f12301d780556060149--

.

On Sat, Aug 5, 2017 at 1:44 PM, Ricardo Fabiano de Andrade
<ricardofabianodeandrade@gmail.com> wrote:
> Based on examples provided by others, I don't see cursed libraries but
> legacy systems (Posix, Win32...), which are industry standards for many
> years and certainly will be around for many more.
>

Cursed, newly written, libraries.

> Supporting -at least- this use case for POD-types by not enforcing order
> would be beneficial both in developer productivity (don't have to deal with
> ordering) and portability (among platforms order is irrelevant).
>

The raised use cases have already being
covered by https://godbolt.org/g/nSk8cr (Matt),
what you are asking for right now is to solve
a solved problem in a specific form rather
than solving a problem itself.

> From a practical point of view, constraining designated initializer to
> declaration order will be a burden and most likely won't be used as much.
>

There is nothing to support your claim.

> Unless, that's the goal - being annoying to use by design. In this case, I
> would rather not have it in the language.
>

It is okay if you don't share our motivations,
but if you don't even bother reading the first
page of the paper,

  http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0329r0.pdf

, I have little to help.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________

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

.

On Sat, Aug 05, 2017 at 11:29:29PM -0500, Zhihao Yuan wrote:
> On Sat, Aug 5, 2017 at 1:44 PM, Ricardo Fabiano de Andrade
> <ricardofabianodeandrade@gmail.com> wrote:
> > Based on examples provided by others, I don't see cursed libraries but
> > legacy systems (Posix, Win32...), which are industry standards for many
> > years and certainly will be around for many more.
>
> Cursed, newly written, libraries.

Yes, you disagree with their style but please do not force that disagreement
upon the rest of us.

> > Supporting -at least- this use case for POD-types by not enforcing order
> > would be beneficial both in developer productivity (don't have to deal with
> > ordering) and portability (among platforms order is irrelevant).
> >
>
> The raised use cases have already being
> covered by https://godbolt.org/g/nSk8cr (Matt),
> what you are asking for right now is to solve
> a solved problem in a specific form rather
> than solving a problem itself.
>
> > From a practical point of view, constraining designated initializer to
> > declaration order will be a burden and most likely won't be used as much.
>
> There is nothing to support your claim.
>
> > Unless, that's the goal - being annoying to use by design. In this case, I
> > would rather not have it in the language.
>
> It is okay if you don't share our motivations,
> but if you don't even bother reading the first
> page of the paper,
>
>   http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0329r0.pdf

On that very first page one of the motivations you are listing is

"To increase interoperability between C and C++"

but you are then arguing for the use of a lambda construct rather than
designated initializers in cases where C programs would use designated
initializers.

Is this feature intended to increase interoperability or not?

I would also claim that this restriction works against your stated motivation
"Towards more flexible and sustainable aggregate initialization" since you are
putting limitations on the implementation of the structure that wasn't there
before.

Please remember that the godbolt solution works equally well for all
variations and that if we import designated initializers from C99 as is and
limit them to trivial types then that is more interoperable than this proposal.

/MF

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

.

On Sun, Aug 6, 2017 at 2:48 AM, Magnus Fromreide <magfr@lysator.liu.se> wrote:
> On Sat, Aug 05, 2017 at 11:29:29PM -0500, Zhihao Yuan wrote:
>>   http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0329r0.pdf
>
> On that very first page one of the motivations you are listing is
>
> "To increase interoperability between C and C++"
>
> but you are then arguing for the use of a lambda construct rather than
> designated initializers in cases where C programs would use designated
> initializers.
>
> Is this feature intended to increase interoperability or not?
>

Yes, and it already does.  It allows library authors
to form a header embedded with designated
initializers supporting both C and C++.  More
specifically, take

  https://code.woboq.org/linux/linux/arch/x86/include/uapi/asm/stat.h.html

as an example, the macros like

#define INIT_STRUCT_STAT_PADDING(st) do { \
    st.__unused4 = 0; \
    st.__unused5 = 0; \
} while (0)

can be replaced with an initializer macro (in the
style of PTHREAD_MUTEX_INITIALIZER)
using designated initializers.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________

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

.

On Sun, Aug 06, 2017 at 04:57:35AM -0500, Zhihao Yuan wrote:
> On Sun, Aug 6, 2017 at 2:48 AM, Magnus Fromreide <magfr@lysator.liu.se> wrote:
> > On Sat, Aug 05, 2017 at 11:29:29PM -0500, Zhihao Yuan wrote:
> >>   http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0329r0.pdf
> >
> > On that very first page one of the motivations you are listing is
> >
> > "To increase interoperability between C and C++"
> >
> > but you are then arguing for the use of a lambda construct rather than
> > designated initializers in cases where C programs would use designated
> > initializers.
> >
> > Is this feature intended to increase interoperability or not?
> >
>
> Yes, and it already does.  It allows library authors to form a header
> embedded with designated initializers supporting both C and C++.

Library authors are about the only people who don't need this feature (sure,
it is nice but not needed that much) since they are in control of the
internals of their structs and thus they can use old style struct
initialization safely.

This is why some libraries contain initialization macros like
PTHREAD_MUTEX_INITIALIZER.

> More specifically, take
>
>   https://code.woboq.org/linux/linux/arch/x86/include/uapi/asm/stat.h.html
>
> as an example, the macros like
>
> #define INIT_STRUCT_STAT_PADDING(st) do { \
>     st.__unused4 = 0; \
>     st.__unused5 = 0; \
> } while (0)
>
> can be replaced with an initializer macro (in the
> style of PTHREAD_MUTEX_INITIALIZER)
> using designated initializers.

No, they can't. If you read the comment right above that macro then you will
see that the point of it is to initialize just the padding members while the
the rest of the struct is left untouched, so in this case deferred
initialization is what the author is looking for.

This file also demonstrates, in the alternate definition of that very macro
on lines 106-111, that initialization of array members is a used feature.

/MF

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

.

------=_Part_2297_160116592.1502040270713
Content-Type: multipart/alternative;
 boundary="----=_Part_2298_601215137.1502040270713"

------=_Part_2298_601215137.1502040270713
Content-Type: text/plain; charset="UTF-8"

I thought the C99 compatibility aspect would resound more, especially as
there is no C++ specific issues in the argumentation for setting a
different rule: Using uninitialized fields is the same (tiny) problem in C
as in C++ struct initialization.

Another aspect is upgrading from C to C++. With stricter rules in C++ this
puts additional burden on those who want to move from C to C++, and I think
we should make this upgrade path as smooth as possible...

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

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

<div dir=3D"ltr"><div>I thought the C99 compatibility aspect would resound =
more, especially as there is no C++ specific issues in the argumentation fo=
r setting a different rule: Using uninitialized fields is the same (tiny) p=
roblem in C as in C++ struct initialization.</div><div><br></div>Another as=
pect is upgrading from C to C++. With stricter rules in C++ this puts addit=
ional burden on those who want to move from C to C++, and I think we should=
 make this upgrade path as smooth as possible...</div>

<p></p>

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

------=_Part_2298_601215137.1502040270713--

------=_Part_2297_160116592.1502040270713--

.

On Sun, Aug 6, 2017 at 5:27 AM, Magnus Fromreide <magfr@lysator.liu.se> wrote:
>
> Library authors are about the only people who don't need this feature (sure,
> it is nice but not needed that much) since they are in control of the
> internals of their structs and thus they can use old style struct
> initialization safely.
>

Are you denying our needs? :)

>> can be replaced with an initializer macro (in the
>> style of PTHREAD_MUTEX_INITIALIZER)
>> using designated initializers.
>
> No, they can't. If you read the comment right above that macro then you will
> see that the point of it is to initialize just the padding members while the
> the rest of the struct is left untouched, so in this case deferred
> initialization is what the author is looking for.
>

Just an example, as long as you understand
the pattern.

> This file also demonstrates, in the alternate definition of that very macro
> on lines 106-111, that initialization of array members is a used feature.
>

That can simply be replaced by

    st.__unused = { 0, 0, 0 }

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________

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

.

On Sun, Aug 6, 2017 at 12:24 PM, Bengt Gustafsson
<bengt.gustafsson@beamways.com> wrote:
> Another aspect is upgrading from C to C++. With stricter rules in C++ this
> puts additional burden on those who want to move from C to C++, and I think
> we should make this upgrade path as smooth as possible...
>

Narrowing conversion rules are an precedent
as stricter rules, and we see it works well.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________

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

.

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

On Sat, Aug 5, 2017 at 11:29 PM, Zhihao Yuan <zy@miator.net> wrote:

> On Sat, Aug 5, 2017 at 1:44 PM, Ricardo Fabiano de Andrade
> <ricardofabianodeandrade@gmail.com> wrote:
> > Based on examples provided by others, I don't see cursed libraries but
> > legacy systems (Posix, Win32...), which are industry standards for many
> > years and certainly will be around for many more.
> >
>
> Cursed, newly written, libraries.
>
>
I understand that if strict ordering is not enforced, new code may rely on
it and either:
1) break, because there are dependencies among members.
2) have the performance affected, because it requires temporaries, as
mentioned in the proposal.

For 1, compilers may be smart enough to be able to detect the situation and
warn accordingly.
For 2, I am willing to pay this cost in name of usability if there was a
way to safely opt-in, at least for POD-types.

> Supporting -at least- this use case for POD-types by not enforcing order
> > would be beneficial both in developer productivity (don't have to deal
> with
> > ordering) and portability (among platforms order is irrelevant).
> >
>
> The raised use cases have already being
> covered by https://godbolt.org/g/nSk8cr (Matt),
> what you are asking for right now is to solve
> a solved problem in a specific form rather
> than solving a problem itself.
>
>
You're telling me that:
struct A { int x; int y; int z; ...a zillion members... };
A aVeryLongAndMeaningfulName;
aVeryLongAndMeaningfulName.x = 1
aVeryLongAndMeaningfulName.y = 2
aVeryLongAndMeaningfulName.z = 3
....repeat the variable name a zillion times...

It's the same as:
A aVeryLongAndMeaningfulName = { .x = 1, .y = 2, .z = 3 ...just
initialization... };

From the perspective of the user, it's not. The former adds lot of noise.


> > From a practical point of view, constraining designated initializer to
> > declaration order will be a burden and most likely won't be used as much.
> >
>
> There is nothing to support your claim.
>
>
I really can't predict the future with such certainty.
But most people give up easily on something that doesn't work according to
their expectations and first impressions.


> > Unless, that's the goal - being annoying to use by design. In this case,
> I
> > would rather not have it in the language.
> >
>
> It is okay if you don't share our motivations,
> but if you don't even bother reading the first
> page of the paper,
>
>   http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0329r0.pdf
>
> , I have little to help.
>
>
Yes, I've read the paper and it feels like it strips down the C99 designed
initializers a bit too much.
I understand the way the proposal was written may be what's needed in order
to make it pass through the standardization process though.

I'll step back from my previous rumbling...
Let's say it may be worth something testing the waters with the proposal as
is and improve the support for designated initializers over time.
However, strict ordering was something of an issue that may not be "forward
compatible" and therefore worth to fight for in name of usability.


> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> _______________________________________________
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/is
> ocpp.org/d/msgid/std-proposals/CAGsORuBVSoUhkMg2_fGYRWzSCwbz
> %3DSPxUZ6P0c5%2BYmY_KKRLOw%40mail.gmail.com.
>

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

--f403043794c097694b05562a3516
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 Sat, Aug 5, 2017 at 11:29 PM, Zhihao Yuan <span dir=3D"ltr">&lt;<a href=
=3D"mailto:zy@miator.net" target=3D"_blank">zy@miator.net</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Aug 5, 20=
17 at 1:44 PM, Ricardo Fabiano de Andrade<br>
&lt;<a href=3D"mailto:ricardofabianodeandrade@gmail.com" target=3D"_blank">=
ricardofabianodeandrade@gmail<wbr>.com</a>&gt; wrote:<br>
&gt; Based on examples provided by others, I don&#39;t see cursed libraries=
 but<br>
&gt; legacy systems (Posix, Win32...), which are industry standards for man=
y<br>
&gt; years and certainly will be around for many more.<br>
&gt;<br>
<br>
Cursed, newly written, libraries.<br>
<br></blockquote><div><br></div><div>I understand that if strict ordering i=
s not enforced, new code may rely on it and either:</div><div>1) break, bec=
ause there are dependencies among members.</div><div>2) have the performanc=
e affected, because it requires temporaries, as mentioned in the proposal.<=
/div><div><br></div><div>For 1, compilers may be smart enough to be able to=
 detect the situation and warn accordingly.<br></div><div><div>For 2, I am =
willing to pay this cost in name of usability if there was a way to safely =
opt-in, at least=C2=A0for POD-types.</div></div><div><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex">
&gt; Supporting -at least- this use case for POD-types by not enforcing ord=
er<br>
&gt; would be beneficial both in developer productivity (don&#39;t have to =
deal with<br>
&gt; ordering) and portability (among platforms order is irrelevant).<br>
&gt;<br>
<br>
The raised use cases have already being<br>
covered by <a href=3D"https://godbolt.org/g/nSk8cr" rel=3D"noreferrer" targ=
et=3D"_blank">https://godbolt.org/g/nSk8cr</a> (Matt),<br>
what you are asking for right now is to solve<br>
a solved problem in a specific form rather<br>
than solving a problem itself.<br>
<br></blockquote><div><br></div><div>You&#39;re telling me that:<br></div><=
div>struct A { int x; int y; int z; ...a zillion members... };</div><div>A =
aVeryLongAndMeaningfulName;</div><div>aVeryLongAndMeaningfulName.x =3D 1</d=
iv><div>aVeryLongAndMeaningfulName.y =3D 2<br></div><div>aVeryLongAndMeanin=
gfulName.z =3D 3<br></div><div>...repeat the variable name a zillion times.=
...</div><div><br></div><div>It&#39;s the same as:</div><div>A aVeryLongAndM=
eaningfulName =3D { .x =3D 1, .y =3D 2, .z =3D 3 ...just initialization... =
};</div><div><br></div><div>From the perspective of the user, it&#39;s not.=
 The former adds lot of noise.</div><div>=C2=A0<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
&gt; From a practical point of view, constraining designated initializer to=
<br>
&gt; declaration order will be a burden and most likely won&#39;t be used a=
s much.<br>
&gt;<br>
<br>
There is nothing to support your claim.<br>
<br></blockquote><div><br></div><div>I really can&#39;t predict the future =
with such certainty.</div><div>But most people give up easily on something =
that doesn&#39;t work according to their expectations and first impressions=
..</div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">
&gt; Unless, that&#39;s the goal - being annoying to use by design. In this=
 case, I<br>
&gt; would rather not have it in the language.<br>
&gt;<br>
<br>
It is okay if you don&#39;t share our motivations,<br>
but if you don&#39;t even bother reading the first<br>
page of the paper,<br>
<br>
=C2=A0 <a href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2016/p=
0329r0.pdf" rel=3D"noreferrer" target=3D"_blank">http://www.open-std.org/JT=
C1/S<wbr>C22/WG21/docs/papers/2016/p032<wbr>9r0.pdf</a><br>
<br>
, I have little to help.<br>
<span class=3D"gmail-m_-6144073142348546950gmail-HOEnZb"><font color=3D"#88=
8888"><br></font></span></blockquote><div><br></div><div>Yes, I&#39;ve read=
 the paper and it feels like it strips down the C99 designed initializers a=
 bit too much.<br></div><div><div><div>I understand the way the proposal wa=
s written may be what&#39;s needed in order to make it pass through the sta=
ndardization process though.</div></div><div><br></div><div>I&#39;ll step b=
ack from my previous rumbling...</div><div>Let&#39;s say it may be worth so=
mething testing the waters with the proposal as is and improve the support =
for designated initializers over time.<br></div></div><div>However, strict =
ordering was something of an issue that may not be &quot;forward
compatible&quot; and therefore worth to fight for in name of usability.<br>=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><s=
pan class=3D"gmail-m_-6144073142348546950gmail-HOEnZb"><font color=3D"#8888=
88">
--<br>
Zhihao Yuan, ID lichray<br>
The best way to predict the future is to invent it.<br>
______________________________<wbr>_________________<br>
<br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGsORuBVSoUhkMg2_fGYRWzSCwbz%3DSPxUZ=
6P0c5%2BYmY_KKRLOw%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">h=
ttps://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/CAGsO=
RuBVSoUhkMg2_fGYRWzSCwbz<wbr>%3DSPxUZ6P0c5%2BYmY_KKRLOw%<wbr>40mail.gmail.c=
om</a>.<br>
</font></span></blockquote></div><br></div></div>

<p></p>

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

--f403043794c097694b05562a3516--

.

On Mon, Aug 7, 2017 at 8:56 AM, Ricardo Fabiano de Andrade
<ricardofabianodeandrade@gmail.com> wrote:
>
> I understand that if strict ordering is not enforced, new code may rely on
> it and either:
> 1) break, because there are dependencies among members.
> 2) have the performance affected, because it requires temporaries, as
> mentioned in the proposal.
>
> For 1, compilers may be smart enough to be able to detect the situation and
> warn accordingly.
> For 2, I am willing to pay this cost in name of usability if there was a way
> to safely opt-in, at least for POD-types.
>

Show me your plans.

>
> You're telling me that:
> struct A { int x; int y; int z; ...a zillion members... };
> A aVeryLongAndMeaningfulName;
> aVeryLongAndMeaningfulName.x = 1
> aVeryLongAndMeaningfulName.y = 2
> aVeryLongAndMeaningfulName.z = 3
> ...repeat the variable name a zillion times...
>
> It's the same as:
> A aVeryLongAndMeaningfulName = { .x = 1, .y = 2, .z = 3 ...just
> initialization... };
>
> From the perspective of the user, it's not. The former adds lot of noise.
>

You can fix that with

  A aVeryLongAndMeaningfulName = []
  {
      A a;
      a.x = 1,
      a.y = 2,
      a.z = 3,
      ...repeat `a` and always `a`...
      return a;
  }();

> But most people give up easily on something that doesn't work according to
> their expectations and first impressions.
>

That's exactly how most people react to
C++'s `volatile` keyword, and guess what,
we still have little to solve the "problem" :/

> Yes, I've read the paper and it feels like it strips down the C99 designed
> initializers a bit too much.
>

You can feel so, but the truth is, we started
from trying to understand what does
designated initialization really mean for C++
and the first thing we realized was that it must
be a form of initialization, rather than, for
example, assignment.

> However, strict ordering was something of an issue that may not be "forward
> compatible" and therefore worth to fight for in name of usability.
>

I think we eliminated potential forward compatible
issues, for example, we deliberately deployed rules
to not allow written orders to affect overload
resolution.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________

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

.