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

---