# 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.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 Raw pointers — V1 REQUIS — À FINALISER Les pointeurs bruts existent explicitement et leurs opérations de dereference/arithmétique autorisées doivent être précisément définies. Les noms des types (`Ptr`, `PtrMut` ou autre) restent à figer. ## 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. ---