96 lines
3.1 KiB
Markdown
96 lines
3.1 KiB
Markdown
# 23. `Option<T>` et `Nullable<T>`
|
|
|
|
## 23.1 Deux concepts distincts — V1 REQUIS — FIGÉ EN PRINCIPE
|
|
|
|
`Option<T>` et `Nullable<T>` ne sont ni des alias ni deux syntaxes pour la même idée.
|
|
|
|
`Option<T>` exprime une absence sémantique explicite : une valeur est présente (`Some`) ou absente (`None`). Il est conceptuellement un type algébrique Core disponible pour tout `T` compatible avec les autres règles du langage.
|
|
|
|
```text
|
|
Option<int32>
|
|
Option<String>
|
|
Option<MyStruct>
|
|
Option<MyClass>
|
|
```
|
|
|
|
La forme canonique de l'absence est qualifiée :
|
|
|
|
```text
|
|
Option<MyClass>::None
|
|
```
|
|
|
|
`Nullable<T>` exprime au contraire qu'un type `T` possède une représentation nulle admissible dans le modèle mémoire/ABI. Il n'ajoute pas une absence métier générique à n'importe quel type.
|
|
|
|
La forme canonique de la valeur nulle est :
|
|
|
|
```text
|
|
Nullable<MyClass>::Null
|
|
```
|
|
|
|
Le mot étranger `null` reste réservé/interdit comme identifiant mais n'a aucune sémantique Saselang. `Null` n'est pas une valeur globale magique.
|
|
|
|
La syntaxe nullable courte :
|
|
|
|
```text
|
|
T?
|
|
```
|
|
|
|
est rejetée. Saselang utilise explicitement `Nullable<T>`.
|
|
|
|
## 23.2 Composition — V1 REQUIS — FIGÉ
|
|
|
|
Les compositions suivantes sont distinguées explicitement :
|
|
|
|
```text
|
|
Option<Nullable<MyClass>> autorisé
|
|
Nullable<Option<MyClass>> interdit
|
|
Nullable<Nullable<MyClass>> interdit
|
|
```
|
|
|
|
`Option<Nullable<MyClass>>` peut représenter trois états sémantiquement distincts :
|
|
|
|
```text
|
|
Option::None
|
|
Option::Some(Nullable<MyClass>::Null)
|
|
Option::Some(instance non nulle)
|
|
```
|
|
|
|
`Nullable<Option<T>>` est interdit parce qu'`Option<T>` est un type algébrique qui possède déjà sa propre sémantique d'absence et n'est pas une cible intrinsèquement nullable.
|
|
|
|
`Nullable<Nullable<T>>` est interdit car il n'ajoute aucun état représentationnel utile.
|
|
|
|
Une optimisation physique éventuelle d'`Option<T>` utilisant une niche n'altère jamais cette sémantique et ne rend pas `Option<T>` nullable au niveau du langage.
|
|
|
|
## 23.3 Types admissibles pour `Nullable<T>` — V1 REQUIS — À FINALISER AVEC LE MODÈLE MÉMOIRE
|
|
|
|
`Nullable<T>` est autorisé uniquement lorsque `T` possède réellement une représentation nulle admissible selon le modèle mémoire/ABI Saselang.
|
|
|
|
Les catégories exactes doivent être fermées avec la mémoire et la FFI. Elles pourront notamment concerner des références de classes, raw pointers ou certains handles natifs, sans rendre automatiquement nullables les primitives numériques, `bool`, `char`, structs arbitraires ou types algébriques.
|
|
|
|
La distinction fondamentale est déjà figée :
|
|
|
|
```text
|
|
Option<T> absence sémantique
|
|
Nullable<T> nullabilité représentationnelle
|
|
```
|
|
|
|
## 23.4 Patterns et valeurs explicites — V1 REQUIS — FIGÉ EN PRINCIPE
|
|
|
|
`Option<T>` s'intègre naturellement au `match` par ses variantes :
|
|
|
|
```text
|
|
match (value) {
|
|
Option::Some(uint32 number) => {
|
|
...
|
|
}
|
|
|
|
Option::None => {
|
|
...
|
|
}
|
|
}
|
|
```
|
|
|
|
Aucune absence n'est produite implicitement par `if`, `match` ou `emit`.
|
|
|
|
`Option<Void>` et `Nullable<Void>` sont interdits conformément au statut spécial de `Void`.
|