127 lines
4.3 KiB
Markdown
127 lines
4.3 KiB
Markdown
# 24. Casts et conversions
|
|
|
|
## 24.1 Principe général — V1 REQUIS — FIGÉ EN PRINCIPE
|
|
|
|
Saselang distingue explicitement :
|
|
|
|
```text
|
|
conversion de valeur
|
|
cast de hiérarchie nominale
|
|
bitcast de représentation binaire
|
|
```
|
|
|
|
Ces mécanismes ne sont pas des alias.
|
|
|
|
`bitcast<T>(value)` est défini au chapitre 20 et ne constitue jamais une conversion numérique.
|
|
|
|
## 24.2 Conversions implicites numériques — V1 REQUIS — FIGÉ
|
|
|
|
Il n'existe aucune promotion numérique implicite générale entre deux valeurs déjà typées de types primitifs différents.
|
|
|
|
```text
|
|
int8 small = ...;
|
|
int32 large = small; // ERROR
|
|
int32 explicitLarge = small::toInt32(); // OK
|
|
```
|
|
|
|
Le typage contextuel d'un littéral non encore typé reste une règle distincte.
|
|
|
|
## 24.3 Upcast — V1 REQUIS — FIGÉ
|
|
|
|
Un upcast compatible dans une hiérarchie de classes ou vers une interface satisfaite est une assignation de sous-typage normale et ne nécessite pas une syntaxe de cast dédiée.
|
|
|
|
```text
|
|
Dog dog = ...;
|
|
Animal animal = dog;
|
|
Serializable serializable = dog;
|
|
```
|
|
|
|
## 24.4 Downcast et raffinement — V1 REQUIS — FIGÉ EN PRINCIPE
|
|
|
|
Le mécanisme canonique de downcast V1 est le test `is` suivi du raffinement de type dans le scope positif.
|
|
|
|
```text
|
|
Animal animal = ...;
|
|
|
|
if (animal is Dog) {
|
|
// animal est raffiné en Dog ici.
|
|
}
|
|
```
|
|
|
|
Lorsqu'un test du type runtime **exact** est nécessaire, `instanceof` est utilisé.
|
|
|
|
Saselang n'introduit pas pour le moment de syntaxe générale concurrente telle que `(Dog)value`, `value as Dog` ou `cast<Dog>(value)`. Une telle opération ne pourra être ajoutée que si un besoin distinct de `is`/`instanceof` + refinement est démontré et si son contrat d'échec est explicite.
|
|
|
|
## 24.5 API numérique du Core — V1 REQUIS — DIRECTION FIGÉE
|
|
|
|
Les conversions numériques sont exposées comme membres standard des primitives définis par le Core. Les noms de méthodes ne sont pas des mots-clés du langage.
|
|
|
|
Le compilateur connaît les règles nécessaires pour typer, vérifier, constant-fold et abaisser ces opérations vers Sase IR, mais l'inventaire exhaustif de la surface API appartient au Core.
|
|
|
|
Principe de nommage :
|
|
|
|
```text
|
|
toTarget()
|
|
conversion exacte et totale
|
|
|
|
tryToTarget()
|
|
conversion exacte pour la valeur courante, récupérable si impossible
|
|
|
|
roundToTarget()
|
|
perte de précision explicitement acceptée, conversion totale
|
|
|
|
tryRoundToTarget()
|
|
perte de précision explicitement acceptée, mais conversion pouvant échouer
|
|
|
|
saturateToTarget()
|
|
saturation explicite lorsqu'aucun arrondi supplémentaire n'est nécessaire
|
|
|
|
saturatingRoundToTarget()
|
|
arrondi + saturation explicitement annoncés
|
|
|
|
wrapToTarget()
|
|
wrapping entier explicite
|
|
```
|
|
|
|
Une forme n'existe que si elle apporte une sémantique observable différente d'une autre forme déjà disponible pour la paire source/destination.
|
|
|
|
Ainsi, lorsqu'un `toTarget()` exact et total existe, les variantes `tryToTarget()`, `saturateToTarget()` ou `wrapToTarget()` qui produiraient exactement le même résultat pour tout le domaine source sont absentes.
|
|
|
|
## 24.6 `float -> integer` — V1 REQUIS — DIRECTION FIGÉE
|
|
|
|
Un flottant ne possède jamais un simple `toIntXX()` ou `toUintXX()`.
|
|
|
|
La politique de passage du réel à l'entier doit être explicite, par exemple :
|
|
|
|
```text
|
|
tryExactToInt32()
|
|
tryFloorToInt32()
|
|
tryCeilToInt32()
|
|
tryRoundToInt32()
|
|
tryTruncateToInt32()
|
|
```
|
|
|
|
Les variantes saturantes ou wrapping, lorsqu'elles sont retenues, doivent également annoncer explicitement la politique mathématique appliquée.
|
|
|
|
Aucun comportement de conversion ne dépend d'un profil, d'un linter ou d'un backend.
|
|
|
|
## 24.7 `NumericConversionError` — V1 REQUIS — NOM DE TRAVAIL
|
|
|
|
`NumericConversionError` est retenu comme nom de travail du `ResultError` Core utilisé par les conversions numériques récupérables.
|
|
|
|
Son nom définitif, ses codes et son état minimal pourront encore être ajustés lors de la finalisation du Core sans modifier les principes de conversion de ce chapitre.
|
|
|
|
## 24.8 Matrice exhaustive — ANNEXE NORMATIVE EN COURS DE GEL
|
|
|
|
L'inventaire source → destination des opérations de conversion est maintenu séparément afin d'éviter les oublis, doublons et incohérences.
|
|
|
|
Voir :
|
|
|
|
```text
|
|
annexes/A-numeric-conversions.md
|
|
```
|
|
|
|
L'annexe doit lister le maximum de possibilités sémantiquement distinctes avant réduction finale de l'API Core.
|
|
|
|
---
|