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. ResultError, Exception et Fault sont trois mécanismes distincts : valeur d'échec explicite, propagation checked et échec unchecked capturable.

13. throws ne contient que des Exception et reste indépendant du type de retour ; faults ne contient que des Fault et reste optionnel/non exhaustif.

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.

26. Une interface de collection n'annonce jamais une capacité qui peut être absente et échouer ensuite comme « unsupported ».

27. Capacité intrinsèque d'un type et permission portée par const restent deux dimensions distinctes.

28. Une slice ne peut jamais augmenter les droits de mutation de sa source.

29. Un array safe devient observable uniquement après initialisation complète.

30. Une bibliothèque spécialisée peut être officielle sans appartenir au Core ou au SDK obligatoire ; son artifact normal reste une .saselib.

31. Les dépendances natives de bootstrap peuvent être remplacées progressivement par des implémentations Saselang sans imposer leur architecture historique au langage.

32. Lorsqu'une forme légèrement plus longue supprime un implicite ou une ambiguïté réelle, Saselang privilégie l'explicite.

---