46 lines
4.5 KiB
Markdown
46 lines
4.5 KiB
Markdown
# 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.**
|
|
|
|
33. **Une relocalisation physique de backing storage n'est pas une mutation sémantique observable et ne doit pas, à elle seule, invalider une `Slice<T>`.**
|
|
34. **Les littéraux `[...]` restent des littéraux d'array contextualisés ; les collections dynamiques utilisent des factories/class methods/builders explicites.**
|
|
35. **Une valeur `Hashable` possède une identité hashable stable pendant toute sa durée de vie ; aucune collection hashée ne repose sur un hash qui change silencieusement.**
|
|
36. **Les collisions de hash sont normales ; l'égalité logique tranche l'identité, et aucun ordre d'itération des collections hashées n'est garanti par accident.**
|
|
37. **Les standards externes adoptés normativement sont référencés par version ; une révision externe future ne modifie jamais silencieusement une version publiée de Saselang.**
|
|
|
|
---
|