-
Notifications
You must be signed in to change notification settings - Fork 12.3k
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
[C++] Accessing enumerators from a scoped member enum through operator .
triggers an error
#113844
Comments
According to [class.mem.general]/3 only enumerators of unscoped enumerations are members of the class. [expr.ref]/6.5 establishes the meaning of the member access expression only for member enumerators. However, [expr.ref]/6 also claims "Otherwise, one of the following rules applies." which doesn't seem to be true here. That looks like a defect to me. The suggested resolution for CWG 2902 would however clarify that this is ill-formed (because |
@llvm/issue-subscribers-clang-frontend Author: AndreyT (TheCalligrapher)
Here's the code sample that demonsrates the problem
All six lines that refer to enumerators from enums declared inside class
for last one (i.e. What makes it especially weird is that Clang has no problems with the qualified name in the GCC and MSVC++ have no issues with such code. |
Note that the interpretation of the rules that allows the final example would also allow: enum class E { a };
class B {} b;
E e = b.E::a; (indeed that's basically the same thing as far as the language is concerned). [expr.ref]/7.5 doesn't say what happens here, for an E2 that is a non-member enumerator, so at best this is UB. But it seems appropriate to reject, as CWG2902's suggested resolution says. |
Oh, I see. Thank you for the clarification. [class.mem.general]/3 does indeed make formal sense, even if the behavior might look "illogical" on the surface. Sorry for the false alarm. |
.
triggers an error.
triggers an error
... However, it is possible to "dump" the enumerators from a scoped enum into the class scope by means of a
With this combination of declarations Clang happily accepts
which is not surprising, since this is basically the example from But if I try referring to that
Of course, this is a weird code, but still... are both of these really supposed to be erroneous? (GCC appears to accept all these variants.) |
Here's the code sample that demonsrates the problem
All six lines that refer to enumerators from enums declared inside class
S
are perfectly valid. However, Clang issues an errorfor last one (i.e.
s.U::B
). Why?What makes it especially weird is that Clang has no problems with the qualified name in the
s.T::A
line, i.e. it does allow one to optionally use a qualified name to access enumerators from a "classic" unscoped enum (using qualified name with such enums is a possibility since C++11). However, for some unknown reason Clang rejects a similar attempt to access an enumerator from a scoped enum.GCC and MSVC++ have no issues with such code.
The text was updated successfully, but these errors were encountered: