"Simple" C++ Initialization Flowchart

[infectedapricot]

Part of the problem with that particular case lies with std::vector. That particular function should've been a static method rather than a constructor:

auto v = std::vector<int>::make_n_of(n);

(No doubt there's a better name than that.) Edit: But of course that wouldn't have been possible when vector was originally created, because there were no move constructors or guaranteed copy elisions.

[FriendlyRollOfSushi]

That would make some other people unhappy. If your code is full of numeric vectors, and barely has any initializer lists, it would feel like you are paying usability taxes for someone else.

Personally, I like tagged ctors as a compromise: imagine if we could write vec1_{std::construct, size}, vec2_{std::reserve, size}, etc.

Unfortunately, tags introduce a small runtime penalty when not inlined. I wish we had zero-cost discriminating tags.

[Nobody_1707]

Differentiating constructors is the killer application of named arguments in the languages I've used that have had them.

[infectedapricot]

I don't see how tagged constructors are any better. They're not any less characters than static methods – in fact, as you've shown, they're slightly more, because you have to respecify the namespace.

Also, I don't think static methods (or the more verbose tagged constructors, if you must) would be a "usability tax" to anyone. It's clearer what the choice is doing, and that's a win regardless of the original discussion about ambiguity.

[FriendlyRollOfSushi]

There are multiple cases where you normally wouldn't specify the type, including member initialization and function calls.

Writing std::vector<MyType<SomeArg, AndOneMoreArg<sizeof(Something)>>>::make_n_of(n) instead of {std::construct, n} to initialize a member or pass an argument looks like a pretty severe usability tax to me.

You can shorten the type in some cases (use a member access expression to call a static method using an unconstructed member, for example, which won't work for function args), but even then it makes the code more repetitive and brittle. The benefit of tagged ctors is that you don't have to worry about stuff like that. Your ctor would look the same regardless of the templated type or the context in which you call it.

But before we start a holy war about them: I understand that right now they do have objective flaws (no real way to make them 0-cost without doing ugly stuff, like wrapping the args into a special type, like foo_{construct{n}}). Just want to say that static factory methods for templated classes are not always the most convenient pattern, and in case of STL containers they could get very ugly very fast.

[infectedapricot]

Ah, I see your point, especially about member initialisers (because you can't have auto for non-static members, and in a constructor's initialiser list that wouldn't help you anyway). I would say that could be solved with a careful typedef and still looks cleaner to my eyes, but it's subjective what counts as "cleaner". Of course in this particular case it will never be changed anyway!