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

[Alp Toker]

On 24/12/2013 18:51, Marshall Clow wrote:
> On Dec 24, 2013, at 10:25 AM, Dimitry Andric <dimitry at andric.com> wrote:
>
>> 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.
>
> The change that introduced the __is_void, etc into libc++ was r103490, which was 3 years and 7 months ago.
> (if you want to play silly “this happened a long time ago” games)

Marshall, Howard and Dimitry,

Let's all take a step back.

Regardless of decisions that were made some time ago the fact is we 
control the standard library and the compiler today so there's no 
mistake we're stuck with and nothing we can't fix together if we set our 
minds to it :-)

Considering libc++ to be part of the implementation is one way to look 
at it there will be no unilateral removal of the hack until we find a 
way forward. I will however nudge to get a resolution because we don't 
want to keep such hacks in the parser indefinitely lest third party code 
begins to rely on broken behaviour.

Please be mindful that that compiler has very little choice as to which 
names are used for type trait primitives. Double underscores are used in 
order to stay out of the way and so far we've only ever used names which 
that are already recognised as keywords in other compilers.

libc++ on the other has the freedom to use any identifier in the global 
namespace, or indeed to use a C++ private namespace where any name goes, 
potentially letting you use short private names without any prefix or 
underscores at all.

Alp.



>
> — Marshall
>

-- 
http://www.nuanti.com
the browser experts