2013/8/14  <tomaszkam@gmail.com>:
> The std::initializer_list<T> is defined as a non-owning handle to a const
> array of the T elements placed probably on stack, with requires from
>  containers constructor to copy the elements into container. This lead for
> usability problem, especially in generic programming.
>
> The most common example of usage of std::initializer_list is to write:
>   std::vector<int> v{1,2,3,4};
> instead of:
>   std::vector<int> v; v.reserve(4);
>   v.emplace_back(1);
>   v.emplace_back(2);
>   v.emplace_back(3);
>   v.emplace_back(4);
> There is not difference between this two codes, because the copy and move
> constructor of int does not differ.
>
> The problem start to begin when we start to use the non-movable types (ex.
> locks). The following code:
>   std::vector<std::unique_ptr<int>> v{ make_unique<int>(),
> make_unique<int>() };
> Does not work because the copy constructor is required to copy elements from
> initializer_list and such
> constructor does not exist for unique_ptr. So not all types of vector can be
> uniformly initialized.

This is a well-known characteristics of std:initializer_list and has
been discussed when considering the (late) proposals

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2719.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2801.pdf

IMO it is natural for an handle to immutable data not to allow invalid
mutating operations that would be required to be used for the
referenced values.

> Furthermore the use of the initializer list incur unnecessary performance
> penalty, please consider:
> std::vector<std::string> v{ "ala", "ola", "ula" };
> This initialization requires construction of the 6 string objects - 3 for
> initializer_list and 3 for copies in vector.

If this difference is relevant I recommend to stay away here from
std::initializer_list or to invent a new mutable initializer_list (see
proposals mentioned above).

> This 2 problems makes the usage of uniform intialization of container
> questionalable especially in generic code.

I agree, I would not suggest to use them in deeply generic code that
should impose as little constraints as possible on the value types of
the container.

> The problem itself make be solved by changing the initializer_list to be
> owning, non-copyable, non-movable handle for the
> array. The the vector, should have 2 constructors:
>   1. vector(std::initializer_list<T> cons& list)
>   2. vector(std::initializer_list<T> && list)

This wouldn't change anything, because it would still be invalid to
modify the referenced data via the second overload. Core issue

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1418

clarified that the underlying data of the std::initializer_list indeed
has to be considered as constant values and any modification of that
would be undefined behaviour.

> Probably it is to late to make such a change, and the initializer_list will
> not take move into account.

It clearly is too late and I recommend to work on updated proposals
similar to the direction of n2801 mentioned above.

- Daniel

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



.

--047d7b6d7ada0543e804e3e6fd48
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 14 August 2013 14:40, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wrote=
:

> 2013/8/14  <tomaszkam@gmail.com>:
> > The std::initializer_list<T> is defined as a non-owning handle to a con=
st
> > array of the T elements placed probably on stack, with requires from
> >  containers constructor to copy the elements into container. This lead
> for
> > usability problem, especially in generic programming.
> >
> > The most common example of usage of std::initializer_list is to write:
> >   std::vector<int> v{1,2,3,4};
> > instead of:
> >   std::vector<int> v; v.reserve(4);
> >   v.emplace_back(1);
> >   v.emplace_back(2);
> >   v.emplace_back(3);
> >   v.emplace_back(4);
> > There is not difference between this two codes, because the copy and mo=
ve
> > constructor of int does not differ.
> >
> > The problem start to begin when we start to use the non-movable types
> (ex.
> > locks). The following code:
> >   std::vector<std::unique_ptr<int>> v{ make_unique<int>(),
> > make_unique<int>() };
> > Does not work because the copy constructor is required to copy elements
> from
> > initializer_list and such
> > constructor does not exist for unique_ptr. So not all types of vector
> can be
> > uniformly initialized.
>
> This is a well-known characteristics of std:initializer_list and has
> been discussed when considering the (late) proposals
>

I wouldn't personally call it well-known, because it manages to surprise
programmers when they
run into it, experts and novices alike, myself somewhere in that spectrum
included.


> > Probably it is to late to make such a change, and the initializer_list
> will
> > not take move into account.
>
> It clearly is too late and I recommend to work on updated proposals
> similar to the direction of n2801 mentioned above.
>
>
>
I find it quite unfortunate if there's nothing that can be done for
braced-initializers that
have move-only types in them, unique_ptr being a very good example,
stringstreams being
another.

--=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/.



--047d7b6d7ada0543e804e3e6fd48
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 14 August 2013 14:40, Daniel Kr=FCgler <span dir=3D"ltr">&lt;<a =
href=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blank">daniel.kruegler=
@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">2013/8/14 =A0&lt;<a href=3D"mailto:tomaszkam=
@gmail.com">tomaszkam@gmail.com</a>&gt;:<br>
<div class=3D"im">&gt; The std::initializer_list&lt;T&gt; is defined as a n=
on-owning handle to a const<br>
&gt; array of the T elements placed probably on stack, with requires from<b=
r>
&gt; =A0containers constructor to copy the elements into container. This le=
ad for<br>
&gt; usability problem, especially in generic programming.<br>
&gt;<br>
&gt; The most common example of usage of std::initializer_list is to write:=
<br>
&gt; =A0 std::vector&lt;int&gt; v{1,2,3,4};<br>
&gt; instead of:<br>
&gt; =A0 std::vector&lt;int&gt; v; v.reserve(4);<br>
&gt; =A0 v.emplace_back(1);<br>
&gt; =A0 v.emplace_back(2);<br>
&gt; =A0 v.emplace_back(3);<br>
&gt; =A0 v.emplace_back(4);<br>
&gt; There is not difference between this two codes, because the copy and m=
ove<br>
&gt; constructor of int does not differ.<br>
&gt;<br>
&gt; The problem start to begin when we start to use the non-movable types =
(ex.<br>
&gt; locks). The following code:<br>
&gt; =A0 std::vector&lt;std::unique_ptr&lt;int&gt;&gt; v{ make_unique&lt;in=
t&gt;(),<br>
&gt; make_unique&lt;int&gt;() };<br>
&gt; Does not work because the copy constructor is required to copy element=
s from<br>
&gt; initializer_list and such<br>
&gt; constructor does not exist for unique_ptr. So not all types of vector =
can be<br>
&gt; uniformly initialized.<br>
<br>
</div>This is a well-known characteristics of std:initializer_list and has<=
br>
been discussed when considering the (late) proposals<br></blockquote><div><=
br></div><div>I wouldn&#39;t personally call it well-known, because it mana=
ges to surprise programmers when they<br>run into it, experts and novices a=
like, myself somewhere in that spectrum included. <br>
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div class=3D"im">
&gt; Probably it is to late to make such a change, and the initializer_list=
 will<br>
&gt; not take move into account.<br>
<br>
</div>It clearly is too late and I recommend to work on updated proposals<b=
r>
similar to the direction of n2801 mentioned above.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br><br></font></span></bloc=
kquote><div><br></div><div>I find it quite unfortunate if there&#39;s nothi=
ng that can be done for braced-initializers that<br></div><div>have move-on=
ly types in them, unique_ptr being a very good example, stringstreams being=
<br>
another. <br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

--047d7b6d7ada0543e804e3e6fd48--

.

2013/8/14 Ville Voutilainen <ville.voutilainen@gmail.com>:
>> This is a well-known characteristics of std:initializer_list and has
>> been discussed when considering the (late) proposals
>
> I wouldn't personally call it well-known, because it manages to surprise
> programmers when they
> run into it, experts and novices alike, myself somewhere in that spectrum
> included.
> I find it quite unfortunate if there's nothing that can be done for
> braced-initializers that
> have move-only types in them, unique_ptr being a very good example,
> stringstreams being
> another.

It is certainly possible to host std::initializer_type<MoveOnly>. The
only (IMO natural) constraint is that you cannot modify the underlying
data. Is this really such a surprise?

#include <initializer_list>

struct MoveOnly
{
  int value;
  MoveOnly(int value) : value(value) {}
  MoveOnly(MoveOnly&&) = default;
  MoveOnly& operator=(MoveOnly&&) = default;
};

std::initializer_list<MoveOnly> mos{MoveOnly(1), MoveOnly(2)};

The request by the OP sounds to me that it seems unfortunate that
immutable data cannot be mutated. What is so special for
std::initializer_list to change this fundamental concept?

I'm not opposed to invent a new mutable initializer_list, but that
looks like a feature to me. From begin with the model of
std::initializer_list was intended to support constant data.

- Daniel

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--089e013cbae833f6bd04e3e75817
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 14 August 2013 15:10, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wrote=
:

> 2013/8/14 Ville Voutilainen <ville.voutilainen@gmail.com>:
> >> This is a well-known characteristics of std:initializer_list and has
> >> been discussed when considering the (late) proposals
> >
> > I wouldn't personally call it well-known, because it manages to surpris=
e
> > programmers when they
> > run into it, experts and novices alike, myself somewhere in that spectr=
um
> > included.
> > I find it quite unfortunate if there's nothing that can be done for
> > braced-initializers that
> > have move-only types in them, unique_ptr being a very good example,
> > stringstreams being
> > another.
>
> It is certainly possible to host std::initializer_type<MoveOnly>. The
> only (IMO natural) constraint is that you cannot modify the underlying
> data. Is this really such a surprise?
>
> #include <initializer_list>
>
> struct MoveOnly
> {
>   int value;
>   MoveOnly(int value) : value(value) {}
>   MoveOnly(MoveOnly&&) =3D default;
>   MoveOnly& operator=3D(MoveOnly&&) =3D default;
> };
>
> std::initializer_list<MoveOnly> mos{MoveOnly(1), MoveOnly(2)};
>
> The request by the OP sounds to me that it seems unfortunate that
> immutable data cannot be mutated. What is so special for
> std::initializer_list to change this fundamental concept?
>
> I'm not opposed to invent a new mutable initializer_list, but that
> looks like a feature to me. From begin with the model of
> std::initializer_list was intended to support constant data.
>
>
>
It's not unfortunate that immutable data can't be mutated. What's
unfortunate is that
one easily gets the impression that vector<int>{foo(), bar(), baz()} is
supposed to allow
putting the contents of the vector right-into-it, to avoid having to write
vector<int> vec;
vec.push_back(foo());
vec.push_back(bar());
vec.push_back(baz());
but with move-only types we again have to fall back to that verbosity. If I
reach further
into the issue, we can't initialize vectors and its ilk with move-only
types. Since Resource
Acquisition Is Initialization, I find it potentially very unfortunate.

I think a solution like mutable_initializer_list is certainly a feature.
Not being able to
initialize standard containers with move-only types certainly looks like a
bug.

--=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/.



--089e013cbae833f6bd04e3e75817
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 14 August 2013 15:10, Daniel Kr=FCgler <span dir=3D"ltr">&lt;<a =
href=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blank">daniel.kruegler=
@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">2013/8/14 Ville Voutilain=
en &lt;<a href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen@gma=
il.com</a>&gt;:<br>

<div class=3D"im">&gt;&gt; This is a well-known characteristics of std:init=
ializer_list and has<br>
&gt;&gt; been discussed when considering the (late) proposals<br>
&gt;<br>
&gt; I wouldn&#39;t personally call it well-known, because it manages to su=
rprise<br>
&gt; programmers when they<br>
&gt; run into it, experts and novices alike, myself somewhere in that spect=
rum<br>
&gt; included.<br>
</div><div class=3D"im">&gt; I find it quite unfortunate if there&#39;s not=
hing that can be done for<br>
&gt; braced-initializers that<br>
&gt; have move-only types in them, unique_ptr being a very good example,<br=
>
&gt; stringstreams being<br>
&gt; another.<br>
<br>
</div>It is certainly possible to host std::initializer_type&lt;MoveOnly&gt=
;. The<br>
only (IMO natural) constraint is that you cannot modify the underlying<br>
data. Is this really such a surprise?<br>
<br>
#include &lt;initializer_list&gt;<br>
<br>
struct MoveOnly<br>
{<br>
=A0 int value;<br>
=A0 MoveOnly(int value) : value(value) {}<br>
=A0 MoveOnly(MoveOnly&amp;&amp;) =3D default;<br>
=A0 MoveOnly&amp; operator=3D(MoveOnly&amp;&amp;) =3D default;<br>
};<br>
<br>
std::initializer_list&lt;MoveOnly&gt; mos{MoveOnly(1), MoveOnly(2)};<br>
<br>
The request by the OP sounds to me that it seems unfortunate that<br>
immutable data cannot be mutated. What is so special for<br>
std::initializer_list to change this fundamental concept?<br>
<br>
I&#39;m not opposed to invent a new mutable initializer_list, but that<br>
looks like a feature to me. From begin with the model of<br>
std::initializer_list was intended to support constant data.<br>
<div class=3D""><div class=3D"h5"><br><br></div></div></blockquote><div><br=
></div><div>It&#39;s not unfortunate that immutable data can&#39;t be mutat=
ed. What&#39;s unfortunate is that<br></div><div>one easily gets the impres=
sion that vector&lt;int&gt;{foo(), bar(), baz()} is supposed to allow<br>
</div><div>putting the contents of the vector right-into-it, to avoid havin=
g to write<br></div>vector&lt;int&gt; vec;<br>vec.push_back(foo());<br>vec.=
push_back(bar());<br>vec.push_back(baz());<br></div><div class=3D"gmail_quo=
te">
but with move-only types we again have to fall back to that verbosity. If I=
 reach further<br>into the issue, we can&#39;t initialize vectors and its i=
lk with move-only types. Since Resource<br></div><div class=3D"gmail_quote"=
>
Acquisition Is Initialization, I find it potentially very unfortunate.<br><=
br></div><div class=3D"gmail_quote">I think a solution like mutable_initial=
izer_list is certainly a feature. Not being able to<br></div><div class=3D"=
gmail_quote">
initialize standard containers with move-only types certainly looks like a =
bug.<br></div></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

--089e013cbae833f6bd04e3e75817--

.

2013/8/14 Ville Voutilainen <ville.voutilainen@gmail.com>:
> It's not unfortunate that immutable data can't be mutated. What's
> unfortunate is that
> one easily gets the impression that vector<int>{foo(), bar(), baz()} is
> supposed to allow
> putting the contents of the vector right-into-it, to avoid having to write
> vector<int> vec;
> vec.push_back(foo());
> vec.push_back(bar());
> vec.push_back(baz());
> but with move-only types we again have to fall back to that verbosity. If I
> reach further
> into the issue, we can't initialize vectors and its ilk with move-only
> types. Since Resource
> Acquisition Is Initialization, I find it potentially very unfortunate.
>
> I think a solution like mutable_initializer_list is certainly a feature. Not
> being able to
> initialize standard containers with move-only types certainly looks like a
> bug.

The initializer_list constructor overloads were added to containers
and other types as an additional convenience, not as a replacement for
the iterator-based constructors or as a replacement for usage of
emplace. So to me it seems now that you are inverting the roles of
std::initializer_list constructors to the most fundamental ones.

I also cannot really share the interpretation, that RAII is not
possible for move-only types, but given any of the alternatives
mentioned above it seems still valid to me.

- Daniel

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



.

Daniel Kr=FCgler <daniel.kruegler@gmail.com> writes:

