v0.2.12

chapters/051-invariants-de-conception.md

@@ -0,0 +1,23 @@
+# 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.**
+
+---