v0.2.17

chapters/020-operateurs.md

@@ -6,13 +6,15 @@ Les opérateurs utilisateur ne peuvent être fournis que via un ensemble fermé
 
 L'utilisateur ne peut pas inventer de nouveaux symboles opérateurs.
 
-Les `operator` contracts :
+Les contrats `operator` :
 
 - retournent directement leur valeur ;
 - ne retournent jamais `Result` ;
-- ne déclarent jamais `throws`.
+- ne déclarent jamais `throws` ;
+- peuvent produire des `Fault` unchecked lorsque le contrat de l'opération le prévoit ;
+- peuvent documenter ces faults par une clause `faults`.
 
-Une faute de contrat du langage peut néanmoins déclencher une faute runtime déterministe.
+Une opération dont la précondition est statiquement prouvée fausse est rejetée à la compilation lorsque la règle du langage permet cette preuve. Une violation seulement dynamique produit le `Fault` correspondant.
 
 ## 20.2 Interfaces arithmétiques — V1 REQUIS — FIGÉ
 
@@ -124,29 +126,38 @@ Les classes ne reçoivent aucune comparaison champ-à-champ automatique : elles
 
 ## 20.6 Comparaison — V1 REQUIS — FIGÉ EN PRINCIPE
 
-Core :
+Core distingue l'ordre partiel de l'ordre total :
 
 ```text
-public enum Ordering {
+public enum PartialOrdering {
     Less,
     Equal,
     Greater,
     Unordered
 }
+
+public enum Ordering {
+    Less,
+    Equal,
+    Greater
+}
 ```
 
-Interfaces :
+Interfaces opérateur :
 
 ```text
 OpPartialCompare<Lhs,Rhs>
+    -> PartialOrdering
+
 OpCompare<T>
+    -> Ordering
 ```
 
-`OpCompare<T>` renforce `OpPartialCompare<T,T>` et garantit un ordre total, donc pas de `Ordering::Unordered`.
+`OpCompare<T>` garantit un ordre total. Les floats utilisent l'ordre partiel pour leurs opérateurs généraux en raison de `NaN`; les entiers peuvent utiliser l'ordre total.
 
-Les floats utilisent l'ordre partiel ; les entiers peuvent utiliser l'ordre total.
+`Ordering::Equal` signifie équivalence dans la relation d'ordre considérée. Il ne doit pas être confondu automatiquement avec l'égalité générale `==`.
 
-Le lien exact entre égalité et comparaison pour éviter deux contrats contradictoires sur une même paire doit être verrouillé dans la spécification finale des interfaces `Op`.
+Les contrats applicatifs `Comparable<T>` et `Comparator<T>` des collections ordonnées utilisent `Ordering` et sont définis au chapitre 22.
 
 ## 20.7 Comparaisons hétérogènes — V1 REQUIS — FIGÉ EN PRINCIPE
 
@@ -187,21 +198,25 @@ D'autres index numériques pourront être supportés ultérieurement sans modifi
 
 Un type utilisateur peut utiliser n'importe quel type d'index pertinent.
 
-## 20.10 Map — V1 REQUIS — DIRECTION FIGÉE
+## 20.10 Map — V1 REQUIS — FIGÉ EN PRINCIPE
 
-Direction recommandée :
+Le contrat des maps est défini au chapitre 22.
+
+L'indexation est stricte :
 
 ```text
-Map<K,V>
-OpIndex<K,Option<V>>
-OpIndexMut<K,V>
+map[key] -> V
 ```
 
-Lecture : absent -> `None` ; présent -> `Some(value)`.
+La clé doit exister ; une absence dynamique produit `KeyNotFoundFault`.
 
-Écriture : insertion si absent, remplacement si présent.
+L'accès conditionnel est explicite et distinct :
 
-Une méthode `containsKey` peut compléter l'API sans être obligatoire avant toute lecture.
+```text
+map::get(key) -> Option<V>
+```
+
+`OpIndexMut<K,V>` remplace uniquement la valeur d'une clé existante ; l'affectation indexée n'insère jamais implicitement une nouvelle clé.
 
 ## 20.11 Affectation — V1 REQUIS — FIGÉ