Topic: Initializing arrays using non-default constructors
Author: Avi Kivity <avi@scylladb.com>
Date: Sun, 8 Apr 2018 19:48:45 +0300
Raw View
If I have an array
=C2=A0=C2=A0=C2=A0 foo a[10000];
I can either let it be initialized with the default constructor, or=20
choose aggregate initialization and specify initializers for each element.
Since the trend is not to require default constructors (or move/copy=20
assignment operators), we should have a way to initialize arrays using=20
user-defined constructors.
We might allow something like
=C2=A0=C2=A0=C2=A0 foo a[10000] =3D std::by_element(some_iterator);
The user supplied an input iterator, whose operator* returns a tuple,=20
and that tuple is used to to feed the constructor. For example
=C2=A0=C2=A0=C2=A0 int a[10000] =3D=20
std::by_element(boost::make_transform_iterator(boost::make_counting_iterato=
r(0),=20
[] (int x) { return std::tuple(x); }));
will initialize the array to the sequence 0..9999. We might relax the=20
constraints to allow non-tuples, in which case the result of operator*=20
is def to a single-argument constructor of the array element type:
=C2=A0=C2=A0=C2=A0 std::array<foo, N> xform(std::array<bar, N> a) {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return std::array<f=
oo, N>(std::by_element(a));
=C2=A0=C2=A0=C2=A0 }
calls foo::foo(bar&).
Currently, we can solve the problem with std::aligned_storage and=20
placement new, but that's quite an ugly workaround.
--=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/64e29521-ac56-f324-7140-23e824f418d8%40scylladb.=
com.
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Sun, 08 Apr 2018 16:51:50 +0000
Raw View
--001a11407d14b853970569591b75
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
El dom., 8 de abril de 2018 13:48, Avi Kivity <avi@scylladb.com> escribi=C3=
=B3:
> If I have an array
>
>
> foo a[10000];
>
>
> I can either let it be initialized with the default constructor, or
> choose aggregate initialization and specify initializers for each element=
..
>
Long ago in a galaxy far far away...
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1467.pdf
>
> Since the trend is not to require default constructors (or move/copy
> assignment operators), we should have a way to initialize arrays using
> user-defined constructors.
>
>
> We might allow something like
>
>
> foo a[10000] =3D std::by_element(some_iterator);
>
>
> The user supplied an input iterator, whose operator* returns a tuple,
> and that tuple is used to to feed the constructor. For example
>
>
>
> int a[10000] =3D
>
> std::by_element(boost::make_transform_iterator(boost::make_counting_itera=
tor(0),
> [] (int x) { return std::tuple(x); }));
>
>
> will initialize the array to the sequence 0..9999. We might relax the
> constraints to allow non-tuples, in which case the result of operator*
> is def to a single-argument constructor of the array element type:
>
>
> std::array<foo, N> xform(std::array<bar, N> a) {
>
> return std::array<foo, N>(std::by_element(a));
>
> }
>
>
> calls foo::foo(bar&).
>
>
> Currently, we can solve the problem with std::aligned_storage and
> placement new, but that's quite an ugly workaround.
>
>
> --
> 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/64e29521-ac5=
6-f324-7140-23e824f418d8%40scylladb.com
> .
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFdMc-15cx%3DsuctMUmttF8DXAreFwh7%3DWxLzWRu033O=
eCtECuA%40mail.gmail.com.
--001a11407d14b853970569591b75
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
El dom., 8 de abril de 2018 13:48, Avi Kivity <<a href=3D"mailto:avi@scy=
lladb.com">avi@scylladb.com</a>> escribi=C3=B3:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">If I have an array<br>
<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 foo a[10000];<br>
<br>
<br>
I can either let it be initialized with the default constructor, or<br>
choose aggregate initialization and specify initializers for each element.<=
br></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">L=
ong ago in a galaxy far far away...</div><div dir=3D"auto">=C2=A0 =C2=A0 =
=C2=A0=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2=
003/n1467.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n146=
7.pdf</a></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div=
dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Since the trend is not to require default constructors (or move/copy<br>
assignment operators), we should have a way to initialize arrays using<br>
user-defined constructors.<br>
<br>
<br>
We might allow something like<br>
<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 foo a[10000] =3D std::by_element(some_iterator);<b=
r>
<br>
<br>
The user supplied an input iterator, whose operator* returns a tuple,<br>
and that tuple is used to to feed the constructor. For example<br>
<br>
<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 int a[10000] =3D<br>
std::by_element(boost::make_transform_iterator(boost::make_counting_iterato=
r(0),<br>
[] (int x) { return std::tuple(x); }));<br>
<br>
<br>
will initialize the array to the sequence 0..9999. We might relax the<br>
constraints to allow non-tuples, in which case the result of operator*<br>
is def to a single-argument constructor of the array element type:<br>
<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 std::array<foo, N> xform(std::array<bar, =
N> a) {<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return std::ar=
ray<foo, N>(std::by_element(a));<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 }<br>
<br>
<br>
calls foo::foo(bar&).<br>
<br>
<br>
Currently, we can solve the problem with std::aligned_storage and<br>
placement new, but that's quite an ugly workaround.<br>
<br>
<br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank" rel=3D"noreferrer">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" rel=3D"noreferrer">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/64e29521-ac56-f324-7140-23e824f418d8%=
40scylladb.com" rel=3D"noreferrer noreferrer" target=3D"_blank">https://gro=
ups.google.com/a/isocpp.org/d/msgid/std-proposals/64e29521-ac56-f324-7140-2=
3e824f418d8%40scylladb.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" 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/CAFdMc-15cx%3DsuctMUmttF8DXAreFwh7%3D=
WxLzWRu033OeCtECuA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-15cx%3=
DsuctMUmttF8DXAreFwh7%3DWxLzWRu033OeCtECuA%40mail.gmail.com</a>.<br />
--001a11407d14b853970569591b75--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Sun, 8 Apr 2018 20:01:38 +0300
Raw View
This is a multi-part message in MIME format.
--------------C7B124C38C11FBF080709289
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
On 04/08/2018 07:51 PM, dgutson . wrote:
>
>
> El dom., 8 de abril de 2018 13:48, Avi Kivity <avi@scylladb.com=20
> <mailto:avi@scylladb.com>> escribi=C3=B3:
>
> If I have an array
>
>
> =C2=A0=C2=A0=C2=A0=C2=A0 foo a[10000];
>
>
> I can either let it be initialized with the default constructor, or
> choose aggregate initialization and specify initializers for each
> element.
>
>
> Long ago in a galaxy far far away...
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1467.pdf
>
>
Interesting! Nicer and simpler than my proposal.
Did it get any traction?
--=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/ff984fb4-3448-e698-4506-879a80ac1182%40scylladb.=
com.
--------------C7B124C38C11FBF080709289
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
<br>
<div class=3D"moz-cite-prefix">On 04/08/2018 07:51 PM, dgutson .
wrote:<br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:CAFdMc-15cx=3DsuctMUmttF8DXAreFwh7=3DWxLzWRu033OeCtECuA@mail.gm=
ail.com">
<div dir=3D"auto">
<div><br>
<br>
<div class=3D"gmail_quote">
<div dir=3D"ltr">El dom., 8 de abril de 2018 13:48, Avi Kivity
<<a href=3D"mailto:avi@scylladb.com"
moz-do-not-send=3D"true">avi@scylladb.com</a>>
escribi=C3=B3:<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">If I
have an array<br>
<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 foo a[10000];<br>
<br>
<br>
I can either let it be initialized with the default
constructor, or<br>
choose aggregate initialization and specify initializers
for each element.<br>
</blockquote>
</div>
</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">Long ago in a galaxy far far away...</div>
<div dir=3D"auto">=C2=A0 =C2=A0 =C2=A0=C2=A0<a
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003=
/n1467.pdf"
moz-do-not-send=3D"true">http://www.open-std.org/jtc1/sc22/wg21=
/docs/papers/2003/n1467.pdf</a></div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto"><br>
</div>
</div>
</blockquote>
<br>
Interesting! Nicer and simpler than my proposal.<br>
<br>
Did it get any traction?<br>
<br>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/ff984fb4-3448-e698-4506-879a80ac1182%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/ff984fb4-3448-e698-4506-879a80ac11=
82%40scylladb.com</a>.<br />
--------------C7B124C38C11FBF080709289--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Sun, 08 Apr 2018 17:06:15 +0000
Raw View
--001a11407d1435f7150569594fa6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
El dom., 8 de abril de 2018 14:01, Avi Kivity <avi@scylladb.com> escribi=C3=
=B3:
>
>
> On 04/08/2018 07:51 PM, dgutson . wrote:
>
>
>
> El dom., 8 de abril de 2018 13:48, Avi Kivity <avi@scylladb.com> escribi=
=C3=B3:
>
>> If I have an array
>>
>>
>> foo a[10000];
>>
>>
>> I can either let it be initialized with the default constructor, or
>> choose aggregate initialization and specify initializers for each elemen=
t.
>>
>
> Long ago in a galaxy far far away...
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1467.pdf
>
>
>
> Interesting! Nicer and simpler than my proposal.
>
> Did it get any traction?
>
I had no chance to present it. I had to choose 3 proposals (I wrote 13 for
that meeting). One of them later led to the initializer list. I could only
come back to a wg21 meeting 10 years later with a different goal.
>
--=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/CAFdMc-3m9auFOhYCZC8L08T%3Dav2uxtSsdyM5MdS61UupY=
d%3Dn4A%40mail.gmail.com.
--001a11407d1435f7150569594fa6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
El dom., 8 de abril de 2018 14:01, Avi Kivity <<a href=3D"mailto:avi@scy=
lladb.com">avi@scylladb.com</a>> escribi=C3=B3:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
<br>
<div class=3D"m_-2824481361494882118moz-cite-prefix">On 04/08/2018 07:5=
1 PM, dgutson .
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"auto">
<div><br>
<br>
<div class=3D"gmail_quote">
<div dir=3D"ltr">El dom., 8 de abril de 2018 13:48, Avi Kivity
<<a href=3D"mailto:avi@scylladb.com" target=3D"_blank" rel=
=3D"noreferrer">avi@scylladb.com</a>>
escribi=C3=B3:<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">If I
have an array<br>
<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 foo a[10000];<br>
<br>
<br>
I can either let it be initialized with the default
constructor, or<br>
choose aggregate initialization and specify initializers
for each element.<br>
</blockquote>
</div>
</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">Long ago in a galaxy far far away...</div>
<div dir=3D"auto">=C2=A0 =C2=A0 =C2=A0=C2=A0<a href=3D"http://www.o=
pen-std.org/jtc1/sc22/wg21/docs/papers/2003/n1467.pdf" target=3D"_blank" re=
l=3D"noreferrer">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1=
467.pdf</a></div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto"><br>
</div>
</div>
</blockquote>
<br>
Interesting! Nicer and simpler than my proposal.<br>
<br>
Did it get any traction?<br></div></blockquote></div></div><div dir=3D"=
auto"><br></div><div dir=3D"auto">I had no chance to present it. I had to c=
hoose 3 proposals (I wrote 13 for that meeting). One of them later led to t=
he initializer list. I could only come back to a wg21 meeting 10 years late=
r with a different goal.</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div text=3D"#000000" bgcolor=3D"#FFFFFF">
<br>
</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" 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/CAFdMc-3m9auFOhYCZC8L08T%3Dav2uxtSsdy=
M5MdS61UupYd%3Dn4A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-3m9auF=
OhYCZC8L08T%3Dav2uxtSsdyM5MdS61UupYd%3Dn4A%40mail.gmail.com</a>.<br />
--001a11407d1435f7150569594fa6--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Sun, 8 Apr 2018 20:10:03 +0300
Raw View
This is a multi-part message in MIME format.
--------------DEADE1C3DA71A3BFBF61BA70
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
On 04/08/2018 08:06 PM, dgutson . wrote:
>
>
> El dom., 8 de abril de 2018 14:01, Avi Kivity <avi@scylladb.com=20
> <mailto:avi@scylladb.com>> escribi=C3=B3:
>
>
>
> On 04/08/2018 07:51 PM, dgutson . wrote:
>>
>>
>> El dom., 8 de abril de 2018 13:48, Avi Kivity <avi@scylladb.com
>> <mailto:avi@scylladb.com>> escribi=C3=B3:
>>
>> If I have an array
>>
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0 foo a[10000];
>>
>>
>> I can either let it be initialized with the default
>> constructor, or
>> choose aggregate initialization and specify initializers for
>> each element.
>>
>>
>> Long ago in a galaxy far far away...
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1467.pdf
>>
>>
>
> Interesting! Nicer and simpler than my proposal.
>
> Did it get any traction?
>
>
> I had no chance to present it. I had to choose 3 proposals (I wrote 13=20
> for that meeting). One of them later led to the initializer list. I=20
> could only come back to a wg21 meeting 10 years later with a different=20
> goal.
>
Well, I hope it makes it into the language one day. It's not a huge=20
problem, but it's a wart, and your proposal fixes it very neatly.
--=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/54f78ec5-77a7-76f5-db86-fff79d38c6b0%40scylladb.=
com.
--------------DEADE1C3DA71A3BFBF61BA70
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
<br>
<div class=3D"moz-cite-prefix">On 04/08/2018 08:06 PM, dgutson .
wrote:<br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:CAFdMc-3m9auFOhYCZC8L08T=3Dav2uxtSsdyM5MdS61UupYd=3Dn4A@mail.gm=
ail.com">
<div dir=3D"auto">
<div><br>
<br>
<div class=3D"gmail_quote">
<div dir=3D"ltr">El dom., 8 de abril de 2018 14:01, Avi Kivity
<<a href=3D"mailto:avi@scylladb.com"
moz-do-not-send=3D"true">avi@scylladb.com</a>>
escribi=C3=B3:<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
<br>
<div class=3D"m_-2824481361494882118moz-cite-prefix">On
04/08/2018 07:51 PM, dgutson . wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"auto">
<div><br>
<br>
<div class=3D"gmail_quote">
<div dir=3D"ltr">El dom., 8 de abril de 2018
13:48, Avi Kivity <<a
href=3D"mailto:avi@scylladb.com"
target=3D"_blank" rel=3D"noreferrer"
moz-do-not-send=3D"true">avi@scylladb.com</a>&g=
t;
escribi=C3=B3:<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">If I have an array<br>
<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 foo a[10000];<br>
<br>
<br>
I can either let it be initialized with the
default constructor, or<br>
choose aggregate initialization and specify
initializers for each element.<br>
</blockquote>
</div>
</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">Long ago in a galaxy far far away...<=
/div>
<div dir=3D"auto">=C2=A0 =C2=A0 =C2=A0=C2=A0<a
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs=
/papers/2003/n1467.pdf"
target=3D"_blank" rel=3D"noreferrer"
moz-do-not-send=3D"true">http://www.open-std.org/jt=
c1/sc22/wg21/docs/papers/2003/n1467.pdf</a></div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto"><br>
</div>
</div>
</blockquote>
<br>
Interesting! Nicer and simpler than my proposal.<br>
<br>
Did it get any traction?<br>
</div>
</blockquote>
</div>
</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">I had no chance to present it. I had to choose 3
proposals (I wrote 13 for that meeting). One of them later led
to the initializer list. I could only come back to a wg21
meeting 10 years later with a different goal.</div>
<div dir=3D"auto"><br>
</div>
</div>
</blockquote>
<br>
Well, I hope it makes it into the language one day. It's not a huge
problem, but it's a wart, and your proposal fixes it very neatly.<br>
<br>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/54f78ec5-77a7-76f5-db86-fff79d38c6b0%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/54f78ec5-77a7-76f5-db86-fff79d38c6=
b0%40scylladb.com</a>.<br />
--------------DEADE1C3DA71A3BFBF61BA70--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 8 Apr 2018 10:32:32 -0700 (PDT)
Raw View
------=_Part_19148_519914849.1523208753058
Content-Type: multipart/alternative;
boundary="----=_Part_19149_856126447.1523208753058"
------=_Part_19149_856126447.1523208753058
Content-Type: text/plain; charset="UTF-8"
On Sunday, April 8, 2018 at 12:48:50 PM UTC-4, Avi Kivity wrote:
>
> If I have an array
>
>
> foo a[10000];
>
>
> I can either let it be initialized with the default constructor, or
> choose aggregate initialization and specify initializers for each element.
>
>
> Since the trend is not to require default constructors (or move/copy
> assignment operators),
Wait, there's a trend towards that? I certainly don't see it in the
standard library. `variant` in particular practically bends over backwards
to allow default construction.
The trend is to avoiding *uninitialization*. If `foo` had a proper default
constructor, then none of the elements in that array will go uninitialized.
And you can avoid leaving things uninitialized even if `foo` has trivial
default construction by doing `foo a[10000] = {};`.
The idea of initializing an array by repeatedly calling some function is
not without merit. The problem is that it doesn't work for `std::array`.
And we really would rather people use that than language arrays.
--
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/b1e90895-1e46-41d0-a81d-f680aaf1e5e8%40isocpp.org.
------=_Part_19149_856126447.1523208753058
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, April 8, 2018 at 12:48:50 PM UTC-4, Avi=
Kivity wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">If I have an arr=
ay
<br>
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0 foo a[10000];
<br>
<br>
<br>I can either let it be initialized with the default constructor, or=20
<br>choose aggregate initialization and specify initializers for each eleme=
nt.
<br>
<br>
<br>Since the trend is not to require default constructors (or move/copy=20
<br>assignment operators),</blockquote><div><br>Wait, there's a trend t=
owards that? I certainly don't see it in the standard library. `variant=
` in particular practically bends over backwards to allow default construct=
ion.<br><br>The trend is to avoiding <i>uninitialization</i>. If `foo` had =
a proper default constructor, then none of the elements in that array will =
go uninitialized. And you can avoid leaving things uninitialized even if `f=
oo` has trivial default construction by doing `foo a[10000] =3D {};`.<br><b=
r>The idea of initializing an array by repeatedly calling some function is =
not without merit. The problem is that it doesn't work for `std::array`=
.. And we really would rather people use that than language arrays.<br></div=
></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b1e90895-1e46-41d0-a81d-f680aaf1e5e8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b1e90895-1e46-41d0-a81d-f680aaf1e5e8=
%40isocpp.org</a>.<br />
------=_Part_19149_856126447.1523208753058--
------=_Part_19148_519914849.1523208753058--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Sun, 08 Apr 2018 17:51:17 +0000
Raw View
--94eb2c19290a59d22c056959f00c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
El dom., 8 de abril de 2018 14:32, Nicol Bolas <jmckesson@gmail.com>
escribi=C3=B3:
>
>
> On Sunday, April 8, 2018 at 12:48:50 PM UTC-4, Avi Kivity wrote:
>>
>> If I have an array
>>
>>
>> foo a[10000];
>>
>>
>> I can either let it be initialized with the default constructor, or
>> choose aggregate initialization and specify initializers for each
>> element.
>>
>>
>> Since the trend is not to require default constructors (or move/copy
>> assignment operators),
>
>
> Wait, there's a trend towards that? I certainly don't see it in the
> standard library. `variant` in particular practically bends over backward=
s
> to allow default construction.
>
> The trend is to avoiding *uninitialization*. If `foo` had a proper
> default constructor, then none of the elements in that array will go
> uninitialized. And you can avoid leaving things uninitialized even if `fo=
o`
> has trivial default construction by doing `foo a[10000] =3D {};`.
>
> The idea of initializing an array by repeatedly calling some function is
> not without merit. The problem is that it doesn't work for `std::array`
>
Why fixing that would be a problem? E.g. a special class&& receiving
something like a lambda or std::function as constructor argument for being
itself an argumeny for std::array ctor. By special I mean a specific std
class, such as nothrow_t.
auto i=3D0u;
std::array<X, Y> arr(std::constructor_arg ([&i] (return ++i;)));
.. And we really would rather people use that than language arrays.
>
> --
> 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/b1e90895-1e4=
6-41d0-a81d-f680aaf1e5e8%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b1e90895-1e=
46-41d0-a81d-f680aaf1e5e8%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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/CAFdMc-13NCOPp_TxKDWk4%2BXfTxJBHxoR_L%3DcKdiZtxP=
HbWrtxA%40mail.gmail.com.
--94eb2c19290a59d22c056959f00c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
El dom., 8 de abril de 2018 14:32, Nicol Bolas <<a href=3D"mailto:jmckes=
son@gmail.com">jmckesson@gmail.com</a>> escribi=C3=B3:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Sunday, April 8, 2018 at=
12:48:50 PM UTC-4, Avi Kivity wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
">If I have an array
<br>
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0 foo a[10000];
<br>
<br>
<br>I can either let it be initialized with the default constructor, or=20
<br>choose aggregate initialization and specify initializers for each eleme=
nt.
<br>
<br>
<br>Since the trend is not to require default constructors (or move/copy=20
<br>assignment operators),</blockquote><div><br>Wait, there's a trend t=
owards that? I certainly don't see it in the standard library. `variant=
` in particular practically bends over backwards to allow default construct=
ion.<br><br>The trend is to avoiding <i>uninitialization</i>. If `foo` had =
a proper default constructor, then none of the elements in that array will =
go uninitialized. And you can avoid leaving things uninitialized even if `f=
oo` has trivial default construction by doing `foo a[10000] =3D {};`.<br><b=
r>The idea of initializing an array by repeatedly calling some function is =
not without merit. The problem is that it doesn't work for `std::array`=
</div></div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Why fixing that would be a problem? E.g. a special class&&=
; receiving something like a lambda or std::function as constructor argumen=
t for being itself an argumeny for std::array ctor. By special I mean a spe=
cific std class, such as nothrow_t.</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">auto i=3D0u;</div><div dir=3D"auto">std::array<X, Y> arr(=
std::constructor_arg ([&i] (return ++i;)));</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>. And we really wo=
uld rather people use that than language arrays.<br></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">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" rel=3D"noreferrer">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/b1e90895-1e46-41d0-a81d-f680aaf1e5e8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/b1e90895-1e46-41d0-a81d-f680aaf1e5e8%40isocpp.org</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" 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/CAFdMc-13NCOPp_TxKDWk4%2BXfTxJBHxoR_L=
%3DcKdiZtxPHbWrtxA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-13NCOP=
p_TxKDWk4%2BXfTxJBHxoR_L%3DcKdiZtxPHbWrtxA%40mail.gmail.com</a>.<br />
--94eb2c19290a59d22c056959f00c--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 8 Apr 2018 12:52:14 -0700 (PDT)
Raw View
------=_Part_19764_64437608.1523217134757
Content-Type: multipart/alternative;
boundary="----=_Part_19765_1439745212.1523217134757"
------=_Part_19765_1439745212.1523217134757
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Sunday, April 8, 2018 at 1:51:31 PM UTC-4, dgutson wrote:
>
>
>
> El dom., 8 de abril de 2018 14:32, Nicol Bolas <jmck...@gmail.com=20
> <javascript:>> escribi=C3=B3:
>
>>
>>
>> On Sunday, April 8, 2018 at 12:48:50 PM UTC-4, Avi Kivity wrote:
>>>
>>> If I have an array=20
>>>
>>>
>>> foo a[10000];=20
>>>
>>>
>>> I can either let it be initialized with the default constructor, or=20
>>> choose aggregate initialization and specify initializers for each=20
>>> element.=20
>>>
>>>
>>> Since the trend is not to require default constructors (or move/copy=20
>>> assignment operators),
>>
>>
>> Wait, there's a trend towards that? I certainly don't see it in the=20
>> standard library. `variant` in particular practically bends over backwar=
ds=20
>> to allow default construction.
>>
>> The trend is to avoiding *uninitialization*. If `foo` had a proper=20
>> default constructor, then none of the elements in that array will go=20
>> uninitialized. And you can avoid leaving things uninitialized even if `f=
oo`=20
>> has trivial default construction by doing `foo a[10000] =3D {};`.
>>
>> The idea of initializing an array by repeatedly calling some function is=
=20
>> not without merit. The problem is that it doesn't work for `std::array`
>>
>
> Why fixing that would be a problem? E.g. a special class&& receiving=20
> something like a lambda or std::function as constructor argument for bein=
g=20
> itself an argumeny for std::array ctor. By special I mean a specific std=
=20
> class, such as nothrow_t.
>
> auto i=3D0u;
> std::array<X, Y> arr(std::constructor_arg ([&i] (return ++i;)));
>
Because this would require `array` to have constructors. And it can't do=20
that if it's going to remain an *aggregate*. And you can't just make it not=
=20
an aggregate anymore, since there's tons of code out there which relies on=
=20
it using aggregate initialization.
So if there's going to be something like this, it needs to be tied into=20
aggregate initialization as a mechanism. And that's really hard to do,=20
since AI can be used on heterogeneous structs, not just homogeneous arrays.
--=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/337e41e6-57fc-4e3a-91c1-36eded2667dd%40isocpp.or=
g.
------=_Part_19765_1439745212.1523217134757
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, April 8, 2018 at 1:51:31 PM UTC-4, dgut=
son 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"><d=
iv><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">El dom., 8 de abril =
de 2018 14:32, Nicol Bolas <<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"tu5uQyMMCAAJ" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D'javascript:';return true;" onclick=3D"this.href=3D'javas=
cript:';return true;">jmck...@gmail.com</a>> escribi=C3=B3:<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Sunday, April 8=
, 2018 at 12:48:50 PM UTC-4, Avi Kivity wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex">If I have an array
<br>
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0 foo a[10000];
<br>
<br>
<br>I can either let it be initialized with the default constructor, or=20
<br>choose aggregate initialization and specify initializers for each eleme=
nt.
<br>
<br>
<br>Since the trend is not to require default constructors (or move/copy=20
<br>assignment operators),</blockquote><div><br>Wait, there's a trend t=
owards that? I certainly don't see it in the standard library. `variant=
` in particular practically bends over backwards to allow default construct=
ion.<br><br>The trend is to avoiding <i>uninitialization</i>. If `foo` had =
a proper default constructor, then none of the elements in that array will =
go uninitialized. And you can avoid leaving things uninitialized even if `f=
oo` has trivial default construction by doing `foo a[10000] =3D {};`.<br><b=
r>The idea of initializing an array by repeatedly calling some function is =
not without merit. The problem is that it doesn't work for `std::array`=
</div></div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Why fixing that would be a problem? E.g. a special class&&=
; receiving something like a lambda or std::function as constructor argumen=
t for being itself an argumeny for std::array ctor. By special I mean a spe=
cific std class, such as nothrow_t.</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">auto i=3D0u;</div><div dir=3D"auto">std::array<X, Y> arr(=
std::constructor_arg ([&i] (return ++i;)));</div></div></blockquote><di=
v><br>Because this would require `array` to have constructors. And it can&#=
39;t do that if it's going to remain an <i>aggregate</i>. And you can&#=
39;t just make it not an aggregate anymore, since there's tons of code =
out there which relies on it using aggregate initialization.<br><br>So if t=
here's going to be something like this, it needs to be tied into aggreg=
ate initialization as a mechanism. And that's really hard to do, since =
AI can be used on heterogeneous structs, not just homogeneous arrays.<br></=
div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/337e41e6-57fc-4e3a-91c1-36eded2667dd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/337e41e6-57fc-4e3a-91c1-36eded2667dd=
%40isocpp.org</a>.<br />
------=_Part_19765_1439745212.1523217134757--
------=_Part_19764_64437608.1523217134757--
.
Author: Alberto Barbati <albertobarbati@gmail.com>
Date: Mon, 9 Apr 2018 02:43:08 -0700 (PDT)
Raw View
------=_Part_22228_670499984.1523266988851
Content-Type: multipart/alternative;
boundary="----=_Part_22229_681624937.1523266988851"
------=_Part_22229_681624937.1523266988851
Content-Type: text/plain; charset="UTF-8"
Il giorno domenica 8 aprile 2018 19:10:07 UTC+2, Avi Kivity ha scritto:
>
> Well, I hope it makes it into the language one day. It's not a huge
> problem, but it's a wart, and your proposal fixes it very neatly.
>
>
I don't think we need a language facility for that. This scenario could be
addressed with special library function:
template <class T, size_t N, class InputIterator>
std::array<T, N> make_array(InputIterator values);
This has to be a library function, because the implementation needs,
possibly exploiting compiler magic, to ensure that:
1) the array is created *without* calling the default constructors of its
elements, even if they would be used: elements are then initialized with
std::uninitialized_copy_n
2) the constructed array is returned with guaranteed copy elision (this may
be the hard part, since this is probably a case of NRVO where the elision
may occur, but it's not guaranteed)
Since we have a parallel version of std::uninitialized_copy_n, we might
even have a parallel version of make_array.
--
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/605f73ad-2157-4a8c-9abc-7dcb24606a7d%40isocpp.org.
------=_Part_22229_681624937.1523266988851
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Il giorno domenica 8 aprile 2018 19:10:07 UTC+2, Avi Kivit=
y ha scritto:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">Well, I hope it makes it into t=
he language one day. It's not a huge
problem, but it's a wart, and your proposal fixes it very neatly.<b=
r>
<br></div></blockquote><div><br>I don't think we need a language fa=
cility for that. This scenario could be addressed with special library func=
tion:<br><br>template <class T, size_t N, class InputIterator><br>std=
::array<T, N> make_array(InputIterator values);<br><br>This has to be=
a library function, because the implementation needs, possibly exploiting =
compiler magic, to ensure that:<br><br>1) the array is created *without* ca=
lling the default constructors of its elements, even if they would be used:=
elements are then initialized with std::uninitialized_copy_n<br>2) the con=
structed array is returned with guaranteed copy elision (this may be the ha=
rd part, since this is probably a case of NRVO where the elision may occur,=
but it's not guaranteed)<br><br>Since we have a parallel version of st=
d::uninitialized_copy_n, we might even have a parallel version of make_arra=
y.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/605f73ad-2157-4a8c-9abc-7dcb24606a7d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/605f73ad-2157-4a8c-9abc-7dcb24606a7d=
%40isocpp.org</a>.<br />
------=_Part_22229_681624937.1523266988851--
------=_Part_22228_670499984.1523266988851--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Mon, 9 Apr 2018 16:23:39 +0300
Raw View
This is a multi-part message in MIME format.
--------------2F8706D7238D9030151864A1
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
On 2018-04-09 12:43, Alberto Barbati wrote:
> Il giorno domenica 8 aprile 2018 19:10:07 UTC+2, Avi Kivity ha scritto:
>
> Well, I hope it makes it into the language one day. It's not a
> huge problem, but it's a wart, and your proposal fixes it very neatly=
..
>
>
> I don't think we need a language facility for that. This scenario=20
> could be addressed with special library function:
>
> template <class T, size_t N, class InputIterator>
> std::array<T, N> make_array(InputIterator values);
>
> This has to be a library function, because the implementation needs,=20
> possibly exploiting compiler magic, to ensure that:
>
> 1) the array is created *without* calling the default constructors of=20
> its elements, even if they would be used: elements are then=20
> initialized with std::uninitialized_copy_n
> 2) the constructed array is returned with guaranteed copy elision=20
> (this may be the hard part, since this is probably a case of NRVO=20
> where the elision may occur, but it's not guaranteed)
>
> Since we have a parallel version of std::uninitialized_copy_n, we=20
> might even have a parallel version of make_array.
>
Minor problems in a library implementation:
=C2=A0- I think it will be hard to make it constexpr, and such a low-level=
=20
facility should support constexpr
=C2=A0- it still requires move construction, which may not be possible for=
=20
classes whose constructors capture 'this' (for example, in a lambda that=20
gets registered somewhere).
--=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/52caa97d-2cc6-98f8-e4ae-6cc6de3f68b0%40scylladb.=
com.
--------------2F8706D7238D9030151864A1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
<br>
<div class=3D"moz-cite-prefix">On 2018-04-09 12:43, Alberto Barbati
wrote:<br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:605f73ad-2157-4a8c-9abc-7dcb24606a7d@isocpp.org">
<div dir=3D"ltr">Il giorno domenica 8 aprile 2018 19:10:07 UTC+2,
Avi Kivity ha scritto:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">Well, I hope it makes i=
t
into the language one day. It's not a huge problem, but it's
a wart, and your proposal fixes it very neatly.<br>
<br>
</div>
</blockquote>
<div><br>
I don't think we need a language facility for that. This
scenario could be addressed with special library function:<br>
<br>
template <class T, size_t N, class InputIterator><br>
std::array<T, N> make_array(InputIterator values);<br>
<br>
This has to be a library function, because the implementation
needs, possibly exploiting compiler magic, to ensure that:<br>
<br>
1) the array is created *without* calling the default
constructors of its elements, even if they would be used:
elements are then initialized with std::uninitialized_copy_n<br>
2) the constructed array is returned with guaranteed copy
elision (this may be the hard part, since this is probably a
case of NRVO where the elision may occur, but it's not
guaranteed)<br>
<br>
Since we have a parallel version of std::uninitialized_copy_n,
we might even have a parallel version of make_array.<br>
</div>
</div>
<br>
</blockquote>
<br>
Minor problems in a library implementation:<br>
=C2=A0- I think it will be hard to make it constexpr, and such a
low-level facility should support constexpr<br>
=C2=A0- it still requires move construction, which may not be possible
for classes whose constructors capture 'this' (for example, in a
lambda that gets registered somewhere).<br>
<br>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/52caa97d-2cc6-98f8-e4ae-6cc6de3f68b0%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/52caa97d-2cc6-98f8-e4ae-6cc6de3f68=
b0%40scylladb.com</a>.<br />
--------------2F8706D7238D9030151864A1--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Mon, 9 Apr 2018 16:25:19 +0300
Raw View
This is a multi-part message in MIME format.
--------------E6DA1FF0F231FCE8A760A563
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
On 2018-04-08 20:32, Nicol Bolas wrote:
>
>
> On Sunday, April 8, 2018 at 12:48:50 PM UTC-4, Avi Kivity wrote:
>
> If I have an array
>
>
> =C2=A0=C2=A0=C2=A0=C2=A0 foo a[10000];
>
>
> I can either let it be initialized with the default constructor, or
> choose aggregate initialization and specify initializers for each
> element.
>
>
> Since the trend is not to require default constructors (or move/copy
> assignment operators),
>
>
> Wait, there's a trend towards that? I certainly don't see it in the=20
> standard library. `variant` in particular practically bends over=20
> backwards to allow default construction.
The trend is towards not requiring default constructors in user types.
>
> The trend is to avoiding /uninitialization/. If `foo` had a proper=20
> default constructor, then none of the elements in that array will go=20
> uninitialized. And you can avoid leaving things uninitialized even if=20
> `foo` has trivial default construction by doing `foo a[10000] =3D {};`.
>
Not all classes can have a reasonable default constructor (for example,=20
classes with reference members).
> The idea of initializing an array by repeatedly calling some function=20
> is not without merit. The problem is that it doesn't work for=20
> `std::array`. And we really would rather people use that than language=20
> arrays.
>
--=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/c209e43c-3629-e1f7-c2df-4c6bbe6a2407%40scylladb.=
com.
--------------E6DA1FF0F231FCE8A760A563
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
<br>
<div class=3D"moz-cite-prefix">On 2018-04-08 20:32, Nicol Bolas wrote:<=
br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:b1e90895-1e46-41d0-a81d-f680aaf1e5e8@isocpp.org">
<div dir=3D"ltr"><br>
<br>
On Sunday, April 8, 2018 at 12:48:50 PM UTC-4, Avi Kivity wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">If I
have an array
<br>
<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 foo a[10000];
<br>
<br>
<br>
I can either let it be initialized with the default
constructor, or <br>
choose aggregate initialization and specify initializers for
each element.
<br>
<br>
<br>
Since the trend is not to require default constructors (or
move/copy <br>
assignment operators),</blockquote>
<div><br>
Wait, there's a trend towards that? I certainly don't see it
in the standard library. `variant` in particular practically
bends over backwards to allow default construction.<br>
</div>
</div>
</blockquote>
<br>
The trend is towards not requiring default constructors in user
types.<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:b1e90895-1e46-41d0-a81d-f680aaf1e5e8@isocpp.org">
<div dir=3D"ltr">
<div><br>
The trend is to avoiding <i>uninitialization</i>. If `foo`
had a proper default constructor, then none of the elements in
that array will go uninitialized. And you can avoid leaving
things uninitialized even if `foo` has trivial default
construction by doing `foo a[10000] =3D {};`.<br>
<br>
</div>
</div>
</blockquote>
<br>
Not all classes can have a reasonable default constructor (for
example, classes with reference members).<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:b1e90895-1e46-41d0-a81d-f680aaf1e5e8@isocpp.org">
<div dir=3D"ltr">
<div>The idea of initializing an array by repeatedly calling
some function is not without merit. The problem is that it
doesn't work for `std::array`. And we really would rather
people use that than language arrays.<br>
</div>
</div>
<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c209e43c-3629-e1f7-c2df-4c6bbe6a2407%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/c209e43c-3629-e1f7-c2df-4c6bbe6a24=
07%40scylladb.com</a>.<br />
--------------E6DA1FF0F231FCE8A760A563--
.
Author: Alberto Barbati <albertobarbati@gmail.com>
Date: Mon, 9 Apr 2018 06:45:52 -0700 (PDT)
Raw View
------=_Part_23717_1082873791.1523281552699
Content-Type: multipart/alternative;
boundary="----=_Part_23718_727407196.1523281552699"
------=_Part_23718_727407196.1523281552699
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Il giorno luned=C3=AC 9 aprile 2018 15:23:44 UTC+2, Avi Kivity ha scritto:
>
>
> Minor problems in a library implementation:
> - I think it will be hard to make it constexpr, and such a low-level=20
> facility should support constexpr
>
I agree that having it constexpr would be useful. I'm not convinced it=20
would be hard to get, what makes you so sure?=20
- it still requires move construction, which may not be possible for=20
> classes whose constructors capture 'this' (for example, in a lambda that=
=20
> gets registered somewhere).
>
>
I don't see where it would require a move construction. Could you please=20
elaborate? (Notice that I assume we can have both guaranteed NRVO and=20
guaranteed copy elision. Without either of them, the approach loses most of=
=20
its appeal.)
A.
PS: I forgot to mention that we could also have a variant using=20
uninitialized_move_n instead of uninitialized_copy_n. =20
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/3a388583-2bd5-45c1-8802-04f3be788317%40isocpp.or=
g.
------=_Part_23718_727407196.1523281552699
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>Il giorno luned=C3=AC 9 aprile 2018 15:23:44 UTC+2, Av=
i Kivity ha scritto:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
Minor problems in a library implementation:<br>
=C2=A0- I think it will be hard to make it constexpr, and such a
low-level facility should support constexpr<br></div></blockquote><div>=
<br><br>I agree that having it constexpr would be useful. I'm not convi=
nced it would be hard to get, what makes you so sure? <br><br></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 text=3D"#000000" bgcolor=3D"#FFF=
FFF">
=C2=A0- it still requires move construction, which may not be possible
for classes whose constructors capture 'this' (for example, in =
a
lambda that gets registered somewhere).<br>
<br></div></blockquote><div><br><br>I don't see where it would requ=
ire a move construction. Could you please elaborate? (Notice that I assume =
we can have both guaranteed NRVO and guaranteed copy elision. Without eithe=
r of them, the approach loses most of its appeal.)<br><br>A.<br><br>PS: I f=
orgot to mention that we could also have a variant using uninitialized_move=
_n instead of uninitialized_copy_n.=C2=A0 <br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3a388583-2bd5-45c1-8802-04f3be788317%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3a388583-2bd5-45c1-8802-04f3be788317=
%40isocpp.org</a>.<br />
------=_Part_23718_727407196.1523281552699--
------=_Part_23717_1082873791.1523281552699--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Mon, 9 Apr 2018 16:53:15 +0300
Raw View
This is a multi-part message in MIME format.
--------------075717B0DC5245FC92D82BD3
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
On 2018-04-09 16:45, Alberto Barbati wrote:
>
> Il giorno luned=C3=AC 9 aprile 2018 15:23:44 UTC+2, Avi Kivity ha scritto=
:
>
>
> Minor problems in a library implementation:
> =C2=A0- I think it will be hard to make it constexpr, and such a
> low-level facility should support constexpr
>
>
>
> I agree that having it constexpr would be useful. I'm not convinced it=20
> would be hard to get, what makes you so sure?
I'm not sure at all. I'm just not optimistic that all the=20
union+placement new stuff would be constexpr.
>
> =C2=A0- it still requires move construction, which may not be possibl=
e
> for classes whose constructors capture 'this' (for example, in a
> lambda that gets registered somewhere).
>
>
>
> I don't see where it would require a move construction. Could you=20
> please elaborate? (Notice that I assume we can have both guaranteed=20
> NRVO and guaranteed copy elision. Without either of them, the approach=20
> loses most of its appeal.)
>
We can't construct the return value as a local since it would involve=20
default construction. So we have to have some kind of union, from which=20
the result would be moved.
std::array<T, N> make_array(Iterator i ) {
=C2=A0=C2=A0=C2=A0 std::array<T, N> ret =3D ?;
=C2=A0=C2=A0=C2=A0 ...
=C2=A0=C2=A0=C2=A0 return ret;
}
> A.
>
> PS: I forgot to mention that we could also have a variant using=20
> uninitialized_move_n instead of uninitialized_copy_n.
>
Those are also not constexpr, perhaps due to the placement new requirement.
--=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/400d315d-e76e-9174-ace4-fb53c3a7b077%40scylladb.=
com.
--------------075717B0DC5245FC92D82BD3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
<br>
<div class=3D"moz-cite-prefix">On 2018-04-09 16:45, Alberto Barbati
wrote:<br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:3a388583-2bd5-45c1-8802-04f3be788317@isocpp.org">
<div dir=3D"ltr"><br>
Il giorno luned=C3=AC 9 aprile 2018 15:23:44 UTC+2, Avi Kivity ha
scritto:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
Minor problems in a library implementation:<br>
=C2=A0- I think it will be hard to make it constexpr, and such =
a
low-level facility should support constexpr<br>
</div>
</blockquote>
<div><br>
<br>
I agree that having it constexpr would be useful. I'm not
convinced it would be hard to get, what makes you so sure? <br>
</div>
</div>
</blockquote>
<br>
I'm not sure at all. I'm just not optimistic that all the
union+placement new stuff would be constexpr.<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:3a388583-2bd5-45c1-8802-04f3be788317@isocpp.org">
<div dir=3D"ltr">
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div text=3D"#000000" bgcolor=3D"#FFFFFF"> =C2=A0- it still requi=
res
move construction, which may not be possible for classes
whose constructors capture 'this' (for example, in a lambda
that gets registered somewhere).<br>
<br>
</div>
</blockquote>
<div><br>
<br>
I don't see where it would require a move construction. Could
you please elaborate? (Notice that I assume we can have both
guaranteed NRVO and guaranteed copy elision. Without either of
them, the approach loses most of its appeal.)<br>
<br>
</div>
</div>
</blockquote>
<br>
We can't construct the return value as a local since it would
involve default construction. So we have to have some kind of union,
from which the result would be moved.<br>
<br>
std::array<T, N> make_array(Iterator i ) {<br>
=C2=A0=C2=A0=C2=A0 std::array<T, N> ret =3D ?;<br>
=C2=A0=C2=A0=C2=A0 ...<br>
=C2=A0=C2=A0=C2=A0 return ret;<br>
}<br>
<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:3a388583-2bd5-45c1-8802-04f3be788317@isocpp.org">
<div dir=3D"ltr">
<div>A.<br>
<br>
PS: I forgot to mention that we could also have a variant
using uninitialized_move_n instead of uninitialized_copy_n.=C2=A0=
<br>
</div>
</div>
<br>
</blockquote>
<br>
Those are also not constexpr, perhaps due to the placement new
requirement.<br>
<br>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/400d315d-e76e-9174-ace4-fb53c3a7b077%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/400d315d-e76e-9174-ace4-fb53c3a7b0=
77%40scylladb.com</a>.<br />
--------------075717B0DC5245FC92D82BD3--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 9 Apr 2018 07:52:44 -0700 (PDT)
Raw View
------=_Part_23803_1953462748.1523285564287
Content-Type: multipart/alternative;
boundary="----=_Part_23804_1108562115.1523285564287"
------=_Part_23804_1108562115.1523285564287
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Monday, April 9, 2018 at 9:53:19 AM UTC-4, Avi Kivity wrote:
>
>
>
> On 2018-04-09 16:45, Alberto Barbati wrote:
>
>
> Il giorno luned=C3=AC 9 aprile 2018 15:23:44 UTC+2, Avi Kivity ha scritto=
:=20
>>
>>
>> Minor problems in a library implementation:
>> - I think it will be hard to make it constexpr, and such a low-level=20
>> facility should support constexpr
>>
>
>
> I agree that having it constexpr would be useful. I'm not convinced it=20
> would be hard to get, what makes you so sure?=20
>
>
> I'm not sure at all. I'm just not optimistic that all the union+placement=
=20
> new stuff would be constexpr.
>
The whole point of making it a standard library function is that it doens't=
=20
*have* to be implemented with "all the union+placement new stuff". It works=
=20
because the standard *says* that it works. It will be `constexpr` by=20
definition.
--=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/45edbfd0-4d33-4796-b86e-68b2a552dfb6%40isocpp.or=
g.
------=_Part_23804_1108562115.1523285564287
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, April 9, 2018 at 9:53:19 AM UTC-4, Avi Kivity w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
<br>
<div>On 2018-04-09 16:45, Alberto Barbati
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
Il giorno luned=C3=AC 9 aprile 2018 15:23:44 UTC+2, Avi Kivity ha
scritto:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
Minor problems in a library implementation:<br>
=C2=A0- I think it will be hard to make it constexpr, and such =
a
low-level facility should support constexpr<br>
</div>
</blockquote>
<div><br>
<br>
I agree that having it constexpr would be useful. I'm not
convinced it would be hard to get, what makes you so sure? <br>
</div>
</div>
</blockquote>
<br>
I'm not sure at all. I'm just not optimistic that all the
union+placement new stuff would be constexpr.<br></div></blockquote><di=
v><br>The whole point of making it a standard library function is that it d=
oens't <i>have</i> to be implemented with "all the union+placement=
new stuff". It works because the standard <i>says</i> that it works. =
It will be `constexpr` by definition.</div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/45edbfd0-4d33-4796-b86e-68b2a552dfb6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/45edbfd0-4d33-4796-b86e-68b2a552dfb6=
%40isocpp.org</a>.<br />
------=_Part_23804_1108562115.1523285564287--
------=_Part_23803_1953462748.1523285564287--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 9 Apr 2018 08:00:49 -0700 (PDT)
Raw View
------=_Part_23467_1109638129.1523286049421
Content-Type: multipart/alternative;
boundary="----=_Part_23468_1151646535.1523286049421"
------=_Part_23468_1151646535.1523286049421
Content-Type: text/plain; charset="UTF-8"
On Monday, April 9, 2018 at 9:25:23 AM UTC-4, Avi Kivity wrote:
>
>
>
> On 2018-04-08 20:32, Nicol Bolas wrote:
>
>
>
> On Sunday, April 8, 2018 at 12:48:50 PM UTC-4, Avi Kivity wrote:
>>
>> If I have an array
>>
>>
>> foo a[10000];
>>
>>
>> I can either let it be initialized with the default constructor, or
>> choose aggregate initialization and specify initializers for each
>> element.
>>
>>
>> Since the trend is not to require default constructors (or move/copy
>> assignment operators),
>
>
> Wait, there's a trend towards that? I certainly don't see it in the
> standard library. `variant` in particular practically bends over backwards
> to allow default construction.
>
>
> The trend is towards not requiring default constructors in user types.
>
Can you point to some evidence for this trend? Because I don't see a great
increase in the number of types without default constructors in C++.
Indeed, the range concepts use Semiregular *everywhere*, and Semiregular,
requires DefaultConstructible.
So I see plenty of evidence that DefaultConstructible remains a common
expectation for user 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/ea8f7a49-fb18-488c-99ca-2e1fdffccd64%40isocpp.org.
------=_Part_23468_1151646535.1523286049421
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, April 9, 2018 at 9:25:23 AM UTC-4, Avi =
Kivity wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
<br>
<div>On 2018-04-08 20:32, Nicol Bolas wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
<br>
On Sunday, April 8, 2018 at 12:48:50 PM UTC-4, Avi Kivity wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">If I
have an array
<br>
<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 foo a[10000];
<br>
<br>
<br>
I can either let it be initialized with the default
constructor, or <br>
choose aggregate initialization and specify initializers for
each element.
<br>
<br>
<br>
Since the trend is not to require default constructors (or
move/copy <br>
assignment operators),</blockquote>
<div><br>
Wait, there's a trend towards that? I certainly don't see=
it
in the standard library. `variant` in particular practically
bends over backwards to allow default construction.<br>
</div>
</div>
</blockquote>
<br>
The trend is towards not requiring default constructors in user
types.<br></div></blockquote><div><br>Can you point to some evidence fo=
r this trend? Because I don't see a great increase in the number of typ=
es without default constructors in C++. Indeed, the range concepts use Semi=
regular <i>everywhere</i>, and Semiregular, requires DefaultConstructible.<=
br><br>So I see plenty of evidence that DefaultConstructible remains a comm=
on expectation for user types.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ea8f7a49-fb18-488c-99ca-2e1fdffccd64%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ea8f7a49-fb18-488c-99ca-2e1fdffccd64=
%40isocpp.org</a>.<br />
------=_Part_23468_1151646535.1523286049421--
------=_Part_23467_1109638129.1523286049421--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Mon, 9 Apr 2018 16:53:48 +0100
Raw View
--0000000000006822c905696c6969
Content-Type: text/plain; charset="UTF-8"
On 9 April 2018 at 16:00, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Monday, April 9, 2018 at 9:25:23 AM UTC-4, Avi Kivity wrote:
>>
>>
>>
>> On 2018-04-08 20:32, Nicol Bolas wrote:
>>
>>
>>
>> On Sunday, April 8, 2018 at 12:48:50 PM UTC-4, Avi Kivity wrote:
>>>
>>> If I have an array
>>>
>>>
>>> foo a[10000];
>>>
>>>
>>> I can either let it be initialized with the default constructor, or
>>> choose aggregate initialization and specify initializers for each
>>> element.
>>>
>>>
>>> Since the trend is not to require default constructors (or move/copy
>>> assignment operators),
>>
>>
>> Wait, there's a trend towards that? I certainly don't see it in the
>> standard library. `variant` in particular practically bends over backwards
>> to allow default construction.
>>
>>
>> The trend is towards not requiring default constructors in user types.
>>
>
> Can you point to some evidence for this trend? Because I don't see a great
> increase in the number of types without default constructors in C++.
> Indeed, the range concepts use Semiregular *everywhere*, and Semiregular,
> requires DefaultConstructible.
>
FWIW 1 data point here.
In my code, types are only ever default-constructible if they are useful if
constructed as such. If I'm deserialising non-default-constructible objects
or storing them in arrays I use generator functions. I don't tolerate
redundant constructions. It's bad form, invites inefficiency, and invites
bugs.
>
> So I see plenty of evidence that DefaultConstructible remains a common
> expectation for user 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/ea8f7a49-fb18-488c-
> 99ca-2e1fdffccd64%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ea8f7a49-fb18-488c-99ca-2e1fdffccd64%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hawja9ZC8rg7CL%2B66Eiw%2BxWG9ABsiSoVXnC33qyWG965A%40mail.gmail.com.
--0000000000006822c905696c6969
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 9 April 2018 at 16:00, Nicol Bolas <span dir=3D"ltr"><<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=
=3D""><br><br>On Monday, April 9, 2018 at 9:25:23 AM UTC-4, Avi Kivity wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
<br>
<div>On 2018-04-08 20:32, Nicol Bolas wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
<br>
On Sunday, April 8, 2018 at 12:48:50 PM UTC-4, Avi Kivity wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">If I
have an array
<br>
<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 foo a[10000];
<br>
<br>
<br>
I can either let it be initialized with the default
constructor, or <br>
choose aggregate initialization and specify initializers for
each element.
<br>
<br>
<br>
Since the trend is not to require default constructors (or
move/copy <br>
assignment operators),</blockquote>
<div><br>
Wait, there's a trend towards that? I certainly don't see=
it
in the standard library. `variant` in particular practically
bends over backwards to allow default construction.<br>
</div>
</div>
</blockquote>
<br>
The trend is towards not requiring default constructors in user
types.<br></div></blockquote></span><div><br>Can you point to some evid=
ence for this trend? Because I don't see a great increase in the number=
of types without default constructors in C++. Indeed, the range concepts u=
se Semiregular <i>everywhere</i>, and Semiregular, requires DefaultConstruc=
tible.<br></div></div></blockquote><div><br></div><div>FWIW 1 data point he=
re.</div><div><br></div><div>In my code, types are only ever default-constr=
uctible if they are useful if constructed as such. If I'm deserialising=
non-default-constructible objects or storing them in arrays I use generato=
r functions. I don't tolerate redundant constructions. It's bad for=
m, invites inefficiency, and invites bugs.=C2=A0</div><div><br></div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>So I s=
ee plenty of evidence that DefaultConstructible remains a common expectatio=
n for user types.</div></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ea8f7a49-fb18-488c-99ca-2e1fdffccd64%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/ea8f=
7a49-fb18-488c-<wbr>99ca-2e1fdffccd64%40isocpp.org</a><wbr>.<br>
</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" 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/CALvx3hawja9ZC8rg7CL%2B66Eiw%2BxWG9AB=
siSoVXnC33qyWG965A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hawja9Z=
C8rg7CL%2B66Eiw%2BxWG9ABsiSoVXnC33qyWG965A%40mail.gmail.com</a>.<br />
--0000000000006822c905696c6969--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Mon, 9 Apr 2018 18:55:28 +0300
Raw View
This is a multi-part message in MIME format.
--------------ACBE6AC56F46A05A9F5A7F8C
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
On 2018-04-09 17:52, Nicol Bolas wrote:
> On Monday, April 9, 2018 at 9:53:19 AM UTC-4, Avi Kivity wrote:
>
>
>
> On 2018-04-09 16:45, Alberto Barbati wrote:
>>
>> Il giorno luned=C3=AC 9 aprile 2018 15:23:44 UTC+2, Avi Kivity ha
>> scritto:
>>
>>
>> Minor problems in a library implementation:
>> =C2=A0- I think it will be hard to make it constexpr, and such a
>> low-level facility should support constexpr
>>
>>
>>
>> I agree that having it constexpr would be useful. I'm not
>> convinced it would be hard to get, what makes you so sure?
>
> I'm not sure at all. I'm just not optimistic that all the
> union+placement new stuff would be constexpr.
>
>
> The whole point of making it a standard library function is that it=20
> doens't /have/ to be implemented with "all the union+placement new=20
> stuff". It works because the standard /says/ that it works. It will be=20
> `constexpr` by definition.
>
>
One of the nice things (IMO) about the standard C++ library is that much=20
of it is implementable with the language itself, without resorting to=20
compiler magic.
If the standard library requires a back-door compiler interface, we=20
might as well find good syntax for it and make it a language feature (as=20
was proposed earlier in the thread, by Daniel).
--=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/7f0d6522-ba34-773d-95de-4803f4d5bcbe%40scylladb.=
com.
--------------ACBE6AC56F46A05A9F5A7F8C
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
On 2018-04-09 17:52, Nicol Bolas wrote:<br>
<blockquote type=3D"cite"
cite=3D"mid:45edbfd0-4d33-4796-b86e-68b2a552dfb6@isocpp.org">
<div dir=3D"ltr">On Monday, April 9, 2018 at 9:53:19 AM UTC-4, Avi
Kivity wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
<br>
<div>On 2018-04-09 16:45, Alberto Barbati wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
Il giorno luned=C3=AC 9 aprile 2018 15:23:44 UTC+2, Avi
Kivity ha scritto:
<blockquote class=3D"gmail_quote"
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
Minor problems in a library implementation:<br>
=C2=A0- I think it will be hard to make it constexpr, a=
nd
such a low-level facility should support constexpr<br>
</div>
</blockquote>
<div><br>
<br>
I agree that having it constexpr would be useful. I'm
not convinced it would be hard to get, what makes you
so sure? <br>
</div>
</div>
</blockquote>
<br>
I'm not sure at all. I'm just not optimistic that all the
union+placement new stuff would be constexpr.<br>
</div>
</blockquote>
<div><br>
The whole point of making it a standard library function is
that it doens't <i>have</i> to be implemented with "all the
union+placement new stuff". It works because the standard <i>says=
</i>
that it works. It will be `constexpr` by definition.</div>
<br>
</div>
<br>
</blockquote>
<br>
One of the nice things (IMO) about the standard C++ library is that
much of it is implementable with the language itself, without
resorting to compiler magic.<br>
<br>
If the standard library requires a back-door compiler interface, we
might as well find good syntax for it and make it a language feature
(as was proposed earlier in the thread, by Daniel).<br>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7f0d6522-ba34-773d-95de-4803f4d5bcbe%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/7f0d6522-ba34-773d-95de-4803f4d5bc=
be%40scylladb.com</a>.<br />
--------------ACBE6AC56F46A05A9F5A7F8C--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Mon, 9 Apr 2018 18:56:45 +0300
Raw View
This is a multi-part message in MIME format.
--------------E8D4CE60C4402AE9C1751240
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
On 2018-04-09 18:53, Richard Hodges wrote:
>
>
> On 9 April 2018 at 16:00, Nicol Bolas <jmckesson@gmail.com=20
> <mailto:jmckesson@gmail.com>> wrote:
>
>
>
> On Monday, April 9, 2018 at 9:25:23 AM UTC-4, Avi Kivity wrote:
>
>
>
> On 2018-04-08 20:32, Nicol Bolas wrote:
>>
>>
>> On Sunday, April 8, 2018 at 12:48:50 PM UTC-4, Avi Kivity wrote:
>>
>> If I have an array
>>
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0 foo a[10000];
>>
>>
>> I can either let it be initialized with the default
>> constructor, or
>> choose aggregate initialization and specify initializers
>> for each element.
>>
>>
>> Since the trend is not to require default constructors
>> (or move/copy
>> assignment operators),
>>
>>
>> Wait, there's a trend towards that? I certainly don't see it
>> in the standard library. `variant` in particular practically
>> bends over backwards to allow default construction.
>
> The trend is towards not requiring default constructors in
> user types.
>
>
> Can you point to some evidence for this trend? Because I don't see
> a great increase in the number of types without default
> constructors in C++. Indeed, the range concepts use Semiregular
> /everywhere/, and Semiregular, requires DefaultConstructible.
>
>
> FWIW 1 data point here.
>
> In my code, types are only ever default-constructible if they are=20
> useful if constructed as such. If I'm deserialising=20
> non-default-constructible objects or storing them in arrays I use=20
> generator functions. I don't tolerate redundant constructions. It's=20
> bad form, invites inefficiency, and invites bugs.
>
Ditto here. If I'm forced to add a default constructor, I'm extremely=20
annoyed. Sometimes I refuse and use an std::optional instead.
--=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/7777b0fb-b8bd-d581-5dbd-2d6d6f3e4f1c%40scylladb.=
com.
--------------E8D4CE60C4402AE9C1751240
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
<br>
<div class=3D"moz-cite-prefix">On 2018-04-09 18:53, Richard Hodges
wrote:<br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:CALvx3hawja9ZC8rg7CL+66Eiw+xWG9ABsiSoVXnC33qyWG965A@mail.gmail.=
com">
<div dir=3D"ltr"><br>
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On 9 April 2018 at 16:00, Nicol Bolas
<span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com"
target=3D"_blank" moz-do-not-send=3D"true">jmckesson@gmail.=
com</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><span class=3D""><br>
<br>
On Monday, April 9, 2018 at 9:25:23 AM UTC-4, Avi
Kivity wrote:
<blockquote class=3D"gmail_quote"
style=3D"margin:0;margin-left:0.8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
<br>
<div>On 2018-04-08 20:32, Nicol Bolas wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
<br>
On Sunday, April 8, 2018 at 12:48:50 PM UTC-4,
Avi Kivity wrote:
<blockquote class=3D"gmail_quote"
style=3D"margin:0;margin-left:0.8ex;border-left=
:1px
#ccc solid;padding-left:1ex">If I have an
array <br>
<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 foo a[10000]; <br>
<br>
<br>
I can either let it be initialized with the
default constructor, or <br>
choose aggregate initialization and specify
initializers for each element. <br>
<br>
<br>
Since the trend is not to require default
constructors (or move/copy <br>
assignment operators),</blockquote>
<div><br>
Wait, there's a trend towards that? I
certainly don't see it in the standard
library. `variant` in particular practically
bends over backwards to allow default
construction.<br>
</div>
</div>
</blockquote>
<br>
The trend is towards not requiring default
constructors in user types.<br>
</div>
</blockquote>
</span>
<div><br>
Can you point to some evidence for this trend? Because
I don't see a great increase in the number of types
without default constructors in C++. Indeed, the range
concepts use Semiregular <i>everywhere</i>, and
Semiregular, requires DefaultConstructible.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>FWIW 1 data point here.</div>
<div><br>
</div>
<div>In my code, types are only ever default-constructible
if they are useful if constructed as such. If I'm
deserialising non-default-constructible objects or storing
them in arrays I use generator functions. I don't tolerate
redundant constructions. It's bad form, invites
inefficiency, and invites bugs.=C2=A0</div>
<br>
</div>
</div>
</div>
</blockquote>
<br>
Ditto here. If I'm forced to add a default constructor, I'm
extremely annoyed. Sometimes I refuse and use an std::optional
instead.<br>
<br>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/7777b0fb-b8bd-d581-5dbd-2d6d6f3e4f1c%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/7777b0fb-b8bd-d581-5dbd-2d6d6f3e4f=
1c%40scylladb.com</a>.<br />
--------------E8D4CE60C4402AE9C1751240--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 9 Apr 2018 09:37:31 -0700 (PDT)
Raw View
------=_Part_24236_475882144.1523291851414
Content-Type: multipart/alternative;
boundary="----=_Part_24237_956864988.1523291851415"
------=_Part_24237_956864988.1523291851415
Content-Type: text/plain; charset="UTF-8"
On Monday, April 9, 2018 at 11:56:49 AM UTC-4, Avi Kivity wrote:
>
> On 2018-04-09 18:53, Richard Hodges wrote:
>
>
>
> On 9 April 2018 at 16:00, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
>
>>
>>
>> On Monday, April 9, 2018 at 9:25:23 AM UTC-4, Avi Kivity wrote:
>>>
>>>
>>>
>>> On 2018-04-08 20:32, Nicol Bolas wrote:
>>>
>>>
>>>
>>> On Sunday, April 8, 2018 at 12:48:50 PM UTC-4, Avi Kivity wrote:
>>>>
>>>> If I have an array
>>>>
>>>>
>>>> foo a[10000];
>>>>
>>>>
>>>> I can either let it be initialized with the default constructor, or
>>>> choose aggregate initialization and specify initializers for each
>>>> element.
>>>>
>>>>
>>>> Since the trend is not to require default constructors (or move/copy
>>>> assignment operators),
>>>
>>>
>>> Wait, there's a trend towards that? I certainly don't see it in the
>>> standard library. `variant` in particular practically bends over backwards
>>> to allow default construction.
>>>
>>>
>>> The trend is towards not requiring default constructors in user types.
>>>
>>
>> Can you point to some evidence for this trend? Because I don't see a
>> great increase in the number of types without default constructors in C++.
>> Indeed, the range concepts use Semiregular *everywhere*, and
>> Semiregular, requires DefaultConstructible.
>>
>
> FWIW 1 data point here.
>
> In my code, types are only ever default-constructible if they are useful
> if constructed as such. If I'm deserialising non-default-constructible
> objects or storing them in arrays I use generator functions. I don't
> tolerate redundant constructions. It's bad form, invites inefficiency, and
> invites bugs.
>
>
> Ditto here. If I'm forced to add a default constructor, I'm extremely
> annoyed. Sometimes I refuse and use an std::optional instead.
>
>
That's all fine, but that doesn't change the fact that, as far as the
*standard* is concerned, default constructors are frequently expected to be
available, and this expectation is being encoded into increasingly large
parts of the standard library. This is the opposite of "the trend is not to
require default constructors". It may be a personal trend among some
programmers, but it is not a general C++ trend, and *certainly* not a trend
for the C++ standard library.
You cannot write an iterator that is not default constructible, for
example. Even though no sane implementation of an algorithm will bother to
use it, it must be there as part of the concept constraint.
I don't think the "avoid default construction/tors" is a good motivation
for the proposal. A better one is to avoid unnecessary work. We already
have the annoyance of having `vector` value-initialize types, thus
frequently provoking multiple initializations if you're just going to copy
into the array. Having ways to avoid potentially-expensive default
initialization that will quickly be overwritten by the actual data would be
a good thing.
--
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/5975ea7e-5c6c-47a7-a38f-95ce91cb0a76%40isocpp.org.
------=_Part_24237_956864988.1523291851415
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, April 9, 2018 at 11:56:49 AM UTC-4, Avi Kivity =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>On 2018-04-09 18:53, Richard Hodges
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
<div><br>
<div class=3D"gmail_quote">On 9 April 2018 at 16:00, Nicol Bolas
<span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank"=
gdf-obfuscated-mailto=3D"Al3SrHVUCAAJ" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D'javascript:';return true;" onclick=3D"this.href=3D'ja=
vascript:';return true;">jmck...@gmail.com</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><span><br>
<br>
On Monday, April 9, 2018 at 9:25:23 AM UTC-4, Avi
Kivity wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
<br>
<div>On 2018-04-08 20:32, Nicol Bolas wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
<br>
On Sunday, April 8, 2018 at 12:48:50 PM UTC-4,
Avi Kivity wrote:
<blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">If I have=
an
array <br>
<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 foo a[10000]; <br>
<br>
<br>
I can either let it be initialized with the
default constructor, or <br>
choose aggregate initialization and specify
initializers for each element. <br>
<br>
<br>
Since the trend is not to require default
constructors (or move/copy <br>
assignment operators),</blockquote>
<div><br>
Wait, there's a trend towards that? I
certainly don't see it in the standard
library. `variant` in particular practically
bends over backwards to allow default
construction.<br>
</div>
</div>
</blockquote>
<br>
The trend is towards not requiring default
constructors in user types.<br>
</div>
</blockquote>
</span>
<div><br>
Can you point to some evidence for this trend? Because
I don't see a great increase in the number of types
without default constructors in C++. Indeed, the range
concepts use Semiregular <i>everywhere</i>, and
Semiregular, requires DefaultConstructible.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>FWIW 1 data point here.</div>
<div><br>
</div>
<div>In my code, types are only ever default-constructible
if they are useful if constructed as such. If I'm
deserialising non-default-constructible objects or storing
them in arrays I use generator functions. I don't tolerat=
e
redundant constructions. It's bad form, invites
inefficiency, and invites bugs.=C2=A0</div>
<br>
</div>
</div>
</div>
</blockquote>
<br>
Ditto here. If I'm forced to add a default constructor, I'm
extremely annoyed. Sometimes I refuse and use an std::optional
instead.<br>
<br></div></blockquote><div><br>That's all fine, but that doesn'=
;t change the fact that, as far as the <i>standard</i> is concerned, defaul=
t constructors are frequently expected to be available, and this expectatio=
n is being encoded into increasingly large parts of the standard library. T=
his is the opposite of "<span>the trend is not to require default
constructors". It may be a personal trend =
among some programmers, but it is not a general C++ trend, and <i>certainly=
</i> not a trend for the C++ standard library.</span><br><br>You cannot wri=
te an iterator that is not default constructible, for example. Even though =
no sane implementation of an algorithm will bother to use it, it must be th=
ere as part of the concept constraint.<br><br>I don't think the "a=
void default construction/tors" is a good motivation for the proposal.=
A better one is to avoid unnecessary work. We already have the annoyance o=
f having `vector` value-initialize types, thus frequently provoking multipl=
e initializations if you're just going to copy into the array. Having w=
ays to avoid potentially-expensive default initialization that will quickly=
be overwritten by the actual data would be a good thing.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5975ea7e-5c6c-47a7-a38f-95ce91cb0a76%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5975ea7e-5c6c-47a7-a38f-95ce91cb0a76=
%40isocpp.org</a>.<br />
------=_Part_24237_956864988.1523291851415--
------=_Part_24236_475882144.1523291851414--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Mon, 9 Apr 2018 20:33:36 +0300
Raw View
This is a multi-part message in MIME format.
--------------FF51C99F16F35B14312731D9
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
On 2018-04-09 19:37, Nicol Bolas wrote:
> On Monday, April 9, 2018 at 11:56:49 AM UTC-4, Avi Kivity wrote:
>
> On 2018-04-09 18:53, Richard Hodges wrote:
>>
>>
>> On 9 April 2018 at 16:00, Nicol Bolas <jmck...@gmail.com
>> <javascript:>> wrote:
>>
>>
>>
>> On Monday, April 9, 2018 at 9:25:23 AM UTC-4, Avi Kivity wrote:
>>
>>
>>
>> On 2018-04-08 20:32, Nicol Bolas wrote:
>>>
>>>
>>> On Sunday, April 8, 2018 at 12:48:50 PM UTC-4, Avi
>>> Kivity wrote:
>>>
>>> If I have an array
>>>
>>>
>>> =C2=A0=C2=A0=C2=A0=C2=A0 foo a[10000];
>>>
>>>
>>> I can either let it be initialized with the default
>>> constructor, or
>>> choose aggregate initialization and specify
>>> initializers for each element.
>>>
>>>
>>> Since the trend is not to require default
>>> constructors (or move/copy
>>> assignment operators),
>>>
>>>
>>> Wait, there's a trend towards that? I certainly don't
>>> see it in the standard library. `variant` in particular
>>> practically bends over backwards to allow default
>>> construction.
>>
>> The trend is towards not requiring default constructors
>> in user types.
>>
>>
>> Can you point to some evidence for this trend? Because I
>> don't see a great increase in the number of types without
>> default constructors in C++. Indeed, the range concepts use
>> Semiregular /everywhere/, and Semiregular, requires
>> DefaultConstructible.
>>
>>
>> FWIW 1 data point here.
>>
>> In my code, types are only ever default-constructible if they are
>> useful if constructed as such. If I'm deserialising
>> non-default-constructible objects or storing them in arrays I use
>> generator functions. I don't tolerate redundant constructions.
>> It's bad form, invites inefficiency, and invites bugs.
>>
>
> Ditto here. If I'm forced to add a default constructor, I'm
> extremely annoyed. Sometimes I refuse and use an std::optional
> instead.
>
>
> That's all fine, but that doesn't change the fact that, as far as the=20
> /standard/ is concerned, default constructors are frequently expected=20
> to be available, and this expectation is being encoded into=20
> increasingly large parts of the standard library. This is the opposite=20
> of "the trend is not to require default constructors". It may be a=20
> personal trend among some programmers, but it is not a general C++=20
> trend, and /certainly/ not a trend for the C++ standard library.
>
I think it is. Can you name new library features that requires default=20
constructors of user-provided types unnecessarily?
Even iterators only require default-constructibility only for a subset=20
(Forward and above), not all.
> You cannot write an iterator that is not default constructible, for=20
> example. Even though no sane implementation of an algorithm will=20
> bother to use it, it must be there as part of the concept constraint.
>
> I don't think the "avoid default construction/tors" is a good=20
> motivation for the proposal. A better one is to avoid unnecessary work.
In some cases, default constructors don't make sense, in other cases=20
they are hard to provide. I think that avoiding the need to require them=20
is motivation on its own.
Avoiding unneeded work is distinct motivation.
> We already have the annoyance of having `vector` value-initialize=20
> types, thus frequently provoking multiple initializations if you're=20
> just going to copy into the array. Having ways to avoid=20
> potentially-expensive default initialization that will quickly be=20
> overwritten by the actual data would be a good thing.
>
vector doesn't require a default constructor from its value type and=20
won't provoke multiple initialization if used correctly. The proposal=20
brings something that is available in vector to C arrays (and std::array).
--=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/8a42296e-a752-9bb6-acd7-9db4672a31c7%40scylladb.=
com.
--------------FF51C99F16F35B14312731D9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
<br>
<div class=3D"moz-cite-prefix">On 2018-04-09 19:37, Nicol Bolas wrote:<=
br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:5975ea7e-5c6c-47a7-a38f-95ce91cb0a76@isocpp.org">
<div dir=3D"ltr">On Monday, April 9, 2018 at 11:56:49 AM UTC-4, Avi
Kivity wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>On 2018-04-09 18:53, Richard Hodges wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
<div><br>
<div class=3D"gmail_quote">On 9 April 2018 at 16:00,
Nicol Bolas <span dir=3D"ltr"><<a
href=3D"javascript:" target=3D"_blank"
gdf-obfuscated-mailto=3D"Al3SrHVUCAAJ"
rel=3D"nofollow"
onmousedown=3D"this.href=3D'javascript:';return
true;" onclick=3D"this.href=3D'javascript:';return
true;" moz-do-not-send=3D"true">jmck...@gmail.com</=
a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><span><br>
<br>
On Monday, April 9, 2018 at 9:25:23 AM UTC-4,
Avi Kivity wrote:
<blockquote class=3D"gmail_quote"
style=3D"margin:0;margin-left:0.8ex;border-left=
:1px
#ccc solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
<br>
<div>On 2018-04-08 20:32, Nicol Bolas
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
<br>
On Sunday, April 8, 2018 at 12:48:50
PM UTC-4, Avi Kivity wrote:
<blockquote class=3D"gmail_quote"
style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px
#ccc solid;padding-left:1ex">If I
have an array <br>
<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 foo a[10000]; =
<br>
<br>
<br>
I can either let it be initialized
with the default constructor, or <br>
choose aggregate initialization and
specify initializers for each
element. <br>
<br>
<br>
Since the trend is not to require
default constructors (or move/copy <br>
assignment operators),</blockquote>
<div><br>
Wait, there's a trend towards that?
I certainly don't see it in the
standard library. `variant` in
particular practically bends over
backwards to allow default
construction.<br>
</div>
</div>
</blockquote>
<br>
The trend is towards not requiring default
constructors in user types.<br>
</div>
</blockquote>
</span>
<div><br>
Can you point to some evidence for this trend?
Because I don't see a great increase in the
number of types without default constructors
in C++. Indeed, the range concepts use
Semiregular <i>everywhere</i>, and
Semiregular, requires DefaultConstructible.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>FWIW 1 data point here.</div>
<div><br>
</div>
<div>In my code, types are only ever
default-constructible if they are useful if
constructed as such. If I'm deserialising
non-default-constructible objects or storing them
in arrays I use generator functions. I don't
tolerate redundant constructions. It's bad form,
invites inefficiency, and invites bugs.=C2=A0</div>
<br>
</div>
</div>
</div>
</blockquote>
<br>
Ditto here. If I'm forced to add a default constructor, I'm
extremely annoyed. Sometimes I refuse and use an
std::optional instead.<br>
<br>
</div>
</blockquote>
<div><br>
That's all fine, but that doesn't change the fact that, as far
as the <i>standard</i> is concerned, default constructors are
frequently expected to be available, and this expectation is
being encoded into increasingly large parts of the standard
library. This is the opposite of "<span>the trend is not to
require default constructors". It may be a personal trend
among some programmers, but it is not a general C++ trend,
and <i>certainly</i> not a trend for the C++ standard
library.</span><br>
<br>
</div>
</div>
</blockquote>
<br>
I think it is. Can you name new library features that requires
default constructors of user-provided types unnecessarily?<br>
<br>
Even iterators only require default-constructibility only for a
subset (Forward and above), not all.<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:5975ea7e-5c6c-47a7-a38f-95ce91cb0a76@isocpp.org">
<div dir=3D"ltr">
<div>You cannot write an iterator that is not default
constructible, for example. Even though no sane implementation
of an algorithm will bother to use it, it must be there as
part of the concept constraint.<br>
<br>
I don't think the "avoid default construction/tors" is a good
motivation for the proposal. A better one is to avoid
unnecessary work. </div>
</div>
</blockquote>
<br>
In some cases, default constructors don't make sense, in other cases
they are hard to provide. I think that avoiding the need to require
them is motivation on its own.<br>
<br>
Avoiding unneeded work is distinct motivation.<br>
<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:5975ea7e-5c6c-47a7-a38f-95ce91cb0a76@isocpp.org">
<div dir=3D"ltr">
<div>We already have the annoyance of having `vector`
value-initialize types, thus frequently provoking multiple
initializations if you're just going to copy into the array.
Having ways to avoid potentially-expensive default
initialization that will quickly be overwritten by the actual
data would be a good thing.<br>
</div>
</div>
<br>
</blockquote>
<br>
vector doesn't require a default constructor from its value type and
won't provoke multiple initialization if used correctly. The
proposal brings something that is available in vector to C arrays
(and std::array).<br>
<br>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/8a42296e-a752-9bb6-acd7-9db4672a31c7%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/8a42296e-a752-9bb6-acd7-9db4672a31=
c7%40scylladb.com</a>.<br />
--------------FF51C99F16F35B14312731D9--
.