[cfe-dev] RFC: Nullability qualifiers

[Jonathan Schleifer]

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.

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.

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.

> 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 :).

--
Jonathan