------=_Part_100_30180816.1376477447397
Content-Type: text/plain; charset=ISO-8859-1

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.

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.

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


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)

The first one will be used only in situations when the intializer list was
declared before, the second one will allow to move the
values of list element (instead of coping) to the container so the
move-only objects will work, and performance penalty will be
lowered for std::string cases (3 constructor, 3 moves). The move of the
elements will be safe because of the change in the semantic
of the list, to own the elements (non-other list depends of them).

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

--

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

<div dir=3D"ltr">The std::initializer_list&lt;T&gt; is defined as a non-own=
ing handle to a const array of the T elements placed probably on stack, wit=
h requires from<br>&nbsp;containers constructor to copy the elements into c=
ontainer. This lead for usability problem, especially in generic programmin=
g.<br><br>The most common example of usage of std::initializer_list is to w=
rite:<br><span style=3D"font-family: courier new,monospace;">&nbsp; std::ve=
ctor&lt;int&gt; v{1,2,3,4};</span><br>instead of:<br><span style=3D"font-fa=
mily: courier 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.emp=
lace_back(3);<br>&nbsp; v.emplace_back(4);</span><br>There is not differenc=
e between this two codes, because the copy and move constructor of int does=
 not differ.<br><br>The problem start to begin when we start to use the non=
-movable types (ex. locks). The following code:<br>&nbsp; std::vector&lt;st=
d::unique_ptr&lt;int&gt;&gt; v{ make_unique&lt;int&gt;(), make_unique&lt;in=
t&gt;() };<br>Does not work because the copy constructor is required to cop=
y elements from initializer_list and such <br>constructor does not exist fo=
r unique_ptr. So not all types of vector can be uniformly initialized.<br><=
br>Furthermore the use of the initializer list incur unnecessary performanc=
e penalty, please consider:<br>std::vector&lt;std::string&gt; v{ "ala", "ol=
a", "ula" };<br>This initialization requires construction of the 6 string o=
bjects - 3 for initializer_list and 3 for copies in vector.<br><br>This 2 p=
roblems makes the usage of uniform intialization of container questionalabl=
e especially in generic code.<br><br><br>The problem itself make be solved =
by changing the initializer_list to be owning, non-copyable, non-movable ha=
ndle for the <br>array. The the vector, should have 2 constructors:<br>&nbs=
p; 1. vector(std::initializer_list&lt;T&gt; cons&amp; list)<br>&nbsp; 2. ve=
ctor(std::initializer_list&lt;T&gt; &amp;&amp; list)<br><br>The first one w=
ill be used only in situations when the intializer list was declared before=
, the second one will allow to move the<br>values of list element (instead =
of coping) to the container so the move-only objects will work, and perform=
ance penalty will be <br>lowered for std::string cases (3 constructor, 3 mo=
ves). The move of the elements will be safe because of the change in the se=
mantic<br>of the list, to own the elements (non-other list depends of them)=
..<br><br>Probably it is to late to make such a change, and the initializer_=
list will&nbsp; not take move into account.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_100_30180816.1376477447397--

.