La différence entre les valeurs null, __nullable et _Nullable en Objective-C

Avec Xcode 6.3 il y avait de nouvelles annotations introduites pour mieux exprimer l'intention de l'API dans Objective-C (et pour assurer une meilleure Swift support de cours). Ces annotations ont été bien sûr nonnull, nullable et null_unspecified.

Mais avec Xcode 7, il y a beaucoup de mises en garde apparaissant comme:

Pointeur manque une possibilité de valeur null spécificateur de type (_Nonnull, _Nullable ou _Null_unspecified).

En plus de cela, Apple utilise un autre type de possibilité de valeur null prescripteurs, 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 différentes possibilité de valeur null annotations:

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

Même si je sais pourquoi et où l'utilisation d'annotation, je suis un peu confus par type d'annotations dois-je utiliser, où et pourquoi. C'est ce que j'ai pu recueillir:

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 des méthodes C que je devrais utiliser __nonnull, __nullable, __null_unspecified.
Pour d'autres cas, tels que les doubles pointeurs que je devrais utiliser _Nonnull, _Nullable, _Null_unspecified.

Mais je suis encore confus quant à pourquoi nous avons tellement de nombreuses annotations qui, en gros, faire la même chose.

Donc ma question est:

Quelle est la différence exacte entre ces annotations, comment mettre correctement en place, et pourquoi?

J'ai lu ce poste, mais il n'explique pas la différence et pourquoi nous avons 3 types d'annotations maintenant et j'ai vraiment envie de comprendre pourquoi ils sont allés sur l'ajout du troisième type.
Ce n'est vraiment pas aider @Cy-4AH et vous le savez. 🙂
êtes-vous sûr que vous avez lu attentivement? il explique précisément où et comment vous devez les utiliser, ce sont les états étendues, lorsque vous pouvez utiliser l'autre pour une meilleure lisibilité, des raisons de compatibilité, etc, etc... vous pourriez ne pas savoir ce que vous aimez vraiment à poser, mais la réponse est clairement sous le lien. c'est peut-être juste moi, mais je ne pense pas que toute explication supplémentaire serait nécessaire pour expliquer leur usage, de copier et de coller cette simple explication ici réponse ici serait vraiment bizarre, je suppose. 🙁
Il est clair certaines parties, mais non, je ne comprends toujours pas pourquoi nous n'avons pas que la première des annotations. Il n'explique pourquoi ils sont allés de l' __nullable à _Nullable, mais pas pourquoi avons-nous besoin _Nullable, si nous avons nullable. Et elle n'a pas d'expliquer pourquoi Apple utilise toujours __nullable dans leur propre code.

InformationsquelleAutor Legoless | 2015-09-08

134

De la clang la documentation:

La possibilité de valeur null (type) des qualificatifs de dire si une valeur d'un pointeur de type peut être nul (le _Nullable qualifier), n'ont pas une signification bien définie pour les nuls (la _Nonnull qualifier), ou pour laquelle la valeur null n'est pas claire (la _Null_unspecified qualifier). Parce que la possibilité de valeur null qualificatifs sont exprimés dans le système de type, ils sont plus générales que les nonnull et returns_nonnull attributs qui permettent de les exprimer (par exemple) nullable pointeur vers un tableau de pointeurs non. La possibilité de valeur null qualificatifs sont écrits à la droite du pointeur à laquelle ils s'appliquent.

et

En Objective-C, il y a une autre orthographe de la possibilité de valeur null qualificatifs qui peuvent être utilisés en Objective-C, les méthodes et les propriétés à l'aide contextuelle, non souligné les mots-clés

Donc pour la méthode retourne et les paramètres que vous pouvez utiliser l'
le double-souligné versions __nonnull/__nullable/__null_unspecified au lieu de l'unique souligné, ou plutôt de la non-souligné chers. La différence est que le simple et double souligné celles-ci ont besoin d'être placé à la suite de la définition de type, tandis que le non-souligné celles-ci ont besoin pour être placé à l'avant de la définition de type.

