Perfectly forwarding initializer_list, in cases other than any/optional/variant

[Arthur O'Dwyer]

Now that std::any, std::optional, and std::variant have blessed the idea of splitting each "perfectly forwarding emplacement function" into a pair of functions, one taking initializer_list and the other not, I wonder if there's any significant interest in retrofitting that solution onto the rest of the STL containers.

For example, to take this current wording in [forwardlist.modifiers]

template <class... Args> reference emplace_front(Args&&... args);

Effects: Inserts an object of type value_type constructed with value_type(std::forward<Args>( args)...) at the beginning of the list. 

and replace it with this wording instead:

template <class... Args> reference emplace_front(Args&&... args);

Effects: Inserts an object of type value_type constructed with value_type(std::forward<Args>( args)...) at the beginning of the list. 

Remarks: This function shall not participate in overload resolution unless is_constructible_v<T, Args...> is true.

template <class U, class... Args> reference emplace_front(initializer_list<U> il, Args&&... args);

Effects: Inserts an object of type value_type constructed with value_type(il, std::forward<Args>( args)...) at the beginning of the list. 

Remarks: This function shall not participate in overload resolution unless is_constructible_v<T, std::initializer_list<U>&, Args...> is true.

and so on for std::vector, std::list, std::deque,...
Is there a technical reason this retrofitting hasn't happened, or is it just one of those "nobody's written the paper yet" cases?

Ville's N4462 seems to be a discussion of the "how to forward initializer_list" problem in general, but AFAICT it dates from before the adoption of the two-function approach. I don't know where the two-function approach originally came from — not that I've tried very hard to find out.

–Arthur

[Ville Voutilainen]

On 27 November 2016 at 11:33, Arthur O'Dwyer <arthur....@gmail.com> wrote:
> Ville's N4462 seems to be a discussion of the "how to forward
> initializer_list" problem in general, but AFAICT it dates from before the
> adoption of the two-function approach. I don't know where the two-function
> approach originally came from — not that I've tried very hard to find out.

It's more about "how to the kind of initialization" and especially how
to forward aggregate-initialization.
Adding constructors doesn't help for types that don't have any. It was
well-known at the time of writing
that paper that some parts of the problem space can be solved by
adding constructor signatures
with initializer_list parameters, but that doesn't solve the general problem.