------=_Part_617_843685.1379361735823
Content-Type: text/plain; charset=ISO-8859-1

Taking vector as an example, N3763 proposes to add

    template <class Traversable>
      explicit vector(Traversable&&, const Allocator& = Allocator());
    template <class Traversable>
      vector& operator=(Traversable&&);
    template <class Traversable>
      void assign(Traversable&&);
    template <class Traversable>
      iterator   insert(const_iterator position, Traversable&& range);

where a Traversable type is anything that can be iterated over in a
range-for loop.

I like this in general, but I'm surprised by the inclusion of operator=.
I would have thought that if there is no implicit conversion from one
type to another, then there shouldn't be an operator= either. This
specification allows you to write

std::vector<int> v;
v = f();

where f() is a function returning a std::list<int>. To me this seems
surprising and also a possible source of problems: for example if f()
originally returned a std::vector<int> and was later changed to return
a list, the code still compiles but has silently changed from a move
assignment to a copy. The assign() function seems a more natural way
to assign a range to a container.

Can anyone explain why adding an operator= might be the right thing
to do here?

--

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

<div dir=3D"ltr">Taking vector as an example, N3763 proposes to add<br><br>=
&nbsp;&nbsp;&nbsp; template &lt;class Traversable&gt;<br>&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; explicit vector(Traversable&amp;&amp;, const Allocator&amp; =
=3D Allocator());<br>&nbsp;&nbsp;&nbsp; template &lt;class Traversable&gt;<=
br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; vector&amp; operator=3D(Traversable&amp;&=
amp;);<br>&nbsp;&nbsp;&nbsp; template &lt;class Traversable&gt;<br>&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; void assign(Traversable&amp;&amp;);<br>&nbsp;&nbsp;&=
nbsp; template &lt;class Traversable&gt;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
iterator&nbsp;&nbsp; insert(const_iterator position, Traversable&amp;&amp; =
range);<br><br>where a Traversable type is anything that can be iterated ov=
er in a<br>range-for loop.<br><br>I like this in general, but I'm surprised=
 by the inclusion of operator=3D.<br>I would have thought that if there is =
no implicit conversion from one<br>type to another, then there shouldn't be=
 an operator=3D either. This<br>specification allows you to write<br><br>st=
d::vector&lt;int&gt; v;<br>v =3D f();<br><br>where f() is a function return=
ing a std::list&lt;int&gt;. To me this seems<br>surprising and also a possi=
ble source of problems: for example if f()<br>originally returned a std::ve=
ctor&lt;int&gt; and was later changed to return<br>a list, the code still c=
ompiles but has silently changed from a move<br>assignment to a copy. The a=
ssign() function seems a more natural way<br>to assign a range to a contain=
er.<br><br>Can anyone explain why adding an operator=3D might be the right =
thing<br>to do here?<br><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_617_843685.1379361735823--

.