Ainsi, les déclarations suivantes sont équivalentes et sont corrects:
```
- (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
```
Mais les choses compliquer quand on double des pointeurs ou des blocs de retourner quelque chose de différent que nulle sont impliqués, comme la non-trait de soulignement sont pas autorisés ici:
```
- (void)compute:(NSError *  _Nullable * _Nullable)error
- (void)compute:(NSError *  __nullable * _Null_unspecified)error;
//and all other combinations
```
Similaire avec des méthodes qui acceptent les blocs comme des paramètres, veuillez noter que le nonnull/nullable qualificatif s'applique au bloc, et non pas son type de retour, donc les suivantes sont équivalentes:
```
- (void)executeWithCompletion:(nullable void (^)())handler
- (void)executeWithCompletion:(void (^ _Nullable)())handler
- (void)executeWithCompletion:(void (^ __nullable)())handler
```
Si le bloc a une valeur de retour, alors vous êtes forcés dans une de le trait de soulignement versions:
```
- (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 guise de conclusion, vous pouvez utiliser soit, du moment que le compilateur peut déterminer le point d'attribuer le qualificatif de.
- Il semble que le souligne versions peuvent être utilisées partout, donc je suppose que je vais utiliser de manière cohérente, plutôt que d'utiliser souligné versions dans certains endroits, et sans le trait de soulignement dans d'autres. - Il Correct?
- oui, correct, vous pouvez toujours utiliser le seul a souligné, ou le double souligné versions.
- _Null_unspecified dans Swift cela se traduit par option? non optionnel ou quoi?
- est importé dans Swift comme Implicitement Déballé en Option
- aha. Je suppose que c'est sa valeur par défaut...parce que quand j'ai ne pas spécifier j'ai été faire Implicitement déballé en option...
InformationsquelleAutor Cristik
25

De la Swift blog:

Cette fonctionnalité a été tout d'abord publié dans Xcode 6.3 avec les mots-clés
__nullable et __ _ _ non null. En raison des risques de conflits avec les bibliothèques de tiers, nous les avons modifiés dans Xcode 7 à la _Nullable et _Nonnull
vous voyez ici. Toutefois, pour assurer la compatibilité avec Xcode 6.3 nous avons
macros prédéfinies __nullable et __ _ _ non de l'étendre à de nouveaux noms.
- En un mot, le simple et le double a souligné les versions sont identiques.
- Également documenté dans Xcode 7.0 release notes: "Le double a souligné la possibilité de valeur null qualificatifs (__nullable, __non, et __ _ _ nul_non précisée) ont été renommés pour l'utilisation d'un seul trait de soulignement par une lettre majuscule:_Nullable, _Nonnull, et _Null_unspecified, respectivement). Le compilateur prédéfinit les macros de cartographie de l'ancien double-non spécifié noms pour les nouveaux noms de source de compatibilité. (21530726)"
InformationsquelleAutor Ben Thomas
22

J'ai vraiment aimé cet article, je suis donc le simple fait de montrer ce que l'auteur a écrit:
https://swiftunboxed.com/interop/objc-nullability-annotations/
- null_unspecified: ponts à une Swift implicitement-déballé en option. C'est le par défaut.
- nonnull: la valeur ne sera pas nul, les ponts à un standard de référence.
- nullable: la valeur peut être nul; ponts à une option.
- null_resettable: la valeur ne peut jamais être nul lors de la lecture, mais vous pouvez le mettre à néant pour le réinitialiser. S'applique uniquement aux propriétés.
Les notations ci-dessus, puis varier si vous les utilisez dans le contexte de propriétés ou 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;
```
InformationsquelleAutor kgaidis
12

Très pratique est
```
NS_ASSUME_NONNULL_BEGIN 
```
et de fermeture avec
```
NS_ASSUME_NONNULL_END 
```
Cela annulera la nécessité pour le niveau de code 'nullibis' 🙂 comme il sorte de logique de supposer que tout est non-nulle (ou nonnull ou _nonnull ou __nonnull), sauf indication contraire.

Malheureusement il y a des exceptions à cela aussi...
- typedefs ne sont pas supposés être __nonnull (remarque, nonnull ne semble pas fonctionner, il faut utiliser c'est laid, demi-frère)
- id * besoins explicite nullibi mais wow le péché impôts ( _Nullable id * _Nonnull <- devinez ce que cela signifie...)
- NSError ** est toujours supposé nullable
Donc, avec les exceptions aux exceptions et l'incohérence des mots-clés du déclenchement de la même fonctionnalité, peut-être l'approche est d'utiliser le laid versions __nonnull /__nullable /__null_unspecified et d'échange lorsque le compilateur se plaint... ? Peut-être que c'est pourquoi ils existent dans les headers d'Apple?

Assez intéressant, quelque chose de le mettre dans mon code... j'ai horreur des traits de soulignement dans le code (de la vieille école Apple style C++ mec) donc je suis absolument sûr que je n'ai pas de type ces, mais ils sont apparus (un exemple de plusieurs):
```
typedef void ( ^ DidReceiveChallengeBlock ) ( NSURLSessionAuthChallengeDisposition disposition,
                                          NSURLCredential * __nullable credential );
```
Et encore plus intéressant, où il a inséré l' __nullable est faux... (eek@!)

Je souhaite vraiment que je pourrais simplement utiliser le trait de soulignement version, mais apparemment ne volent pas avec le compilateur comme cela est signalé comme une erreur:
```
typedef void ( ^ DidReceiveChallengeBlock ) ( NSURLSessionAuthChallengeDisposition disposition,
                                          NSURLCredential * nonnull  credential );
```
- Non trait de soulignement ne peut être utilisé directement après une parenthèse ouvrante, c'est à dire (non ... Juste pour rendre la vie plus intéressante, j'en suis sûr.
InformationsquelleAutor William Cerniuk

Vous devez vous connecter pour publier un commentaire.