5.0 KiB
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 :
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<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.
Il autorise uniquement une liste fermée d'opérations dont les garanties ne sont pas prouvables automatiquement.
Formes retenues :
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 :
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<T>.
La spécification devra distinguer au minimum :
référence de classe
accès sûr ordinaire vers un objet
Slice<T>
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<T>, PtrMut<T> ou autre) restent à figer.
Doivent être définis explicitement :
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 :
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.