| 2013/8/14 Ville Voutilainen <ville.voutilainen@gmail.com>:
| > It's not unfortunate that immutable data can't be mutated. What's
| > unfortunate is that
| > one easily gets the impression that vector<int>{foo(), bar(), baz()} is
| > supposed to allow
| > putting the contents of the vector right-into-it, to avoid having to wr=
ite
| > vector<int> vec;
| > vec.push_back(foo());
| > vec.push_back(bar());
| > vec.push_back(baz());
| > but with move-only types we again have to fall back to that verbosity. =
If I
| > reach further
| > into the issue, we can't initialize vectors and its ilk with move-only
| > types. Since Resource
| > Acquisition Is Initialization, I find it potentially very unfortunate.
| >
| > I think a solution like mutable_initializer_list is certainly a feature=
.. Not
| > being able to
| > initialize standard containers with move-only types certainly looks lik=
e a
| > bug.
|=20
| The initializer_list constructor overloads were added to containers
| and other types as an additional convenience, not as a replacement for
| the iterator-based constructors or as a replacement for usage of
| emplace.

Correct.

| So to me it seems now that you are inverting the roles of
| std::initializer_list constructors to the most fundamental ones.
|=20
| I also cannot really share the interpretation, that RAII is not
| possible for move-only types, but given any of the alternatives
| mentioned above it seems still valid to me.

Agreed.

I hope we're not too quick in reaching conclusions.

-- Gaby

--=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/.



.

--047d7bea35246705f104e3e7d903
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 14 August 2013 15:30, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wrote=
:

> The initializer_list constructor overloads were added to containers
> and other types as an additional convenience, not as a replacement for
> the iterator-based constructors or as a replacement for usage of
>

Yet they are able to do things iterator constructors or emplace cannot do.


> emplace. So to me it seems now that you are inverting the roles of
> std::initializer_list constructors to the most fundamental ones.
>

Uh, ok. I didn't realize I was in the field of such role inversion, I
certainly
didn't intend to be.


>
> I also cannot really share the interpretation, that RAII is not
> possible for move-only types, but given any of the alternatives
> mentioned above it seems still valid to me.
>

The alternatives above aren't applicable, since to use an iterator
constructor, I'd need to have something iterable. And emplace isn't
initialization.

--=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/.



--047d7bea35246705f104e3e7d903
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 14 August 2013 15:30, Daniel Kr=FCgler <span dir=3D"ltr">&lt;<a =
href=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blank">daniel.kruegler=
@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">The initializer_list constructor overloads w=
ere added to containers<br>
and other types as an additional convenience, not as a replacement for<br>
the iterator-based constructors or as a replacement for usage of<br></block=
quote><div><br></div><div>Yet they are able to do things iterator construct=
ors or emplace cannot do.<br>=A0<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

emplace. So to me it seems now that you are inverting the roles of<br>
std::initializer_list constructors to the most fundamental ones.<br></block=
quote><div><br></div><div>Uh, ok. I didn&#39;t realize I was in the field o=
f such role inversion, I certainly<br></div><div>didn&#39;t intend to be.<b=
r>
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">
<br>
I also cannot really share the interpretation, that RAII is not<br>
possible for move-only types, but given any of the alternatives<br>
mentioned above it seems still valid to me.<br></blockquote><div><br></div>=
<div>The alternatives above aren&#39;t applicable, since to use an iterator=
<br></div><div>constructor, I&#39;d need to have something iterable. And em=
place isn&#39;t<br>
</div><div>initialization.=A0 <br></div></div></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

--047d7bea35246705f104e3e7d903--

.

------=_Part_4223_19123662.1376486006933
Content-Type: text/plain; charset=ISO-8859-1


On Wednesday, August 14, 2013 1:53:51 PM UTC+1, Ville Voutilainen wrote:
>
>
>
> I also cannot really share the interpretation, that RAII is not
>> possible for move-only types, but given any of the alternatives
>> mentioned above it seems still valid to me.
>>
>
> The alternatives above aren't applicable, since to use an iterator
> constructor, I'd need to have something iterable. And emplace isn't
> initialization.
>

It's not tooooo hard to make it into something iterable, that can be moved
from:

MoveOnly arr[] = { foo(), bar(), baz() };
std::vector<MoveOnly> v(std::make_move_iterator(std::begin(arr)),
std::make_move_iterator(std::end(arr)));


--

---
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_4223_19123662.1376486006933
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Wednesday, August 14, 2013 1:53:51 PM UTC+1, Ville =
Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><br><div><br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
I also cannot really share the interpretation, that RAII is not<br>
possible for move-only types, but given any of the alternatives<br>
mentioned above it seems still valid to me.<br></blockquote><div><br></div>=
<div>The alternatives above aren't applicable, since to use an iterator<br>=
</div><div>constructor, I'd need to have something iterable. And emplace is=
n't<br>
</div><div>initialization.&nbsp; <br></div></div></div></div></blockquote><=
div><br>It's not tooooo hard to make it into something iterable, that can b=
e moved from:<br><br>MoveOnly arr[] =3D { foo(), bar(), baz() };<br>std::ve=
ctor&lt;MoveOnly&gt; v(std::make_move_iterator(std::begin(arr)), std::make_=
move_iterator(std::end(arr)));<br>&nbsp;<br><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_4223_19123662.1376486006933--

.

2013/8/14 Ville Voutilainen <ville.voutilainen@gmail.com>:
>
> On 14 August 2013 15:30, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wro=
te:
>> I also cannot really share the interpretation, that RAII is not
>> possible for move-only types, but given any of the alternatives
>> mentioned above it seems still valid to me.
>
> The alternatives above aren't applicable, since to use an iterator
> constructor, I'd need to have something iterable. And emplace isn't
> initialization.

1) Since initializer_list constructor of constainers are already a
kind of two-step initialization (Allocate an array of some const
stuff, let std::initializer_list point to it and then iterate over the
std::initializer_list range), this scheme can be rewritten acting upon
non-constant data using e.g. std::move_iterator to provide the data to
the constructor of the container. Instead of a single-liner this can
be two-liner (if expanded and not wrapped into a function).

MoveOnly data[] =3D { .... };
std::vector<MoveOnly> v(std::make_move_iterator(std::begin(data)),
std::make_move_iterator(std::end(data)));

(I see now that Jonathan proposes the same strategy)

If this is not good enough, it should be possible to write a function
template of the form

template<class T, std::size_t N>
std::move_iterator<T> move_away(T (&& t)[N]);

and wait for the expect range-support to allow something like:

std::vector<MoveOnly> v(move_away({MoveOnly(1), MoveOnly(2)}));

[untested]

2) Alternatively you can create a local container, emplace the
elements, then move this container into the actual target container
(typically all this is provided by a single function template).

- Daniel

--=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/.



.

--14dae94ee3e7d26c6604e3e8d183
Content-Type: text/plain; charset=ISO-8859-1

On 14 August 2013 16:13, Jonathan Wakely <cxx@kayari.org> wrote:

>
> The alternatives above aren't applicable, since to use an iterator
>> constructor, I'd need to have something iterable. And emplace isn't
>> initialization.
>>
>
> It's not tooooo hard to make it into something iterable, that can be moved
> from:
>
> MoveOnly arr[] = { foo(), bar(), baz() };
> std::vector<MoveOnly> v(std::make_move_iterator(std::begin(arr)),
> std::make_move_iterator(std::end(arr)));
>
>
Thanks. That's not toooo hard, but I would rather not encourage people to
have to use
raw arrays or even std::array to achieve something that's arguably
fundamental. Perhaps
it's just me. </bitch bitch whine>. :)  Arguably.

--

---
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/.



--14dae94ee3e7d26c6604e3e8d183
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 14 August 2013 16:13, Jonathan Wakely <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:cxx@kayari.org" target=3D"_blank">cxx@kayari.org</a>&gt;</spa=
n> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"im"><br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>The alternatives abov=
e aren&#39;t applicable, since to use an iterator<br></div><div>constructor=
, I&#39;d need to have something iterable. And emplace isn&#39;t<br>
</div><div>initialization.=A0 <br></div></div></div></div></blockquote></di=
v><div><br>It&#39;s not tooooo hard to make it into something iterable, tha=
t can be moved from:<br><br>MoveOnly arr[] =3D { foo(), bar(), baz() };<br>
std::vector&lt;MoveOnly&gt; v(std::make_move_iterator(std::begin(arr)), std=
::make_move_iterator(std::end(arr)));<br><br></div></div></blockquote><div>=
<br></div><div>Thanks. That&#39;s not toooo hard, but I would rather not en=
courage people to have to use<br>
</div><div>raw arrays or even std::array to achieve something that&#39;s ar=
guably fundamental. Perhaps<br>it&#39;s just me. &lt;/bitch bitch whine&gt;=
.. :)=A0 Arguably.<br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

--14dae94ee3e7d26c6604e3e8d183--

.

--001a1133beb64704f704e3e8ddef
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 14 August 2013 16:19, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wrote=
:

>
> If this is not good enough, it should be possible to write a function
> template of the form
>
> template<class T, std::size_t N>
> std::move_iterator<T> move_away(T (&& t)[N]);
>
> and wait for the expect range-support to allow something like:
>
> std::vector<MoveOnly> v(move_away({MoveOnly(1), MoveOnly(2)}));
>
> [untested]
>
> 2) Alternatively you can create a local container, emplace the
> elements, then move this container into the actual target container
> (typically all this is provided by a single function template).
>
>
>
As working as these work-arounds may be, they are still work-arounds. At
any rate,
I think it would be worthwhile to explore whether we can do a fix that
doesn't require
such work-arounds. The "wait for the expected range-support" rings an alarm
bell
in my head. The second option requires as much if not more code written as
the push_back/emplace-separately.

--=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/.



--001a1133beb64704f704e3e8ddef
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 14 August 2013 16:19, Daniel Kr=FCgler <span dir=3D"ltr">&lt;<a =
href=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blank">daniel.kruegler=
@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
If this is not good enough, it should be possible to write a function<br>
template of the form<br>
<br>
template&lt;class T, std::size_t N&gt;<br>
std::move_iterator&lt;T&gt; move_away(T (&amp;&amp; t)[N]);<br>
<br>
and wait for the expect range-support to allow something like:<br>
<br>
std::vector&lt;MoveOnly&gt; v(move_away({MoveOnly(1), MoveOnly(2)}));<br>
<br>
[untested]<br>
<br>
2) Alternatively you can create a local container, emplace the<br>
elements, then move this container into the actual target container<br>
(typically all this is provided by a single function template).<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br><br></div></div></blockquote><d=
iv><br></div><div>As working as these work-arounds may be, they are still w=
ork-arounds. At any rate,<br></div><div>I think it would be worthwhile to e=
xplore whether we can do a fix that doesn&#39;t require<br>
</div><div>such work-arounds. The &quot;wait for the expected range-support=
&quot; rings an alarm bell<br></div><div>in my head. The second option requ=
ires as much if not more code written as<br>the push_back/emplace-separatel=
y. <br>
</div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

--001a1133beb64704f704e3e8ddef--

.

2013/8/14 Ville Voutilainen <ville.voutilainen@gmail.com>:
>
> On 14 August 2013 16:19, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wro=
te:
>>
>> If this is not good enough, it should be possible to write a function
>> template of the form
>>
>> template<class T, std::size_t N>
>> std::move_iterator<T> move_away(T (&& t)[N]);
>>
>> and wait for the expect range-support to allow something like:
>>
>> std::vector<MoveOnly> v(move_away({MoveOnly(1), MoveOnly(2)}));
>>
>> [untested]
>>
>> 2) Alternatively you can create a local container, emplace the
>> elements, then move this container into the actual target container
>> (typically all this is provided by a single function template).
>>
>>
> As working as these work-arounds may be, they are still work-arounds. At =
any
> rate,
> I think it would be worthwhile to explore whether we can do a fix that
> doesn't require such work-arounds. The "wait for the expected range-suppo=
rt" rings an alarm
> bell in my head.

I don't understand why. Are you against range-support? IMO
std::initializer_list constructors in the library are just a special
case of a more generalized range support pattern and I find it more
reasonable to look for a more general solution instead of trying to
mutate std::initializer_list to something that it was not intended to
be.

> The second option requires as much if not more code written as
> the push_back/emplace-separately.

It's your choice ;-) (But I doubt the premise)

- Daniel

--=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/.



.

--089e0139ff76034c4004e3eb27de
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 14 August 2013 17:39, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wrote=
:

> > I think it would be worthwhile to explore whether we can do a fix that
> > doesn't require such work-arounds. The "wait for the expected
> range-support" rings an alarm
> > bell in my head.
>
> I don't understand why. Are you against range-support? IMO
>

No. I'm against lumping every problem we have under the range umbrella.
string::split being one of them, this move-from-braced-list being another.
I don't think ranges are the proper solution for such things.


> std::initializer_list constructors in the library are just a special
> case of a more generalized range support pattern and I find it more
> reasonable to look for a more general solution instead of trying to
> mutate std::initializer_list to something that it was not intended to
> be.
>

That's ok, I don't know what the solution should be yet, perhaps
mutating initializer_list isn't it. The problem shouldn't be "this is how
initializer_lists work, don't expect braced-initializers to work
differently".
I'm not supposed to KNOW there's an initializer_list involved when
I construct a vector from a braced list. At least I'm under the impression
that initializer_list was supposed to be implementation plumbing
rather than something that's in-my-face. And again, I don't think
that implementation plumbing works quite right if I can't braced-init
with move-only types. Other people can freely agree to disagree
with that.

--=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/.



--089e0139ff76034c4004e3eb27de
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 14 August 2013 17:39, Daniel Kr=FCgler <span dir=3D"ltr">&lt;<a =
href=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blank">daniel.kruegler=
@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">&gt; I think it would be worthwhile to explo=
re whether we can do a fix that<br><div class=3D"im">
&gt; doesn&#39;t require such work-arounds. The &quot;wait for the expected=
 range-support&quot; rings an alarm<br>
&gt; bell in my head.<br>
<br>
</div>I don&#39;t understand why. Are you against range-support? IMO<br></b=
lockquote><div><br></div><div>No. I&#39;m against lumping every problem we =
have under the range umbrella.<br></div><div>string::split being one of the=
m, this move-from-braced-list being another.<br>
</div><div>I don&#39;t think ranges are the proper solution for such things=
..<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
std::initializer_list constructors in the library are just a special<br>
case of a more generalized range support pattern and I find it more<br>
reasonable to look for a more general solution instead of trying to<br>
mutate std::initializer_list to something that it was not intended to<br>
be.<br></blockquote><div><br></div><div>That&#39;s ok, I don&#39;t know wha=
t the solution should be yet, perhaps<br>mutating initializer_list isn&#39;=
t it. The problem shouldn&#39;t be &quot;this is how<br>initializer_lists w=
ork, don&#39;t expect braced-initializers to work differently&quot;.<br>
</div><div>I&#39;m not supposed to KNOW there&#39;s an initializer_list inv=
olved when<br></div><div>I construct a vector from a braced list. At least =
I&#39;m under the impression<br>that initializer_list was supposed to be im=
plementation plumbing<br>
rather than something that&#39;s in-my-face. And again, I don&#39;t think<b=
r>that implementation plumbing works quite right if I can&#39;t braced-init=
<br>with move-only types. Other people can freely agree to disagree<br>
with that.<br>=A0<br><br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

--089e0139ff76034c4004e3eb27de--

.

------=_Part_1480_29725969.1376512958154
Content-Type: text/plain; charset=ISO-8859-1



>
> That's ok, I don't know what the solution should be yet, perhaps
> mutating initializer_list isn't it. The problem shouldn't be "this is how
> initializer_lists work, don't expect braced-initializers to work
> differently".
> I'm not supposed to KNOW there's an initializer_list involved when
> I construct a vector from a braced list. At least I'm under the impression
> that initializer_list was supposed to be implementation plumbing
> rather than something that's in-my-face. And again, I don't think
> that implementation plumbing works quite right if I can't braced-init
> with move-only types. Other people can freely agree to disagree
> with that.
>
>
The std::initializer_list<int> is only the solution of the uniform
initialization problem,
not the problem itself. So while the design of initializer list is
perfectly valid (thanks
Daniel for the papers), this model failed to achieve the main goal:

