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.

Sign up for GitHub

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

Jump to bottom

[expr.type.conv] doesn't define T() for T ≠ void #4566

Closed
aaronpuchert opened this issue Mar 28, 2021 · 6 comments
Closed

[expr.type.conv] doesn't define T() for T ≠ void #4566

aaronpuchert opened this issue Mar 28, 2021 · 6 comments

Comments

@aaronpuchert
Copy link

Let's go through the second paragraph point by point:

  1. "If the initializer is a parenthesized single expression, the type conversion expression is equivalent to the corresponding cast expression." This is defining T(initializer-clause) as equivalent to a C-style cast.
  2. "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." That is defining void().
  3. "Otherwise, the expression is a prvalue of the specified type whose result object is direct-initialized with the initializer." This seems to define T(expression-list) and T braced-init-list, so it defines T{} but not T() because an expression-list, unless I'm misreading something, cannot be empty.

What seems to be missing is that T() does a value initialization.
@jwakely
Copy link
Member

jwakely commented Mar 28, 2021

Because T() for non-void types is not a conversion and is defined elsewhere.

@aaronpuchert
Copy link
Author

Paragraph 1 seems to include T(): "A simple-type-specifier or typename-specifier followed by a parenthesized optional expression-list or by a braced-init-list (the initializer) constructs a value of the specified type given the initializer."

@JohelEGP
Copy link
Contributor

Paragraph 1 seems to include T(): "A simple-type-specifier or typename-specifier followed by a parenthesized optional expression-list or by a braced-init-list (the initializer) constructs a value of the specified type given the initializer."

This has been raised before. Not sure if in another issue, a CWG issue, or perhaps an r/cpp comment.

@xmh0511
Copy link
Contributor

xmh0511 commented Mar 29, 2021 •
edited

Paragraph 1 seems to include T(): "A simple-type-specifier or typename-specifier followed by a parenthesized optional expression-list or by a braced-init-list (the initializer) constructs a value of the specified type given the initializer."

Isn't that

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.

covers such a case?
And the introduction of the first paragraph indicates that

A simple-type-specifier or typename-specifier followed by a parenthesized optional expression-list

That means it could be the form T(expression-list opt).

@zygoloid
Copy link
Member

Isn't that [...] covers such a case?

Yes, I think so. For example, for int(), we say the expression is a prvalue of type int whose result object is direct-initialized with the initializer (). Then [dcl.init.general]/15.4 says that means we perform value-initialization. (Also, [dcl.init.general]/14.4 agrees that this form of initialization is direct-initialization, even though we don't hit the [dcl.init.general]/14.1 case of a parenthesized expression-list.)

I don't see a problem here.

@aaronpuchert
Copy link
Author

aaronpuchert commented Mar 30, 2021 •
edited

For example, for int(), we say the expression is a prvalue of type int whose result object is direct-initialized with the initializer (). Then [dcl.init.general]/15.4 says that means we perform value-initialization.

Thanks for the hint, [dcl.init.general]/15.4 is what I've been looking for.

Sorry for bothering you with this, I wrongly assumed that T() couldn't be direct initialization because of the vexing parse issue for declarations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@zygoloid @jwakely @aaronpuchert @xmh0511 @JohelEGP @jensmaurer