Topic: State of N2801: initializer lists and move semantics
Author: David Krauss <potswa@gmail.com>
Date: Tue, 30 Sep 2014 12:38:57 +0800
Raw View
--Apple-Mail=_FA8161F7-0572-4A84-9C22-589D87B8E71E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
Hello Rodrigo,
I'd like to make a similar proposal, but I can't find what happened to N280=
1, from 2008. Someone asked about it on comp.lang.c++.moderated back in 201=
0 but there was no reply.
The main differences in my proposal (yet to be drafted, but due in 10 days)=
are:
The new mutable list class is derived from std::initializer_list<T>, elimin=
ating the need for a member conversion function and special cases in overlo=
ading.
The new class is used whenever ownership is available, not according to a m=
etafunction.
Clarify rough edges in the specification of underlying array lifetime. The =
mutable list destructor destroys its sequence, which may happen in a callee=
.. Any other initializer list array is a global handled by [basic.start.init=
] =A73.6.2.
In support of the previous point and to reflect the common use case, it mig=
ht be called movable_initializer_list instead of mutable_initializer_list. =
And, it is movable but not copyable (although it does slice by copy, losing=
ownership).
Do not rely on Concepts.
Also, I'm curious about any concrete advantages of calling it mutable_initi=
alizer_list<T> over initializer_list<T&&>. My proposed interface is identic=
al aside from the member typedefs and return types of begin and end, and ha=
ving only one template-name might simplify the spec.
Thanks!
/cc std-proposals
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_FA8161F7-0572-4A84-9C22-589D87B8E71E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><div>Hello Rodrigo,</d=
iv><div><br></div>I’d like to make a similar proposal, but I can&rsqu=
o;t find what happened to <a href=3D"http://www.open-std.org/jtc1/sc22=
/wg21/docs/papers/2008/n2801.pdf">N2801</a>, from 2008. Someone asked about=
it on comp.lang.c++.moderated back in 2010 but there was no reply.<div><br=
></div><div>The main differences in my proposal (yet to be drafted, but due=
in 10 days) are:</div><div><ul class=3D"MailOutline"><li>The new muta=
ble list class is derived from <font face=3D"Courier">std::initializer=
_list<T></font>, eliminating the need for a member conversion functio=
n and special cases in overloading.</li><li>The new class is used whenever =
ownership is available, not according to a metafunction.</li><li>Clarify ro=
ugh edges in the specification of underlying array lifetime. The mutable li=
st destructor destroys its sequence, which may happen in a callee. Any othe=
r initializer list array is a global handled by [basic.start.init] =A73.6.2=
..</li><li>In support of the previous point and to reflect the common use ca=
se, it might be called <font face=3D"Courier">movable_initializer_list</fon=
t> instead of <font face=3D"Courier">mutable_initializer_list</font>. And, =
it is movable but not copyable (although it does slice by copy, losing owne=
rship).</li><li>Do not rely on Concepts.</li></ul></div><div><br></div><div=
>Also, I’m curious about any concrete advantages of calling it <=
font face=3D"Courier">mutable_initializer_list<T></font> over <font f=
ace=3D"Courier">initializer_list<T&&></font>. My proposed int=
erface is identical aside from the member typedefs and return types of <fon=
t face=3D"Courier">begin</font> and <font face=3D"Courier">end</font>, and =
having only one template-name might simplify the spec.</div><div><br></div>=
<div>Thanks!</div><div><br></div><div>/cc std-proposals</div><div><br></div=
></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_FA8161F7-0572-4A84-9C22-589D87B8E71E--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 30 Sep 2014 18:23:18 +0800
Raw View
--Apple-Mail=_77997821-024B-4ABA-B070-2870516C0336
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-30, at 12:38 PM, David Krauss <potswa@gmail.com> wrote:
> Hello Rodrigo,
>
> I'd like to make a similar proposal, but I can't find what happened to N2801, from 2008. Someone asked about it on comp.lang.c++.moderated back in 2010 but there was no reply.
>
> The main differences in my proposal (yet to be drafted, but due in 10 days) are:
> The new mutable list class is derived from std::initializer_list<T>, eliminating the need for a member conversion function and special cases in overloading.
Bah, the problem with deriving a move-only, sequence-owning class from initializer_list is that the user can access its copy assignment operator. I didn't realize they were assignable at all; it's not explicitly specified.
Is this supported by the standard or not? There's no mention in N2215, the last revision of the rationale, and it doesn't work very well.
{
std::initializer_list< foo > dst;
{
std::initializer_list< foo > src = { { {}, {}, {} };
dst = src;
}
// Now dst is dangling.
}
The misbehavior is nastier with my proposal:
{
std::initializer_list< foo && > src { {}, {}, {} }, dst;
dst.std::initializer_list< foo >::operator = ( src );
} // The sequence is deleted twice.
However, simply prohibiting the user from accessing the base operator= sounds reasonable. Getting there by slicing would require binding a non-const reference std::initializer_list<T> & , and nobody uses that... right?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--Apple-Mail=_77997821-024B-4ABA-B070-2870516C0336
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09–30, at 12:38 PM, David Krauss <<a href=3D"mailto:potswa@g=
mail.com">potswa@gmail.com</a>> wrote:</div><br class=3D"Apple-interchan=
ge-newline"><blockquote type=3D"cite"><meta http-equiv=3D"Content-Type" con=
tent=3D"text/html charset=3Dwindows-1252"><div style=3D"word-wrap: break-wo=
rd; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>=
Hello Rodrigo,</div><div><br></div>I’d like to make a similar proposa=
l, but I can’t find what happened to <a href=3D"http://www.open-=
std.org/jtc1/sc22/wg21/docs/papers/2008/n2801.pdf">N2801</a>, from 2008. So=
meone asked about it on comp.lang.c++.moderated back in 2010 but there was =
no reply.<div><br></div><div>The main differences in my proposal (yet to be=
drafted, but due in 10 days) are:</div><div><ul class=3D"MailOutline"><li>=
The new mutable list class is derived from <font face=3D"Courier"=
>std::initializer_list<T></font>, eliminating the need for a member c=
onversion function and special cases in overloading.</li></ul></div></div><=
/blockquote><div><br></div><div>Bah, the problem with deriving a move-only,=
sequence-owning class from <font face=3D"Courier">initializer_list</font> =
is that the user can access its copy assignment operator. I didn’t re=
alize they were assignable at all; it’s not explicitly specified.</di=
v><div><br></div><div>Is this supported by the standard or not? There&rsquo=
;s no mention in N2215, the last revision of the rationale, and it doesn&rs=
quo;t work very well.</div><div><br></div><div><font face=3D"Courier">{</fo=
nt></div><div><font face=3D"Courier"> std::initializer_list<=
; foo > dst;</font></div><div><span style=3D"font-family: Courier;">&nbs=
p; </span><span style=3D"font-family: Courier;"> </span><font fa=
ce=3D"Courier">{</font></div><div><span style=3D"font-family: Courier;">&nb=
sp; </span><span style=3D"font-family: Courier;"> </span><span s=
tyle=3D"font-family: Courier;"> </span><span style=3D"font-fami=
ly: Courier;"> </span><span style=3D"font-family: Courier;">std::initi=
alizer_list< foo > src =3D { { {}, {}, {} };</span></div><div><span s=
tyle=3D"font-family: Courier;"> </span><span style=3D"font-fami=
ly: Courier;"> </span><span style=3D"font-family: Courier;"> &nb=
sp;</span><span style=3D"font-family: Courier;"> </span><span style=3D=
"font-family: Courier;">dst =3D src;</span></div><div><span style=3D"font-f=
amily: Courier;"> </span><span style=3D"font-family: Courier;">=
</span><font face=3D"Courier">}</font></div><div><span style=3D"font-=
family: Courier;"> </span><span style=3D"font-family: Courier;"=
> </span><font face=3D"Courier">// Now dst is dangling.</font></div><d=
iv><font face=3D"Courier">}</font></div><div><br></div><div>The misbehavior=
is nastier with my proposal:</div><div><br></div><div><font face=3D"Courie=
r">{</font></div><div><font face=3D"Courier"> std::initia=
lizer_list< foo && > src { {}, {}, {} }, dst;</font></div><di=
v><font face=3D"Courier"><br></font></div><div><font face=3D"Courier"> =
; dst.std::initializer_list< foo >::operator =3D ( src );</fon=
t></div><div><font face=3D"Courier">} // The sequence is deleted twice.</fo=
nt></div><div><br></div><div>However, simply prohibiting the user from acce=
ssing the base <font face=3D"Courier">operator=3D</font> sounds reasonable.=
Getting there by slicing would require binding a non-const reference <font=
face=3D"Courier">std::initializer_list<T> &</font> , and nobody =
uses that… right?</div></div><br></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_77997821-024B-4ABA-B070-2870516C0336--
.
Author: Douglas Boffey <douglas.boffey@gmail.com>
Date: Tue, 30 Sep 2014 06:45:16 -0700 (PDT)
Raw View
------=_Part_469_527855324.1412084717137
Content-Type: text/plain; charset=UTF-8
On Tuesday, 30 September 2014 11:23:24 UTC+1, David Krauss wrote:
>
>
>
> {
> std::initializer_list< foo > dst;
> {
> std::initializer_list< foo > src = { { {}, {}, {} };
> dst = src;
> }
> // Now dst is dangling.
> }
>
> There seems to be an imbalance in the braces.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_469_527855324.1412084717137
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Tuesday, 30 September 2014 11:23:24 UTC+1, David Kr=
auss wrote:<blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1=
ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-l=
eft-style: solid;" class=3D"gmail_quote"><div style=3D"word-wrap: break-wor=
d;"><br><div><div><br></div><div><font face=3D"Courier">{</font></div><div>=
<font face=3D"Courier"> std::initializer_list< foo > dst=
;</font></div><div><span style=3D"font-family: Courier;"> </spa=
n><span style=3D"font-family: Courier;"> </span><font face=3D"Courier"=
>{</font></div><div><span style=3D"font-family: Courier;"> </sp=
an><span style=3D"font-family: Courier;"> </span><span style=3D"font-f=
amily: Courier;"> </span><span style=3D"font-family: Courier;">=
</span><span style=3D"font-family: Courier;">std::initializer_list<=
; foo > src =3D { { {}, {}, {} };</span></div><div><span style=3D"font-f=
amily: Courier;"> </span><span style=3D"font-family: Courier;">=
</span><span style=3D"font-family: Courier;"> </span><spa=
n style=3D"font-family: Courier;"> </span><span style=3D"font-family: =
Courier;">dst =3D src;</span></div><div><span style=3D"font-family: Courier=
;"> </span><span style=3D"font-family: Courier;"> </span><=
font face=3D"Courier">}</font></div><div><span style=3D"font-family: Courie=
r;"> </span><span style=3D"font-family: Courier;"> </span>=
<font face=3D"Courier">// Now dst is dangling.</font></div><div><font face=
=3D"Courier">}</font></div><div><br></div></div></div></blockquote><div>The=
re seems to be an imbalance in the braces. </div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_469_527855324.1412084717137--
.
Author: Rodrigo <rcc.dark@gmail.com>
Date: Tue, 30 Sep 2014 09:17:16 -0500
Raw View
--e89a8f83a13f8a61490504490b5b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi David.
I'm glad to see someone else found the current std::initializer_list design
lacking. My paper was considered by the commitee to be tackling a problem
that is worth solving, but it was already too late to be considered for
C+11 and was left to be open for resubmission in the future. I don't
remember the details of my proposal (and I would not like to check it,
since I'm sure I did many things wrong, I was just a 20 year old kid when I
proposed it) but right now I have the following observations:
* Right now I believe having a class with a different name will only make
things more complicated without enough benefit (the ideal programming
language must be "simple", so we must avoid making more mistakes even if
C++ is already complicated enough).
* I liked your idea about inheriting, but if the class doesn't have a
different name, then it would be (a bit) confusing to quickly determine for
non-experts which class in inheriting from which.
* Probably my new preference: given that literal types are already in the
language and supported via the std::is_literal_type trait, you could argue
that the current inmutable std::initializer_list is perfect for literal
types (for these types, "moving" is copying); std::initializer_list for
non-literal types then must provide a non-const interface.
* I understand you want to provide a mutable view of a
std::initializer_list via detecting ownership and not via a trait, but
literal types are already understood and I think an std::initializer_list
must not be used as a generic container, but only for initialization
purposes of another container. This is, the only problem that I think must
be solved is the current inability to move from an std::initializer_list
when it is obvious it would be faster than copying.
Cheers! I hope your proposal (in any of its forms) fixes the problem and is
accepted.
Rodrigo
2014-09-29 23:38 GMT-05:00 David Krauss <potswa@gmail.com>:
> Hello Rodrigo,
>
> I=E2=80=99d like to make a similar proposal, but I can=E2=80=99t find wha=
t happened to
> N2801 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2801.pdf>=
,
> from 2008. Someone asked about it on comp.lang.c++.moderated back in 2010
> but there was no reply.
>
> The main differences in my proposal (yet to be drafted, but due in 10
> days) are:
>
> - The new mutable list class is derived from std::initializer_list<T>,
> eliminating the need for a member conversion function and special case=
s in
> overloading.
> - The new class is used whenever ownership is available, not according
> to a metafunction.
> - Clarify rough edges in the specification of underlying array
> lifetime. The mutable list destructor destroys its sequence, which may
> happen in a callee. Any other initializer list array is a global handl=
ed by
> [basic.start.init] =C2=A73.6.2.
> - In support of the previous point and to reflect the common use case,
> it might be called movable_initializer_list instead of
> mutable_initializer_list. And, it is movable but not copyable
> (although it does slice by copy, losing ownership).
> - Do not rely on Concepts.
>
>
> Also, I=E2=80=99m curious about any concrete advantages of calling it
> mutable_initializer_list<T> over initializer_list<T&&>. My proposed
> interface is identical aside from the member typedefs and return types of
> begin and end, and having only one template-name might simplify the spec.
>
> Thanks!
>
> /cc std-proposals
>
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--e89a8f83a13f8a61490504490b5b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi David.<div><br></div><div>I'm glad to see someone e=
lse found the current std::initializer_list design lacking. My paper was co=
nsidered by the commitee to be tackling a problem that is worth solving, bu=
t it was already too late to be considered for C+11 and was left to be open=
for resubmission in the future. I don't remember the details of my pro=
posal (and I would not like to check it, since I'm sure I did many thin=
gs wrong, I was just a 20 year old kid when I proposed it) but right now I =
have the following observations:</div><div><br></div><div>* Right now I bel=
ieve having a class with a different name will only make things more compli=
cated without enough benefit (the ideal programming language must be "=
simple", so we must avoid making more mistakes even if C++ is already =
complicated enough).</div><div>* I liked your idea about inheriting, but if=
the class doesn't have a different name, then it would be (a bit) conf=
using to quickly determine for non-experts which class in inheriting from w=
hich.</div><div>* Probably my new preference: given that literal types are =
already in the language and supported via the std::is_literal_type trait, y=
ou could argue that the current inmutable std::initializer_list is perfect =
for literal types (for these types, "moving" is copying); std::in=
itializer_list for non-literal types then must provide a non-const interfac=
e.</div><div>* I understand you want to provide a mutable view of a std::in=
itializer_list via detecting ownership and not via a trait, but literal typ=
es are already understood and I think an std::initializer_list must not be =
used as a generic container, but only for initialization purposes of anothe=
r container. This is, the only problem that I think must be solved is the c=
urrent inability to move from an std::initializer_list when it is obvious i=
t would be faster than copying.</div><div><br></div><div>Cheers! I hope you=
r proposal (in any of its forms) fixes the problem and is accepted.</div><d=
iv><br></div><div>Rodrigo</div><div><br></div><div><br></div></div><div cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote">2014-09-29 23:38 GMT-05:0=
0 David Krauss <span dir=3D"ltr"><<a href=3D"mailto:potswa@gmail.com" ta=
rget=3D"_blank">potswa@gmail.com</a>></span>:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div style=3D"word-wrap:break-word"><div>Hello Rodrigo,</div><div><=
br></div>I=E2=80=99d like to make a similar proposal, but I can=E2=80=99t f=
ind what happened to=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg21=
/docs/papers/2008/n2801.pdf" target=3D"_blank">N2801</a>, from 2008. Someon=
e asked about it on comp.lang.c++.moderated back in 2010 but there was no r=
eply.<div><br></div><div>The main differences in my proposal (yet to be dra=
fted, but due in 10 days) are:</div><div><ul><li>The new=C2=A0mutable list=
=C2=A0class is derived from <font face=3D"Courier">std::initializer_list<=
;T></font>, eliminating the need for a member conversion function and sp=
ecial cases in overloading.</li><li>The new class is used whenever ownershi=
p is available, not according to a metafunction.</li><li>Clarify rough edge=
s in the specification of underlying array lifetime. The mutable list destr=
uctor destroys its sequence, which may happen in a callee. Any other initia=
lizer list array is a global handled by [basic.start.init] =C2=A73.6.2.</li=
><li>In support of the previous point and to reflect the common use case, i=
t might be called <font face=3D"Courier">movable_initializer_list</font> in=
stead of <font face=3D"Courier">mutable_initializer_list</font>. And, it is=
movable but not copyable (although it does slice by copy, losing ownership=
).</li><li>Do not rely on Concepts.</li></ul></div><div><br></div><div>Also=
, I=E2=80=99m curious about any concrete advantages of calling it=C2=A0<fon=
t face=3D"Courier">mutable_initializer_list<T></font> over <font face=
=3D"Courier">initializer_list<T&&></font>. My proposed interf=
ace is identical aside from the member typedefs and return types of <font f=
ace=3D"Courier">begin</font> and <font face=3D"Courier">end</font>, and hav=
ing only one template-name might simplify the spec.</div><div><br></div><di=
v>Thanks!</div><div><br></div><div>/cc std-proposals</div><div><br></div></=
div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--e89a8f83a13f8a61490504490b5b--
.
Author: Rodrigo <rcc.dark@gmail.com>
Date: Tue, 30 Sep 2014 09:30:14 -0500
Raw View
--001a11c2a1d4ec2ba6050449398a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
One more thing I forgot, I think deducing std::initializer_list when using
"auto" was a mistake (people try to use it as a tuple and then notice they
can't).
Maybe your ownsership detection proposal could help, but then you need to
teach programmers what ownership means in the context of
std::initializer_list which I still don't see as simple. Rather than trying
to fix that unfortunate mistake, I would simply leave it alone in favor
of a simple solution of the most important problem (moving inside sequence
constructors).
Cheers!
2014-09-29 23:38 GMT-05:00 David Krauss <potswa@gmail.com>:
> Hello Rodrigo,
>
> I=E2=80=99d like to make a similar proposal, but I can=E2=80=99t find wha=
t happened to
> N2801 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2801.pdf>=
,
> from 2008. Someone asked about it on comp.lang.c++.moderated back in 2010
> but there was no reply.
>
> The main differences in my proposal (yet to be drafted, but due in 10
> days) are:
>
> - The new mutable list class is derived from std::initializer_list<T>,
> eliminating the need for a member conversion function and special case=
s in
> overloading.
> - The new class is used whenever ownership is available, not according
> to a metafunction.
> - Clarify rough edges in the specification of underlying array
> lifetime. The mutable list destructor destroys its sequence, which may
> happen in a callee. Any other initializer list array is a global handl=
ed by
> [basic.start.init] =C2=A73.6.2.
> - In support of the previous point and to reflect the common use case,
> it might be called movable_initializer_list instead of
> mutable_initializer_list. And, it is movable but not copyable
> (although it does slice by copy, losing ownership).
> - Do not rely on Concepts.
>
>
> Also, I=E2=80=99m curious about any concrete advantages of calling it
> mutable_initializer_list<T> over initializer_list<T&&>. My proposed
> interface is identical aside from the member typedefs and return types of
> begin and end, and having only one template-name might simplify the spec.
>
> Thanks!
>
> /cc std-proposals
>
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c2a1d4ec2ba6050449398a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">One more thing I forgot, I think deducing std::initializer=
_list when using "auto" was a mistake (people try to use it as a =
tuple and then notice they can't).=C2=A0<div><br></div><div>Maybe your =
ownsership detection proposal could help, but then you need to teach progra=
mmers what ownership means in the context of std::initializer_list which I =
still don't see as simple. Rather than trying to fix that unfortunate m=
istake, I would simply leave it alone in favor of=C2=A0a simple solution of=
the most important problem (moving inside sequence constructors).</div><di=
v><br></div><div>Cheers!</div></div><div class=3D"gmail_extra"><br><div cla=
ss=3D"gmail_quote">2014-09-29 23:38 GMT-05:00 David Krauss <span dir=3D"ltr=
"><<a href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.co=
m</a>></span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap=
:break-word"><div>Hello Rodrigo,</div><div><br></div>I=E2=80=99d like to ma=
ke a similar proposal, but I can=E2=80=99t find what happened to=C2=A0<a hr=
ef=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2801.pdf" ta=
rget=3D"_blank">N2801</a>, from 2008. Someone asked about it on comp.lang.c=
++.moderated back in 2010 but there was no reply.<div><br></div><div>The ma=
in differences in my proposal (yet to be drafted, but due in 10 days) are:<=
/div><div><ul><li>The new=C2=A0mutable list=C2=A0class is derived from <fon=
t face=3D"Courier">std::initializer_list<T></font>, eliminating the n=
eed for a member conversion function and special cases in overloading.</li>=
<li>The new class is used whenever ownership is available, not according to=
a metafunction.</li><li>Clarify rough edges in the specification of underl=
ying array lifetime. The mutable list destructor destroys its sequence, whi=
ch may happen in a callee. Any other initializer list array is a global han=
dled by [basic.start.init] =C2=A73.6.2.</li><li>In support of the previous =
point and to reflect the common use case, it might be called <font face=3D"=
Courier">movable_initializer_list</font> instead of <font face=3D"Courier">=
mutable_initializer_list</font>. And, it is movable but not copyable (altho=
ugh it does slice by copy, losing ownership).</li><li>Do not rely on Concep=
ts.</li></ul></div><div><br></div><div>Also, I=E2=80=99m curious about any =
concrete advantages of calling it=C2=A0<font face=3D"Courier">mutable_initi=
alizer_list<T></font> over <font face=3D"Courier">initializer_list<=
;T&&></font>. My proposed interface is identical aside from the =
member typedefs and return types of <font face=3D"Courier">begin</font> and=
<font face=3D"Courier">end</font>, and having only one template-name might=
simplify the spec.</div><div><br></div><div>Thanks!</div><div><br></div><d=
iv>/cc std-proposals</div><div><br></div></div></blockquote></div><br></div=
>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c2a1d4ec2ba6050449398a--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 30 Sep 2014 17:31:52 +0300
Raw View
On 30 September 2014 17:30, Rodrigo <rcc.dark@gmail.com> wrote:
> One more thing I forgot, I think deducing std::initializer_list when using
> "auto" was a mistake (people try to use it as a tuple and then notice they
> can't).
See http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3912.html
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 1 Oct 2014 01:35:06 +0800
Raw View
On 2014-09-30, at 10:17 PM, Rodrigo <rcc.dark@gmail.com> wrote:
> since I'm sure I did many things wrong, I was just a 20 year old kid when=
I proposed it)
I guess that means I'm not a kid any more :( ;)
> but right now I have the following observations:
>=20
> * Right now I believe having a class with a different name will only make=
things more complicated without enough benefit (the ideal programming lang=
uage must be "simple", so we must avoid making more mistakes even if C++ is=
already complicated enough).
> * I liked your idea about inheriting, but if the class doesn't have a dif=
ferent name, then it would be (a bit) confusing to quickly determine for no=
n-experts which class in inheriting from which.
Hmm, my hope is that non-experts won't even care. The inheritance is mainly=
for the sake of implicit casts, and one simply has to remember that <T&&> =
(owning) initializes <T> (non-owning) but not the other way around.
> * Probably my new preference: given that literal types are already in the=
language and supported via the std::is_literal_type trait, you could argue=
that the current inmutable std::initializer_list is perfect for literal ty=
pes (for these types, "moving" is copying); std::initializer_list for non-l=
iteral types then must provide a non-const interface.
Literal type isn't exactly that; it doesn't imply that moving equates to co=
pying or even that copying is trivial. This is a bit odd, since making the =
trip from an initializer expression to static storage requires a non-const =
prvalue to become const without a copy elision. Anyway, an owned list (non-=
static sequence) of literal type should still be passed reflecting ownershi=
p semantics.
The effect is exacerbated as the breadth of constexpr evaluation widens. In=
the foreseeable future even std::string may be a literal type. There is so=
me resistance/backlash to even having std::is_literal_type in the library a=
t all, because it makes for brittle code.
> * I understand you want to provide a mutable view of a std::initializer_l=
ist via detecting ownership and not via a trait, but literal types are alre=
ady understood and I think an std::initializer_list must not be used as a g=
eneric container, but only for initialization purposes of another container=
.. This is, the only problem that I think must be solved is the current inab=
ility to move from an std::initializer_list when it is obvious it would be =
faster than copying.
Hmm, I need to be careful about how I present this aspect. I also strongly =
believe that it's not a container, and regret that they can be named or loc=
ally declared at all.
It's better, though, to free resources at the earliest possible opportunity=
, which is in the innermost function that does not pass ownership along to =
something else.
> Cheers! I hope your proposal (in any of its forms) fixes the problem and =
is accepted.
Thanks to you too, for fighting the good fight :)
- D
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.