Différence entre nullable, __nullable et _Nullable en Objective-C

Avec Xcode 6.3, de nouvelles annotations ont été introduites pour mieux exprimer l'intention des API en Objective-C (et pour assurer un meilleur support Swift bien sûr). Ces annotations étaient bien sûr nonnull, nullableet null_unspecified.

Mais avec Xcode 7, de nombreux avertissements apparaissent tels que:

Le pointeur n'a pas de spécificateur de type de nullabilité (_Nonnull, _Nullable ou _Null_unspecified).

En plus de cela, Apple utilise un autre type de spécificateurs de nullabilité, marquant leur code C ( source ):

CFArrayRef __nonnull CFArrayCreate(
CFAllocatorRef __nullable allocator, const void * __nonnull * __nullable values, CFIndex numValues, const CFArrayCallBacks * __nullable callBacks);

Donc, pour résumer, nous avons maintenant ces 3 annotations de nullabilité différentes:

• nonnull, nullable,null_unspecified
• _Nonnull, _Nullable,_Null_unspecified
• __nonnull, __nullable,__null_unspecified

Même si je sais pourquoi et où utiliser quelle annotation, je ne sais pas trop quel type d'annotations dois-je utiliser, où et pourquoi. Voici ce que je pourrais comprendre:

• Pour les propriétés que je devrais utiliser nonnull, nullable, null_unspecified.
• Pour les paramètres de la méthode que je devrais utiliser nonnull, nullable, null_unspecified.
• Pour les méthodes C je devrais utiliser __nonnull, __nullable, __null_unspecified.
• Pour d' autres cas, comme doubles pointeurs que je devrais utiliser _Nonnull, _Nullable, _Null_unspecified.

Mais je ne comprends toujours pas pourquoi nous avons tant d'annotations qui font essentiellement la même chose.

Ma question est donc:

Quelle est la différence exacte entre ces annotations, comment les placer correctement et pourquoi?

De la clang documentation :

Les qualificatifs de nullabilité (type) expriment si une valeur d'un type de pointeur donné peut être null (le _Nullablequalificatif), n'a pas de signification définie pour null (le _Nonnullqualificatif), ou pour lequel le but de null n'est pas clair (le _Null_unspecifiedqualificatif) . Étant donné que les qualificatifs de nullabilité sont exprimés dans le système de types, ils sont plus généraux que les attributs nonnullet returns_nonnull, ce qui permet d'exprimer (par exemple) un pointeur de type nullable vers un tableau de pointeurs non nuls. Les qualificatifs de nullité sont écrits à droite du pointeur auquel ils s'appliquent.

, et

En Objective-C, il existe une orthographe alternative pour les qualificatifs de nullabilité qui peuvent être utilisés dans les méthodes et propriétés Objective-C à l'aide de mots-clés contextuels non soulignés

Donc, pour les retours de méthode et les paramètres, vous pouvez utiliser les versions à double soulignement __nonnull/ __nullable/ __null_unspecifiedau lieu des versions à simple soulignement ou à la place des versions non soulignées. La différence est que les simples et doubles soulignés doivent être placés après la définition de type, tandis que les non soulignés doivent être placés avant la définition de type.

Ainsi, les déclarations suivantes sont équivalentes et correctes:

- (nullable NSNumber *)result
- (NSNumber * __nullable)result
- (NSNumber * _Nullable)result

Pour les paramètres:

- (void)doSomethingWithString:(nullable NSString *)str
- (void)doSomethingWithString:(NSString * _Nullable)str
- (void)doSomethingWithString:(NSString * __nullable)str

Pour les propriétés:

@property(nullable) NSNumber *status
@property NSNumber *__nullable status
@property NSNumber * _Nullable status

Les choses se compliquent cependant lorsque des doubles pointeurs ou des blocs retournant quelque chose de différent de void sont impliqués, car les non-soulignés ne sont pas autorisés ici:

- (void)compute:(NSError *  _Nullable * _Nullable)error
- (void)compute:(NSError *  __nullable * _Null_unspecified)error;
// and all other combinations

Similaire aux méthodes qui acceptent des blocs comme paramètres, veuillez noter que le qualificatif nonnull/ nullables'applique au bloc, et non à son type de retour, donc les éléments suivants sont équivalents:

