Why C++ forbids new T[n](arg...)? - c++

Question

This question seems ancient (since C++98), but a quick search didn't lead me to an answer.
std::size_t n = 100;
std::unique_ptr<int[]> data(new int[n]); // ok, uninitialized
std::unique_ptr<int[]> data(new int[n]()); // ok, value-initialized
std::unique_ptr<int[]> data(new int[n](5)); // not allowed, but why?
What's the rationale behind this restriction, some UDTs cannot be default constructed, so those types cannot be used with new[].
Please don't go astray to suggesting something like std::vector or just say that's how the standard defines it, everyone knows that, but I want to know the reason why new T[n](arg...) is forbidden by the standard.

Answer 1

The first part of the answer to "why is it forbidden" is almost tautological: because it is not allowed by the standard. I know you probably don't like such an answer, but that's the nature of the beast, sorry.
And why should it be allowed anyway? What would it mean? In your very very very simple case, initializing every int with a specific value is fairly reasonable. But then again, for normal (statically allocated) array initialization, the rule is that each element in the right hand side {} is passed to an element of the left hand side array, with extra elements getting default-initialization treatment. Ie,
int data[n] = {5};
would only initialize the first element with 5.
But let's look at another example, which isn't even very contrived, which shows that what you ask for doesn't really make a lot of sense in a general context.
struct Foo {
int a,b,c,d;
Foo(int a=0, int b=0, int c=0, int d=0)
: a(a), b(b), c(c), d(d) {}
};
...
Foo *f = new Foo[4](1,2,3,4); // <-- what does this mean?!?!
Should there be four Foo(1,2,3,4)s? Or [Foo(1,2,3,4), Foo(), Foo(), Foo()]? Or maybe [Foo(1), Foo(2), Foo(3), Foo(4)]? Or why not [Foo(1,2,3), Foo(4), Foo(), Foo()]? What if one of Foo's arguments was rvalue reference or something? There are just soooo many cases in which there is no obvious Right Thing that the compiler should do. Most of the examples I just gave have valid use cases, and there isn't one that's clearly better than the others.
PS: You can achieve what you want with eg
std::vector<int> data(n, 5);

Answer 2

some UDTs don't even have a default ctor, so those types cannot be used with new[]
I'm not sure what you mean by this. E.g. int does not have a default constructor. However, you can initialize it as new int(3) or as new int[n](), as you already know. The event that takes place here is called initialization. Initialization can be carried out by constructors, but that's just a specific kind of initialization applicable to class types only. int is not a class type and constructors are completely inapplicable to int. So, you should not be even mentioning constructors with regard to int.
As for new int[n](5)... What did you expect to happen in this case? C++ does not support such syntax for array initialization. What did you want it to mean? You have n array elements and only one initializer. How are you proposing to initialize n array elements and only one initializer? Use value 5 to initialize each array element? But C++ never had such multi-initialization. Even the modern C++ doesn't.
You seem to have adopted this "multi-initialization" interpretation of new int[n](5) syntax as the one and only "obviously natural" way for it to behave. However, this is not necessarily that clear-cut. Historically C++ language (and C language) followed a different philosophy with regard to initializers that are "smaller" or "shorter" than the aggregate being initialized. Historically the language used the explicitly specified initializers to initialize the sub-objects at the beginning of the aggregate, while the rest of the sub-objects got default-initialized (sticking to C++98 terminology). From this point of view, you can actually see the () initializer in new int[n]() not as your "multi-initializer", but rather as an initializer only for the very first element of the array. Meanwhile, the rest of the elements get default-initialized (producing the same effect as () would). Granted, one can argue that the above logic usually applies to { ... } initializers, not to (...) initializers, but nevertheless this general design principle is present in the language.

Answer 3

It's not clear what int[n](5) would even mean. int[5]{1,2,3,4,5} is perfectly well-defined, however.
I'm going to assume you mean for int[n](...) to construct each array element in the same way with the given arguments. Your use case for such a syntax is for data types without a default constructor, but I posit that you don't actually solve that use case: that for many (most?) arrays of such types, each object needs to be constructed differently.

Answer 4

The original expectation is to allow new T[n](arg…) to call T(arg…) to initialize each element.
It turns out that people don't even agree on what new T[n](arg…) would mean.
I gather some good points from the ansnwers and comments, here's the summary:
Inconsistent meaning. parenthesized initializer is used to initialize the object, in case of an array, the only viable one is () which default initializes the array and its elements. Give T[n](arg…) a new meaning will conflict with the current meaning of parenthesized initializer.
No general way to channel the args. Consider a type T with ctor T(int, Ref&, Rval&&), and the usage new T[n](++i, ref, Rval{}). If the args is supplied literally (i.e. call T(++i, ref, Rval{}) for each), ++i will be called multiple times. If the args is supplied through some temporaries, how can you decide ref will pass by reference, while Rval{} will pass as prvalue?
In short, the syntax seems plausible but doesn't actually make sense and is not generally implementable.