[cfe-dev] RFC: Nullability qualifiers

[Douglas Gregor]

Sent from my iPhone

> On Jun 14, 2015, at 10:05 AM, Jonathan Schleifer <js at webkeks.org> wrote:
> 
>> Am 14.06.2015 um 18:54 schrieb Douglas Gregor <dgregor at apple.com>:
>> 
>> I hadn't noticed this, and none of the initial feedback on this feature (3-4 months ago) mentioned the collision. We made some other changes based on feedback here, but at this point, it's far too late to change the spelling of __nonnull: Apple Clang has been shipping with this feature since Xcode 6.3.
> 
> Well, Xcode 6.3 is still kind of new and I don't know how widespread the use of __nonnull in OS X / iOS code is, but I guess not much, since this has only been announced at WWDC as a feature of Xcode 7. However, I'm not really sure it's a good idea to keep it like that just because there might already be some use of it.

The use of this feature is too widespread in iOS/OS X to change the spelling there. The feature was in the Xcode 6.3 release notes, the subject of a Swift blog entry, and has been adopted in the wild. It is too late. 

> 
> How about this: Maybe we should change the name,and *in addition*, Clang on OS X / iOS keeps accepting __nonnull? This will not break any existing code and new code can use a name that has no conflicts. If this does not work for you, what would work for you and solve the problem? Since this is not only an ObjC feature, but a C feature, like it is right now, C code using it is no longer portable.

You're jumping to the conclusion that this is an unresolvable conflict and that it's the language feature that must change. We might have overlapping features, or an easy way to teach Clang to account for the differences. Creating a terminology schism has costs, too, if both uses are driving toward the same goal. 

What breaks due to this conflict?

> Also, since this is not the first time this happens, can you guys maybe add to your release guidelines to test if there are conflicts on Linux and/or other major OSes? Just grepping through glibc headers would already have prevented it and would have taken maybe a minute. Maybe as a general rule of thumb, if you use something that's reserved by the standard, check if there's anything else that can also claim it according to those reservation rules and check if it already uses that name.

Your tone here is not conducive to a productive discussion. We don't vilify vendors nor patronize it's developers here in the Clang community. Keep it civil and keep it technical. 

And, for the record, this language feature has been tested on Linux and this did not manifest as an observable problem there. 

> 
>> It's a general problem when you have different compiler and library vendors all working in the same space. Some vendor will conflict with another. It's more fun when a vendor conflicts with itself, eg, libstdc++ 4.2's __is_pod class template vs. GCC > 4.2's __is_pod type trait intrinsic, but it happens even when everything is developed in the open over years: C++11 lambda syntax is barely distinguishable from C array designated initializers and Objective-C message sends, both of which predates lambdas by a decade. With very few exceptions, we can deal with this gracefully in Clang.
> 
> Yes, I totally agree here. The standard was written under the assumption that the compiler vendor is also the library vendor. It would totally make sense to change this in the next version of C, e.g. specify _Foo is for the compiler and __foo for the libc. However, this will take quite a long while, if it ever succeeds, and won't give us a solution for now :).

You missed my point completely. 

Conflicts over syntax happen, even under the most idealized situation of well-established languages and slow-moving standards committees. We don't point fingers, we dive into the technical problem and come up with a solution. And most of the time, it's worked out quite well in Clang. 

A quick search shows that glibc is defining __nonnull as a function-like macro, so this conflict is trivial to resolve.  Is there something more I've missed that causes an actual problem?

  - Doug