- (void)executeWithCompletion:(nullable void (^)())handler
- (void)executeWithCompletion:(void (^ _Nullable)())handler
- (void)executeWithCompletion:(void (^ __nullable)())handler

Si le bloc a une valeur de retour, vous êtes forcé dans l'une des versions de soulignement:

- (void)convertObject:(nullable id __nonnull (^)(nullable id obj))handler
- (void)convertObject:(id __nonnull (^ _Nullable)())handler
- (void)convertObject:(id _Nonnull (^ __nullable)())handler
// the method accepts a nullable block that returns a nonnull value
// there are some more combinations here, you get the idea

En conclusion, vous pouvez utiliser l'un ou l'autre, tant que le compilateur peut déterminer l'élément auquel attribuer le qualificatif.

Sur le blog Swift :

Cette fonctionnalité a été publiée pour la première fois dans Xcode 6.3 avec les mots-clés __nullable et __nonnull. En raison de conflits potentiels avec des bibliothèques tierces, nous les avons modifiés dans Xcode 7 en _Nullable et _Nonnull que vous voyez ici. Cependant, pour la compatibilité avec Xcode 6.3, nous avons prédéfini des macros __nullable et __nonnull pour étendre les nouveaux noms.

J'ai vraiment aimé cet article , donc je montre simplement ce que l'auteur a écrit: https://swiftunboxed.com/interop/objc-nullability-annotations/

• null_unspecified:ponts vers un Swift implicitement déroulé en option. C'est la valeur par défaut .
• nonnull: la valeur ne sera pas nulle; ponts vers une référence régulière.
• nullable: la valeur peut être nulle; ponts à une option.
• null_resettable: la valeur ne peut jamais être nulle lors de la lecture, mais vous pouvez la définir sur nil pour la réinitialiser. S'applique uniquement aux propriétés.

Les notations ci-dessus, diffèrent alors si vous les utilisez dans le contexte de propriétés ou de fonctions / variables:

L'auteur de l'article a également fourni un bel exemple:

// property style
@property (nonatomic, strong, null_resettable) NSString *name;

// pointer style
+ (NSArray<NSView *> * _Nullable)interestingObjectsForKey:(NSString * _Nonnull)key;

// these two are equivalent!
@property (nonatomic, strong, nullable) NSString *identifier1;
@property (nonatomic, strong) NSString * _Nullable identifier2;

Très pratique est

NS_ASSUME_NONNULL_BEGIN 

et en terminant avec

NS_ASSUME_NONNULL_END 

Cela annulera le besoin du niveau de code 'nullibis' :-) car il est en quelque sorte logique de supposer que tout est non nul (ou nonnullou _nonnullou __nonnull) sauf indication contraire.

Malheureusement, il y a aussi des exceptions à cela ...

• typedefs ne sont pas supposés être __nonnull(note, nonnullne semble pas fonctionner, faut utiliser son demi-frère moche)
• id *a besoin d'un nullibi explicite mais wow le péché-tax ( _Nullable id * _Nonnull<- devinez ce que cela signifie ...)
• NSError ** est toujours supposé nullable

Donc, à l'exception des exceptions et des mots-clés incohérents suscitant la même fonctionnalité, peut-être que l'approche consiste à utiliser les versions laides __nonnull/ __nullable/ __null_unspecifiedet à échanger lorsque le complicateur se plaint ...? C'est peut-être pourquoi ils existent dans les en-têtes Apple?

Fait intéressant, quelque chose l'a mis dans mon code ... J'ai horreur des soulignements dans le code (type de style Apple C ++ de la vieille école) donc je suis absolument sûr que je ne les ai pas tapés mais ils sont apparus (un exemple parmi plusieurs):

typedef void ( ^ DidReceiveChallengeBlock ) ( NSURLSessionAuthChallengeDisposition disposition,
                                          NSURLCredential * __nullable credential );

Et encore plus intéressant, là où il a inséré le __nullable est faux ... (eek @!)

J'aimerais vraiment pouvoir utiliser la version non soulignée, mais apparemment, cela ne fonctionne pas avec le compilateur car cela est signalé comme une erreur:

typedef void ( ^ DidReceiveChallengeBlock ) ( NSURLSessionAuthChallengeDisposition disposition,
                                          NSURLCredential * nonnull  credential );