[expr.new] new-initializer is specified to be direct-initialization twice

[Endilll]

Consider [expr.new] paragraph 24:

A new-expression that creates an object of type T initializes that object as follows:
— <...>
— Otherwise, the new-initializer is interpreted according to the initialization rules of [dcl.init] for direct-initialization.

and [dcl.init] paragraph 15:

The initialization that occurs
— <...>
— for a new-initializer ([expr.new]),
— <...>
is called direct-initialization.

This seems to be a normative duplication.

Suggested resolution

Change [expr.new] paragraph 24 as follows:

A new-expression that creates an object of type T initializes that object as follows:
— <...>
— Otherwise, the new-initializer is interpreted according to the initialization rules of [dcl.init] for direct-initialization.
[ Note: In this case new-initializer follows rules for direct-initialization. — end note ]

Alternatively, the note could be omitted.

[Endilll]

Note in the suggested resolution (and, consequently, the current wording of [expr.new]/24) might not be entirely correct, because for ::new (ptr) bool() direct-initialization doesn't make sense: value-initialization takes place instead.

[ddvamp]

@Endilll What's wrong with the fact that direct-initialization is mentioned here? In many places of the standard, including those included in the definition of direct-initialization, it is also clarified. Moreover, the fact that the object here is value-initialized does not contradict that direct-initialization is taking place here. direct-initialization, like copy-initialization, are just forms (contexts), aren't they?

[Endilll]

What's wrong with the fact that direct-initialization is mentioned here? In many places of the standard, including those included in the definition of direct-initialization, it is also clarified.

I think that clarifications, if they are deemed necessary, should be done with notes and examples, and not normative text.

Moreover, the fact that the object here is value-initialized does not contradict that direct-initialization is taking place here. direct-initialization, like copy-initialization, are just forms (contexts), aren't they?

"The initialization rules of [dcl.init] for direct-initialization", in my reading, are concerned with class types and a specific case of bool(std::nullptr). Value-initialization is not included.

[ddvamp]

If I'm not mistaken, for example, in explicit type conversion (functional notation) bool() is direct-initialization, and value-initialization by further reading [dcl.init]. It seems to me that the same logic applies for new-expression.

[jensmaurer]

If a new-initializer has enough syntactic cues that [dcl.init] works for it, specifying "direct-initialization" in [expr.new] is redundant (and possibly misleading).

[ddvamp]

I would suggest a wording consistent with other places, something like

A new-expression that creates an object of type T initializes that object as follows:
— <...>
— Otherwise, the object is direct-initialized ([dcl.init]) with the new-initializer.

Although, maybe I don't understand the intentions.

[Endilll]

— Otherwise, the object is direct-initialized ([dcl.init]) with the new-initializer.

What does it mean to direct-initialize an object of type bool with the new-initializer of the form ()? Would be nice if you can provide link to the [dcl.init] wording for this.

[t3nsor]

Note that direct-initialization with empty parentheses is also invoked by https://eel.is/c++draft/expr.type.conv

[ddvamp]

What does it mean to direct-initialize an object of type bool with the new-initializer of the form ()? Would be nice if you can provide link to the [dcl.init] wording for this.

I read it like this. Unlike zero-initialization, default-initialization, and value-initialization, which are defined using the word "means", direct-initialization and copy-initialization are defined using the word "called". That is, the last two are orthogonal to the first. The former define the initialization "subprocess", while direct-initialization and copy-initialization do not define, but specify the initialization context.

[dcl.init] describes the initialization process for any syntactic context. We have a combination of initializer semantics + direct/copy initialization context, and we're looking at exactly what happens in [dcl.init.general]#16.

We have bool(), where the initialization context is direct and the initializer is (). With this in mind, we interpret the initializer and we find [dcl.init.general]#16.4 which sends us to a "subprocess" for value-initialization