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

Type of an enumerator inside the declaration of its enumeration - a conflict #1845

Closed
h0nzZik opened this issue Nov 23, 2017 · 1 comment
Closed

Comments

@h0nzZik
Copy link

h0nzZik commented Nov 23, 2017

I believe that [expr.prim.id.qual]/4

A nested-name-specifier that denotes an enumeration (10.2), followed by the name of an enumerator of that enumeration, is a qualified-id that refers to the enumerator. The result is the enumerator. The type of the result is the type of the enumeration. The result is a prvalue.

is in conflict with [dcl.enum]/5

Each enumeration defines a type that is different from all other types. Each enumeration also has an underlying type. The underlying type can be explicitly specified using an enum-base. For a scoped enumeration type, the underlying type is int if it is not explicitly specified. In both of these cases, the underlying type is said to be fixed. Following the closing brace of an enum-specifier, each enumerator has the type of its enumeration. If the underlying type is fixed, the type of each enumerator prior to the closing brace is the underlying type and the constant-expression in the enumerator-definition shall be a converted constant expression of the underlying type (8.20). [...]

in this example:

enum class E {
    A,
    B = E::A // what is the type of E::A?
};

The clang and gcc seem to follow [dcl.enum]/5. The two parts would not be in conflict if the [expr.prim.id.qual]/4 said:

[...] The type of the result is the type of the enumerator. [...]

It was discussed on StackOverflow a few months ago.

@tkoeppe
Copy link
Contributor

tkoeppe commented Nov 23, 2017

This does not appear editorial. This should be filed as a technical issue, for which this repository is the wrong place (see https://github.com/cplusplus/draft/blob/master/README.rst for directions).

However, I believe @zygoloid is already working on this particular problem.

@tkoeppe tkoeppe closed this as completed Nov 23, 2017
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

2 participants