RÉFÉRENCE VITTE / Langage

Types

Un type décrit les valeurs qu’une expression peut représenter et les opérations qui ont du sens dessus.

Niveau de garantieLes tests runtime vérifient plusieurs types et conversions ; les types composés ou avancés restent séparés par niveau.

Source de référence : grammar/vitte.ebnf · src/bootstrap/builtin/README.md · modules/core/README.md

Types primitifs documentés dans le registre bootstrap

Famille	Noms listés	Notes
Contrôle	`bool`, `void`, `never`, `error`	Valeurs logiques, absence de résultat, absence normale de retour et valeur d’erreur.
Entiers	`u8`, `u32`, `u64`, `usize`, `int`, `i64`	Le registre bootstrap n’énumère qu’un sous-ensemble ; les modules et fixtures emploient aussi des types plus larges.
Flottants	`f32`, `f64`	Valeurs à virgule flottante.
Texte	`string`	Chaîne dans les interfaces intégrées.

Cette liste vient du registre décrit dans src/bootstrap/builtin/README.md. Elle n’est pas exhaustive : les tests compilés utilisent aussi plusieurs autres largeurs entières et char.

Types composés et qualifiés

[4]i64          // tableau fixe de quatre entiers
&Point          // référence
&mut Point      // référence mutable
*u8             // pointeur
module::Point   // type qualifié

La grammaire décrit les références avec &T ou ref T, éventuellement suivies de mut ; les pointeurs avec *T ; les tableaux avec [expression]T ; et les chemins de type avec des paramètres génériques entre chevrons ou crochets.

Génériques et alias

type Option<T> = ?T;

form Paire<T> {
    premier: T,
    second: T,
}

proc identite<T>(valeur: T) -> T {
    return valeur;
}

Les paramètres génériques rendent un type ou une procédure réutilisable pour plusieurs types. La grammaire prévoit une contrainte après : et des clauses where. Les sources de core utilisent des types génériques, mais le test de compilation natif rejette explicitement une forme générique Box<T> au backend. Le code ci-dessus sert à illustrer la syntaxe visée ; il n’est pas une promesse de compilation.

Nullable : écart à résoudre entre les sources

Les sources de modules/core emploient le type nullable ?T et représentent l’absence avec null. Toutefois, la production type de grammar/vitte.ebnf ne liste pas explicitement cette forme. Aucun des tests d’exécution audités ne prouve son acceptation et sa génération C17 ; l’exemple suivant illustre le code source de core, pas une forme garantie par l’EBNF ou le backend natif.

proc valeur_ou_zero(valeur: ?i64) -> i64 {
    if valeur != null {
        return valeur;
    }
    return 0;
}

Conversions

Le mot de conversion as est accepté et compilé dans les tests natifs, notamment pour convertir des valeurs en u8 et f64. Il n’apparaît pas dans la production d’expression de l’EBNF actuelle. Une conversion explicite annonce le changement de type ; elle ne prouve pas à elle seule que la valeur reste dans la plage de destination. La bibliothèque core::convert fournit des conversions vérifiées pour certains couples de types.

Vérification par famille de types

Construction	EBNF	Analyseur	Compilation constatée
Booléens, entiers signés/non signés, `string`	Les types nommés passent par `path_type`.	Acceptés dans les fixtures natives et bootstrap.	Oui : booléens, largeurs entières et chaînes sont exercés dans les 11 fixtures runtime.
`f64` et conversions numériques	Les noms de type et cast sont des chemins syntaxiques ; `as` est absent de l’EBNF.	`as` accepté dans une fixture runtime.	Oui : `llvm_integer_width_runtime.vit` compile puis exécute une conversion vers `f64`.
Tableaux fixes, tableaux imbriqués, index	Décrits par `[expression]type`.	Acceptés ; erreurs de taille et de type également testées.	Oui : HIR/IR, C17 et exécution pour lectures, écritures et matrices.
Références et champs de formes	Décrits par `&T` et `ref T`.	Marqueurs de paramètre couverts par fixture ; formes et champs couverts dans le frontend natif.	Oui pour références à des formes et accès de champs dans `aggregate_runtime.vit`.
Pointeurs `*T`	Décrits.	Pas de fixture ciblée d’analyse retenue.	Non prouvé dans le runtime audité.
Génériques et contraintes	Décrits par paramètres génériques et clauses `where`.	Le parseur bootstrap les documente ; les cas natifs testés ne valident pas un générique complet.	Forme générique explicitement rejetée au backend ; autres combinaisons non prouvées.
Nullable `?T`	Absent de la production EBNF `type`.	Utilisé dans les sources `core`, sans fixture ciblée de parseur dans les tests exécutés.	Non prouvé.
Cast `valeur as T`	Absent de l’EBNF.	Accepté par le frontend natif des tests.	Oui pour les casts vers `u8` et `f64` exercés en runtime.

La matrice générale du support donne les commandes de vérification et distingue le frontend natif du chemin bootstrap.

Règle de consultation

Utilise le type le plus étroit qui exprime réellement ton domaine, puis vérifie la disponibilité et les règles de conversion sur la cible de compilation utilisée.

Sources : grammaire EBNF · registre des types intégrés · contrats de core.