97 lines
2.7 KiB
Markdown
97 lines
2.7 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 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 :
|
|
|
|
```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.
|
|
|
|
---
|