C++ Logo

std-proposals

Advanced search

Re: initializer_list vs. move semantics breaks uniform initialization

From: Brian Bi <bbi5291_at_[hidden]>
Date: Fri, 15 Nov 2019 14:12:14 -0600
This question gets asked from time to time. As far as I know, the answer is
still that http://wg21.link/P0065 remains the most popular proposal to
allow move semantics to be used with initializer lists but the committee
still isn't convinced this is important. See Reddit threads 1
<https://www.reddit.com/r/cpp/comments/7a1o7f/why_does_stdinitializer_list_prevents_using/dp6jvlw/>,
2
<https://www.reddit.com/r/cpp/comments/8wvyvo/update_on_the_status_of_movable_initializer_lists/>
.

It's pretty strange to me, because I can think of much less important
proposals that have made it into the language.

On Fri, Nov 15, 2019 at 1:58 PM Marc Mutz via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hi,
>
> Consider
>
> std::vector<std::unique_ptr<Widget>> v = {
> std::make_unique<Widget>(1),
> std::make_unique<Widget>(2),
> }; // ERROR: call to deleted copy ctor requested
>
> which doesn't work because unique_ptr isn't copyable.
>
> This is unfortunate, because the following works as expected:
>
> std::unique_ptr<Widget> v[] = {
> std::make_unique<Widget>(1),
> std::make_unique<Widget>(2),
> }; // OK
>
> We're therefore back in a situation where std::vector cannot be
> initialized like a C array, something we wanted to fix with
> initializer_list.
>
> The design paper for initializer_list, wg21.link/N2215 has an example,
> in the Q&A section, describing a scenario where modification of an
> initializer_list's elements might backfire:
>
> int f() {
> Odd_vector<int> = {1, 2, 3};
> return v[0];
> };
> f();
> f();
> f();
>
> If Odd_vector's ctor changed the first element in the initializer_list,
> then subsequent calls to f() would produce different values.
>
> However, the final wording, wg21.link/N2675, binds the lifetime of the
> implicit array to the lifetime of the initializer_object:
>
> > The lifetime of the array is the same as that of the initializer_list
> > object.
>
> By this token, the array needs to be re-created for each invocation of
> f() (though there's an escape hatch by which compilers are allowed to
> store the array in read-only memory, too).
>
> I presume the paper has been written pre-move-semantics.
>
> Have there been attempts since to reconcile move semantics and
> initializer_list? Pointers welcome.
>
> Thanks,
> Marc
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>


-- 
*Brian Bi*

Received on 2019-11-15 14:14:46