Does the Objective-C compiler actually warn you if it thinks that you may be passing nil
to a parameter marked with _Nonnull
?
Or is it merely a hint to whatever tool converts between Swift and Objective-C to better deal with Swift optionals?
On its own, there is warning only in the extremely trivial case: when you pass nil
to a function accepting _Nonnull
value.
NSObject* _Nonnull test(NSObject* _Nonnull) {
test(nil); // warning
NSObject* _Nullable f = nil;
test(f); // no warning (passing _Nullable to _Nonnull), only warn in static analysis
NSObject* _Nonnull g = [[NSObject alloc] init];
g = nil; // no warning (!) (assigning nil to _Nonnull)
if (g != nil) { // no warning (unnecessary '!= nil' comparison)
test(g);
}
return nil; // no warning (returning nil to _Nonnull)
}
(There is a -Wnullable-to-nonnull-conversion
flag but it doesn't seem to have any effect to the code above.)
As documented, the three attributes will not change the behavior of the code:
ā¦ Note that, unlike the declaration attribute
nonnull
, the presence of_Nonnull
does not imply that passing null is undefined behavior:fetch
is free to consider null undefined behavior or (perhaps for backward-compatibility reasons) defensively handle null.
Beyond the compiler, it will also help the static analyzer, but again clang's static analyzer will only catch the trivial case where it knows for sure you are assigning a nil
to a _Nonnull
(i.e. the test(f)
example above).
Nevertheless, it is still useful to mark a pointer _Nonnull
/_Nullable
as