2
int main(){
  using T = int[2];
  T arr = T{1,2};
}

Clang and GCC both rejected the example. However, according to
dcl.dcl#dcl.init.general-15.9

Otherwise, the initial value of the object being initialized is the (possibly converted) value of the initializer expression. A standard conversion sequence ([conv]) will be used, if necessary, to convert the initializer expression to the cv-unqualified version of the destination type; no user-defined conversions are considered. If the conversion cannot be done, the initialization is ill-formed. When initializing a bit-field with a value that it cannot represent, the resulting value of the bit-field is implementation-defined.

basic.lval#1.2

A prvalue is an expression whose evaluation initializes an object or computes the value of an operand of an operator, as specified by the context in which it appears, or an expression that has type cv void.

There's no restriction in the standard that forbids the example.The result object arr should be initialized by the prvalue. Why do all compilers reject this example?

It is a bit different with Assignment to array in C++17, here is talking about initialization

xmh0511
  • 7,010
  • 1
  • 9
  • 36
  • Didn't you already ask like two other questions, where the answer basically boils down to "arrays aren't normal types?" – Nicol Bolas Apr 09 '21 at 14:20
  • @NicolBolas Where's the relevant rule that restricts array cannot initialized by a prvalue? If it were, why `T&& arr_ref = T{1,2}` is ok? It's weird. – xmh0511 Apr 09 '21 at 14:24
  • `T&&` is a reference, no copy, just an alias. – Jarod42 Apr 09 '21 at 14:24
  • @Jarod42 Yes, but the prvalue would initialized the result object which is bound to the reference. – xmh0511 Apr 09 '21 at 14:25
  • @S.M. If a relevant rule could be cited here, it's sufficient to Persuade me. – xmh0511 Apr 09 '21 at 14:27
  • 1
    @xmh0511: "*Where's the relevant rule*" Here's a question: why does it matter? Arrays in C++ do not work like regular objects; that's just how it is. Unless you're trying to write a standards proposal to make them work like regular objects, determining the exact parameters and mechanisms by which this happens isn't really useful. Just stop trying to use arrays like objects and use `std::array` whenever possible/practical. – Nicol Bolas Apr 09 '21 at 14:29
  • @NicolBolas Actually, you mean that it can be considered a defect in the current standard, as well as the similar question in https://stackoverflow.com/questions/57439129/assignment-to-array-in-c17. I think it is more difficult to refute than in that question by using the current wording. As I mentioned in the above comment, a prvalue can be used to initialize a temporary that is created by materialization conversion but it cannot be used to initialize an object by a declaration. It's not intuitively. – xmh0511 Apr 09 '21 at 14:35
  • The condition for bullet 15.5 is exhaustive. You never fall into 15.9. – T.C. Apr 09 '21 at 21:37
  • @T.C. 15.5 just say that the destination type is an array and the initializer is parenthesized expression-list, it didn't say other cases would be ill-formed. So, why cannot fall into 15.9? – xmh0511 Apr 10 '21 at 01:27
  • "and the initializer is parenthesized expression-list" is not part of the condition. – T.C. Apr 10 '21 at 01:28
  • @T.C. "Let x1...xk be the elements of the expression-list. " There's no expression-list here. Moreover, [expr.type.conv](https://eel.is/c++draft/expr.type.conv) *Otherwise, the expression is a prvalue of the specified type whose result object is direct-initialized with the initializer* where the initializer in this case is `{1,2}`, which is aggregate initialization. – xmh0511 Apr 10 '21 at 01:39
  • That doesn't mean you get to fall through into the next bullet and below. – T.C. Apr 10 '21 at 01:52
  • @T.C. It didn't say that *Otherwise, the program is ill-formed* – xmh0511 Apr 10 '21 at 01:55

0 Answers0