v0.2.18

chapters/020-operateurs.md

@@ -97,11 +97,12 @@ a ^ b
 
 Pas de NAND/NOR natifs.
 
-## 20.5 Égalité — V1 REQUIS — FIGÉ EN PRINCIPE
+## 20.5 Égalité — V1 REQUIS — FIGÉ
 
 ```text
 OpPartialEqual<Lhs,Rhs>
 OpEqual<T>
+Equatable<T>
 ```
 
 `OpEqual<T>` renforce :
@@ -118,11 +119,20 @@ symétrique
 transitive
 ```
 
-`float*` n'est pas `OpEqual` au sens strict si NaN brise la réflexivité ; il relève de l'égalité partielle.
+`Equatable<T>` est la capacité Core destinée aux APIs génériques qui ont besoin de cette égalité totale. Elle réutilise l'implémentation opérateur canonique et n'introduit ni seconde méthode `equals()` ni deuxième définition de `==` :
 
-`!=` est toujours dérivé de `==`, jamais implémenté indépendamment.
+```text
+interface Equatable<T> extends OpEqual<T> {
+}
+```
 
-Les classes ne reçoivent aucune comparaison champ-à-champ automatique : elles doivent choisir explicitement leur sémantique d'égalité si elles veulent supporter `==`.
+Ainsi, la règle générale reste inchangée : les opérateurs utilisateur sont définis uniquement via les interfaces compiler-known `Op...`, tandis que `Equatable<T>` permet d'exprimer une contrainte sémantique de haut niveau sans dupliquer l'opération.
+
+Les `float*` conservent les comparaisons IEEE de la version normative adoptée. Comme `NaN == NaN` est faux, ils ne satisfont pas directement `Equatable<float*>` et relèvent de l'égalité partielle générale.
+
+`!=` est toujours la négation logique de `==`, jamais une implémentation indépendante.
+
+Les classes ne reçoivent aucune comparaison champ-à-champ automatique : elles doivent choisir explicitement leur sémantique d'égalité si elles veulent supporter `==`. L'identité de référence universelle reste distincte et s'obtient par `Object::sameIdentity(...)`.
 
 ## 20.6 Comparaison — V1 REQUIS — FIGÉ EN PRINCIPE