Am I allowed to move elements out of a std::initializer_list<T>
?
#include <initializer_list>
#include <utility>
template<typename T>
void foo(std::initializer_list<T> list)
{
for (auto it = list.begin(); it != list.end(); ++it)
{
bar(std::move(*it)); // kosher?
}
}
Since std::intializer_list<T>
requires special compiler attention and does not have value semantics like normal containers of the C++ standard library, I'd rather be safe than sorry and ask.
Consider the
in<T>
idiom described on cpptruths. The idea is to determine lvalue/rvalue at run-time and then call move or copy-construction.in<T>
will detect rvalue/lvalue even though the standard interface provided by initializer_list is const reference.Not in the way that you intend. You cannot move a
const
object. Andstd::initializer_list
only providesconst
access to its elements. So the type ofit
isconst T *
.Your attempt to call
std::move(*it)
will only result in an l-value. IE: a copy.std::initializer_list
references static memory. That's what the class is for. You cannot move from static memory, because movement implies changing it. You can only copy from it.It seems not allowed in the current standard as already answered. Here is another workaround to achieve something similar, by defining the function as variadic instead of taking an initializer list.
Variadic templates can handle r-value references appropriately, unlike initializer_list.
In this example code, I used a set of small helper functions to convert the variadic arguments into a vector, to make it similar to the original code. But of course you can write a recursive function with variadic templates directly instead.
No, that won't work as intended; you will still get copies. I'm pretty surprised by this, as I'd thought that
initializer_list
existed to keep an array of temporaries until they weremove
'd.begin
andend
forinitializer_list
returnconst T *
, so the result ofmove
in your code isT const &&
— an immutable rvalue reference. Such an expression can't meaningfully be moved from. It will bind to an function parameter of typeT const &
because rvalues do bind to const lvalue references, and you will still see copy semantics.Probably the reason for this is so the compiler can elect to make the
initializer_list
a statically-initialized constant, but it seems it would be cleaner to make its typeinitializer_list
orconst initializer_list
at the compiler's discretion, so the user doesn't know whether to expect aconst
or mutable result frombegin
andend
. But that's just my gut feeling, probably there's a good reason I'm wrong.Update: I've written an ISO proposal for
initializer_list
support of move-only types. It's only a first draft, and it's not implemented anywhere yet, but you can see it for more analysis of the problem.I thought it might be instructive to offer a reasonable starting point for a workaround.
Comments inline.
This won't work as stated, because
list.begin()
has typeconst T *
, and there is no way you can move from a constant object. The language designers probably made that so in order to allow initializer lists to contain for instance string constants, from which it would be inappropriate to move.However, if you are in a situation where you know that the initializer list contains rvalue expressions (or you want to force the user to write those) then there is a trick that will make it work (I was inspired by the answer by Sumant for this, but the solution is way simpler than that one). You need the elements stored in the initialiser list to be not
T
values, but values that encapsulateT&&
. Then even if those values themselves areconst
qualified, they can still retrieve a modifiable rvalue.Now instead of declaring an
initializer_list<T>
argument, you declare aninitializer_list<rref_capture<T> >
argument. Here is a concrete example, involving a vector ofstd::unique_ptr<int>
smart pointers, for which only move semantics is defined (so these objects themselves can never be stored in an initializer list); yet the initializer list below compiles without problem.One question does need an answer: if the elements of the initializer list should be true prvalues (in the example they are xvalues), does the language ensure that the lifetime of the corresponding temporaries extends to the point where they are used? Frankly, I don't think the relevant section 8.5 of the standard addresses this issue at all. However, reading 1.9:10, it would seem that the relevant full-expression in all cases encompasses the use of the initializer list, so I think there is no danger of dangling rvalue references.