Topic: Draft: movable initializer lists
Author: David Krauss <potswa@gmail.com>
Date: Wed, 1 Oct 2014 02:29:34 +0800
Raw View
--Apple-Mail=_703F6569-4FC5-4946-A57D-9334FCC8A006
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
Here is a proposal to fix std::initializer<std::unique_ptr<T>>.
Abstract:
---
Often std::initializer_list cannot be used, or it requires a const_cast hac=
k, because it provides read-only access to its sequence. This is a conseque=
nce of non-ownership of the sequence. A new initializer list class template=
is proposed to allow function parameters which may leverage (by overloadin=
g) or require strict ownership.
---
Link: http://bit.ly/1pEm5gQ
--=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=_703F6569-4FC5-4946-A57D-9334FCC8A006
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;">Here is a proposal to =
fix <font face=3D"Courier">std::initializer<std::unique_ptr<T>>=
</font>.<div><br></div><div>Abstract:</div><div>–––</div>=
<div>Often <font face=3D"Courier">std::initializer_list</font> ca=
nnot be used, or it requires a <font face=3D"Courier">const_cast</font=
> hack, because it provides read-only access to its sequence. Thi=
s is a consequence of non-ownership of the sequence. A new initializer list=
class template is proposed to allow function parameters which may lev=
erage (by overloading) or require strict ownership.<br>––&ndash=
;</div><div><br></div><div>Link: <a href=3D"http://bit.ly/1pEm5gQ">http://b=
it.ly/1pEm5gQ</a></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=_703F6569-4FC5-4946-A57D-9334FCC8A006--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 30 Sep 2014 21:34:32 +0300
Raw View
On 30 September 2014 21:29, David Krauss <potswa@gmail.com> wrote:
> Here is a proposal to fix std::initializer<std::unique_ptr<T>>.
>
> Abstract:
> =E2=80=93=E2=80=93=E2=80=93
> Often std::initializer_list cannot be used, or it requires a const_cast
> hack, because it provides read-only access to its sequence. This is a
> consequence of non-ownership of the sequence. A new initializer list clas=
s
> template is proposed to allow function parameters which may leverage (by
> overloading) or require strict ownership.
> =E2=80=93=E2=80=93=E2=80=93
I don't quite grasp the part "is a consequence of non-ownership of the
sequence".
The reason why initializer_list elements cannot be moved from is that
the immutability
of an initializer_list allows implementations to perform optimizations, lik=
e
hoisting initializer_lists containing compile-time values out of loops etc.
--=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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 1 Oct 2014 07:02:19 +0800
Raw View
On 2014-10-01, at 2:34 AM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> On 30 September 2014 21:29, David Krauss <potswa@gmail.com> wrote:
>> Here is a proposal to fix std::initializer<std::unique_ptr<T>>.
>>
>> Abstract:
>> ---
>> Often std::initializer_list cannot be used, or it requires a const_cast
>> hack, because it provides read-only access to its sequence. This is a
>> consequence of non-ownership of the sequence. A new initializer list class
>> template is proposed to allow function parameters which may leverage (by
>> overloading) or require strict ownership.
>> ---
>
>
> I don't quite grasp the part "is a consequence of non-ownership of the
> sequence".
> The reason why initializer_list elements cannot be moved from is that
> the immutability
> of an initializer_list allows implementations to perform optimizations, like
> hoisting initializer_lists containing compile-time values out of loops etc.
Right. How about, "This is a consequence of the sequence potentially being shared with other initializer_list objects, although often it is statically known not to be."
--
---
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: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 1 Oct 2014 02:36:47 +0300
Raw View
On 1 October 2014 02:02, David Krauss <potswa@gmail.com> wrote:
>> I don't quite grasp the part "is a consequence of non-ownership of the
>> sequence".
>> The reason why initializer_list elements cannot be moved from is that
>> the immutability
>> of an initializer_list allows implementations to perform optimizations, like
>> hoisting initializer_lists containing compile-time values out of loops etc.
> Right. How about, "This is a consequence of the sequence potentially being shared with other initializer_list objects, although often it is statically known not to be."
Uh.. I don't see it as a consequence of any sharing, either. It's a
consequence of
considering optimization opportunities created by immutability more
important than
support for move semantics.
--
---
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 07:44:11 +0800
Raw View
--Apple-Mail=_C699D510-4FAD-4662-99A2-C650D76CA44B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-10-01, at 7:36 AM, Ville Voutilainen <ville.voutilainen@gmail.com> =
wrote:
> Uh.. I don't see it as a consequence of any sharing, either. It's a
> consequence of
> considering optimization opportunities created by immutability more
> important than
> support for move semantics.
At the technical level, support for alias-style sharing is what generates t=
he immutability requirement.
I'm not deprecating any optimization opportunities, so that doesn't really =
play into it. Also, reading the history, I don't see evidence of such a rel=
ative judgment about movability vs. ROMability being made. Do you recall su=
ch a discussion happening at the time? The potential popularity and commona=
lity of move semantics was somewhat an unknown when initializer_list was de=
signed, as mentioned in the "background" section.
There might be a misunderstanding; have you read the rest of the proposal?
--=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=_C699D510-4FAD-4662-99A2-C650D76CA44B
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;10–01, at 7:36 AM, Ville Voutilainen <<a href=3D"mailto:vill=
e.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>> wrote:</div><b=
r class=3D"Apple-interchange-newline"><blockquote type=3D"cite">Uh.. I don'=
t see it as a consequence of any sharing, either. It's a<br>consequence of<=
br>considering optimization opportunities created by immutability more<br>i=
mportant than<br>support for move semantics.<br></blockquote></div><br><div=
>At the technical level, support for alias-style sharing is what generates =
the immutability requirement.</div><div><br></div><div>I’m not deprec=
ating any optimization opportunities, so that doesn’t really play int=
o it. Also, reading the history, I don’t see evidence of such a relat=
ive judgment about movability vs. ROMability being made. Do you recall such=
a discussion happening at the time? The potential popularity and commonali=
ty of move semantics was somewhat an unknown when <font face=3D"Courier">in=
itializer_list</font> was designed, as mentioned in the “background&r=
dquo; section.</div><div><br></div><div>There might be a misunderstanding; =
have you read the rest of the proposal?</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=_C699D510-4FAD-4662-99A2-C650D76CA44B--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 1 Oct 2014 03:07:05 +0300
Raw View
On 1 October 2014 02:44, David Krauss <potswa@gmail.com> wrote:
> Uh.. I don't see it as a consequence of any sharing, either. It's a
> consequence of
> considering optimization opportunities created by immutability more
> important than
> support for move semantics.
>
> At the technical level, support for alias-style sharing is what generates
> the immutability requirement.
>
> I=E2=80=99m not deprecating any optimization opportunities, so that doesn=
=E2=80=99t really
> play into it. Also, reading the history, I don=E2=80=99t see evidence of =
such a
I didn't mean to suggest you are. I was merely trying to clarify the reason
why initializer_lists are not movable.
> relative judgment about movability vs. ROMability being made. Do you reca=
ll
> such a discussion happening at the time? The potential popularity and
It happened before I joined the committee, but multiple people have cited
immutability as important. And it's not just ROMability - you can hoist eve=
n
run-time initializer_lists out of loops when you know that they won't chang=
e.
I don't know whether existing implementations take advantage of these
optimization opportunities.
> commonality of move semantics was somewhat an unknown when initializer_li=
st
> was designed, as mentioned in the =E2=80=9Cbackground=E2=80=9D section.
I have heard people say that even when move semantics became well enough
understood to consider supporting them in initializer_lists, the immutabili=
ty
was still considered more important.
> There might be a misunderstanding; have you read the rest of the proposal=
?
Thus far rather superficially, I'm afraid.
--=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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 1 Oct 2014 08:11:53 +0800
Raw View
On 2014-10-01, at 8:07 AM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> I didn't mean to suggest you are. I was merely trying to clarify the reason
> why initializer_lists are not movable.
Okay, I changed "because it provides..." to "as it provides..." to change the emphasis. Quite a minor change but I don't want any readers to feel disagreement with the abstract!
>> There might be a misunderstanding; have you read the rest of the proposal?
>
> Thus far rather superficially, I'm afraid.
Alright. When you've finished, if your impression is positive, please let me know whether a standardese section would help the cause.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 1 Oct 2014 03:23:11 +0300
Raw View
On 1 October 2014 03:11, David Krauss <potswa@gmail.com> wrote:
>>> There might be a misunderstanding; have you read the rest of the proposal?
>> Thus far rather superficially, I'm afraid.
> Alright. When you've finished, if your impression is positive, please let me know whether a standardese section would help the cause.
Having read it more, some thoughts:
1) I think it's a bit early to strive for standardese. That effort may
be wasted if for whatever
reason the mere idea gets rejected. I believe there are design
considerations to discuss
first, such as
2) Do you envision that braced-initializers can turn into movable
initializer_lists? If so,
under what circumstances, what are the design rules?
3) I guess making eg. vector be able to use a movable
initializer_list, it needs new constructor
overloads, in order to be able to move from eg.
initializer_list<unique_ptr<foo>&&>?
In other words, I recommend writing some guesstimates what the impact
on the standard library
would be, and how initializer_list<T&&> ties into braced-initializers,
if at all. And I think it's
always worth the while to show the example that always puzzles
non-experts, which looks
somewhat like
vector<unique_ptr<foo>> vupf{make_unique<foo>(what), make_unique<foo>(ever)};
--
---
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 08:33:36 +0800
Raw View
--Apple-Mail=_13345CBE-0D00-4A9D-A7C6-83DACDA76B79
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-10-01, at 8:23 AM, Ville Voutilainen <ville.voutilainen@gmail.com> =
wrote:
> 2) Do you envision that braced-initializers can turn into movable
> initializer_lists? If so,
> under what circumstances, what are the design rules?
Yes. There's no other way to get a (non-empty) initializer_list<T&&>.
It's partially there, in this paragraph:
> When the implementation generates a temporary initializer list object to =
represent an initializer list ([dcl.init.list] =A78.5.4), that object is a =
specialization of initializer_list<T&&> if the implementation gives the und=
erlying array an equivalent lifetime, and if the object has static storage =
duration, if the underlying array is not const. When this object is used as=
an initializer, in overload resolution it will match a parameter of type i=
nitializer_list<T&&> in preference to one of type initializer_list<T>, due =
to the derived-to-base conversion.
>=20
The intent is that a temporary initializer_list<T&&> object is created to t=
he exclusion of any initializer_list<T> object, and then it is the argument=
in overload resolution. However, I neglected to specify that this replaces=
the current means of overload resolution, where the braced-init-list initi=
alizes the parameter initializer_list<T> object during the process of findi=
ng viable functions.
> 3) I guess making eg. vector be able to use a movable
> initializer_list, it needs new constructor
> overloads, in order to be able to move from eg.
> initializer_list<unique_ptr<foo>&&>?
Yes. That needs to be added to "future work."
> In other words, I recommend writing some guesstimates what the impact
> on the standard library
> would be, and how initializer_list<T&&> ties into braced-initializers,
> if at all. And I think it's
> always worth the while to show the example that always puzzles
> non-experts, which looks
> somewhat like
>=20
> vector<unique_ptr<foo>> vupf{make_unique<foo>(what), make_unique<foo>(eve=
r)};
Yeah... gimmicks...
Thanks!
--=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=_13345CBE-0D00-4A9D-A7C6-83DACDA76B79
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;10–01, at 8:23 AM, Ville Voutilainen <<a href=3D"mailto:vill=
e.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>> wrote:</div><b=
r class=3D"Apple-interchange-newline"><blockquote type=3D"cite">2) Do you e=
nvision that braced-initializers can turn into movable<br>initializer_lists=
? If so,<br>under what circumstances, what are the design rules?<br></block=
quote><div><br></div><div>Yes. There’s no other way to get a (non-emp=
ty) <font face=3D"Courier">initializer_list<T&&></font>.</div=
><div><br></div><div>It’s partially there, in this paragraph:</div><d=
iv><br></div><div><p style=3D"margin: 0px 0px 6px; font-family: Times;"></p=
><blockquote type=3D"cite"><p style=3D"margin: 0px 0px 6px; font-family: Ti=
mes;"><span style=3D"letter-spacing: 0.0px">When the implementation generat=
es a temporary initializer list object to represent an initializer list ([d=
cl.init.list] =A78.5.4), that object is a specialization of </span><span st=
yle=3D"font-family: Courier; letter-spacing: 0px;">initializer_list<T&am=
p;&></span><span style=3D"letter-spacing: 0.0px"> if the implementat=
ion gives the underlying array an equivalent lifetime, and if the object ha=
s static storage duration, if the underlying array is not </span><span styl=
e=3D"font-family: Courier; letter-spacing: 0px;">const</span><span style=3D=
"letter-spacing: 0.0px">. When this object is used as an initializer, in ov=
erload resolution it will match a parameter of type </span><span style=3D"f=
ont-family: Courier; letter-spacing: 0px;">initializer_list<T&&&=
gt;</span><span style=3D"letter-spacing: 0.0px"> in preference to one of ty=
pe </span><span style=3D"font-family: Courier; letter-spacing: 0px;">initia=
lizer_list<T></span><span style=3D"letter-spacing: 0.0px">, due to th=
e derived-to-base conversion.</span></p></blockquote><div><span style=3D"le=
tter-spacing: 0.0px"><br></span></div><div><span style=3D"letter-spacing: 0=
..0px">The intent is that a temporary <font face=3D"Courier">initialize=
r_list<T&&></font> object is created to the exclusion of any =
<font face=3D"Courier">initializer_list<T></font> object, and then it=
is the argument in overload resolution. However, I neglected to specify th=
at this replaces the current means of overload resolution, where the braced=
-init-list initializes the parameter </span><span style=3D"font-family=
: Courier; letter-spacing: 0px;">initializer_list<T></span><span styl=
e=3D"letter-spacing: 0px;"> object during the </span>process<span=
style=3D"letter-spacing: 0px;"> of finding viable functions.</span></=
div></div><br><blockquote type=3D"cite">3) I guess making eg. vector be abl=
e to use a movable<br>initializer_list, it needs new constructor<br>overloa=
ds, in order to be able to move from eg.<br>initializer_list<unique_ptr&=
lt;foo>&&>?<br></blockquote><div><br></div><div>Yes. That nee=
ds to be added to “future work.”</div><br><blockquote type=3D"c=
ite">In other words, I recommend writing some guesstimates what the impact<=
br>on the standard library<br>would be, and how initializer_list<T&&=
amp;> ties into braced-initializers,<br>if at all. And I think it's<br>a=
lways worth the while to show the example that always puzzles<br>non-expert=
s, which looks<br>somewhat like<br><br>vector<unique_ptr<foo>> =
vupf{make_unique<foo>(what), make_unique<foo>(ever)};<br></bloc=
kquote><div><br></div></div>Yeah… gimmicks…<div><br></div><di=
v>Thanks!</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=_13345CBE-0D00-4A9D-A7C6-83DACDA76B79--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 1 Oct 2014 11:57:21 +0800
Raw View
--Apple-Mail=_2CE25766-5887-4BB1-8CFE-900B10B981F3
Content-Type: text/plain; charset=ISO-8859-1
On 2014-10-01, at 8:23 AM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> In other words, I recommend writing some guesstimates what the impact
> on the standard library
> would be, and how initializer_list<T&&> ties into braced-initializers,
> if at all. And I think it's
> always worth the while to show the example that always puzzles
> non-experts, which looks
> somewhat like
>
> vector<unique_ptr<foo>> vupf{make_unique<foo>(what), make_unique<foo>(ever)};
I've posted a major update which should satisfy all the concerns so far, so long as the prose is clear enough.
(Same) link: http://bit.ly/1pEm5gQ
Thanks for bearing with me, the initial post was a bit premature. It seemed fairly complete at the end of the bleary-eyed bedtime writing session.
--
---
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=_2CE25766-5887-4BB1-8CFE-900B10B981F3
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;10–01, at 8:23 AM, Ville Voutilainen <<a href=3D"mailto:vill=
e.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>> wrote:</div><b=
r class=3D"Apple-interchange-newline"><blockquote type=3D"cite">In other wo=
rds, I recommend writing some guesstimates what the impact<br>on the standa=
rd library<br>would be, and how initializer_list<T&&> ties in=
to braced-initializers,<br>if at all. And I think it's<br>always worth the =
while to show the example that always puzzles<br>non-experts, which looks<b=
r>somewhat like<br><br>vector<unique_ptr<foo>> vupf{make_unique=
<foo>(what), make_unique<foo>(ever)};<br></blockquote></div><br=
><div>I’ve posted a major update which should satisfy all the concern=
s so far, so long as the prose is clear enough.</div><div><br></div><div>(S=
ame) link: <a href=3D"http://bit.ly/1pEm5gQ">http://bit.ly/1pEm5gQ</a>=
</div><div><br></div><div>Thanks for bearing with me, the initial post was =
a bit premature. It seemed fairly complete at the end of the bleary-eyed be=
dtime writing session.</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=_2CE25766-5887-4BB1-8CFE-900B10B981F3--
.