# 27. Mémoire, références et `unsafe` ## 27.1 GC obligatoire — REJETÉ Pas de garbage collector obligatoire pour le modèle natif Saselang. Un backend futur comme JVM peut utiliser son runtime interne à condition de préserver les garanties observables Saselang nécessaires. ## 27.2 Modèle mémoire — V1 REQUIS — À FINALISER CRITIQUE Le modèle mémoire est un bloqueur majeur de V1. Objectifs : - ergonomie ordinaire proche des langages managed ; - performances C/Rust-class lorsque possible ; - ressources déterministes ; - analyse interne ownership/move/escape possible ; - pas de syntaxe de lifetimes omniprésente ; - raw pointers explicites et unsafe. Doivent être définis : ```text value vs reference semantics object allocation moves/copies/clones borrow/reference semantics si nécessaire escape analysis lifetimes internes partial construction partial destruction cycles éventuels 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` ne doivent pas dépendre directement de l'adresse physique actuelle d'un buffer redimensionnable. Pour `Vector`, 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. Il autorise uniquement une liste fermée d'opérations dont les garanties ne sont pas prouvables automatiquement. Formes retenues : ```text unsafe { ... } unsafe func unsafe method unsafe clsmethod unsafe construct unsafe union ``` `unsafe` sur une callable décrit son contrat externe : l'appelant doit respecter des préconditions non vérifiables. Une fonction sûre peut contenir localement un bloc `unsafe` si elle rétablit ses invariants avant de retourner. Pas de modificateur général : ```text unsafe variable unsafe constant unsafe field ``` Le caractère dangereux est porté par le type/opération. ## 27.4 Pointeurs et accès mémoire bas niveau — V1 REQUIS — À FINALISER CRITIQUE Le modèle mémoire contient un sous-ensemble dédié aux pointeurs ; il ne doit pas être confondu avec les références de classe ou `Slice`. La spécification devra distinguer au minimum : ```text référence de classe accès sûr ordinaire vers un objet Slice vue sûre, bornée et contiguë sur un stockage existant pointeur Saselang adresse explicite avec contrat de type/mutabilité à définir pointeur brut / FFI accès mémoire bas niveau potentiellement unsafe function pointer représentation ABI d'une cible callable, distincte des callables/closures ordinaires ``` Les noms exacts des types (`Ptr`, `PtrMut` ou autre) restent à figer. Doivent être définis explicitement : ```text nullabilité et non-null par défaut éventuel const T pointé et constness du pointeur lui-même dereference address-of arithmétique de pointeurs alignement allocation/libération manuelles casts entre pointeurs conversion pointeur <-> entier si elle existe pointeur opaque / équivalent éventuel de void* function pointers FFI C ownership ou absence d'ownership attaché au pointeur interaction avec allocator, lifetime interne et thread safety ``` Le code ordinaire ne doit pas avoir besoin de pointeurs explicites lorsque les références de classe, arrays, slices ou autres abstractions sûres suffisent. Les opérations dangereuses doivent rester dans l'inventaire fermé `unsafe`. ## 27.5 Allocator — V1 REQUIS — À FINALISER CRITIQUE Le modèle allocator doit être défini avec le modèle mémoire avant finalisation du runtime V1. ## 27.6 Mutabilité visible et `const` — V1 REQUIS — FIGÉ EN PRINCIPE Le modèle mémoire V1 ne doit pas imposer au code ordinaire : ```text mot-clé mut pour obtenir la mutabilité normale borrow checker visible dans la syntaxe lifetimes utilisateur omniprésents ownership annotations pour les usages ordinaires ``` La mutabilité normale est implicite. `const` réduit les droits de l'accès qui le porte sans rendre globalement immutable l'objet et sans invalider les autres alias mutables légitimes. Les analyses internes de move, escape, aliasing ou lifetime restent des libertés d'implémentation tant qu'elles ne changent pas cette sémantique visible. ---