137 lines
4.0 KiB
Markdown
137 lines
4.0 KiB
Markdown
# 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 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 :
|
|
|
|
```text
|
|
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 :
|
|
|
|
```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.
|
|
|
|
---
|