3.5 KiB
33. Imports et résolution des noms
33.1 Imports — V1 REQUIS — FIGÉ
Les imports sont file-level uniquement, après namespace lorsque celui-ci existe.
Pas de wildcard *.
Import symbole par symbole :
import type saselang.compiler.lexer.Token;
import func saselang.compiler.lexer.tokenize;
import const saselang.compiler.config.MaxDepth;
import var saselang.runtime.state.CurrentMode;
import type couvre :
class
struct
enum
interface
union
33.2 Alias — V1 REQUIS — FIGÉ
Sans as, le dernier nom devient l'alias local implicite.
import type foo.Token;
importe Token.
Alias explicite :
import type foo.Token as FooToken;
Les alias locaux doivent être uniques dans le fichier.
Pas d'alias de module.
33.3 Import explicite même dans le même namespace — V1 REQUIS — FIGÉ
Appartenir au même namespace ne rend pas automatiquement les symboles visibles entre fichiers.
Avec :
src/foo/A.saseltype
src/foo/B.saseltype
si B.saseltype utilise A, il doit contenir :
import type foo.A;
même si les deux fichiers déclarent :
namespace foo;
La même règle s'applique aux autres kinds importables.
Un symbole top-level défini dans un autre fichier ne peut pas contourner cette règle en étant référencé directement par son chemin qualifié complet dans une expression ou une déclaration.
Le chemin pleinement qualifié sert notamment à identifier le symbole dans la clause import, pas à créer une seconde forme d'utilisation sans import.
Cette règle rend toutes les dépendances de fichier visibles localement et évite que la portée d'un namespace agisse comme un import implicite.
33.4 Dépendances externes — V1 REQUIS — FIGÉ EN PRINCIPE
Un symbole provenant d'une dépendance externe doit être importé explicitement avec une clause from "vendor/package@requirement" selon la grammaire de package à finaliser.
Les coordonnées de package (/, @, contrainte SemVer) restent confinées à la syntaxe d'import/dépendance et ne deviennent pas une syntaxe générale de qualification dans les expressions.
33.5 Imports déclaratifs et cycles — V1 REQUIS — FIGÉ
Un import Saselang est une déclaration de résolution de symbole.
Il ne signifie jamais :
charger le fichier immédiatement
exécuter le fichier
initialiser le fichier
compiler ce fichier avant le fichier courant
Les cycles d'import sont donc autorisés :
A imports B
B imports A
ou :
A imports B
B imports C
C imports A
Un cycle d'import n'est pas en lui-même une erreur.
Le compilateur doit ensuite analyser les graphes sémantiques réellement concernés.
Exemples :
cycle de références de classes
autorisé
cycle d'appels
autorisé
cycle d'héritage
ERROR
cycle de layout by-value
ERROR
Le diagnostic doit identifier la violation réelle et ne pas utiliser un générique circular import lorsque les imports eux-mêmes sont valides.
33.6 Ordre de résolution — V1 REQUIS — FIGÉ EN PRINCIPE
Les fichiers et imports organisent le source mais ne définissent pas un ordre sémantique de compilation.
Le frontend collecte les déclarations nominales accessibles avant de finaliser les relations d'héritage, contrats, layouts et corps.
Cela permet notamment à deux classes placées dans deux .saseltype distincts de se référencer mutuellement sans dépendre d'un ordre de chargement de fichiers.