2.1 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.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 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<T>, PtrMut<T> 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.