[cfe-dev] RFC: Nullability qualifiers

[Jonathan Schleifer]

Am 14.06.2015 um 19:50 schrieb Douglas Gregor <dgregor at apple.com>:

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

Which is why I suggested to have __nonnull as an alias to whatever the new name would be on OS X / iOS. Can you please elaborate why that would not be a solution? All existing code will keep working.

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

I don't see where this is a problem of overlapping features. It's an issue of using a name that is already used.

> What breaks due to this conflict?

Well, there are two cases we have to look at: The case where Clang supports nullability and the case where it doesn't.

Let's start with the one that has nullability:
glibc defines __nonnull in sys/cdef.h. This will change the behavior of __nonnull to that that glibc wants. If you now want to use code that uses the __nonnull from Clang, things will not compile.

Now for the case where you don't have nullability:
You add __nonnull to your code to have the new nullability feature on OS X / iOS. Because this is not available in upstream Clang yet, you add code like:

#if !__has_feature(nullability)
# define __nonnull
# define __nullable
#endif

Now, __nonnull is already defined and thus this won't work. You might think that it's a good idea to just #undef __nonnull. However, this will break the glibc headers.

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

I don't see how my tone here is not productive - I was merely suggesting what to do to prevent this in the future, as this is not the first time of this is happening and I'm sensing a pattern here. These were suggestions to make sure this won't happen again. The whole __block thing was a real problem for quite a long while.

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

Could you share what exactly you tested? For me, even the case where your Clang doesn't support nullability fails, so I didn't even bother trying further after that, as that was already a complete blocker to using __nonnull.

> 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?

How is this trivially fixed other than changing it in glibc to have a different name? Could you please elaborate? The only other way I can think of is not making __nonnull available for system headers, which, honestly, strikes me as a bad idea as that means system headers can't define libc functions a __nonnull, which might be quite useful.

--
Jonathan