saselang-bible/chapters/051-invariants-de-conception.md

51. Invariants de conception

Les futures décisions doivent respecter les invariants suivants :

1. Une sémantique Saselang ne change pas silencieusement selon le backend.
2. Le frontend reste indépendant de LLVM.
3. V1 est suffisamment complet pour construire le compilateur/interpréteur sans inventer des règles pendant l'implémentation.
4. V2 doit pouvoir réimplémenter V1 en Saselang.
5. Les décisions V1 évitent de bloquer les backends V3+ sans prétendre les spécifier définitivement.
6. Pas de préprocesseur textuel.
7. Pas de magie lorsque la même capacité peut être exprimée explicitement et de façon déterministe.
8. Pas de duplication de concepts par des alias syntaxiques gratuits.
9. Les types Core compiler-known restent peu nombreux.
10. Le package, le namespace, le target, la feature, la capability et l'artifact restent des dimensions distinctes.
11. Une collision de namespace entre packages ne doit jamais fusionner implicitement leurs types.
12. Les erreurs récupérables utilisent Result; les opérations réellement infaillibles retournent directement leur valeur.
13. throws n'existe que sur une callable retournant Result.
14. L'identité d'objet est distincte de l'égalité de valeur.
15. Les opérateurs utilisateur passent uniquement par les contrats Core Op....
16. Les interfaces fournissent l'héritage multiple de contrats/comportements sans introduire un second système de traits.
17. Le modèle mémoire V1 doit fournir performances, sûreté et destruction déterministe sans imposer des lifetimes explicites partout.
18. L'ordre des fichiers et des imports n'est pas un ordre d'exécution ou de résolution sémantique.
19. Un cycle n'est interdit que par la règle du graphe concerné : héritage et layout by-value doivent être acycliques ; références de classes, imports et appels peuvent être cycliques.
20. Une fonctionnalité n'est réservée que lorsqu'un besoin réel est identifié ; pas de réservation spéculative « au cas où ».
21. Une opération Core combinée n'existe pas lorsqu'une composition d'opérations existantes exprime strictement la même sémantique.
22. La mutabilité est le défaut ; const retire explicitement les droits de mutation depuis l'accès concerné.
23. const ne crée pas d'immutabilité globale et n'invalide pas les autres alias mutables légitimes.
24. Saselang ne requiert pas de mut, borrow syntax ou lifetimes utilisateur pour le code mutable ordinaire.
25. Les conversions et opérations textuelles ne transcendent jamais implicitement les encodages : conversion explicite d'abord, opération ensuite.

---