Open Quuxplusone opened 13 years ago
Bugzilla Link | PR9124 |
Status | NEW |
Importance | P normal |
Reported by | Johannes Schaub (schaub.johannes@googlemail.com) |
Reported on | 2011-02-02 09:55:46 -0800 |
Last modified on | 2016-08-24 04:28:22 -0700 |
Version | trunk |
Hardware | PC Linux |
CC | dgregor@apple.com, gonzalo.gadeschi@gmail.com, llvm-bugs@lists.llvm.org, richard-llvm@metafoo.co.uk |
Fixed by commit(s) | |
Attachments | |
Blocks | |
Blocked by | |
See also |
[namespace.udecl]p7 is clear that we should diagnose this, but it's not obvious why. The functionality is useful and doesn't have any obvious semantic issues.
Johannes: Do you have a DR# for this? I couldn't find it in the issues list, and I'd like to suggest a different resolution :)
I sent this issue to WMM twice with a year of distance between each iteration,
but he did not respond -.- So there is no DR# yet.
Hello Mike,
7.3.3p7 says
A /using-declaration/ shall not name a scoped enumerator.
Presumably, this is intended to forbid the following case too.
enum A { B };
void f() { using A::B; }
However, A::B is an unscoped enumerator according to 7.2p2. It should
probably forbid the nested-name-specifier of the using-declaration to
name an enumeration, instead.
Thanks,
Johannes.
Of couse we cannot straight out forbid referring to a unscoped enumerator because it needs still to be allowed as a member declaration if the NNS is a class.
FWIW with inline variables:
static constexpr auto B = A::B;
Is safe and does the right thing.
While I would like "using A::B" to work, I would rather warn on this until this is allowed by the standard.