Provide uniform initialization for build-in types (arrays) and
user defined types.

That is the slogan/promotional phase for the most of materials about C++11.
But the initialization of the vector is not uniform with the build-in
arrays, which
is suprising for the users and make learning of C++ harder, not easer as
uniform initialization suppose to. Especially when no presentation/material
know to me
on C++11 mentions this - they use the slogan.

*Was another approach possible?*
I think yes. To point is to not use 2-face initialization and use varidatic
templates instead:

template<typename T>
inline static_for_init(T* data) {}

template<typename T, typename U, typename... Us>
inline static_for_init(T* data, U&& u, Us&& us)
{
  new(data) T{std::forward<U>(u)}; //the allocator should be used here, but
this will show idea
  static_for_init(data++, std::forward<Us>(us)...);
}

template<typename T>
struct vector
{
  template<typename... Us>
  vector(Us&&... us)
  //some SFINAE on type of arguments.
    : _data(sizeof...(Us)),
      _size(sizeof...(Us))
  {  static_for_init(_data, std::forward<Us>(us)); }
private:
  T* _data;
  std::size_t _size;
};
Of course this code needs allocator support (std::allocator_arg should be
used), but this
is doable.

This will of course make writing an STL-like container even harder, but the
allocator support
and exception safety already make this a really hrd task so that should not
be a problem. Also
there will be some problem with ambiguity of constructor. But from the user
perspective the goal will
be achived - the vector intialization will be uniform with intialization of
build in arrays, even considering
performance.

*Summary:
*At this moment this cannot be changed, as the C++11 standard was shipped.
I written my first post
to emphasize the problem, because I was aware of the problem (I am used to
read the standard to check new things),
but non of my co-workers was aware of it.

Also it is a bit sad, that the solution choosen (std::intializer_list) to
address problem (aggreate intialization) lead us to not
fulfilling the goal.

--

---
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_1480_29725969.1376512958154
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><div><br></div><div>That's ok, I d=
on't know what the solution should be yet, perhaps<br>mutating initializer_=
list isn't it. The problem shouldn't be "this is how<br>initializer_lists w=
ork, don't expect braced-initializers to work differently".<br>
</div><div>I'm not supposed to KNOW there's an initializer_list involved wh=
en<br></div><div>I construct a vector from a braced list. At least I'm unde=
r the impression<br>that initializer_list was supposed to be implementation=
 plumbing<br>
rather than something that's in-my-face. And again, I don't think<br>that i=
mplementation plumbing works quite right if I can't braced-init<br>with mov=
e-only types. Other people can freely agree to disagree<br>
with that.<br>&nbsp;</div></div></div></div></blockquote><div>The std::init=
ializer_list&lt;int&gt; is only the solution of the uniform initialization =
problem,<br>not the problem itself. So while the design of initializer list=
 is perfectly valid (thanks<br>Daniel for the papers), this model failed to=
 achieve the main goal:<br><span style=3D"font-family: courier new,monospac=
e;"><br>Provide uniform initialization for build-in types (arrays) and<br>u=
ser defined types.<br><br>That is the slogan/promotional phase for the most=
 of materials about C++11.<br>But the initialization of the vector is not u=
niform with the build-in arrays, which<br>is suprising for the users and ma=
ke learning of C++ harder, not easer as <br>uniform initialization suppose =
to. Especially when no presentation/material know to me<br>on C++11 mention=
s this - they use the slogan.<br><br><b>Was another approach possible?</b><=
br>I think yes. To point is to not use 2-face initialization and use varida=
tic templates instead:<br><br>template&lt;typename T&gt;<br>inline static_f=
or_init(T* data) {}<br><br>template&lt;typename T, typename U, typename... =
Us&gt;<br>inline static_for_init(T* data, U&amp;&amp; u, Us&amp;&amp; us)<b=
r>{<br>&nbsp; new(data) T{std::forward&lt;U&gt;(u)}; //the allocator should=
 be used here, but this will show idea<br>&nbsp; static_for_init(data++, st=
d::forward&lt;Us&gt;(us)...);<br>}<br><br>template&lt;typename T&gt;<br>str=
uct vector<br>{<br>&nbsp; template&lt;typename... Us&gt;<br>&nbsp; vector(U=
s&amp;&amp;... us)<br>&nbsp; //some SFINAE on type of arguments.<br>&nbsp;&=
nbsp;&nbsp; : _data(sizeof...(Us)),<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; _size=
(sizeof...(Us))<br>&nbsp; {&nbsp; <font face=3D"arial,sans-serif"><span sty=
le=3D"font-family: courier new,monospace;">static_for_init(_data, std::forw=
ard&lt;Us&gt;(us)); }<br>private:<br>&nbsp; T* _data;<br>&nbsp; std::size_t=
 _size;<br>};</span><br>Of course this code needs allocator support (std::a=
llocator_arg should be used), but this<br>is doable.<br><br>This will of co=
urse make writing an STL-like container even harder, but the allocator supp=
ort<br>and exception safety already make this a really hrd task so that sho=
uld not be a problem. Also<br>there will be some problem with ambiguity of =
constructor. But from the user perspective the goal will<br>be achived - th=
e vector intialization will be uniform with intialization of build in array=
s, even considering<br>performance.<br><br><b>Summary:<br></b>At this momen=
t this cannot be changed, as the C++11 standard was shipped. I written my f=
irst post<br>to emphasize the problem, because I was aware of the problem (=
I am used to read the standard to check new things),<br>but non of my co-wo=
rkers was aware of it.<br><br>Also it is a bit sad, that the solution choos=
en (std::intializer_list) to address problem (aggreate intialization) lead =
us to not<br>fulfilling the goal.<br></font></span></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1480_29725969.1376512958154--

.

------=_Part_2999_31542940.1376524753480
Content-Type: text/plain; charset=ISO-8859-1

On Wednesday, August 14, 2013 1:42:38 PM UTC-7, toma...@gmail.com wrote:
>
> That's ok, I don't know what the solution should be yet, perhaps
>> mutating initializer_list isn't it. The problem shouldn't be "this is how
>> initializer_lists work, don't expect braced-initializers to work
>> differently".
>> I'm not supposed to KNOW there's an initializer_list involved when
>> I construct a vector from a braced list. At least I'm under the impression
>> that initializer_list was supposed to be implementation plumbing
>> rather than something that's in-my-face. And again, I don't think
>> that implementation plumbing works quite right if I can't braced-init
>> with move-only types. Other people can freely agree to disagree
>> with that.
>>
>>
> The std::initializer_list<int> is only the solution of the uniform
> initialization problem,
> not the problem itself. So while the design of initializer list is
> perfectly valid (thanks
> Daniel for the papers), this model failed to achieve the main goal:
>
> Provide uniform initialization for build-in types (arrays) and
> user defined types.
>

No. Uniform initialization was about the copy vs. direct vs. aggregate
initialization paradigm. That is, providing a single way to initialize a
type that works exactly the same in all circumstances, which can be used
for all types. But because it used {} syntax, it was also adopted into
providing a way to initialize an arbitrary object from a sequence of
equivalently typed parameters. But that wasn't its primary purpose.

That is the slogan/promotional phase for the most of materials about C++11.
> But the initialization of the vector is not uniform with the build-in
> arrays, which
> is suprising for the users and make learning of C++ harder, not easer as
> uniform initialization suppose to. Especially when no
> presentation/material know to me
> on C++11 mentions this - they use the slogan.
>

That's because it's fairly minor, all things considered. The far more
eggregious issue with UI is that initializer_list constructors can hide
constructors that just so happen to take the same types of parameters. The
fact that you can't put a non-copyable type in a braced-init-list that will
be converted into an initializer_list is pretty minor next to hiding
important constructors, thus forcing you back into () constructor syntax.


> *Was another approach possible?*
> I think yes. To point is to not use 2-face initialization and use
> varidatic templates instead:
>

Um, how does that help? It now turns something that was quite simple into
something incredibly complex. Yes, it solves one problem, but it creates
many more.

It makes accidental narrowing very possible. It makes the compiler errors
you get for creating a braced-init-list of different types much more
oddball. It causes the generation of lots of pointless code, bloating
compile times needlessly (it's a list of known size. We shouldn't have to
template metaprogram recurse through it). It also conflicts with other
parts of uniform initialization: being able to call non-initializer_list
constructors with braced-init-lists.** Lastly, there's no way to
differentiate between a variadic template intended for some other purpose
and an object that you want to be constructed from an arbitrary list of
values.


> Of course this code needs allocator support (std::allocator_arg should be
> used), but this
> is doable.
>
> This will of course make writing an STL-like container even harder, but
> the allocator support
> and exception safety already make this a really hrd task so that should
> not be a problem. Also
> there will be some problem with ambiguity of constructor. But from the
> user perspective the goal will
> be achived - the vector intialization will be uniform with intialization
> of build in arrays, even considering
> performance.
>

There are a lot more uses for having an object with an initializer_list
constructor than *just* an STL-compliant container type. We shouldn't make
you have to go through that much effort to process *an array*.

As people have said, this is a solveable problem. We may need a new
"initializer_list" type to solve it, but it can certainly be resolved under
the existing paradigm.

--

---
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_2999_31542940.1376524753480
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, August 14, 2013 1:42:38 PM UTC-7, toma...@gm=
ail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote"><div></div><div>That's ok, I don't know what the solution =
should be yet, perhaps<br>mutating initializer_list isn't it. The problem s=
houldn't be "this is how<br>initializer_lists work, don't expect braced-ini=
tializers to work differently".<br>
</div><div>I'm not supposed to KNOW there's an initializer_list involved wh=
en<br></div><div>I construct a vector from a braced list. At least I'm unde=
r the impression<br>that initializer_list was supposed to be implementation=
 plumbing<br>
rather than something that's in-my-face. And again, I don't think<br>that i=
mplementation plumbing works quite right if I can't braced-init<br>with mov=
e-only types. Other people can freely agree to disagree<br>
with that.<br>&nbsp;</div></div></div></div></blockquote><div>The std::init=
ializer_list&lt;int&gt; is only the solution of the uniform initialization =
problem,<br>not the problem itself. So while the design of initializer list=
 is perfectly valid (thanks<br>Daniel for the papers), this model failed to=
 achieve the main goal:<br><span style=3D"font-family:courier new,monospace=
"><br>Provide uniform initialization for build-in types (arrays) and<br>use=
r defined types.<br></span></div></div></blockquote><div><br>No. Uniform in=
itialization was about the copy vs. direct vs. aggregate=20
initialization paradigm. That is, providing a single way to initialize a
 type that works exactly the same in all circumstances, which can be=20
used for all types. But because it used {} syntax, it was also adopted=20
into providing a way to initialize an arbitrary object from a sequence=20
of equivalently typed parameters. But that wasn't its primary purpose.<br><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
><span style=3D"font-family:courier new,monospace">That is the slogan/promo=
tional phase for the most of materials about C++11.<br>But the initializati=
on of the vector is not uniform with the build-in arrays, which<br>is supri=
sing for the users and make learning of C++ harder, not easer as <br>unifor=
m initialization suppose to. Especially when no presentation/material know =
to me<br>on C++11 mentions this - they use the slogan.<br></span></div></di=
v></blockquote><div>&nbsp;<br>That's because it's fairly minor, all things =
considered. The far more eggregious issue with UI is that initializer_list =
constructors can hide constructors that just so happen to take the same typ=
es of parameters. The fact that you can't put a non-copyable type in a brac=
ed-init-list that will be converted into an initializer_list is pretty mino=
r next to hiding important constructors, thus forcing you back into () cons=
tructor syntax.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div><span style=3D"font-family:courier new,monospace"><b=
>Was another approach possible?</b><br>I think yes. To point is to not use =
2-face initialization and use varidatic templates instead:<br></span></div>=
</div></blockquote><div><br>Um, how does that help? It now turns something =
that was quite simple into something incredibly complex. Yes, it solves one=
 problem, but it creates many more.<br><br>It makes accidental narrowing ve=
