[cfe-dev] Keyword warnings in libc++'s type_traits and other headers
oneill at cs.hmc.edu
Tue Dec 24 09:57:35 PST 2013
Howard Hinnant <howard.hinnant at gmail.com> wrote:
> If there is no breakage I see no reason for libc++ to change.
The issue is partly that the C++ standard (220.127.116.11.2 [global.names]) says:
>> Certain sets of names and function signatures are always reserved to the implementation:
>> — Each name that contains a double underscore _ _ or begins with an underscore followed by an uppercase letter (2.12) is reserved to the implementation for any use.
If you see libc++ as part of "the implementation" (i.e., there is one single LLVM system that libc++ is part of), then your use of double underscores is absolutely fine (at least technically, if not practically).
If, however, you want libc++ to be usable with other compilers (e.g., GCC), the double underscores don't really belong to you. A conforming C++ compiler could reject all identifiers that begin with double underscores in code that isn't part of the compiler's own implementation. (Of course, arguably a conforming C++ compiler might not let you swap in a new standard library at all.)
But in practical terms, there is a bigger problem -- across several system-level projects, there seems to be a belief in a kind of double underscore magical thinking that goes like this: “Worried about a name clash? Here's the fix! Prefix your identifier with a double underscore and it'll be all good!!”
Various libraries do this. Glibc thinks it's a system library and has the right to all names starting with double underscores. Hence problems stemming from their using identifiers reserved by non-GCC compilers, like __block which got taken by the blocks extension from Objective-C. And it's not just Glibc, other libraries like cygwin that feel "system"ish do it too.
If you want to reduce the risk, instead of using __x and __y, you should instead use _llvm_libcxx_x and _llvm_libcxx_y. It may feel like this is a mouthful, but it's much less risky.
__You __may __think __that __such __a __change __would __detract __from __readability, __but __that __is __probably __because __you __have __become __used __to __all __the __noise __of __double __underscores __and __stopped __noticing __it. __To __other __people, __it __is __already __pretty __noisy.
Given all the tooling the LLVM project has now, it would be simple enough to have a source-to-source transformation on the libc++ headers, with their being written without underscores (or maybe even leaving them unchanged) but transforming them into a form with a consistent prefix that you can feel like you have better ownership rights over.
But probably even if you make the change, the complexities in Clang's lexer/parser will have to remain. Even if you fix libc++, there will still be plenty of other libraries out there applying double-underscore magical thinking.
More information about the cfe-dev