2.7 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.
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.