ry possible. It makes the compiler errors you get for creating a braced-ini=
t-list of different types much more oddball. It causes the generation of lo=
ts of pointless code, bloating compile times needlessly (it's a list of kno=
wn size. We shouldn't have to template metaprogram recurse through it). It =
also conflicts with other parts of uniform initialization: being able to ca=
ll non-initializer_list constructors with braced-init-lists.<i></i> Lastly,=
 there's no way to differentiate between a variadic template intended for s=
ome other purpose and an object that you want to be constructed from an arb=
itrary list of values.<br>&nbsp;</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><div><span style=3D"font-family:courier new,monosp=
ace"><font face=3D"arial,sans-serif">Of course this code needs allocator su=
pport (std::allocator_arg should be used), but this<br>is doable.<br><br>Th=
is will of course make writing an STL-like container even harder, but the a=
llocator support<br>and exception safety already make this a really hrd tas=
k so that should not be a problem. Also<br>there will be some problem with =
ambiguity of constructor. But from the user perspective the goal will<br>be=
 achived - the vector intialization will be uniform with intialization of b=
uild in arrays, even considering<br>performance.<br></font></span></div></d=
iv></blockquote><div><br>There are a lot more uses for having an object wit=
h an initializer_list constructor than <i>just</i> an STL-compliant contain=
er type. We shouldn't make you have to go through that much effort to proce=
ss <i>an array</i>.</div><br><font face=3D"arial,sans-serif">As people have=
 said, this is a solveable problem. We may need a new "initializer_list" ty=
pe to solve it, but it can certainly be resolved under the existing paradig=
m.</font><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_2999_31542940.1376524753480--

.

------=_Part_87_32955712.1376530558863
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, August 15, 2013 7:59:13 AM UTC+8, Nicol Bolas wrote:
>
> There are a lot more uses for having an object with an initializer_list
> constructor than *just* an STL-compliant container type. We shouldn't
> make you have to go through that much effort to process *an array*.
> As people have said, this is a solveable problem. We may need a new
> "initializer_list" type to solve it, but it can certainly be resolved under
> the existing paradigm.
>

What tools or flexibilities are available to solve within the existing
paradigm? The really unfortunate thing is not that the initial solution
fell short, but that the revision is already too late for C++14?

Has there been any preliminary study of what might be changed and what is
really essential as-is in the std::initializer_list spec?

For example, so much would be fixed if begin() and end() could return
non-const pointers. Is this a serious breaking change per se? It doesn't
seem so to me.

A good start would be to differentiate between const and non-const
std::initializer_list. A function taking a const std::initializer_list *by
value* would have read-only access to its contents, and allow the
implementation to use storage in ROM, whereas dropping the const would
force it into stack allocation.

Although pass-by-const-value is generally useless, a quick trial in GCC
shows that you're already allowed to overload const and non-const
parameters (i.e. const does not decay away in a function parameter type),
so the implementation might not be so bad.

--

---
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_87_32955712.1376530558863
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, August 15, 2013 7:59:13 AM UTC+8, Nicol Bolas=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">There =
are a lot more uses for having an object with an initializer_list construct=
or than <i>just</i> an STL-compliant container type. We shouldn't make you =
have to go through that much effort to process <i>an array</i>.<br><font fa=
ce=3D"arial,sans-serif">As people have said, this is a solveable problem. W=
e may need a new "initializer_list" type to solve it, but it can certainly =
be resolved under the existing paradigm.</font><br></div></blockquote><div>=
<br>What tools or flexibilities are available to solve within the existing =
paradigm? The really unfortunate thing is not that the initial solution fel=
l short, but that the revision is already too late for C++14?<br><br>Has th=
ere been any preliminary study of what might be changed and what is really =
essential as-is in the std::initializer_list spec?<br><br>For example, so m=
uch would be fixed if begin() and end() could return non-const pointers. Is=
 this a serious breaking change per se? It doesn't seem so to me.<br><br>A =
good start would be to differentiate between const and non-const std::initi=
alizer_list. A function taking a const std::initializer_list <i>by value</i=
> would have read-only access to its contents, and allow the implementation=
 to use storage in ROM, whereas dropping the const would force it into stac=
k allocation.<br><br>Although pass-by-const-value is generally useless, a q=
uick trial in GCC shows that you're already allowed to overload const and n=
on-const parameters (i.e. const does not decay away in a function parameter=
 type), so the implementation might not be so bad.<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_87_32955712.1376530558863--

.

--047d7bd6c2c45a365f04e3f416d2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 14, 2013 at 9:50 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 14 August 2013 17:39, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wro=
te:
>
>> > I think it would be worthwhile to explore whether we can do a fix that
>> > doesn't require such work-arounds. The "wait for the expected
>> range-support" rings an alarm
>> > bell in my head.
>>
>> I don't understand why. Are you against range-support? IMO
>>
>
> No. I'm against lumping every problem we have under the range umbrella.
> string::split being one of them, this move-from-braced-list being another=
..
> I don't think ranges are the proper solution for such things.
>
>
>> std::initializer_list constructors in the library are just a special
>> case of a more generalized range support pattern and I find it more
>> reasonable to look for a more general solution instead of trying to
>> mutate std::initializer_list to something that it was not intended to
>> be.
>>
>
> That's ok, I don't know what the solution should be yet, perhaps
> mutating initializer_list isn't it. The problem shouldn't be "this is how
> initializer_lists work, don't expect braced-initializers to work
> differently".
> I'm not supposed to KNOW there's an initializer_list involved when
> I construct a vector from a braced list. At least I'm under the impressio=
n
> that initializer_list was supposed to be implementation plumbing
> rather than something that's in-my-face. And again, I don't think
> that implementation plumbing works quite right if I can't braced-init
> with move-only types. Other people can freely agree to disagree
> with that.
>

I agree. vector<unique_ptr<T>> can't be brace-initialized, so we have not
fully arrived at the clean, simple, uniform initialization syntax we
wanted. initializer_list<T> is supposed to be the vehicle for communicating
a braced-init-list from an initialization to a constructor, and it's not
fully succeeding at that task.

The core of the problem seems to be that initializer_list<T> does not own
its elements, not that the elements are immutable. If we merely made the
contents of the initializer_list mutable, we would break move-safety:

initializer_list<unique_ptr<T>> x =3D { a, b, c };
auto get() { return x; }
std::vector<unique_ptr<T>> v(get()); // oops, implicitly move here

We could fix this by adding a move-only std::unique_initializer_list<T> (or
similar) that owns its elements, but it seems overly-complicated to have
two similar-but-different initializer_list types in the library.
Conversely, it's probably too late to fix initializer_list to own its
contents (and thus be move-only).

--=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/.

--047d7bd6c2c45a365f04e3f416d2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Aug 14, 2013 at 9:50 AM, Ville Voutilainen <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_bl=
ank">ville.voutilainen@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gma=
il_extra">

<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<span style=3D"color:rgb(80,0,80)">On 14 August 2013 17:39, Daniel Kr=FCgle=
r </span><span dir=3D"ltr" style=3D"color:rgb(80,0,80)">&lt;<a href=3D"mail=
to:daniel.kruegler@gmail.com" target=3D"_blank">daniel.kruegler@gmail.com</=
a>&gt;</span><span style=3D"color:rgb(80,0,80)"> wrote:</span><br>

<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">&gt; I think it would be worthwhile to explo=
re whether we can do a fix that<br><div>
&gt; doesn&#39;t require such work-arounds. The &quot;wait for the expected=
 range-support&quot; rings an alarm<br>
&gt; bell in my head.<br>
<br>
</div>I don&#39;t understand why. Are you against range-support? IMO<br></b=
lockquote><div><br></div></div><div>No. I&#39;m against lumping every probl=
em we have under the range umbrella.<br></div><div>string::split being one =
of them, this move-from-braced-list being another.<br>


</div><div>I don&#39;t think ranges are the proper solution for such things=
..<br>=A0<br></div><div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
std::initializer_list constructors in the library are just a special<br>
case of a more generalized range support pattern and I find it more<br>
reasonable to look for a more general solution instead of trying to<br>
mutate std::initializer_list to something that it was not intended to<br>
be.<br></blockquote><div><br></div></div><div>That&#39;s ok, I don&#39;t kn=
ow what the solution should be yet, perhaps<br>mutating initializer_list is=
n&#39;t it. The problem shouldn&#39;t be &quot;this is how<br>initializer_l=
ists work, don&#39;t expect braced-initializers to work differently&quot;.<=
br>


</div><div>I&#39;m not supposed to KNOW there&#39;s an initializer_list inv=
olved when<br></div><div>I construct a vector from a braced list. At least =
I&#39;m under the impression<br>that initializer_list was supposed to be im=
plementation plumbing<br>


rather than something that&#39;s in-my-face. And again, I don&#39;t think<b=
r>that implementation plumbing works quite right if I can&#39;t braced-init=
<br>with move-only types. Other people can freely agree to disagree<br>


with that.</div></div></div></div></blockquote><div><br></div><div>I agree.=
 vector&lt;unique_ptr&lt;T&gt;&gt; can&#39;t be brace-initialized, so we ha=
ve not fully arrived at the clean, simple, uniform initialization syntax we=
 wanted. initializer_list&lt;T&gt; is supposed to be the vehicle for commun=
icating a braced-init-list from an initialization to a constructor, and it&=
#39;s not fully succeeding at that task.</div>

<div><br></div><div>The core of the problem seems to be that initializer_li=
st&lt;T&gt; does not own its elements, not that the elements are immutable.=
 If we merely made the contents of the initializer_list mutable, we would b=
reak move-safety:</div>

<div><br></div><div>initializer_list&lt;unique_ptr&lt;T&gt;&gt; x =3D { a, =
b, c };</div><div>auto get() { return x; }</div><div>std::vector&lt;unique_=
ptr&lt;T&gt;&gt; v(get()); // oops, implicitly move here</div><div><br></di=
v>

<div>We could fix this by adding a move-only std::unique_initializer_list&l=
t;T&gt; (or similar) that owns its elements, but it seems overly-complicate=
d to have two similar-but-different initializer_list types in the library. =
Conversely, it&#39;s probably too late to fix initializer_list to own its c=
ontents (and thus be move-only).</div>

</div></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7bd6c2c45a365f04e3f416d2--

.

Richard Smith <richard@metafoo.co.uk> writes:

| On Wed, Aug 14, 2013 at 9:50 AM, Ville Voutilainen <ville.voutilainen@gma=
il.com
| > wrote:
|=20
|     On 14 August 2013 17:39, Daniel Kr=FCgler <daniel.kruegler@gmail.com>=
 wrote:
|=20
|         > I think it would be worthwhile to explore whether we can do a f=
ix
|         that
|         > doesn't require such work-arounds. The "wait for the expected
|         range-support" rings an alarm
|         > bell in my head.
|=20
|         I don't understand why. Are you against range-support? IMO
|=20
|=20
|     No. I'm against lumping every problem we have under the range umbrell=
a.
|     string::split being one of them, this move-from-braced-list being ano=
ther.
|     I don't think ranges are the proper solution for such things.
|     =A0
|=20
|         std::initializer_list constructors in the library are just a spec=
ial
|         case of a more generalized range support pattern and I find it mo=
re
|         reasonable to look for a more general solution instead of trying =
to
|         mutate std::initializer_list to something that it was not intende=
d to
|         be.
|=20
|=20
|     That's ok, I don't know what the solution should be yet, perhaps
|     mutating initializer_list isn't it. The problem shouldn't be "this is=
 how
|     initializer_lists work, don't expect braced-initializers to work
|     differently".
|     I'm not supposed to KNOW there's an initializer_list involved when
|     I construct a vector from a braced list. At least I'm under the impre=
ssion
|     that initializer_list was supposed to be implementation plumbing
|     rather than something that's in-my-face. And again, I don't think
|     that implementation plumbing works quite right if I can't braced-init
|     with move-only types. Other people can freely agree to disagree
|     with that.
|=20
|=20
| I agree. vector<unique_ptr<T>> can't be brace-initialized, so we have not=
 fully
| arrived at the clean, simple, uniform initialization syntax we wanted.
| initializer_list<T> is supposed to be the vehicle for communicating a
| braced-init-list from an initialization to a constructor, and it's not fu=
lly
| succeeding at that task.
|=20
| The core of the problem seems to be that initializer_list<T> does not own=
 its
| elements, not that the elements are immutable. If we merely made the cont=
ents
| of the initializer_list mutable, we would break move-safety:
|=20
| initializer_list<unique_ptr<T>> x =3D { a, b, c };
| auto get() { return x; }
| std::vector<unique_ptr<T>> v(get()); // oops, implicitly move here
|=20
| We could fix this by adding a move-only std::unique_initializer_list<T> (=
or
| similar) that owns its elements, but it seems overly-complicated to have =
two
| similar-but-different initializer_list types in the library. Conversely, =
it's
| probably too late to fix initializer_list to own its contents (and thus b=
e
| move-only).

I agree with some of the descriptions here.  However, I have to wonder
whether we are in a classical configuration of 'perfect is the enemy of goo=
d'.

If we get 95% right, then realistically, I consider we've done a good job.

Initialization in C++ is a multi-faceted and treacherous problem -- from
what I've learned working on this problem for a very long period of time.
It is very easy to get one facet perfect, 100% right.  Putting all the
perfect solutions to the isolated problems together is a highly
non-trivial whack-a-mole.  My conjecture is, somewhere we are going to
make a community or an expert unhappy about one resolution or the other.

Even as of today, I still consider the current solution acceptable.
It does not mean that I believe we can't make improvement though -- but
I just think that any substantial improvement from now is going to
result in complication for some segments of users.

-- Gaby

--=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/.

.

------=_Part_4131_17432428.1376546336491
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, August 15, 2013 11:29:53 AM UTC+8, Richard Smith wrote:
>
> The core of the problem seems to be that initializer_list<T> does not own
> its elements, not that the elements are immutable. If we merely made the
> contents of the initializer_list mutable, we would break move-safety:
>
> initializer_list<unique_ptr<T>> x = { a, b, c };
> auto get() { return x; }
> std::vector<unique_ptr<T>> v(get()); // oops, implicitly move here
>

Presuming this is supposed to go inside a class, this example is nonsense.
An initializer_list cannot meaningfully be a member because it doesn't own
its contents.

The problem with mutability is moderated by the limited set of valid
use-cases where the initializer_list could potentially be accessed twice.
Usually its lifetime is that of a temporary used as a function argument.
Its contents are copied (often moving would be preferable) into something,
then it dies. Most attempts to generalize into broader use are fraught with
danger, and should simply be disallowed/deprecated (and opened to future
redefinition).

As a band-aid to my above idea, I would propose that lvalue-to-rvalue
conversion on an initializer_list produce a const rvalue (for lvalues, not
xvalues). Then you can modify the elements in local scope but passing it by
value (as is canonical) to a function does not confer write permission. But
really the mutability proposal is just a distraction.

My intended point is that we need to organize ideas and decide what
initializer_list really needs to do, what we can change and what we cannot.
Then the debate can really be advanced. And maybe we can even outlaw
surprisingly-invalid use cases, such as declaring one to be a class member,
in time for C++14.

--

---
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_4131_17432428.1376546336491
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, August 15, 2013 11:29:53 AM UTC+8, Ri=
chard Smith wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">The core of the problem seems to be that initializer_list&lt;T&gt; doe=
s not own its elements, not that the elements are immutable. If we merely m=
ade the contents of the initializer_list mutable, we would break move-safet=
y:<div><div class=3D"gmail_quote">

<div><br></div><div>initializer_list&lt;unique_ptr&lt;T&gt;<wbr>&gt; x =3D =
{ a, b, c };</div><div>auto get() { return x; }</div><div>std::vector&lt;un=
ique_ptr&lt;T&gt;&gt; v(get()); // oops, implicitly move here</div></div></=
div></div></blockquote><div><br>Presuming this is supposed to go inside a c=
lass, this example is nonsense. An initializer_list cannot meaningfully be =
a member because it doesn't own its contents.<br><br>The problem with mutab=
ility is moderated by the limited set of valid use-cases where the initiali=
zer_list could potentially be accessed twice. Usually its lifetime is that =
of a temporary used as a function argument. Its contents are copied (often =
moving would be preferable) into something, then it dies. Most attempts to =
generalize into broader use are fraught with danger, and should simply be d=
isallowed/deprecated (and opened to future redefinition).<br><br>As a band-=
aid to my above idea, I would propose that lvalue-to-rvalue conversion on a=
n initializer_list produce a const rvalue (for lvalues, not xvalues). Then =
you can modify the elements in local scope but passing it by value (as is c=
anonical) to a function does not confer write permission. But really the mu=
tability proposal is just a distraction.<br><br>My intended point is that w=
e need to organize ideas and decide what initializer_list really needs to d=
o, what we can change and what we cannot. Then the debate can really be adv=
anced. And maybe we can even outlaw surprisingly-invalid use cases, such as=
 declaring one to be a class member, in time for C++14.<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_4131_17432428.1376546336491--

.

David Krauss <potswa@gmail.com> writes:

| My intended point is that we need to organize ideas and decide what
| initializer_list really needs to do, what we can change and what we cannot.

I am pretty sure we did that when we designed (and considered alternatives)
for uniform initialization and std::initializer_list.

-- Gaby

--

---
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_2116_27550413.1376550729989
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu czwartek, 15 sierpnia 2013 01:59:13 UTC+2 u=BFytkownik Nicol Bolas=
=20
napisa=B3:
>
> On Wednesday, August 14, 2013 1:42:38 PM UTC-7, toma...@gmail.com wrote:
>>
>> That's ok, I don't know what the solution should be yet, perhaps
>>> mutating initializer_list isn't it. The problem shouldn't be "this is h=
ow
>>> initializer_lists work, don't expect braced-initializers to work=20
>>> differently".
>>> I'm not supposed to KNOW there's an initializer_list involved when
>>> I construct a vector from a braced list. At least I'm under the=20
>>> impression
>>> that initializer_list was supposed to be implementation plumbing
>>> rather than something that's in-my-face. And again, I don't think
>>> that implementation plumbing works quite right if I can't braced-init
>>> with move-only types. Other people can freely agree to disagree
>>> with that.
>>> =20
>>>
>> The std::initializer_list<int> is only the solution of the uniform=20
>> initialization problem,
>> not the problem itself. So while the design of initializer list is=20
>> perfectly valid (thanks
>> Daniel for the papers), this model failed to achieve the main goal:
>>
>> Provide uniform initialization for build-in types (arrays) and
>> user defined types.
>>
>
> No. Uniform initialization was about the copy vs. direct vs. aggregate=20
> initialization paradigm. That is, providing a single way to initialize a=
=20
> type that works exactly the same in all circumstances, which can be used=
=20
> for all types. But because it used {} syntax, it was also adopted into=20
> providing a way to initialize an arbitrary object from a sequence of=20
> equivalently typed parameters. But that wasn't its primary purpose.
>
> That is the slogan/promotional phase for the most of materials about C++1=
1.
>> But the initialization of the vector is not uniform with the build-in=20
>> arrays, which
>> is suprising for the users and make learning of C++ harder, not easer as=
=20
>> uniform initialization suppose to. Especially when no=20
>> presentation/material know to me
>> on C++11 mentions this - they use the slogan.
>>
> =20
> That's because it's fairly minor, all things considered. The far more=20
> eggregious issue with UI is that initializer_list constructors can hide=
=20
> constructors that just so happen to take the same types of parameters. Th=
e=20
> fact that you can't put a non-copyable type in a braced-init-list that wi=
ll=20
> be converted into an initializer_list is pretty minor next to hiding=20
> important constructors, thus forcing you back into () constructor syntax.
> =20
>
>> *Was another approach possible?*
>> I think yes. To point is to not use 2-face initialization and use=20
>> varidatic templates instead:
>>
>
> Um, how does that help? It now turns something that was quite simple into=
=20
> something incredibly complex. Yes, it solves one problem, but it creates=
=20
> many more.
>
> It makes accidental narrowing very possible.=20
>
No, the constructor code itself brace-initialized constructor for every=20
object, so the some narrowing rules will apply.

It makes the compiler errors you get for creating a braced-init-list of=20
> different types much more oddball.
>
The constructor can be SFINAE'd. The the user will see that there is no=20
viable constructor to construct vector<int> from [char, string].
=20

> It causes the generation of lots of pointless code, bloating compile time=
s=20
> needlessly (it's a list of known size. We shouldn't have to template=20
> metaprogram recurse through it).=20
>
The size of every varidatic parameters packs is know, so your argument=20
apply's also to them, so this is a problem with lack of imperative=20
iteration over parameters pack, not initialization per-se.

It also conflicts with other parts of uniform initialization: being able to=
=20
> call non-initializer_list constructors with braced-init-lists. Lastly,=20
> there's no way to differentiate between a variadic template intended for=
=20
> some other purpose and an object that you want to be constructed from an=
=20
> arbitrary list of values=20
>
=20
>
But you make a comment in this post that this is not such good from=20
user-prespective, to have such diffrenecation in class.


> =20
>
Of course this code needs allocator support (std::allocator_arg should be=
=20
>> used), but this
>> is doable.
>>
>> This will of course make writing an STL-like container even harder, but=
=20
>> the allocator support
>> and exception safety already make this a really hrd task so that should=
=20
>> not be a problem. Also
>> there will be some problem with ambiguity of constructor. But from the=
=20
>> user perspective the goal will
>> be achived - the vector intialization will be uniform with intialization=
=20
>> of build in arrays, even considering
>> performance.
>>
>
> There are a lot more uses for having an object with an initializer_list=
=20
> constructor than *just* an STL-compliant container type. We shouldn't=20
> make you have to go through that much effort to process *an array*.
>
> The ignore pattern may be also used.
struct ignore
{
   template<typename Ts>
   ignore(Ts&&...) {}
};=20

template<typename... Us>
vector(Us&&... us)
//some SFINAE on type of arguments.
  : _data(sizeof...(Us)),
    _size(sizeof...(Us))
{  ignore{new(_data++) T{us}....}; } //order of evalution is left-to-right.

As people have said, this is a solvable problem. We may need a new=20
> "initializer_list" type to solve it, but it can certainly be resolved und=
er=20
> the existing paradigm.
>

If the mutable_initializer_list has the same problem, then how you will=20
choose constructor to use if class have both of them? If they will be=20
ambiguous then one of them mus be SFINAE'd for non-movable/movable objects,=
=20
so if we want the class to accept an list in constructor, then that will be=
=20
still non-tribal.

--=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/.

------=_Part_2116_27550413.1376550729989
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu czwartek, 15 sierpnia 2013 01:59:13 UTC+2 u=
=BFytkownik Nicol Bolas napisa=B3:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr">On Wednesday, August 14, 2013 1:42:38 PM UTC-7, <a>t=
oma...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div=
 class=3D"gmail_quote"><div></div><div>That's ok, I don't know what the sol=
ution should be yet, perhaps<br>mutating initializer_list isn't it. The pro=
blem shouldn't be "this is how<br>initializer_lists work, don't expect brac=
ed-initializers to work differently".<br>
</div><div>I'm not supposed to KNOW there's an initializer_list involved wh=
en<br></div><div>I construct a vector from a braced list. At least I'm unde=
r the impression<br>that initializer_list was supposed to be implementation=
 plumbing<br>
rather than something that's in-my-face. And again, I don't think<br>that i=
mplementation plumbing works quite right if I can't braced-init<br>with mov=
e-only types. Other people can freely agree to disagree<br>
with that.<br>&nbsp;</div></div></div></div></blockquote><div>The std::init=
ializer_list&lt;int&gt; is only the solution of the uniform initialization =
problem,<br>not the problem itself. So while the design of initializer list=
 is perfectly valid (thanks<br>Daniel for the papers), this model failed to=
 achieve the main goal:<br><span style=3D"font-family:courier new,monospace=
"><br>Provide uniform initialization for build-in types (arrays) and<br>use=
r defined types.<br></span></div></div></blockquote><div><br>No. Uniform in=
itialization was about the copy vs. direct vs. aggregate=20
initialization paradigm. That is, providing a single way to initialize a
 type that works exactly the same in all circumstances, which can be=20
used for all types. But because it used {} syntax, it was also adopted=20
into providing a way to initialize an arbitrary object from a sequence=20
of equivalently typed parameters. But that wasn't its primary purpose.<br><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><spa=
n style=3D"font-family:courier new,monospace">That is the slogan/promotiona=
l phase for the most of materials about C++11.<br>But the initialization of=
 the vector is not uniform with the build-in arrays, which<br>is suprising =
for the users and make learning of C++ harder, not easer as <br>uniform ini=
tialization suppose to. Especially when no presentation/material know to me=
<br>on C++11 mentions this - they use the slogan.<br></span></div></div></b=
lockquote><div>&nbsp;<br>That's because it's fairly minor, all things consi=
dered. The far more eggregious issue with UI is that initializer_list const=
ructors can hide constructors that just so happen to take the same types of=
 parameters. The fact that you can't put a non-copyable type in a braced-in=
it-list that will be converted into an initializer_list is pretty minor nex=
t to hiding important constructors, thus forcing you back into () construct=
or syntax.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div><span style=3D"font-family:courier new,monospace"><b>Was anot=
her approach possible?</b><br>I think yes. To point is to not use 2-face in=
itialization and use varidatic templates instead:<br></span></div></div></b=
lockquote><div><br>Um, how does that help? It now turns something that was =
quite simple into something incredibly complex. Yes, it solves one problem,=
 but it creates many more.<br><br>It makes accidental narrowing very possib=
le. </div></div></blockquote><div>No, the constructor code itself brace-ini=
tialized constructor for every object, so the some narrowing rules will app=
ly.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>It makes the compiler errors you get for creating a braced-init-li=
st of different types much more oddball.</div></div></blockquote><div>The c=
onstructor can be SFINAE'd. The the user will see that there is no viable c=
onstructor to construct vector&lt;int&gt; from [char, string].<br>&nbsp;</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div> It c=
auses the generation of lots of pointless code, bloating compile times need=
lessly (it's a list of known size. We shouldn't have to template metaprogra=
m recurse through it). </div></div></blockquote><div>The size of every vari=
datic parameters packs is know, so your argument apply's also to them, so t=
his is a problem with lack of imperative iteration over parameters pack, no=
t initialization per-se.<br><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><div>It also conflicts with other parts of uniform=
 initialization: being able to call non-initializer_list constructors with =
braced-init-lists. Lastly, there's no way to differentiate between a variad=
ic template intended for some other purpose and an object that you want to =
be constructed from an arbitrary list of values <br></div></div></blockquot=
e><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>&nbsp;=
<br></div></div></blockquote><div>But you make a comment in this post that =
this is not such good from user-prespective, to have such diffrenecation in=
 class.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><br>&nbsp;</div></div></blockquote><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div><span style=3D"font-family:courier new,monospace"><f=
ont face=3D"arial,sans-serif">Of course this code needs allocator support (=
std::allocator_arg should be used), but this<br>is doable.<br><br>This will=
 of course make writing an STL-like container even harder, but the allocato=
r support<br>and exception safety already make this a really hrd task so th=
at should not be a problem. Also<br>there will be some problem with ambigui=
ty of constructor. But from the user perspective the goal will<br>be achive=
d - the vector intialization will be uniform with intialization of build in=
 arrays, even considering<br>performance.<br></font></span></div></div></bl=
ockquote><div><br>There are a lot more uses for having an object with an in=
itializer_list constructor than <i>just</i> an STL-compliant container type=
.. We shouldn't make you have to go through that much effort to process <i>a=
n array</i>.</div><br></div></blockquote><div>The ignore pattern may be als=
o used.<br><span style=3D"font-family: courier new,monospace;">struct ignor=
e<br>{<br>&nbsp;&nbsp; template&lt;typename Ts&gt;<br>&nbsp;&nbsp; ignore(T=
s&amp;&amp;...) {}<br>}; <br><br>template&lt;typename... Us&gt;<br>vector(U=
s&amp;&amp;... us)<br>//some SFINAE on type of arguments.<br>&nbsp; : _data=
(sizeof...(Us)),<br>&nbsp;&nbsp;&nbsp; _size(sizeof...(Us))<br>{&nbsp; igno=
re{new(_data++) T{us}....}; }</span> //order of evalution is left-to-right.=
<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><font face=3D"arial,sans-serif">As people have said, this is a solvable pr=
oblem. We may need a new "initializer_list" type to solve it, but it can ce=
rtainly be resolved under the existing paradigm.</font><br></div></blockquo=
te><div><br>If the mutable_initializer_list has the same problem, then how =
you will choose constructor to use if class have both of them? If they will=
 be ambiguous then one of them mus be SFINAE'd for non-movable/movable obje=
cts, so if we want the class to accept an list in constructor, then that wi=
ll be still non-tribal.<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_2116_27550413.1376550729989--

.

--047d7b2e4e70314e1c04e3fa4116
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Aug 14, 2013 at 10:58 PM, David Krauss <potswa@gmail.com> wrote:

>
>
> On Thursday, August 15, 2013 11:29:53 AM UTC+8, Richard Smith wrote:
>>
>> The core of the problem seems to be that initializer_list<T> does not own
>> its elements, not that the elements are immutable. If we merely made the
>> contents of the initializer_list mutable, we would break move-safety:
>>
>> initializer_list<unique_ptr<T>**> x = { a, b, c };
>> auto get() { return x; }
>> std::vector<unique_ptr<T>> v(get()); // oops, implicitly move here
>>
>
> Presuming this is supposed to go inside a class, this example is nonsense.
>

Sure, if you made a weird assumption, the example would be meaningless.
Those were top-level declarations (and just a demonstration of the problem
-- there are plenty of other ways to arrive at the same issue).

--

---
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/.

--047d7b2e4e70314e1c04e3fa4116
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 14, 2013 at 10:58 PM, David Krauss <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</s=
pan> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"im"><br><br>On Thursday, August 15, 2013 11:=
29:53 AM UTC+8, Richard Smith wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">
The core of the problem seems to be that initializer_list&lt;T&gt; does not=
 own its elements, not that the elements are immutable. If we merely made t=
he contents of the initializer_list mutable, we would break move-safety:<di=
v>
<div class=3D"gmail_quote">

<div><br></div><div>initializer_list&lt;unique_ptr&lt;T&gt;<u></u>&gt; x =
=3D { a, b, c };</div><div>auto get() { return x; }</div><div>std::vector&l=
t;unique_ptr&lt;T&gt;&gt; v(get()); // oops, implicitly move here</div></di=
v>
</div></div></blockquote></div><div><br>Presuming this is supposed to go in=
side a class, this example is nonsense.</div></div></blockquote><div><br></=
div><div>Sure, if you made a weird assumption, the example would be meaning=
less. Those were top-level declarations (and just a demonstration of the pr=
oblem -- there are plenty of other ways to arrive at the same issue).</div>
</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7b2e4e70314e1c04e3fa4116--

.

------=_Part_4795_3798399.1376610157413
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, August 15, 2013 6:51:21 PM UTC+8, Richard Smith wrote:
>
> On Wed, Aug 14, 2013 at 10:58 PM, David Krauss <pot...@gmail.com<javascript:>
> > wrote:
>
>>
>>
>> On Thursday, August 15, 2013 11:29:53 AM UTC+8, Richard Smith wrote:
>>>
>>> The core of the problem seems to be that initializer_list<T> does not
>>> own its elements, not that the elements are immutable. If we merely made
>>> the contents of the initializer_list mutable, we would break move-safety:
>>>
>>> initializer_list<unique_ptr<T>**> x = { a, b, c };
>>> auto get() { return x; }
>>> std::vector<unique_ptr<T>> v(get()); // oops, implicitly move here
>>>
>>
>> Presuming this is supposed to go inside a class, this example is nonsense.
>>
>
> Sure, if you made a weird assumption, the example would be meaningless.
> Those were top-level declarations (and just a demonstration of the problem
> -- there are plenty of other ways to arrive at the same issue).
>

For some reason my mental compiler overlooked namespace scope. Surely there
are many minor variations, but similarly silly.

Is there any practical use case of declaring initializer_list to use its
implicit array as a persistent container? Would it be such a bad thing to
simply disallow defining one except as a function argument?

As it is, initializer_list supports the usual syntax of value-semantic
objects without supporting the semantics. As the language gets richer, it
only becomes easier to fall into a trap. Is this valid C++14?

auto f() { return { 1, 2, 3 }; } // dangling reference!

This looks temptingly idiomatic. And it's similar to the very first thing I
ever tried to do with initializer_list: to return a list from a function.
(Which C++11 erroneously specified as being possible.)

Whatever functionality was agreed upon previously, its interface currently
overextends its capabilities. We should fix it or deprecate it for future
semantic redefinition.

--

---
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_4795_3798399.1376610157413
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, August 15, 2013 6:51:21 PM UTC+8, Ric=
hard Smith wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Aug 1=
4, 2013 at 10:58 PM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"javascri=
pt:" target=3D"_blank" gdf-obfuscated-mailto=3D"As0NvZ2kavsJ">pot...@gmail.=
com</a>&gt;</span> wrote:<br><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 dir=3D"ltr"><div><br><br>On Thursday, August 15, 2013 11:29:53 AM UTC+=
8, Richard Smith wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr">
The core of the problem seems to be that initializer_list&lt;T&gt; does not=
 own its elements, not that the elements are immutable. If we merely made t=
he contents of the initializer_list mutable, we would break move-safety:<di=
v>
<div class=3D"gmail_quote">

<div><br></div><div>initializer_list&lt;unique_ptr&lt;T&gt;<u></u><wbr>&gt;=
 x =3D { a, b, c };</div><div>auto get() { return x; }</div><div>std::vecto=
r&lt;unique_ptr&lt;T&gt;&gt; v(get()); // oops, implicitly move here</div><=
/div>
</div></div></blockquote></div><div><br>Presuming this is supposed to go in=
side a class, this example is nonsense.</div></div></blockquote><div><br></=
div><div>Sure, if you made a weird assumption, the example would be meaning=
less. Those were top-level declarations (and just a demonstration of the pr=
oblem -- there are plenty of other ways to arrive at the same issue).</div>=
</div></blockquote><div><br>For some reason my mental compiler overlooked n=
amespace scope. Surely there are many minor variations, but similarly silly=
..<br><br>Is there any practical use case of declaring initializer_list to u=
se its implicit array as a persistent container? Would it be such a bad thi=
ng to simply disallow defining one except as a function argument?<br><br>As=
 it is, initializer_list supports the usual syntax of value-semantic object=
s without supporting the semantics. As the language gets richer, it only be=
comes easier to fall into a trap. Is this valid C++14?<br><br>auto f() { re=
turn { 1, 2, 3 }; } // dangling reference!<br><br>This looks temptingly idi=
omatic. And it's similar to the very first thing I ever tried to do with in=
itializer_list: to return a list from a function. (Which C++11 erroneously =
specified as being possible.)<br><br>Whatever functionality was agreed upon=
 previously, its interface currently overextends its capabilities. We shoul=
d fix it or deprecate it for future semantic redefinition.<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_4795_3798399.1376610157413--

.

------=_Part_2989_22914124.1376610334628
Content-Type: text/plain; charset=ISO-8859-1



On Friday, August 16, 2013 7:42:37 AM UTC+8, David Krauss wrote:
>
>
> Whatever functionality was agreed upon previously, its interface currently
> overextends its capabilities. We should fix it or deprecate it for future
> semantic redefinition.
>

Sorry, the latter "it" referring to things like returning from a function,
declaration as a class member, and perhaps any declaration outside a
parameter list. Not deprecation of the whole class.

--

---
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_2989_22914124.1376610334628
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, August 16, 2013 7:42:37 AM UTC+8, David=
 Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><br><div>Whatever functionality was agreed upon previously, its interface =
currently overextends its capabilities. We should fix it or deprecate it fo=
r future semantic redefinition.<br></div></div></blockquote><div><br>Sorry,=
 the latter "it" referring to things like returning from a function, declar=
ation as a class member, and perhaps any declaration outside a parameter li=
st. Not deprecation of the whole class. <br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_2989_22914124.1376610334628--

.

--001a11c2c6bcb8453404e40513e8
Content-Type: text/plain; charset=ISO-8859-1

On 16 August 2013 02:42, David Krauss <potswa@gmail.com> wrote:

> As it is, initializer_list supports the usual syntax of value-semantic
> objects without supporting the semantics. As the language gets richer, it
> only becomes easier to fall into a trap. Is this valid C++14?
>
> auto f() { return { 1, 2, 3 }; } // dangling reference!
>

No, it's not valid, see
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3638.html
It's ill-formed because it would indeed create a dangling reference.

--

---
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/.

--001a11c2c6bcb8453404e40513e8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 16 August 2013 02:42, David Krauss <span dir=3D"ltr">&lt;<a href=
=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">As it is=
, initializer_list supports the usual syntax of value-semantic objects with=
out supporting the semantics. As the language gets richer, it only becomes =
easier to fall into a trap. Is this valid C++14?<br>
<div><br>auto f() { return { 1, 2, 3 }; } // dangling reference!<br></div><=
/div></blockquote><div><br></div><div>No, it&#39;s not valid, see <a href=
=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3638.html">http://=
open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3638.html</a><br>
</div><div>It&#39;s ill-formed because it would indeed create a dangling re=
ference.<br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--001a11c2c6bcb8453404e40513e8--

.

On Wed, Aug 14, 2013 at 9:19 AM, Daniel Kr=FCgler
<daniel.kruegler@gmail.com> wrote:
> MoveOnly data[] =3D { .... };
> std::vector<MoveOnly> v(std::make_move_iterator(std::begin(data)),
> std::make_move_iterator(std::end(data)));

What I don't understand is, why we need initializer_list?  Variadic
template can handle any case:

  template <typename V, typename T1>
  inline void back_pusher(V& v, T1 t1)
  {
      v.push_back(std::move(t1));
  }

  template <typename V, typename T1, typename... T2>
  inline void back_pusher(V& v, T1 t1, T2... t2)
  {
      v.push_back(std::move(t1));
      back_pusher(v, std::move(t2)...);
  }

  template <typename... T>
  inline auto make_vector(T... t)
      -> std::vector<std::common_type_t<T...>>
  {
      std::vector<std::common_type_t<T...>> v;
      back_pusher(v, std::move(t)...);
      return v;
  }

so that you can use:

    auto v =3D make_vector(std::make_unique<int>(3),
        std::make_unique<int>(12));

or

    std::string s =3D "lvalue";
    auto v =3D make_vector("rvalue", s);

--=20
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--=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/.

.

------=_Part_4664_17550927.1376611302357
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Friday, August 16, 2013 7:53:12 AM UTC+8, Zhihao Yuan wrote:
>
> On Wed, Aug 14, 2013 at 9:19 AM, Daniel Kr=FCgler=20
> <daniel....@gmail.com <javascript:>> wrote:=20
> > MoveOnly data[] =3D { .... };=20
> > std::vector<MoveOnly> v(std::make_move_iterator(std::begin(data)),=20
> > std::make_move_iterator(std::end(data)));=20
>
> What I don't understand is, why we need initializer_list?  Variadic=20
> template can handle any case:=20
>

Variadic templates are templates and each unique arity requires another=20
specialization. One initializer_list function can be exported from a link=
=20
library and yet handle any number of arguments.

It's a noble goal to improve passing arrays.

---

On Friday, August 16, 2013 7:46:03 AM UTC+8, Ville Voutilainen wrote:

> No, it's not valid, see=20
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3638.html
> It's ill-formed because it would indeed create a dangling reference.
>

So automatic deduction cannot result in invalid semantics, but explicit=20
specification can. Sucks for users with more explicit coding style.

--=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/.

------=_Part_4664_17550927.1376611302357
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, August 16, 2013 7:53:12 AM UTC+8, Zhiha=
o Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Aug 14, 2=
013 at 9:19 AM, Daniel Kr=FCgler
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
q31l8M10ke0J">daniel....@gmail.com</a>&gt; wrote:
<br>&gt; MoveOnly data[] =3D { .... };
<br>&gt; std::vector&lt;MoveOnly&gt; v(std::make_move_iterator(std:<wbr>:be=
gin(data)),
<br>&gt; std::make_move_iterator(std::<wbr>end(data)));
<br>
<br>What I don't understand is, why we need initializer_list? &nbsp;Variadi=
c
<br>template can handle any case:
<br></blockquote><div><br>Variadic templates are templates and each unique =
arity requires another specialization. One initializer_list function can be=
 exported from a link library and yet handle any number of arguments.<br><b=
r>It's a noble goal to improve passing arrays.<br><br>---<br><br>On Friday,=
 August 16, 2013 7:46:03 AM UTC+8, Ville Voutilainen wrote:<br><blockquote =
style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 20=
4); padding-left: 1ex;" class=3D"gmail_quote">No, it's not valid, see <a hr=
ef=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3638.html" targe=
t=3D"_blank">http://open-std.org/JTC1/SC22/<wbr>WG21/docs/papers/2013/n3638=
..<wbr>html</a><br>
<div class=3D"gmail_quote"><div>It's ill-formed because it would indeed cre=
ate a dangling reference.<br></div></div></blockquote><br>So automatic dedu=
ction cannot result in invalid semantics, but explicit specification can. S=
ucks for users with more explicit coding style.<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_4664_17550927.1376611302357--

.

------=_Part_100_24208677.1376998159677
Content-Type: text/plain; charset=ISO-8859-1

I would like to present for the consideration and the feedback idea of
owning_initializer_list.

*Semantics:*
The owning_intializer_list<T> should act as a wrapper for a temporary array
that is:
  - non-copyable/non-movable, that means can only by passed by reference
  - owns the elements of temporary array

*Usage:
*As the owning_intializer_list<T> can be only passed by reference, the
usage of this structure in containers would look like:
  - owning_initializer_list<T> const&
    The access to the element would be const, so the elements of the array
must be copied
  - owning_intializer_list<T>&&
    The elements of the intializer list may be moved
The both constructor will be used depended of how initializer list is
created and what kind of elements are stored
std::vector<std::string> v{"a", "b", "c"} - will use && overide
While:
const std::owning_intializer_list<std::string> l{"a", "b", "c"};
std::vector<std::string> v{l}; //will use const& overide

*Explicit ownership/lifetime semantics:
*Current implementation of the std::initializer_list<T> extends the
lifespan of the temporary array the same way as binding the
temporary to reference that means, that for:
struct A
{
  A(const int (& _t)[5])
    : t{_t} {}

  const int (& t)[5];
};

struct B
{
  B(std::initializer_list<int> _t)
    : t{_t} {}

