Que signifie un point d'exclamation dans le langage Swift?

Question

Le Swift Guide du langage de programmation présente l'exemple suivant:

class Person { let name: String init(name: String) { self.name = name } var apartment: Apartment? deinit { println("\(name) is being deinitialized") } } class Apartment { let number: Int init(number: Int) { self.number = number } var tenant: Person? deinit { println("Apartment #\(number) is being deinitialized") } } var john: Person? var number73: Apartment? john = Person(name: "John Appleseed") number73 = Apartment(number: 73) //From Apple's “The Swift Programming Language” guide (https://developer.Apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/AutomaticReferenceCounting.html)

Puis, lors de l'attribution de l'appartement à la personne, ils utilisent un point d'exclamation pour "décompresser l'instance":

john!.apartment = number73

Que signifie "décompresser l'instance"? Pourquoi est-ce nécessaire? En quoi est-ce différent de simplement faire ce qui suit:

john.apartment = number73

Je suis très nouveau dans la langue Swift. J'essaie juste de comprendre les bases.

UPDATE:
Le gros morceau du puzzle qui me manquait (et non pas indiqué directement dans les réponses - du moins pas au moment d'écrire ceci) est que lorsque vous procédez comme suit:

var john: Person?

cela ne signifie PAS que "john est de type Person et il pourrait être nul", comme je le pensais à l'origine. Je ne comprenais tout simplement pas que Person et Person? sont des types complètement séparés. Une fois, j’ai compris que toutes les autres ?, ! et les bonnes réponses ci-dessous avaient beaucoup plus de sens.

Ashley · Accepted Answer

Que signifie "décompresser l'instance"? Pourquoi est-ce nécessaire?

Autant que je peux m'entraîner (c'est très nouveau pour moi aussi) ...

Le terme "enveloppé" implique que nous devrions penser à une variable optionnelle comme un cadeau, enveloppée dans du papier brillant, qui pourrait (malheureusement!) Être vide .

Lorsqu'elle est "encapsulée", la valeur d'une variable optionnelle est une énumération avec deux valeurs possibles (un peu comme un booléen). Cette énumération indique si la variable contient une valeur (Some(T)) ou non (None).

S'il existe une valeur, vous pouvez l'obtenir en "dépliant" la variable (en obtenant la T de Some(T)).

En quoi john!.apartment = number73 est-il différent de john.apartment = number73? (Paraphrasé)

Si vous écrivez le nom d'une variable optionnelle (par exemple text john, sans le !), cela fait référence à l'énumération "wrapped" (Some/None), pas à la valeur elle-même (T). Donc, john n'est pas une instance de Person, et n'a pas de membre apartment:

john.apartment // 'Person?' does not have a member named 'apartment'

La valeur réelle de Person peut être décomposée de différentes manières:

"décompression forcée": john! (donne la valeur Person si elle existe, erreur d'exécution si elle est nulle)
"binding optionnelle": if let p = john { println(p) } (exécute la println si la valeur existe)
"chaining optionnel": john?.learnAboutSwift() (exécute cette méthode inventée si la valeur existe)

J'imagine que vous choisissez l'une de ces méthodes pour décompresser, en fonction de ce qui devrait se passer dans le cas zéro et de sa probabilité. Cette conception de langage oblige le cas nul à être traité explicitement, ce qui, je suppose, améliore la sécurité par rapport à Obj-C (où il est facile d’oublier de traiter le cas nul).

Mise à jour :

Le point d'exclamation est également utilisé dans la syntaxe pour déclarer "Optionsals implicitement non enveloppées".

Dans les exemples précédents, la variable john a été déclarée comme var john:Person? et il s’agit d’un Facultatif. Si vous voulez connaître la valeur réelle de cette variable, vous devez la décompresser en utilisant l’une des trois méthodes ci-dessus.

Si elle était plutôt déclarée comme var john:Person!, la variable serait une option implicitement non enveloppée (voir la section contenant cet en-tête dans le manuel d'Apple). Il n'est pas nécessaire de décompresser ce type de variable lors de l'accès à la valeur, et john peut être utilisé sans syntaxe supplémentaire. Mais le livre d'Apple dit:

Les options non implicites non enveloppées ne doivent pas être utilisées lorsqu'il est possible qu'une variable devienne nulle par la suite. Utilisez toujours un type facultatif normal si vous devez rechercher une valeur nulle pendant la durée de vie d'une variable.

Mise à jour 2 :

L'article " Intéressant Swift Caractéristiques " de Mike Ash donne une certaine motivation pour les types optionnels. Je pense que c'est bien, une écriture claire.

Mise à jour 3 :

Un autre article utile sur l'utilisation de implicitement implicite pour le point d'exclamation: " Swift and the Last Mile " de Chris Adamson. L'article explique qu'il s'agit d'une mesure pragmatique de Apple utilisée pour déclarer les types utilisés par leurs frameworks Objective-C susceptibles de contenir nil. Déclarer un type comme étant facultatif (avec ?) ou implicitement non encapsulé (avec !) est un "compromis entre sécurité et commodité". Dans les exemples donnés dans l'article, Apple ont choisi de déclarer les types implicitement non enveloppés, ce qui rend le code d'appel plus pratique, mais moins sûr.

Peut-être Apple pourrait-il explorer leurs cadres à l'avenir, en supprimant l'incertitude des paramètres implicitement non enveloppés ("probablement jamais nul") et en les remplaçant par des éléments optionnels ("pourrait certainement être nul en particulier [espérons-le, documenté!] circonstances ") ou des déclarations standard non facultatives (" n'est jamais jamais "), basées sur le comportement exact de leur code Objective-C.

Amr · Answer

Voici ce que je pense est la différence:

var john: Person?

Signifie que john peut être nul

john?.apartment = number73

Le compilateur interprétera cette ligne comme suit:

if john != nil { john.apartment = number73 }

Tandis que

john!.apartment = number73

Le compilateur interprétera cette ligne simplement:

john.apartment = number73

Par conséquent, en utilisant! va déballer l'instruction if et la faire courir plus vite, mais si john est nil, une erreur d'exécution se produira.

Donc, encapsuler ici ne signifie pas que la mémoire est encapsulée, mais que le code est encapsulé, dans ce cas, il est encapsulé avec une instruction if, et parce que Apple est très attentif aux performances d'exécution, ils veulent pour vous permettre de faire fonctionner votre application avec les meilleures performances possibles.

Mise à jour:

Revenons à cette réponse au bout de 4 ans, alors que Stackoverflow en tirait la plus haute réputation. J'ai un peu mal compris le sens de la décompression à l'époque. Maintenant, après 4 ans, je pense que le sens de la décompression est d’élargir le code à partir de sa forme compacte originale. Cela signifie également que vous devez éliminer le flou autour de cet objet, car nous ne sommes pas sûrs que, par définition, il est nul ou non. Tout comme la réponse d'Ashley ci-dessus, considérez cela comme un cadeau qui ne pourrait rien contenir. Mais je pense toujours que le déchiffrement est un déchiffrement de code et non un décompressage basé sur la mémoire comme enum.