[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