  std::initializer_list<int> t;
};

A{{1, 2, 3, 4, 5}};
B{1, 2, 3, 4, 5};
Both A and B constructor will create a dangling reference to the temporary
array. So this only add one
more exception to remember for the programmers that want to use the
language. The proposed
owning_initializer_list<T> does not require such case, because the
reference must be used and
naturally the same lifespan expansions rules will apply, without any
exceptions.
The std::initializer_list<int> has reference semantics while value syntax
is used so this
may be error prone. The owning_initializer_list is designed to be
non-copyable/movable for that
reason.

*Optimization:
*As I understand the immutable semantics of the std::initializer_list<int>
allow
the compiler to perform optimization of the storage of initializer_list.
So instead of transforming:
std::vector<int> v{1, 2, 3, 4};
To:
const _temp[] {1, 2, 3, 4};
std::vector<v> v{std::initializer_list<int>{begin(_temp), end(_temp)}};
That may be transformed to:
static const _temp[] {1, 2, 3, 4};
std::vector<v> v{std::initializer_list<int>{begin(_temp), end(_temp)}};
So the temp object is constructed one and may be stored in ROM memory.

As I understand this kind of optimization can be only preformed if the side
effects of the construction
of elements of array are not visible to the user, so that means that it is
only applicable for types with
trivially constructible and for such kind of types there will be no benefit
from using moves. So as I understand
the:
std::vector<std::string> v{"ala", "ola", "ula"};
Cannot be optimized that way, because of user provided new?

The same optimization may be applied for owning_intializer_list<T> if T is
trivially constructible and there is const&
version.
In the case of the
std::vector<int> v{1, 2, 3, 4, 5};
The const reference overloaded may be invoked for the vector constructor
and the temporary array my created
statically.
For the non-trivial types:
std::vector<std::string> v{"ala", "ola", "ula"};
The static storage optimization may not  be used, but the && constructor
will be used and move will be possible.
And of course:
std::vector<std::unique_ptr<int>> v{ make_unique<int>(), make_unique<int>()
};

*Drawbacks:
*To allow both optimizations and move I have introduced another exception,
that for:
template<typename T>
void f(owning_initializer_list<T> const&);
template<typename T>
void f(owning_initializer_list<T>&&);

f({T{}, T{}, T{}});
May result in invocation of const& version if the T is trivially
constructible.

*std::intializer_list<T> and std::owning_initializer_list<T>:
*I think i would be enough to define constructor of
std::initializer_list<T> as
const reference to std::owning_initializer_list<T> cons& with the same
semantics
as initializer_list<T> has for array now.

*Summary:*
The owning_initializer_list<T> seems to merge benefits of initializer_list
and the moving semantics without
losing any benefits. Before going further will the ideas how to introduce
it to the standard without breking
currency code, I would like you to ask about your opinion. Am I missing
some functionalities of std::initializer_list
or making invalid assumptions.

--

---
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_100_24208677.1376998159677
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I would like to present for the consideration and the feed=
back idea of owning_initializer_list.<br><br><b>Semantics:</b><br>The ownin=
g_intializer_list&lt;T&gt; should act as a wrapper for a temporary array th=
at is:<br>&nbsp; - non-copyable/non-movable, that means can only by passed =
by reference<br>&nbsp; - owns the elements of temporary array<br><br><b>Usa=
ge:<br></b>As the owning_intializer_list&lt;T&gt; can be only passed by ref=
erence, the usage of this structure in containers would look like:<br>&nbsp=
; - owning_initializer_list&lt;T&gt; const&amp; <br>&nbsp;&nbsp;&nbsp; The =
access to the element would be const, so the elements of the array must be =
copied<br>&nbsp; - owning_intializer_list&lt;T&gt;&amp;&amp;<br>&nbsp;&nbsp=
;&nbsp; The elements of the intializer list may be moved<br>The both constr=
uctor will be used depended of how initializer list is created and what kin=
d of elements are stored<br>std::vector&lt;std::string&gt; v{"a", "b", "c"}=
 - will use &amp;&amp; overide<br>While:<br>const std::owning_intializer_li=
st&lt;std::string&gt; l{"a", "b", "c"};<br>std::vector&lt;std::string&gt; v=
{l}; //will use const&amp; overide<br><br><b>Explicit ownership/lifetime se=
mantics:<br></b>Current implementation of the std::initializer_list&lt;T&gt=
; extends the lifespan of the temporary array the same way as binding the<b=
r>temporary to reference that means, that for:<br><font face=3D"courier new=
,monospace">struct A<br>{<br>&nbsp; A(</font><font face=3D"courier new,mono=
space"><font face=3D"courier new,monospace">const int (&amp; _t)[5])<br>&nb=
sp;&nbsp;&nbsp; : t{_t} {}<br><br></font>&nbsp; const int (&amp; t)[5];<br>=
};<br><br></font><font face=3D"courier new,monospace">struct B<br>{<br>&nbs=
p; B(</font><font face=3D"courier new,monospace"><font face=3D"courier new,=
monospace">std::initializer_list&lt;int&gt; _t)<br>&nbsp;&nbsp;&nbsp; : t{_=
t} {}<br><br></font>&nbsp; std::initializer_list&lt;int&gt; t;<br>};<br><br=
>A{{1, 2, 3, 4, 5}};<br>B{1, 2, 3, 4, 5};<br><span style=3D"font-family: ar=
ial,sans-serif;">Both A and B constructor will create a dangling reference =
to the temporary array. So this only add one<br>more exception to remember =
for the programmers that want to use the language. The proposed<br>owning_i=
nitializer_list&lt;T&gt; does not require such case, because the reference =
must be used and<br>naturally the same lifespan expansions rules will apply=
, without any exceptions.<br>The std::initializer_list&lt;int&gt; has refer=
ence semantics while value syntax is used so this <br>may be error prone. T=
he owning_initializer_list is designed to be non-copyable/movable for that<=
br>reason.</span><br><br><b>Optimization:<br></b><span style=3D"font-family=
: arial,sans-serif;"><font face=3D"courier new,monospace"><span style=3D"fo=
nt-family: arial,sans-serif;">As I understand the immutable semantics of th=
e std::<font face=3D"courier new,monospace">initializer</font>_list&lt;int&=
gt; allow<br>the compiler to perform optimization of the storage of initial=
izer_list.<br>So instead of transforming:</span><br>std::vector&lt;int&gt; =
v{1, 2, 3, 4};<br><span style=3D"font-family: arial,sans-serif;">To:</span>=
<br>const _temp[] {1, 2, 3, 4};<br>std::vector&lt;v&gt; v{std::initializer_=
list&lt;int&gt;{begin(_temp), end(_temp)}};<br><span style=3D"font-family: =
arial,sans-serif;">That may be transformed to:</span><br></font></span></fo=
nt><font face=3D"courier new,monospace"><span style=3D"font-family: arial,s=
ans-serif;"><font face=3D"courier new,monospace">static const _temp[] {1, 2=
, 3, 4};<br>std::vector&lt;v&gt; v{std::initializer_list&lt;int&gt;{begin(_=
temp), end(_temp)}};</font></span></font><br>So the temp object is construc=
ted one and may be stored in ROM memory. <br><br>As I understand this kind =
of optimization can be only preformed if the side effects of the constructi=
on<br>of elements of array are not visible to the user, so that means that =
it is only applicable for types with<br>trivially constructible and for suc=
h kind of types there will be no benefit from using moves. So as I understa=
nd<br>the:<br><span style=3D"font-family: courier new,monospace;">std::vect=
or&lt;std::string&gt; v{"ala", "ola", "ula"};</span><br>Cannot be optimized=
 that way, because of user provided <span style=3D"font-family: courier new=
