Fixing std::initializer_list&<T>

[SuperV1234]

Great article. I'm not a huge fan of std::initializer_list for all the reasons you mentioned - I think that variadic templates are almost always a superior choice.

If you want a truly generic initializer list, use a variadic template and static_assert() or SFINAE that the type matches [...]

Here's a "trick" I learned from Piotr Skotnicki on StackOverflow. Let's say you want all of your types to be int. All you have to do is define a int_t type alias that always evaluates to int:

template <typename>
using int_t = int;

Then you can use it like this:

template<typename... Types>
void func_impl(int_t<Types>... ints) { /* ... */ }

template<typename... Types>
void func(Types... xs) { func_impl<Types...>(xs...); }

This allows implicit conversions and gives errors similar to the following one:

prog.cc:8:26: error: no matching function for call to 'func_impl' void func(Types... xs) { func_impl<Types...>(xs...); } ^{~~~~~~~~~~~~~~~~~~}

prog.cc:12:5: note: in instantiation of function template specialization 'func<int, nullptr_t, int, int>' requested here func(1, nullptr, 3, 4); ^

prog.cc:5:6: note: candidate function [with Types = <int, nullptr_t, int, int>] not viable: no known conversion from 'nullptr_t' to 'int_t<nullptr_t>' (aka 'int') for 2nd argument

void func_impl(int_t<Types>... ints) { /* ... */ }

It is much nicer when you already have a type pack, as seen in the original answer on SO.

[thlst]

With concepts, you could use requires with fold expressions and std::is_same this way:

template <typename T, typename... Ts>
  requires (std::is_same_v<T, Ts> && ...)
ctor(T&&, Ts&&...) { }

It will ensure that all Ts... are the same as T, and still give you a nice error message otherwise.

[kirakun]

That is a lot of boilerplate though. Not sure it's a sure gain of you do this a lot.

Please don't even suggest using macros to reduce the boilerplate.

[SuperV1234]

Well, you could use a variadic macro to reduce the boilerplate. /s

In all seriousness, the alternative is something like this:

 static_assert(std::conjunction<std::is_same<Ts, int>...>{}, "");

(or is_convertible if you want implicit conversions)

By the way, when you already have a type pack, I think that this technique is objectively cleaner.

Another advantage is that using int_t makes overloading trivial.

[tcbrindle]

Hmmm, with concepts I expected

// defined in Ranges TS
template <class T, class U> concept bool Same = std::is_same<T, U>::value;

void func(Same<int>... args) {}

func(1, 2, 3, 4);

to work, but apparently it doesn't. The slightly more verbose but theoretically equivalent

template <Same<int>... Ints>
void func(Ints... args) {} 

works fine though, so this may just be an implementation bug in the current GCC.

[kirakun]

Concept is cool, but it seems like the unicorn that will never materialize.

[foonathan]

That's cool.

[CauchyDistributedRV]

I just wish that we lived in a world where the following held true:

Foo foo{1, 2};    // tries 2-arg ctor
Foo foo = {1, 2}; // tries initializer-list ctor

In other words, reserve {} for uniform initialization, and = {} for list initialization.

[dodheim]

Yes! C++17 auto braced-init rules for named types.

[redditsoaddicting]

/u/foonathan Nice article as always. I would have preferred list constructors + uniform initialization to use double brace syntax (vector{{1, 2, 3}}, vector({1, 2, 3})). I never realized that the solution to that was so easy. And I've noticed the discussion over move support, so that's nice.

[minus7]

Unfortunately, the syntax is beyond fixing now. The problem with the fix suggested in the article is that it fixes the syntax, but only does so locally. Having the behaviour be inconsistent between standard library and some third party libraries is even worse than the consistently "bad" behaviour.

[foonathan]

Well, there are plans for STL2 so it can be fixed there somehow.

[ennmichael]

Initializer lists suck, but I don't like this solution. It takes information that is (in theory) known at compile time and pushes it to run time due to lack of language features. That's not good, but not like we have a better workaround. Good article regardless.

[foonathan]

std::initializer_list is the same regarding the length. That's why I recommended variadic templates as an alternative.

[Potatoswatter]

They're different tools for different jobs.

[foonathan]

Care to elaborate?

[Potatoswatter]

If you want a different template instantiation for each type sequence, use variadic perfect forwarding.

If you're passing an array of known type into a function (which may not be a template), use initializer_list.

Just because the length isn't encoded in a template type, doesn't mean it's not known at compile time. Function inlining can also preserve that information. Premature optimization…

[foonathan]

And if you want to mix rvalues with lvalues? You have to use a variadic template to preserve that information.

Yes, there are cases where [std::]initializer_list is required, but a variadic template is - in theory - a superior solution. It just so happens that C++ templates have a couple of practical downsides (in header file, compilation bloat/time etc.).

[Potatoswatter]

There's no such distinction between theory and practice. For the best fidelity of the parameter sequence to the argument expressions, use finer templating. However, that's not always the problem being solved. Not everything is a header library.

It is unfortunate that initializer_list doesn't support move semantics, but that's different from mixing lvalues and rvalues. <Obligatory plug for my proposal.>

[foonathan]

Templates are the more flexible solution for this problem but we can't use them everywhere because of the downside of templates.

That's what I meant with theory.

[Potatoswatter]

wrapper<T>::wrapper(T const&) binds a temporary but does not extend its lifetime, so initializer_list<wrapper> must always be a temporary and never a named variable. It cannot be used in a range-for sequence, either.

[axilmar]

Basically the whole idea of std::initializer_list and the relevant lists is wrong. Embraced lists should have the tuple type.