v0.2.14

chapters/033-imports-et-resolution-des-noms.md

@@ -2,7 +2,7 @@
 
 ## 33.1 Imports — V1 REQUIS — FIGÉ
 
-Imports file-level uniquement, après `namespace` lorsque celui-ci existe.
+Les imports sont file-level uniquement, après `namespace` lorsque celui-ci existe.
 
 Pas de wildcard `*`.
 
@@ -45,19 +45,99 @@ Les alias locaux doivent être uniques dans le fichier.
 
 Pas d'alias de module.
 
-## 33.3 Utilisation sans import — V1 REQUIS — FIGÉ
+## 33.3 Import explicite même dans le même namespace — V1 REQUIS — FIGÉ
 
-L'utilisation d'un chemin qualifié complet sans `import` est autorisée uniquement pour les symboles appartenant au **package courant**.
+Appartenir au même namespace ne rend pas automatiquement les symboles visibles entre fichiers.
+
+Avec :
 
 ```text
-saselang.compiler.lexer.Token
-saselang.compiler.lexer::tokenize(...)
+src/foo/A.saseltype
+src/foo/B.saseltype
 ```
 
-`.` qualifie le chemin ; `::` accède au symbole contenu.
+si `B.saseltype` utilise `A`, il doit contenir :
 
-Un symbole provenant d'une dépendance externe ne peut pas être référencé directement par un chemin complet dans une expression ou une déclaration. Il doit d'abord être importé explicitement avec une clause `from "vendor/package@requirement"`.
+```text
+import type foo.A;
+```
 
-Cette règle évite d'introduire la syntaxe de coordonnées package (`/`, `@`, contraintes SemVer) dans la grammaire générale des expressions et garantit qu'un fichier énonce explicitement toutes ses provenances externes.
+même si les deux fichiers déclarent :
+
+```text
+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 :
+
+```text
+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 :
+
+```text
+A imports B
+B imports A
+```
+
+ou :
+
+```text
+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 :
+
+```text
+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.
 
 ---