,monospace;">new</span>?<br><br>The same optimization may be applied for ow=
ning_intializer_list&lt;T&gt; if T is trivially constructible and there is =
const&amp;<br>version.<br>In the case of the<br><font face=3D"courier new,m=
onospace"><span style=3D"font-family: arial,sans-serif;"><font face=3D"cour=
ier new,monospace">std::vector&lt;int&gt; v{1, 2, 3, 4, 5};<br><font face=
=3D"arial,sans-serif">The const reference overloaded may be invoked for the=
 vector constructor and the temporary array my created<br>statically.<br>Fo=
r the non-trivial types:<br></font></font></span></font><span style=3D"font=
-family: courier new,monospace;">std::vector&lt;std::string&gt; v{"ala", "o=
la", "ula"};<br><font face=3D"arial,sans-serif">The static storage optimiza=
tion may not&nbsp; be used, but the &amp;&amp; constructor will be used and=
 move will be possible.<br>And of course:<br></font>std::vector&lt;std::uni=
que_ptr&lt;int&gt;&gt; v{ make_unique&lt;int&gt;(), make_unique&lt;int&gt;(=
) };</span><br><br><b>Drawbacks:<br></b>To allow both optimizations and mov=
e I have introduced another exception, that for:<br>template&lt;typename T&=
gt;<br>void f(owning_initializer_list&lt;T&gt; const&amp;);<br>template&lt;=
typename T&gt;<br>void f(owning_initializer_list&lt;T&gt;&amp;&amp;);<br><b=
r><span style=3D"font-family: courier new,monospace;">f({T{}, T{}, T{}});</=
span><br>May result in invocation of const&amp; version if the T is trivial=
ly constructible.<br><br><b>std::intializer_list&lt;T&gt; and std::owning_i=
nitializer_list&lt;T&gt;:<br></b><span style=3D"font-family: arial,sans-ser=
if;">I think i would be enough to define constructor of std::initializer_li=
st&lt;T&gt; as<br>const reference to std::owning_initializer_list&lt;T&gt; =
cons&amp; with the same semantics<br>as initializer_list&lt;T&gt; has for a=
rray now.<br></span><br><b>Summary:</b><br>The owning_initializer_list&lt;T=
&gt; seems to merge benefits of initializer_list and the moving semantics w=
ithout <br>losing any benefits. Before going further will the ideas how to =
introduce it to the standard without breking <br>currency code, I would lik=
e you to ask about your opinion. Am I missing some functionalities of std::=
initializer_list<br>or making invalid assumptions.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_100_24208677.1376998159677--

.

------=_Part_7788_14007997.1377065258845
Content-Type: text/plain; charset=ISO-8859-1

On Tuesday, August 20, 2013 7:29:19 PM UTC+8, toma...@gmail.com wrote:
>
> *std::intializer_list<T> and std::owning_initializer_list<T>:
> *I think i would be enough to define constructor of
> std::initializer_list<T> as
> const reference to std::owning_initializer_list<T> cons& with the same
> semantics
> as initializer_list<T> has for array now.
>

I like the idea of making std::initializer_list an alias template for a
const-qualified version of something else. std::initializer_list behaves as
if it were const-qualified when it is not, and no unqualified instance
should really be allowed to exist.

What's the point of non-movability?

Aside from that, I think the "owning" part is a misnomer if it remains an
accessor to an external "temporary" array. This kind of ownership doesn't
work as a return value or class member. (Return value use is possible for a
non-copyable, non-movable type if the return value is list-initialized and
bound to a reference.) It all sounds more like a proposal for mutability,
with restrictions that cover some but not all of the potential abuses of
initializer_list, and in an entirely new supplemental class instead of
addressing initializer_list directly.

--

---
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_7788_14007997.1377065258845
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, August 20, 2013 7:29:19 PM UTC+8, toma...@gmai=
l.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
b>std::intializer_list&lt;T&gt; and std::owning_initializer_list&lt;<wbr>T&=
gt;:<br></b><span style=3D"font-family:arial,sans-serif">I think i would be=
 enough to define constructor of std::initializer_list&lt;T&gt; as<br>const=
 reference to std::owning_initializer_list&lt;<wbr>T&gt; cons&amp; with the=
 same semantics<br>as initializer_list&lt;T&gt; has for array now.</span><b=
r></div></blockquote><div><br>I like the idea of making std::initializer_li=
st an alias template for a const-qualified version of something else. std::=
initializer_list behaves as if it were const-qualified when it is not, and =
no unqualified instance should really be allowed to exist.<br><br>What's th=
e point of non-movability?<br><br>Aside from that, I think the "owning" par=
t is a misnomer if it remains an accessor to an external "temporary" array.=
 This kind of ownership doesn't work as a return value or class member. (Re=
turn value use is possible for a non-copyable, non-movable type if the retu=
rn value is list-initialized and bound to a reference.) It all sounds more =
like a proposal for mutability, with restrictions that cover some but not a=
ll of the potential abuses of initializer_list, and in an entirely new supp=
lemental class instead of addressing initializer_list directly.<br></div></=
div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_7788_14007997.1377065258845--

.

------=_Part_771_10626060.1377068805363
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu =B6roda, 21 sierpnia 2013 08:07:38 UTC+2 u=BFytkownik David Krauss=
=20
napisa=B3:
>
> On Tuesday, August 20, 2013 7:29:19 PM UTC+8, toma...@gmail.com wrote:
>>
>> *std::intializer_list<T> and std::owning_initializer_list<T>:
>> *I think i would be enough to define constructor of=20
>> std::initializer_list<T> as
>> const reference to std::owning_initializer_list<T> cons& with the same=
=20
>> semantics
>> as initializer_list<T> has for array now.
>>
>
> I like the idea of making std::initializer_list an alias template for a=
=20
> const-qualified version of something else. std::initializer_list behaves =
as=20
> if it were const-qualified when it is not, and no unqualified instance=20
> should really be allowed to exist.
>
> What's the point of non-movability?
>
> Aside from that, I think the "owning" part is a misnomer if it remains an=
=20
> accessor to an external "temporary" array. This kind of ownership doesn't=
=20
> work as a return value or class member. (Return value use is possible for=
 a=20
> non-copyable, non-movable type if the return value is list-initialized an=
d=20
> bound to a reference.) It all sounds more like a proposal for mutability,=
=20
> with restrictions that cover some but not all of the potential abuses of=
=20
> initializer_list, and in an entirely new supplemental class instead of=20
> addressing initializer_list directly.
>

The point of non-movabilty and the ownership semantics is to disallow the=
=20
use of owning_initlizer_list (by value) in return type or as the class=20
member, which results in dangling reference, the dynarray<T> should be used=
=20
in such situations.

The idea is to allow the object of owning_initializer_list to be construed=
=20
only by compiler (not user). That enforces storing it in class or returning=
=20
via reference and this  fall backs to already know cases: do not return=20
reference to local object, do not store reference to temporary in class.=20
Just remove one additional exception from language.

--=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/.

------=_Part_771_10626060.1377068805363
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu =B6roda, 21 sierpnia 2013 08:07:38 UTC+2 u=
=BFytkownik David Krauss napisa=B3:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr">On Tuesday, August 20, 2013 7:29:19 PM UTC+8, <a>tom=
a...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><b>std::intializer_list&lt;T&gt; and std::owning_initializer_list&=
lt;<wbr>T&gt;:<br></b><span style=3D"font-family:arial,sans-serif">I think =
i would be enough to define constructor of std::initializer_list&lt;T&gt; a=
s<br>const reference to std::owning_initializer_list&lt;<wbr>T&gt; cons&amp=
; with the same semantics<br>as initializer_list&lt;T&gt; has for array now=
..</span><br></div></blockquote><div><br>I like the idea of making std::init=
ializer_list an alias template for a const-qualified version of something e=
lse. std::initializer_list behaves as if it were const-qualified when it is=
 not, and no unqualified instance should really be allowed to exist.<br><br=
>What's the point of non-movability?<br><br>Aside from that, I think the "o=
wning" part is a misnomer if it remains an accessor to an external "tempora=
ry" array. This kind of ownership doesn't work as a return value or class m=
ember. (Return value use is possible for a non-copyable, non-movable type i=
f the return value is list-initialized and bound to a reference.) It all so=
unds more like a proposal for mutability, with restrictions that cover some=
 but not all of the potential abuses of initializer_list, and in an entirel=
y new supplemental class instead of addressing initializer_list directly.<b=
r></div></div></blockquote><div><br>The point of non-movabilty and the owne=
rship semantics is to disallow the use of owning_initlizer_list (by value) =
in return type or as the class member, which results in dangling reference,=
 the dynarray&lt;T&gt; should be used in such situations.<br><br>The idea i=
s to allow the object of owning_initializer_list to be construed only by co=
mpiler (not user). That enforces storing it in class or returning via refer=
ence and this&nbsp; fall backs to already know cases: do not return referen=
ce to local object, do not store reference to temporary in class. Just remo=
ve one additional exception from language.<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_771_10626060.1377068805363--

.

------=_Part_331_16991989.1377075164616
Content-Type: text/plain; charset=ISO-8859-1

On Wednesday, August 21, 2013 3:06:45 PM UTC+8, toma...@gmail.com wrote:
>
> The point of non-movabilty and the ownership semantics is to disallow the
> use of owning_initlizer_list (by value) in return type or as the class
> member, which results in dangling reference, the dynarray<T> should be used
> in such situations.
>
> The idea is to allow the object of owning_initializer_list to be construed
> only by compiler (not user). That enforces storing it in class or returning
> via reference and this  fall backs to already know cases: do not return
> reference to local object, do not store reference to temporary in class.
> Just remove one additional exception from language.
>

A noble goal, but it is not accomplished by non-movability. As I mentioned,
you can use a non-movable return value by binding it to a reference. And
non-movability does nothing to hinder class membership.

http://ideone.com/sK79kR

struct nm {
    nm( int v ) {}

