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

[Dimitry Andric]

On 24 Dec 2013, at 05:58, Howard Hinnant <howard.hinnant at gmail.com> wrote:
> 
> On Dec 23, 2013, at 11:40 PM, Howard Hinnant <howard.hinnant at gmail.com> wrote:
>> On Dec 23, 2013, at 8:28 PM, Alp Toker <alp at nuanti.com> wrote:
>>> This would still conflict with the keyword in current clang versions and other compilers that don't have a quality __has_feature() implementation.
>>> 
>>> To reiterate, you'll do well to avoid the __is_* prefix entirely regardless of whether you can feature-test for individual availability of the keywords.
>> 
>> Hi Alp.  libc++ was using __is_void first.  clang needs to avoid stepping on existing identifiers too.  Get a __has_feature going and we're happy to meet you half way.  Neither clang nor libc++ has full ownership of the __namespace.  We have to share it.  It would be just as silly for us to be telling you to avoid this space because we're likely to step on you in the future.
> 
> And in the future please coordinate and test with libc++ prior to introducing breaking changes.  We need to work together.  Not reacting in this uncoordinated fashion.

Hi Howard,

The change that actually 'broke' this was r130342, which was 2 years and 7 months ago, and introduced the Embarcadero __is_xxx keywords.  From that point, those keywords were special (unfortunately, I might say, but I don't think much can be done about them).  It was r196212 by Alp which implemented the new warning, which is apparently on by default.

That said, I think it is just a fact of life some compiler vendors will continue choosing their special keywords so they clash with internal identifiers; it is best to just attempt to work around those clashes. :-)

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131224/91b4e17e/attachment.sig>