Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A corner case for an explicit type conversion whose type-specifier is void and the initializer is non-empty braced-init-list #4626

Open
xmh0511 opened this issue Jun 4, 2021 · 0 comments

Comments

@xmh0511
Copy link
Contributor

xmh0511 commented Jun 4, 2021

int main(){
   void{1,2}; // #1
}

This corner case seems to be ignored by the standard, there's no rule in the current draft that criticizes the example as invalid.

First, the case is permitted by the grammar

simple-type-specifier braced-init-list
The grammar does not restrict what the braced-init-list should be(must be empty or not).

From the perspective of [expr.type.conv#2], it does not cover this case

If the initializer is a parenthesized single expression, the type conversion expression is equivalent to the corresponding cast expression. Otherwise, if the type is cv void and the initializer is () or {} (after pack expansion, if any), the expression is a prvalue of type void that performs no initialization. Otherwise, the expression is a prvalue of the specified type whose result object is direct-initialized with the initializer. If the initializer is a parenthesized optional expression-list, the specified type shall not be an array type.

According to [dcl.init#general-14]

The initialization that occurs

  • in a functional notation type conversion

is called direct-initialization.

So, we will inspect [dcl.init.list] for this case. Meanwhile, [dcl.init.list#3.12] is also not suitable for this case

Otherwise, the program is ill-formed.

Since its condition is:

List-initialization of an object or reference of type T is defined as follows:

A prvalue of type void does not result in "initialization". So, it arguably says that such a corner case is not covered by the standard.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant