[cfe-dev] Keyword warnings in libc++'s type_traits and other headers

[M.E. O'Neill]

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 (17.6.4.3.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.

    M.E.O.