This question gets asked from time to time. As far as I know, the answer is still that 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, 2.

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 <> wrote:


    std::vector<std::unique_ptr<Widget>> v = {
    };  // 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[] = {
    }; // OK

We're therefore back in a situation where std::vector cannot be
initialized like a C array, something we wanted to fix with

The design paper for initializer_list, 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];

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

Std-Proposals mailing list

Brian Bi