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

Alp Toker alp at nuanti.com
Mon Dec 23 22:20:44 PST 2013


On 24/12/2013 05:15, Howard Hinnant wrote:
> On Dec 24, 2013, at 12:13 AM, Alp Toker <alp at nuanti.com> wrote:
>
>> On 24/12/2013 04:58, Howard Hinnant 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
>>
>> What's the breaking change you're seeing?
>>
>> Alp.
>
> If there is no breakage I see no reason for libc++ to change.
>
> Howard
>

How can we coordinate and test with you prior to introducing changes if 
you only see reason for libc++ to change after the breakage happens? 
Like you say, we need to work together.

This is a heads-up that your code may be relying on a non-standard clang 
C++ language extension which is a strict error in other compilers.

If you're asking others to to maintain that old parser workaround a 
little longer I think it's fair that you help set the schedule for its 
removal.

Alternatively, if you think a formal disambiguation rule might be worth 
investigating to place compiler type trait primitives in a separate 
namespace, we can work together to propose that too.

The one thing that doesn't make sense is to wait and do nothing until 
any proposed change goes into effect a year or two down the line.

Alp.


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




More information about the cfe-dev mailing list