[cfe-dev] RFC: Nullability qualifiers

[Douglas Gregor]

Sent from my iPhone

On Jun 14, 2015, at 8:31 AM, Jonathan Schleifer <js at webkeks.org> wrote:

>> Nullability Qualifiers
>> We propose the addition of a new set of type qualifiers,  spelled __nullable, __nonnull, and __null_unspecified, to Clang. These are collectively known as nullability qualifiers and may be written anywhere any other type qualifier may be written (such as const) on any type subject to the following restrictions:
> 
> __nonnull is already used by glibc headers. Can you please use a different name so that we don't have the __block situation all over again? And, hopefully, do that before everybody using the beta has already changed their code to use __nonnull and thus making it too late to change it?

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. 

> As this seems to be a general problem (Apple introducing language extensions that work fine on OS X/iOS but breaking glibc), maybe it would make sense to not enable any language extensions when Clang can detect it's a (g)libc header? Or would it maybe be possible that you use _Foo instead __foo for your language extensions? The C standard reserves both for the compiler and libc, however, glibc only seems to use __foo. So, maybe change this to _Nonnull and _Nullable?

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. 

  - Doug