Rationale (March, 2011):

In consideration of the arguments made in issue 1232, CWG agreed to allow array temporaries and there is thus no reason to prohibit them in this case.

Proposed resolution (November, 2010):

Change 9.4.4 [dcl.init.ref] paragraph 5 as follows:

• ...

• If the initializer expression is a string literal (5.13.5 [lex.string]), the program is ill-formed.

• Otherwise, a temporary of type...

(See also issue 1232, which argues in favor of allowing array temporaries.)

Notes from the November, 2010 meeting:

The CWG agreed that the current wording appears to permit this example but still felt that array temporaries are undesirable. Wording should be added to disallow this usage.

Note (October, 2010):

Although in general an object of array type cannot be initialized from another object of array type, there is special provision in 9.4.3 [dcl.init.string] for doing so when the source object is a string literal, as in this example. The issue is thus being reopened for further consideration in this light.

Rationale (August, 2010):

The Standard does not describe initialization of array temporaries, so a program that requires such is ill-formed.

According to the logic in 9.4.4 [dcl.init.ref] paragraph 5, the following example should create a temporary array and bind the reference to that temporary:

    const char (&p)[10] = "123";

That is presumably not intended (issue 450 calls a similar outcome for rvalue arrays “implausible”). Current implementations reject this example.