    nm( nm const & ) = delete; // non-copyable
    nm( nm && ) = delete; // non-movable};
 struct qc {
    nm m{ 5 }; // direct-initialization of class member} o;

nm qf() {
    return { 5 }; // direct-initialization of object in calling scope}
 void f() {
    nm && qo = qf(); // initialize a persistent local}


I think the best solution to prevent use in a function return or class
member is simply to explicitly forbid them. Besides being semantically
straightforward, such a policy suggests that implementations can honestly
give a diagnostic message simply saying "initializer_list cannot be used
here; try dynarray instead."

Also, just to note again, you have not proposed ownership semantics in the
usual C++ sense.

--

---
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_331_16991989.1377075164616
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, August 21, 2013 3:06:45 PM UTC+8, toma...@gm=
ail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>The point of non-movabilty and the ownership semantics is to disallow the =
use of owning_initlizer_list (by value) in return type or as the class memb=
er, which results in dangling reference, the dynarray&lt;T&gt; should be us=
ed in such situations.<br><div><br>The idea is to allow the object of ownin=
g_initializer_list to be construed only by compiler (not user). That enforc=
es storing it in class or returning via reference and this&nbsp; fall backs=
 to already know cases: do not return reference to local object, do not sto=
re reference to temporary in class. Just remove one additional exception fr=
om language.<br></div></div></blockquote><div><br>A noble goal, but it is n=
ot accomplished by non-movability. As I mentioned, you can use a non-movabl=
e return value by binding it to a reference. And non-movability does nothin=
g to hinder class membership.<br><br>http://ideone.com/sK79kR<br><br><pre c=
lass=3D"source" id=3D"source" style=3D"margin-bottom: 0px"><pre class=3D"de=
1"><span class=3D"kw4">struct</span> nm <span class=3D"br0">{</span>
&nbsp; &nbsp; nm<span class=3D"br0">(</span> <span class=3D"kw4">int</span>=
 v <span class=3D"br0">)</span> <span class=3D"br0">{</span><span class=3D"=
br0">}</span>
&nbsp; &nbsp;=20
&nbsp; &nbsp; nm<span class=3D"br0">(</span> nm <span class=3D"kw4">const</=
span> <span class=3D"sy3">&amp;</span> <span class=3D"br0">)</span> <span c=
lass=3D"sy1">=3D</span> <span class=3D"kw3">delete</span><span class=3D"sy4=
">;</span> // non-copyable
&nbsp; &nbsp; nm<span class=3D"br0">(</span> nm <span class=3D"sy3">&amp;&a=
mp;</span> <span class=3D"br0">)</span> <span class=3D"sy1">=3D</span> <spa=
n class=3D"kw3">delete</span><span class=3D"sy4">; // non-movable</span>
<span class=3D"br0">}</span><span class=3D"sy4">;</span>
&nbsp;
<span class=3D"kw4">struct</span> qc <span class=3D"br0">{</span>
&nbsp; &nbsp; nm m<span class=3D"br0">{</span> <span class=3D"nu0">5</span>=
 <span class=3D"br0">}</span><span class=3D"sy4">;</span> // direct-initial=
ization of class member
<span class=3D"br0">}</span> o<span class=3D"sy4">;</span>
&nbsp;
nm qf<span class=3D"br0">(</span><span class=3D"br0">)</span> <span class=
=3D"br0">{</span>
&nbsp; &nbsp; <span class=3D"kw1">return</span> <span class=3D"br0">{</span=
> <span class=3D"nu0">5</span> <span class=3D"br0">}</span><span class=3D"s=
y4">;</span> // direct-initialization of object in calling scope
<span class=3D"br0">}</span>
&nbsp;
<span class=3D"kw4">void</span> f<span class=3D"br0">(</span><span class=3D=
"br0">)</span> <span class=3D"br0">{</span>
&nbsp; &nbsp; nm <span class=3D"sy3">&amp;&amp;</span> qo <span class=3D"sy=
1">=3D</span> qf<span class=3D"br0">(</span><span class=3D"br0">)</span><sp=
an class=3D"sy4">;</span> // initialize a persistent local
<span class=3D"br0">}</span></pre></pre><br>I think the best solution to pr=
event use in a function return or class member is simply to explicitly forb=
id them. Besides being semantically straightforward, such a policy suggests=
 that implementations can honestly give a diagnostic message simply saying =
"initializer_list cannot be used here; try dynarray instead."<br><br>Also, =
just to note again, you have not proposed ownership semantics in the usual =
C++ sense.<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_331_16991989.1377075164616--

.

------=_Part_9413_28820359.1377080171033
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu =B6roda, 21 sierpnia 2013 10:52:44 UTC+2 u=BFytkownik David Krauss=
=20
napisa=B3:
>
> On Wednesday, August 21, 2013 3:06:45 PM UTC+8, toma...@gmail.com wrote:
>>
>> The point of non-movabilty and the ownership semantics is to disallow th=
e=20
>> use of owning_initlizer_list (by value) in return type or as the class=
=20
>> member, which results in dangling reference, the dynarray<T> should be u=
sed=20
>> in such situations.
>>
>> The idea is to allow the object of owning_initializer_list to be=20
>> construed only by compiler (not user). That enforces storing it in class=
 or=20
>> returning via reference and this  fall backs to already know cases: do n=
ot=20
>> return reference to local object, do not store reference to temporary in=
=20
>> class. Just remove one additional exception from language.
>>
>
> A noble goal, but it is not accomplished by non-movability. As I=20
> mentioned, you can use a non-movable return value by binding it to a=20
> reference. And non-movability does nothing to hinder class membership.
>
> http://ideone.com/sK79kR
>
> struct nm {
>     nm( int v ) {}
>    =20
>     nm( nm const & ) =3D delete; // non-copyable
>     nm( nm && ) =3D delete; // non-movable};
>  struct qc {
>     nm m{ 5 }; // direct-initialization of class member} o;
> =20
> nm qf() {
>     return { 5 }; // direct-initialization of object in calling scope}
>  void f() {
>     nm && qo =3D qf(); // initialize a persistent local}
>
>
> I think the best solution to prevent use in a function return or class=20
> member is simply to explicitly forbid them. Besides being semantically=20
> straightforward, such a policy suggests that implementations can honestly=
=20
> give a diagnostic message simply saying "initializer_list cannot be used=
=20
> here; try dynarray instead."
>
> Yes but still enabling move will not give any benefit, except of probably=
=20
misleading passing argument by value (see variable length array). Also=20
direct initialization of intialzier list in the calling scope should be=20
okay, as the temporary array will be allocated on caller scope, but moving=
=20
out will lead to dangling reference to local memory. The class member is=20
only a problem and compiler should emit error as for VLA.

Also, just to note again, you have not proposed ownership semantics in the=
=20
> usual C++ sense.
>
For my perspective the object own the array, the same way as=20
unique_ptr<int> own a allocated memory. The array handled by=20
onwning_intializer_list is costructed and destructed with the object (as=20
VLA again), but the ownership cannot be transfared,

--=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/.

------=_Part_9413_28820359.1377080171033
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu =B6roda, 21 sierpnia 2013 10:52:44 UTC+2 u=
=BFytkownik David Krauss napisa=B3:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr">On Wednesday, August 21, 2013 3:06:45 PM UTC+8, <a>t=
oma...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">The point of non-movabilty and the ownership semantics is to disal=
low the use of owning_initlizer_list (by value) in return type or as the cl=
ass member, which results in dangling reference, the dynarray&lt;T&gt; shou=
ld be used in such situations.<br><div><br>The idea is to allow the object =
of owning_initializer_list to be construed only by compiler (not user). Tha=
t enforces storing it in class or returning via reference and this&nbsp; fa=
ll backs to already know cases: do not return reference to local object, do=
 not store reference to temporary in class. Just remove one additional exce=
ption from language.<br></div></div></blockquote><div><br>A noble goal, but=
 it is not accomplished by non-movability. As I mentioned, you can use a no=
n-movable return value by binding it to a reference. And non-movability doe=
s nothing to hinder class membership.<br><br><a href=3D"http://ideone.com/s=
K79kR" target=3D"_blank">http://ideone.com/sK79kR</a><br><br><pre style=3D"=
margin-bottom:0px"><pre><span>struct</span> nm <span>{</span>
&nbsp; &nbsp; nm<span>(</span> <span>int</span> v <span>)</span> <span>{</s=
pan><span>}</span>
&nbsp; &nbsp;=20
&nbsp; &nbsp; nm<span>(</span> nm <span>const</span> <span>&amp;</span> <sp=
an>)</span> <span>=3D</span> <span>delete</span><span>;</span> // non-copya=
ble
&nbsp; &nbsp; nm<span>(</span> nm <span>&amp;&amp;</span> <span>)</span> <s=
pan>=3D</span> <span>delete</span><span>; // non-movable</span>
<span>}</span><span>;</span>
&nbsp;
<span>struct</span> qc <span>{</span>
&nbsp; &nbsp; nm m<span>{</span> <span>5</span> <span>}</span><span>;</span=
> // direct-initialization of class member
<span>}</span> o<span>;</span>
&nbsp;
nm qf<span>(</span><span>)</span> <span>{</span>
&nbsp; &nbsp; <span>return</span> <span>{</span> <span>5</span> <span>}</sp=
an><span>;</span> // direct-initialization of object in calling scope
<span>}</span>
&nbsp;
<span>void</span> f<span>(</span><span>)</span> <span>{</span>
&nbsp; &nbsp; nm <span>&amp;&amp;</span> qo <span>=3D</span> qf<span>(</spa=
n><span>)</span><span>;</span> // initialize a persistent local
<span>}</span></pre></pre><br>I think the best solution to prevent use in a=
 function return or class member is simply to explicitly forbid them. Besid=
es being semantically straightforward, such a policy suggests that implemen=
tations can honestly give a diagnostic message simply saying "initializer_l=
ist cannot be used here; try dynarray instead."<br><br></div></div></blockq=
uote><div>Yes but still enabling move will not give any benefit, except of =
probably misleading passing argument by value (see variable length array). =
Also direct initialization of intialzier list in the calling scope should b=
e okay, as the temporary array will be allocated on caller scope, but movin=
g out will lead to dangling reference to local memory. The class member is =
only a problem and compiler should emit error as for VLA.<br><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Also, just t=
o note again, you have not proposed ownership semantics in the usual C++ se=
nse.<br></div></div></blockquote><div>For my perspective the object own the=
 array, the same way as unique_ptr&lt;int&gt; own a allocated memory. The a=
rray handled by onwning_intializer_list is costructed and destructed with t=
he object (as VLA again), but the ownership cannot be transfared,<br></div>=
</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_9413_28820359.1377080171033--

.

------=_Part_24_5154535.1377109829155
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu =B6roda, 21 sierpnia 2013 10:52:44 UTC+2 u=BFytkownik David Krauss=
=20
napisa=B3:
>
> On Wednesday, August 21, 2013 3:06:45 PM UTC+8, toma...@gmail.com wrote:
>>
>> The point of non-movabilty and the ownership semantics is to disallow th=
e=20
>> use of owning_initlizer_list (by value) in return type or as the class=
=20
>> member, which results in dangling reference, the dynarray<T> should be u=
sed=20
>> in such situations.
>>
>> The idea is to allow the object of owning_initializer_list to be=20
>> construed only by compiler (not user). That enforces storing it in class=
 or=20
>> returning via reference and this  fall backs to already know cases: do n=
ot=20
>> return reference to local object, do not store reference to temporary in=
=20
>> class. Just remove one additional exception from language.
>>
>
> A noble goal, but it is not accomplished by non-movability. As I=20
> mentioned, you can use a non-movable return value by binding it to a=20
> reference. And non-movability does nothing to hinder class membership.
>
> Actually the goal can be achieved by combination of non-transferable=20
owning semantics.

The expression {a, b, c, d} in context where some intializer_list context=
=20
is available, should be considered as the expression creating object of=20
unnamed type in a similar way that lambda expression creates closure.
The unnamed object should be publicly derived from=20
owning_initializer_list<T> type, and the should be non-copyable,=20
non-movable, non-constructible, so only the constructor can create such=20
kind of objects.

The created unnamed type may look like (but it should be left to=20
implementation):
struct _unnamed : owning_initializer_list<T>
{
private:
  T elements[N]; //would actualy own elements
};

So the expression:
std::owning_initializer_list<T> v{1,2,3,4};
Would be interpreted as;
_unnamed<T> a;
std::owning_initializer_list<T> v{a};
And wont compile because owning_initializer_list is non-transferable, so no=
=20
slicing will be possible.

You will be able to pass this object to the finction via reference on=20
"store" it locally by using the life of temporary extensions:
std::owning_initializer_list<T>&& v{1,2,3,4}; //no slicing is done here

This will disallow are misuses of that object, by disallowing storing it by=
=20
value anywhere, but in the context where this was well defined you can=20
still declare it before use.
Your examples will be reduced to store by reference, and all exceptions be=
=20
removed from language.

Also will this approach the std::initializer_list<T> would be assignable=20
version of std::owning_initializer_list<T> const&;

--=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/.

------=_Part_24_5154535.1377109829155
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu =B6roda, 21 sierpnia 2013 10:52:44 UTC+2 u=
=BFytkownik David Krauss napisa=B3:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr">On Wednesday, August 21, 2013 3:06:45 PM UTC+8, <a>t=
oma...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">The point of non-movabilty and the ownership semantics is to disal=
low the use of owning_initlizer_list (by value) in return type or as the cl=
ass member, which results in dangling reference, the dynarray&lt;T&gt; shou=
ld be used in such situations.<br><div><br>The idea is to allow the object =
of owning_initializer_list to be construed only by compiler (not user). Tha=
t enforces storing it in class or returning via reference and this&nbsp; fa=
ll backs to already know cases: do not return reference to local object, do=
 not store reference to temporary in class. Just remove one additional exce=
ption from language.<br></div></div></blockquote><div><br>A noble goal, but=
 it is not accomplished by non-movability. As I mentioned, you can use a no=
n-movable return value by binding it to a reference. And non-movability doe=
s nothing to hinder class membership.<br><br></div></div></blockquote><div>=
Actually the goal can be <span id=3D"result_box" class=3D"short_text" lang=
=3D"en"><span class=3D"hps">achieved</span></span> by combination of non-tr=
ansferable owning semantics.<br><br>The expression {a, b, c, d} in context =
where some intializer_list context is available, should be considered as th=
e expression creating object of unnamed type in a similar way that lambda e=
xpression creates closure.<br>The unnamed object should be publicly derived=
 from owning_initializer_list&lt;T&gt; type, and the should be non-copyable=
, non-movable, non-constructible, so only the constructor can create such k=
ind of objects.<br><br>The created unnamed type may look like (but it shoul=
d be left to implementation):<br>struct _unnamed : owning_initializer_list&=
lt;T&gt;<br>{<br>private:<br>&nbsp; T elements[N]; //would actualy own elem=
ents<br>};<br><br>So the expression:<br>std::owning_initializer_list&lt;T&g=
t; v{1,2,3,4};<br>Would be interpreted as;<br>_unnamed&lt;T&gt; a;<br>std::=
owning_initializer_list&lt;T&gt; v{a};<br>And wont compile because owning_i=
nitializer_list is non-transferable, so no slicing will be possible.<br><br=
>You will be able to pass this object to the finction via reference on "sto=
re" it locally by using the life of temporary extensions:<br>std::owning_in=
itializer_list&lt;T&gt;&amp;&amp; v{1,2,3,4}; //no slicing is done here<br>=
<br>This will disallow are misuses of that object, by disallowing storing i=
t by value anywhere, but in the context where this was well defined you can=
 still declare it before use.<br>Your examples will be reduced to store by =
reference, and all exceptions be removed from language.<br><br>Also will th=
is approach the std::initializer_list&lt;T&gt; would be assignable version =
of std::owning_initializer_list&lt;T&gt; const&amp;;<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_24_5154535.1377109829155--

.

------=_Part_890_28558716.1377278091051
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, August 14, 2013 12:50:47 PM UTC+2, toma...@gmail.com wrote:
>
> The std::initializer_list<T> is defined as a non-owning handle to a const
> array of the T elements placed probably on stack, with requires from
>  containers constructor to copy the elements into container. This lead for
> usability problem, especially in generic programming.
>
> The most common example of usage of std::initializer_list is to write:
>   std::vector<int> v{1,2,3,4};
> instead of:
>   std::vector<int> v; v.reserve(4);
>   v.emplace_back(1);
>   v.emplace_back(2);
>   v.emplace_back(3);
>   v.emplace_back(4);
> There is not difference between this two codes, because the copy and move
> constructor of int does not differ.
>
> It can be easy fixed by helper class:

template<typename T>
class make_vector
{
    std::vector<T> data;
public:
    template<typename... A>
    inline make_vector(A&&... a)
    {
        data.reserve(sizeof...(A));
        auto f = {(data.emplace_back(std::forward<A>(a)), 0)...}; //hack to
reduce code size
    }

    operator std::vector<T>() { return std::move(data); }
};

int main()
{
    std::vector<std::unique_ptr<int>> v = make_vector<std::unique_ptr<int>>
    {
        std::unique_ptr<int>(new int{1}),
        std::unique_ptr<int>(new int{2}),
        std::unique_ptr<int>(new int{4}),
    };
    for(auto& i : v)
        std::cout<< *i << "\n";
}


--

---
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_890_28558716.1377278091051
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, August 14, 2013 12:50:47 PM UTC+2, t=
oma...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr">The std::initializer_list&lt;T&gt; is defined as a non-owning han=
dle to a const array of the T elements placed probably on stack, with requi=
res from<br>&nbsp;containers constructor to copy the elements into containe=
r. This lead for usability problem, especially in generic programming.<br><=
br>The most common example of usage of std::initializer_list is to write:<b=
r><span style=3D"font-family:courier new,monospace">&nbsp; std::vector&lt;i=
nt&gt; v{1,2,3,4};</span><br>instead of:<br><span style=3D"font-family:cour=
ier new,monospace">&nbsp; std::vector&lt;int&gt; v; v.reserve(4);<br>&nbsp;=
 v.emplace_back(1);<br>&nbsp; v.emplace_back(2);<br>&nbsp; v.emplace_back(3=
);<br>&nbsp; v.emplace_back(4);</span><br>There is not difference between t=
his two codes, because the copy and move constructor of int does not differ=
..<br><br></div></blockquote><div>It can be easy fixed by helper class:<br><=
div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bo=
rder-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; wor=
d-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettypri=
nt"><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">template</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> make_vector<br></span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>&nbsp; &nbsp; std</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">vector</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
data</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">public</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">...</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> A</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">inline</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> make_vector</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">A</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&amp;&amp;...</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> a</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&n=
bsp; &nbsp; </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nb=
sp; &nbsp; &nbsp; &nbsp; data</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">reserve</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">si=
zeof</span><span style=3D"color: #660;" class=3D"styled-by-prettify">...(</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">A</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">));</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nb=
sp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> f </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">{(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">data</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">emplace_back</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">forwa=
rd</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">A</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">&gt;(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">a</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">)),</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">0</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">)...};</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">//hack to reduce code size</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>&nbsp; &nbsp; <br>&nbsp; &nbsp; </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">operator</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">vector</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&gt;()</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">move</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">data</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> main</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>&nbsp; &nbsp; std</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">vector</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:=
:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">unique_pt=
r</span><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;int&g=
t;</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> v </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> make_vector</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">unique_ptr</span><span style=3D"color: #080;" c=
lass=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; std</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">unique_ptr</span><span style=3D"co=
lor: #080;" class=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">new</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">int</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">{</span><span style=3D"color: #066;" class=3D"styled-by-prettify"=
>1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">}),</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbs=
p; &nbsp; &nbsp; std</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">unique_ptr</span><span style=3D"color: #080;" class=3D"styled-by-prettify=
">&lt;int&gt;</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">new</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">2</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">}),</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; std</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">unique_ptr</span><span style=3D"co=
lor: #080;" class=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">new</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">int</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">{</span><span style=3D"color: #066;" class=3D"styled-by-prettify"=
>4</span><span style=3D"color: #660;" class=3D"styled-by-prettify">}),</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbs=
p; </span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbs=
p; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">for</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> i </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> v</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; std</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">cout</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">&lt;&lt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
i </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;&lt;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #080;" class=3D"styled-by-prettify">"\n"</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span></div></code></div><br><br></div></div=
>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_890_28558716.1377278091051--

.