v0.2.18

chapters/027-memoire-references-et-unsafe.md

@@ -35,6 +35,18 @@ resource ownership
 thread-safety implications
 ```
 
+### 27.2.1 Backing storage stable des collections contiguës — V1 REQUIS — FIGÉ EN PRINCIPE
+
+Les abstractions sûres telles que `Slice<T>` ne doivent pas dépendre directement de l'adresse physique actuelle d'un buffer redimensionnable.
+
+Pour `Vector<T>`, V1 retient un backing storage stable/indirect : le vector et ses slices peuvent conceptuellement référencer un contrôle de stockage commun capable de relocaliser son buffer physique sans rendre les slices invalides uniquement pour cette raison.
+
+Cette exigence est sémantique, pas une structure ABI imposée. Une implémentation peut employer handle stable, indirection, contrôle partagé ou autre mécanisme sûr équivalent.
+
+Le programmeur n'observe ni l'adresse précédente ni la relocalisation, et n'utilise aucun lifetime explicite pour maintenir le stockage nécessaire vivant.
+
+La politique d'invalidation logique des slices (`append` préservé ; `insert`/`removeAt`/`clear` effectif invalidants en V1) est définie au chapitre 22 et reste distincte de la simple relocalisation physique.
+
 ## 27.3 `unsafe` — V1 REQUIS — FIGÉ EN PRINCIPE
 
 `unsafe` ne désactive pas le système de types.