v0.2.14
This commit is contained in:
@@ -1,4 +1,4 @@
|
||||
# Bible Saselang 0.2.12
|
||||
# Bible Saselang 0.2.14
|
||||
|
||||
> **Statut : pré-spécification normative de Saselang V1.**
|
||||
>
|
||||
@@ -7,7 +7,7 @@
|
||||
>
|
||||
> La V2 visera principalement la réécriture/self-hosting de la toolchain V1 en Saselang lui-même. Les extensions majeures de cibles et d'écosystème sont prévues à partir de V3+.
|
||||
>
|
||||
> **Révision 0.2.12 :** première distribution multifichier ; fixation de la distinction `is` / `instanceof`, formalisation initiale des casts/downcasts et de la surface de conversion numérique Core, introduction de l'annexe exhaustive des conversions et du modèle de livraison `full` + deltas SemVer.
|
||||
> **Révision 0.2.14 :** fermeture du socle générique V1 (contraintes, invariance, const generics, récursivité), formalisation de la complétude/layout des types et des imports explicites non séquentiels, stabilisation supplémentaire des conversions numériques (`NaN`, `NumericConversionError`, réduction anti-doublon) et hiérarchie initiale des capabilities par propriétaire.
|
||||
|
||||
## Organisation de cette distribution
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Sommaire — Bible Saselang 0.2.12
|
||||
# Sommaire — Bible Saselang 0.2.14
|
||||
|
||||
## Chapitres
|
||||
|
||||
|
||||
@@ -1,4 +1,33 @@
|
||||
# Changelog documentaire — 0.2.12
|
||||
# Changelog documentaire — 0.2.14
|
||||
|
||||
## 0.2.14
|
||||
|
||||
- fermeture du socle generics V1 : syntaxe, inférence d'appel, contraintes nominales, invariance, absence de CTAD/wildcards/spécialisation ;
|
||||
- `Numeric` retenu comme vraie abstraction Core utilisable dans les contraintes génériques ;
|
||||
- const generics V1 limités aux types de paramètres `bool`, `char`, `uint8..uint256` et enums simples sans payload ;
|
||||
- arguments const generic volontairement boring : aucune callable directement dans `<...>` ; calcul complexe matérialisé d'abord dans une `const` ;
|
||||
- inférence const generic structurelle uniquement, sans solveur algébrique ;
|
||||
- récursivité générique régulière autorisée ; auto-référence transformante et polymorphic recursion interdites V1 ;
|
||||
- toute récursivité by-value interdite, y compris via une instanciation de taille théoriquement nulle ;
|
||||
- cycles d'héritage interdits, diamants non cycliques autorisés ;
|
||||
- classes récursives autorisées via leurs références d'objet ;
|
||||
- distinction nominalement connu / sémantiquement complet / layout-complet et suppression du besoin de forward declarations utilisateur ;
|
||||
- imports explicites requis même entre deux types du même namespace ; les imports sont déclaratifs, non exécutables, et leurs cycles sont autorisés ;
|
||||
- `NaN`, infinities et zéros signés stabilisés pour `float -> float` ;
|
||||
- `NumericConversionError` stabilisé conceptuellement autour de `NotFinite`, `NotIntegral`, `OutOfRange`, `Inexact` ;
|
||||
- matrice `float -> integer` réduite par paire selon la règle anti-doublon ;
|
||||
- conversions fondamentales Core obligatoires pour toute paire de types supportés, avec émulation logicielle lorsque raisonnable ;
|
||||
- nomenclature de capabilities organisée par propriétaires `language.*`, `core.*`, `target.*`, `platform.*`, `sdk.*` ;
|
||||
- V1/V2 explicitement positionnées comme bases/POC, V3 comme première baseline publique de stabilité.
|
||||
|
||||
|
||||
## 0.2.13
|
||||
|
||||
- règle générale de composition Core figée : aucune méthode combinée lorsqu'une chaîne d'opérations existantes exprime exactement la même sémantique ;
|
||||
- suppression conceptuelle des alias `tryFloorTo...`, `tryCeilTo...`, `tryRoundTo...` et `tryTruncateTo...` ;
|
||||
- `float -> integer` réduit aux familles `tryTo...`, `trySaturateTo...` et `tryWrapTo...`, composables avec `floor()`, `ceil()`, `round()` et `truncate()` ;
|
||||
- maintien des méthodes combinées uniquement lorsqu'une composition changerait le contrat ou perdrait l'information nécessaire ;
|
||||
- `saturatingRoundToFloatXX()` reste justifié pour les conversions flottantes où arrondi et saturation ne peuvent pas être séparés sans changer la sémantique.
|
||||
|
||||
## 0.2.12
|
||||
|
||||
|
||||
462
MANIFEST.toml
462
MANIFEST.toml
@@ -1,461 +1,109 @@
|
||||
format = 1
|
||||
version = "0.2.12"
|
||||
distribution = "full"
|
||||
base_version = ""
|
||||
version = "0.2.14"
|
||||
distribution = "delta"
|
||||
base_version = "0.2.13"
|
||||
documentation_layout = "multifile"
|
||||
|
||||
[[files]]
|
||||
[[modified]]
|
||||
path = "000-README.md"
|
||||
sha256 = "54178a0e9d920766859335ae851b5424fe0721344089e926e3df1904e80bb2d5"
|
||||
sha256 = "4ca46426ce93e412b82ce1473202763a9b75dca7a9a76e85f6c7f3afa27245b0"
|
||||
|
||||
[[files]]
|
||||
[[modified]]
|
||||
path = "001-SUMMARY.md"
|
||||
sha256 = "231083968ba2895084386113e1337cd5c63315413eb91151327ba588b8c881b9"
|
||||
sha256 = "a15df88415cfc941907ee03d2d851dbeb12a18ad3c2933fede66e263fd4c95af"
|
||||
|
||||
[[files]]
|
||||
path = "002-DOCUMENTATION-MODEL.md"
|
||||
sha256 = "f939efa7d1379ed263a14a125ca8343ff4f182cda956955b5903f2da99df0a18"
|
||||
|
||||
[[files]]
|
||||
[[modified]]
|
||||
path = "003-CHANGELOG.md"
|
||||
sha256 = "4048bddd42f8d8102735716e8c1378fc254d2cdc08368e69da683b3ebc205cf3"
|
||||
sha256 = "e7c56000d0f64d9109e398d19bac6219a0435db0f52fb0548e354364d5eebb8a"
|
||||
|
||||
[[files]]
|
||||
[[modified]]
|
||||
path = "annexes/A-numeric-conversions.md"
|
||||
sha256 = "b2e8d0d1f7fd2773ad4ba5308e41a0c51f48b23b77983759ef8b44b5c6aa70ba"
|
||||
sha256 = "7e67ab02a99b7ebbb0d5ac0a16bdc89f70fdfdad0620a3927e3f07a13c722743"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/000-statuts-normatifs.md"
|
||||
sha256 = "adad2d9969de674e74b27456088c8ab8287706add7b9b9f4ef25acdb47f98abc"
|
||||
|
||||
[[files]]
|
||||
[[modified]]
|
||||
path = "chapters/001-trajectoire-dimplementation.md"
|
||||
sha256 = "aec24baf0839bcc421b6d3bb1f4362e967655520250e93b63eee9a0b1c6c1ee4"
|
||||
sha256 = "9f0205305e77f3474091795e897743c4e2012fc94a04a954509a7a6c3f3f43ed"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/002-principes-generaux-du-langage.md"
|
||||
sha256 = "375357d732445b3c781121628cc9cabfa01ed1f27bc673143eedc3adbb0db0a1"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/003-architecture-de-compilation.md"
|
||||
sha256 = "aa8289a8f12124215d050f655a63952d11d158e814cf0e92f7ada7f875c18ed1"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/004-couches-de-lecosysteme-v1.md"
|
||||
sha256 = "fbdcfb41f140dc94ed068bbfec7f4740b0c9723128e59959127b38275578e286"
|
||||
|
||||
[[files]]
|
||||
[[modified]]
|
||||
path = "chapters/005-types-primitifs.md"
|
||||
sha256 = "9b313a1adce6f6a12fe2015613603f1e33727e043d56c429afdbf8c60854a792"
|
||||
sha256 = "c723a1fde76ee90badae1d08deab9e7b8e59da6622979c3f89f3da495efe8157"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/006-types-variables-constantes-et-scopes.md"
|
||||
sha256 = "a3f4ea068f5273d64842bc8cbf25cecc36aaa73d166cedd74f85af52fa345d67"
|
||||
|
||||
[[files]]
|
||||
[[modified]]
|
||||
path = "chapters/007-types-nominaux-et-fichiers-saseltype.md"
|
||||
sha256 = "200e87df7e530f58a7bc8d193a857891a56c3594fa7750bf3ae430e2f1af9c7b"
|
||||
sha256 = "1b853fb1160d397565988e3a8dbb9b52b8c5cfbca0c2428948221955728f715c"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/008-classes-et-object.md"
|
||||
sha256 = "442c0b0beeb41d9329400b90edb5c8c510b815f319059b8802120c9532e2fe82"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/009-structs.md"
|
||||
sha256 = "d23b0b4055de2ed32eaef76f534f245a51b7f9fb1030bf73ac2231f3ef858ab3"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/010-enums-algebriques.md"
|
||||
sha256 = "5743f854fba3a0cd7a539ed97686978ff05e0d84bef0cf446307d3583e0c0fe1"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/011-tuples.md"
|
||||
sha256 = "19692031e4ac96b4d15dde240033b92cd4051acce58de17e4969b6a5ac2a06fd"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/012-unions.md"
|
||||
sha256 = "2ba425792989386546f8176cf5937d9256ecbcb5950ec0841989b2888afdeeb6"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/013-interfaces.md"
|
||||
sha256 = "3787c491751256940deddff1e507988ad028b6cb5aa4f3d48e2c88f75dee9517"
|
||||
|
||||
[[files]]
|
||||
[[modified]]
|
||||
path = "chapters/014-generics.md"
|
||||
sha256 = "10507bacab272ec59b3f43f018942e7055b9135335e3748698afc3d4a1cf7331"
|
||||
sha256 = "c827e50f5efd51480e0fc250a3e92d75f40eaadc5d47b42078ae16b4c6c5f14a"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/015-fonctions-methodes-et-clsmethod.md"
|
||||
sha256 = "930b4ce52bf59c372bc2c068d13f2c3b55b4b1409a93438a00aff0fed9e6b3b1"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/016-dispatch-override-et-modificateurs.md"
|
||||
sha256 = "c3072282a152c471e726d485a228e19dc1f34cebb2092fc83354d8ac562b881f"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/017-construction-et-destruction.md"
|
||||
sha256 = "78808a62bd115245fa56908b742fa38d2125a941a41e0b66d10fcfdca71e8ccc"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/018-result-erreurs-et-exceptions.md"
|
||||
sha256 = "a3737a880d01f08cd81146f9b9b8c9079c7c22fdec09a207a6bdbc9479c9a7ed"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/019-controle-de-flux.md"
|
||||
sha256 = "7dd4a4df448145f98f1f3f5adf1727639ebb6f0f62c0167e93d14852fe2e2c1b"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/020-operateurs.md"
|
||||
sha256 = "c01b09d2274650d8de35cb2a859cf5a313babec355f79474780324126f2713a6"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/021-strings-unicode-et-encodages.md"
|
||||
sha256 = "a10a2a5afbe0b95353ef9e56a33b329563b0530e3a1ce9dc0fbb1525e472547b"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/022-collections-et-iteration.md"
|
||||
sha256 = "644c88d2e90a204de64ce8cf941ba876aaac0a35710cbb56a2ff46db09417a6c"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/023-optiont-et-nullablet.md"
|
||||
sha256 = "237f9c31419a9426965ac9a0ca520dcea116138c588579abc1a40628edfd8db8"
|
||||
|
||||
[[files]]
|
||||
[[modified]]
|
||||
path = "chapters/024-casts-et-conversions.md"
|
||||
sha256 = "91672400a7681386b71b3ea1d090527a8609637e7b056450af05c993ce6c0f9a"
|
||||
sha256 = "d625afcee310a5c2eee2342ea96c86cd24f7185a91919849e05641b50ac47b58"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/025-lambdas-closures-callables-et-generators.md"
|
||||
sha256 = "62faff3388b0238cdfbb6ff3fafacf7daaf582fa5e5b40723307425e8b081686"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/026-async-et-concurrence.md"
|
||||
sha256 = "36f936c6af6012d04906c6d6792de589e4d15cbcc28ed45b0538b6a8aabec4ee"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/027-memoire-references-et-unsafe.md"
|
||||
sha256 = "4dafe27ae8243d38013b3c48ea5abe7e987cecdb4b94d193a0ed318452b16242"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/028-defer-et-nettoyage.md"
|
||||
sha256 = "0e7bbdf8cd57652fdaa1bbaef734c561910d5bb99a6d4ec216220a2ab3b38a15"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/029-ffi-et-abi.md"
|
||||
sha256 = "fc395a15a4d5404bd982105fb043a3cac639147cccaf7722fe640aaad17b573c"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/030-reflexion-metadonnees-et-tests.md"
|
||||
sha256 = "818bf11cbafa7b0708dbff2d474abce0abf6e533603d593dcd519c49796d8d8f"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/031-fichiers-source-v1.md"
|
||||
sha256 = "0d978fa1a4e30d71e2bf6634c67ac54194c48640861fbb3e5d3c337aa366fd83"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/032-source-root-modules-et-namespaces.md"
|
||||
sha256 = "ce5077f0475a161221919aa7f15f1c4bc0585e627070e07b99aeabcedf3a683d"
|
||||
|
||||
[[files]]
|
||||
[[modified]]
|
||||
path = "chapters/033-imports-et-resolution-des-noms.md"
|
||||
sha256 = "9b8a4cef4101d35b06235345865f5f7179a8e8219c6e363fedd839251c6eb70e"
|
||||
sha256 = "9e392a4d7adf6c3569f50f6664709a64d3398ded98a6f5365eff5175a9f2a8b5"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/034-packages-identite-et-collisions-de-namespaces.md"
|
||||
sha256 = "e2c69dca0f46e1cc88d47531d2b605f5ffe04a5151a7a73e6e75e6f3e67ff050"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/035-manifests-et-workspaces.md"
|
||||
sha256 = "ddf32952d72bcaf592324295e6c69c0e43f85547e392d1ef22a67cc7aa763463"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/036-semver-et-politique-de-releases.md"
|
||||
sha256 = "d96c4df73e59e76510369a15032c4e1994ebc259309177c36548449ea62112be"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/037-dependances-et-scopes.md"
|
||||
sha256 = "a65d4e69b5a92ca9d04e2f2f83f856c4b9b12790f5b8ea64d2c7b3d21bdb68d4"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/038-resolver-et-lockfile.md"
|
||||
sha256 = "b1312987120a5b25e774af5ae353f112730c68ae81610a818711a12886c3a4f9"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/039-features-module-saselmod-et-compilation-conditionnelle.md"
|
||||
sha256 = "ab3298e8a5402844c61c283fd46c57f1727e2e6a19af7d2d89c70549742f1032"
|
||||
|
||||
[[files]]
|
||||
[[modified]]
|
||||
path = "chapters/040-targets-plateformes-architectures-abi-distributions-et-capabilities.md"
|
||||
sha256 = "a07c118f3ed3dff0fd643e3bcd2334facb22740075100dff2c71384188dcb062"
|
||||
sha256 = "626fb71b95a930cf44ab3ae41f059a12df369063563bde60cb33e7876e045f3f"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/041-artifacts-exports-profils-et-reservation-des-formats-futurs.md"
|
||||
sha256 = "9dd1096b0488d176da8cf48dedb121427c1acf3313509f0da13d8988ae520b87"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/042-main-et-exitcode.md"
|
||||
sha256 = "57499c713a618e5ff52a3186072b3694c1e1144a577589becb8a9a80fae7b88f"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/043-documentation-et-tests-de-conformite.md"
|
||||
sha256 = "8c522c7c6ded5d39dc649c1217dd625ba482a25ec301663e1867857d9b4b1fc5"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/044-browser-futur-v3.md"
|
||||
sha256 = "cf9f95b7c07b2c78c86f07bf6093641645e11e67526311f13a21638ca3f47b8d"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/045-autres-backends-cibles-futur-v3.md"
|
||||
sha256 = "c7ff453312bf0b6db2375c98461f6c722286ab3816512d67509b85bc665cd87e"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/046-quantique-futur-lointain-reserve.md"
|
||||
sha256 = "b538c8e32e3376386e802de174f4a50ff14ca4262969ab065a89bbcb4b40fbe5"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/047-concepts-rejetes-ou-deconseilles.md"
|
||||
sha256 = "eb037983de591edeff740513d98285511bdc60da8dae38f28031dc04902cab1f"
|
||||
|
||||
[[files]]
|
||||
[[modified]]
|
||||
path = "chapters/048-inventaire-des-points-v1-encore-ouverts.md"
|
||||
sha256 = "81234f81aeefa33993b37437ba9fefe83dd6f0286aa527b71a475fab55f294ce"
|
||||
sha256 = "a559b1de74ede0e5b5a209d4fe451e00a5a9d9dfcc1357ef07e376780495545c"
|
||||
|
||||
[[files]]
|
||||
[[modified]]
|
||||
path = "chapters/049-elements-v1-reserves-mais-non-obligatoires-a-implementer-immediatement.md"
|
||||
sha256 = "6451dbf71d2d53e1642c9a33cf1dd109351df926ee2b7f4859c8151058c8222a"
|
||||
sha256 = "1995d1fc3229f3df6456548bec38b2e1adbc29958cef7c8397d137283d0ed243"
|
||||
|
||||
[[files]]
|
||||
path = "chapters/050-elements-futurs-v3-identifies.md"
|
||||
sha256 = "69f6efc022b684d8401f0ae69ce70530d4bc607eed155182961db74ebbd102e8"
|
||||
|
||||
[[files]]
|
||||
[[modified]]
|
||||
path = "chapters/051-invariants-de-conception.md"
|
||||
sha256 = "7c4ba9a3982e37630926666be3a4d4f450fb8c6508605e73a44c0d4a6ac8330e"
|
||||
sha256 = "b02f60468fe292bcfac773a98cf14b865d0fc1936bf353a299d02fec37579a19"
|
||||
|
||||
[[files]]
|
||||
[[modified]]
|
||||
path = "chapters/052-priorite-de-specification-apres-0-2-9.md"
|
||||
sha256 = "c25d105588e2a0ab6dc272887dfd1c7e8fc6ca279c72e72661f140d65aea6406"
|
||||
sha256 = "b8b47f694ea42489e0e83237cbb8c956a716227428e15d8f14c9237266e332a9"
|
||||
|
||||
[[files]]
|
||||
path = "examples/000-statuts-normatifs-examples.md"
|
||||
sha256 = "603326859af5152e7b5097b85acf14b464d8f6e44dd61ee97da1dbfda5ff19c3"
|
||||
|
||||
[[files]]
|
||||
[[modified]]
|
||||
path = "examples/001-trajectoire-dimplementation-examples.md"
|
||||
sha256 = "dc9c9dae4d680d9142688cb9c1f6471f294f3837f69eae287f6cc76c192b8d93"
|
||||
sha256 = "b66c40c7bfc9d76fe80e15f90fcef9c3ab8eabcdbec134fb3f660cfc2b79b5f9"
|
||||
|
||||
[[files]]
|
||||
path = "examples/002-principes-generaux-du-langage-examples.md"
|
||||
sha256 = "0b8662b49f5cec5a396339fb7955b5c94e5f9d3e8ae378a7d7f4bdba1cc5d141"
|
||||
|
||||
[[files]]
|
||||
path = "examples/003-architecture-de-compilation-examples.md"
|
||||
sha256 = "d2a5578e5786ae43dc6f5aa8a2991bf0722a387eb1bbf8edb753d0dece9efef0"
|
||||
|
||||
[[files]]
|
||||
path = "examples/004-couches-de-lecosysteme-v1-examples.md"
|
||||
sha256 = "d77a0dec5925d52eda92ff096eea9c89e17344f954fc873b2748e96159f11304"
|
||||
|
||||
[[files]]
|
||||
[[modified]]
|
||||
path = "examples/005-types-primitifs-examples.md"
|
||||
sha256 = "7f76514d40634957c012225d1505e4f3897e4dc740d2f4bc10faaa9cfe74da91"
|
||||
sha256 = "9d131cd3874606d92988c2fc9ac24dc04c1349893f2be6678618cf13673a94ab"
|
||||
|
||||
[[files]]
|
||||
path = "examples/006-types-variables-constantes-et-scopes-examples.md"
|
||||
sha256 = "aafae93d041b6ff7a1904b38fdf32edd108d8f3e2a4448938789acee22cead95"
|
||||
|
||||
[[files]]
|
||||
[[modified]]
|
||||
path = "examples/007-types-nominaux-et-fichiers-saseltype-examples.md"
|
||||
sha256 = "68f231240b8b2aba706af1c4f31f0ee03031f077808fcc7dce106377cecacf24"
|
||||
sha256 = "a5e4dd8a36a63ea4aba31945379905ed76686b5849bbfb7f7690e5e8c3856ebd"
|
||||
|
||||
[[files]]
|
||||
path = "examples/008-classes-et-object-examples.md"
|
||||
sha256 = "911176c0a75bfe34087d910777b5584b4a2a297ea55d967d47c2c2ce2ee31f28"
|
||||
|
||||
[[files]]
|
||||
path = "examples/009-structs-examples.md"
|
||||
sha256 = "166489ef32db9faf73e490671664c785c700bc945ee13208d29ee54481172d02"
|
||||
|
||||
[[files]]
|
||||
path = "examples/010-enums-algebriques-examples.md"
|
||||
sha256 = "315d85a96f31809ce5a600e262d3719ecfb735ac47603cccd6c7f7af2cdde79b"
|
||||
|
||||
[[files]]
|
||||
path = "examples/011-tuples-examples.md"
|
||||
sha256 = "254dab32d5e9a21f4a9849894bac2d7f946a1c113e76f3c40388fe35dd87229f"
|
||||
|
||||
[[files]]
|
||||
path = "examples/012-unions-examples.md"
|
||||
sha256 = "68bf56ae82d3a82d4c306c44d8be979c3d96342e1d0d6c6d6a864a7dee7a7110"
|
||||
|
||||
[[files]]
|
||||
path = "examples/013-interfaces-examples.md"
|
||||
sha256 = "eaa95dd7a8e4a6d48e132a2e092d8919c70810678adfc4adfcb0144a2ee8fd82"
|
||||
|
||||
[[files]]
|
||||
[[modified]]
|
||||
path = "examples/014-generics-examples.md"
|
||||
sha256 = "31e091f9e765ddf75ed4317871814dd516447d37f96332de4190117e24acdc2d"
|
||||
sha256 = "c1912b3657b0633e9d143e069bd75eb079486d1f2de8e6cd67f374aa7edcd78b"
|
||||
|
||||
[[files]]
|
||||
path = "examples/015-fonctions-methodes-et-clsmethod-examples.md"
|
||||
sha256 = "d200b80b6aa44592fc402e31905d2fad39c6a2c8af72141b62bd50d18327d85d"
|
||||
|
||||
[[files]]
|
||||
path = "examples/016-dispatch-override-et-modificateurs-examples.md"
|
||||
sha256 = "1b0692a23aea7f987413ab9e1b28b47319b5b0bc3b4bbc01da6427e626a0ab6e"
|
||||
|
||||
[[files]]
|
||||
path = "examples/017-construction-et-destruction-examples.md"
|
||||
sha256 = "b5007805d0f49736b0ede122549bc25ccc8324152e391781694daa692df1b1a4"
|
||||
|
||||
[[files]]
|
||||
path = "examples/018-result-erreurs-et-exceptions-examples.md"
|
||||
sha256 = "07ccc65d0f0da12df0b3693931355791a8f10f92b35ff7513f54fd8fa948b9c2"
|
||||
|
||||
[[files]]
|
||||
path = "examples/019-controle-de-flux-examples.md"
|
||||
sha256 = "1932134c40c28ccfc8e412737fa41a3bf7b62230dfaf19b1f8ba9c874897e215"
|
||||
|
||||
[[files]]
|
||||
path = "examples/020-operateurs-examples.md"
|
||||
sha256 = "d3dfdb43d3b22ea49f26d86605a37ebe63bdfd03c1ca281f40b113e50bc7dc47"
|
||||
|
||||
[[files]]
|
||||
path = "examples/021-strings-unicode-et-encodages-examples.md"
|
||||
sha256 = "789523370776c97890bfec3969c04e203ec27580778f169eb78fc00503e51ff3"
|
||||
|
||||
[[files]]
|
||||
path = "examples/022-collections-et-iteration-examples.md"
|
||||
sha256 = "264f10c49cc8743d99709ff6449d7fc1b0ed89825972acbd7619e99167278a13"
|
||||
|
||||
[[files]]
|
||||
path = "examples/023-optiont-et-nullablet-examples.md"
|
||||
sha256 = "4de6187045e9159fd5300219632b79ecdaa558d2c001ff40dac131e31e2d3e19"
|
||||
|
||||
[[files]]
|
||||
[[modified]]
|
||||
path = "examples/024-casts-et-conversions-examples.md"
|
||||
sha256 = "669d64eecfb93484c44d37a4e7ea9089fec6f5369ecd0f51bcdd0e42d478f5ee"
|
||||
sha256 = "5e402ca2584d2272b88a656d335ea8360224de937d75cab3b5c9f83efbf608af"
|
||||
|
||||
[[files]]
|
||||
path = "examples/025-lambdas-closures-callables-et-generators-examples.md"
|
||||
sha256 = "e423a0e4f204187ec7e4082d16ad1c69178009b213730764da3a79318e338b32"
|
||||
|
||||
[[files]]
|
||||
path = "examples/026-async-et-concurrence-examples.md"
|
||||
sha256 = "879445bf8779a0b895fa1e6014a1ac404c1b9c94138edeab8dfc3eeff08e6197"
|
||||
|
||||
[[files]]
|
||||
path = "examples/027-memoire-references-et-unsafe-examples.md"
|
||||
sha256 = "9ae88eb5f6392411da9c1a60b5c1026342c2c73e2e57516a37535f46562fcf8c"
|
||||
|
||||
[[files]]
|
||||
path = "examples/028-defer-et-nettoyage-examples.md"
|
||||
sha256 = "1f9d7ee762391b7cd49811cefe550825ff086160d53a268f37f9eccbb40c1acd"
|
||||
|
||||
[[files]]
|
||||
path = "examples/029-ffi-et-abi-examples.md"
|
||||
sha256 = "32dc3da8d95ab38f5c4beaba7d86a316856f0c18ddf867d915a80a004eced7fc"
|
||||
|
||||
[[files]]
|
||||
path = "examples/030-reflexion-metadonnees-et-tests-examples.md"
|
||||
sha256 = "44fb73994d7d26d67ad9cc1274c8f3ef526b1516696807c59776ad0a9444d33d"
|
||||
|
||||
[[files]]
|
||||
path = "examples/031-fichiers-source-v1-examples.md"
|
||||
sha256 = "9741c8a0dc0e998e006e09b01d4b215e0b61a24282d334bf6a422c78a59c01fd"
|
||||
|
||||
[[files]]
|
||||
path = "examples/032-source-root-modules-et-namespaces-examples.md"
|
||||
sha256 = "b998d3b625c15b9481c2f983c5e7577d32f95b441d839663f1d3e586dc774722"
|
||||
|
||||
[[files]]
|
||||
[[modified]]
|
||||
path = "examples/033-imports-et-resolution-des-noms-examples.md"
|
||||
sha256 = "8c2e4f9777d2fd051bb739a9aa34ab6ba7bbc0fee7f9beef739d98d2c7bc6bde"
|
||||
sha256 = "2932904dce7683d2da856a6be78ba09f57ef1dd4d95c3df8c4280685d28c9003"
|
||||
|
||||
[[files]]
|
||||
path = "examples/034-packages-identite-et-collisions-de-namespaces-examples.md"
|
||||
sha256 = "825e5375e64e3e395d7d5dd3409b2bbcca17a54eef49474aa5041f2374902f6b"
|
||||
|
||||
[[files]]
|
||||
path = "examples/035-manifests-et-workspaces-examples.md"
|
||||
sha256 = "7541fa0ce1a82bb7f3911f7e4c63d45c1b018f58e5e5a1d05a1d0bcc7231e8a2"
|
||||
|
||||
[[files]]
|
||||
path = "examples/036-semver-et-politique-de-releases-examples.md"
|
||||
sha256 = "fc7ced4d0441b0a3ace89da6476dad95ae88a922e4258e239ef207f96296bfe0"
|
||||
|
||||
[[files]]
|
||||
path = "examples/037-dependances-et-scopes-examples.md"
|
||||
sha256 = "fbb49ee7ab46c36494846fb5de6f031a924ef130dcbe3fa8a146061220234a07"
|
||||
|
||||
[[files]]
|
||||
path = "examples/038-resolver-et-lockfile-examples.md"
|
||||
sha256 = "538c464ebf90fe62caa293bed81db33c0c2a83ad5212d2376f13c68d01bcac0c"
|
||||
|
||||
[[files]]
|
||||
path = "examples/039-features-module-saselmod-et-compilation-conditionnelle-examples.md"
|
||||
sha256 = "b94143a8a166341c5b9d7a4d5d1f3d4e30d4246dace2996b04ba5168edde2069"
|
||||
|
||||
[[files]]
|
||||
[[modified]]
|
||||
path = "examples/040-targets-plateformes-architectures-abi-distributions-et-capabilities-examples.md"
|
||||
sha256 = "7d06abcbbdad7bda07bf490f5a8847ad7cfb8634d9479c9b1302f173e2366793"
|
||||
sha256 = "c42e68657c168e6bab2e1d6d4050530f34f649a2be785e66efd64a310e082f3e"
|
||||
|
||||
[[files]]
|
||||
path = "examples/041-artifacts-exports-profils-et-reservation-des-formats-futurs-examples.md"
|
||||
sha256 = "65b85a25d9caed6955864a85dff17cdedfdef56cb27f77dbe133837738850999"
|
||||
|
||||
[[files]]
|
||||
path = "examples/042-main-et-exitcode-examples.md"
|
||||
sha256 = "5e863daae3593ba7e39da2fbee6b1721988d8edf82f5abdb1a0ca14520d54e69"
|
||||
|
||||
[[files]]
|
||||
path = "examples/043-documentation-et-tests-de-conformite-examples.md"
|
||||
sha256 = "a0b99ab645787b6b0bbb2e83041888cfe2782fae0a9064fa2bfa5907b817b819"
|
||||
|
||||
[[files]]
|
||||
path = "examples/044-browser-futur-v3-examples.md"
|
||||
sha256 = "b1b63def42c8abebe943c89f618e16bcabd56e050bee760c9ba3b063dcf951d8"
|
||||
|
||||
[[files]]
|
||||
path = "examples/045-autres-backends-cibles-futur-v3-examples.md"
|
||||
sha256 = "92a6269861d51d9364eb76d4533cecf8ea36e8111f257b96f916d6fd63d91dbd"
|
||||
|
||||
[[files]]
|
||||
path = "examples/046-quantique-futur-lointain-reserve-examples.md"
|
||||
sha256 = "da2b95b3adf5431e4c32dcd631fd380a04b4173c98b2c638cad2e5f4564e131b"
|
||||
|
||||
[[files]]
|
||||
path = "examples/047-concepts-rejetes-ou-deconseilles-examples.md"
|
||||
sha256 = "0c347c9c622096fe026a76671c88258e37896b4e735b33fac2d5b01cc9a73fed"
|
||||
|
||||
[[files]]
|
||||
[[modified]]
|
||||
path = "examples/048-inventaire-des-points-v1-encore-ouverts-examples.md"
|
||||
sha256 = "6b9ce1377041b4bfd40a48eab0bb6a40b852e8c1c7cedde89a6329b6c495c192"
|
||||
sha256 = "0fe4bab707d7ec4a01e33dbf3ed65d146fa4b33b495da20f8cbe89b89113e5d3"
|
||||
|
||||
[[files]]
|
||||
[[modified]]
|
||||
path = "examples/049-elements-v1-reserves-mais-non-obligatoires-a-implementer-immediatement-examples.md"
|
||||
sha256 = "0fde247c9612c8ab74260c948c6d0d9a1648388dbfa5794fb7040a7ecaf7184e"
|
||||
sha256 = "85cb6954c4fc2f5dcb3be207d936a412f1633b81d704ad34c8d63c02cb5b4c5e"
|
||||
|
||||
[[files]]
|
||||
path = "examples/050-elements-futurs-v3-identifies-examples.md"
|
||||
sha256 = "49fa7b31de952d996fa8384ce1addc22a12f9d7a05f46d651e1eb2cf055d1c55"
|
||||
|
||||
[[files]]
|
||||
[[modified]]
|
||||
path = "examples/051-invariants-de-conception-examples.md"
|
||||
sha256 = "491525c8e45c5ef71f4bcc0420d3757ac004f5da47b5a21a29c5088f539bff68"
|
||||
sha256 = "bcf646572abee78a42bdb4e2452b2db53ea38c799cd6c131ec108be0bf6b76c2"
|
||||
|
||||
[[files]]
|
||||
[[modified]]
|
||||
path = "examples/052-priorite-de-specification-apres-0-2-9-examples.md"
|
||||
sha256 = "a663bdf02646d77ed5d870a0a8c24c477f4067ccc163e1c6ac55d46b368f539d"
|
||||
|
||||
[[files]]
|
||||
path = "profiles/language-compiler.md"
|
||||
sha256 = "705758ab8d40838bd9dc119e90183e69013258c028467d66df2678d676f915f1"
|
||||
|
||||
[[files]]
|
||||
path = "profiles/language-core.md"
|
||||
sha256 = "42f503a3ed5fa77e88c218c46523e4ef1b72e4104a2f8471597b4b900d492567"
|
||||
|
||||
[[files]]
|
||||
path = "profiles/platform.md"
|
||||
sha256 = "19440a7628f2e26d15fa8d33a4f0e5b8e5c936b3e23e293a9a27f16d2ff34322"
|
||||
sha256 = "9990f270f36c071dbd471e6955e40156164b8b75baa073668dc8e5e9c258d935"
|
||||
|
||||
@@ -49,6 +49,13 @@ wrapToInt32()
|
||||
|
||||
En revanche, pour `int32 -> int8`, `tryToInt8()`, `saturateToInt8()` et `wrapToInt8()` ont trois contrats différents et peuvent coexister.
|
||||
|
||||
|
||||
Une règle de composition complète cette non-redondance :
|
||||
|
||||
> Deux opérations ne sont fusionnées dans un même nom que si leur séparation en opérations Core successives modifierait la sémantique, perdrait de l'information ou empêcherait d'exprimer le même contrat.
|
||||
|
||||
Ainsi `value::floor()::tryToInt32()` rend inutile un alias `tryFloorToInt32()` si les deux formes sont strictement équivalentes.
|
||||
|
||||
## A.3. Nomenclature générale
|
||||
|
||||
| Code | Famille | Contrat |
|
||||
@@ -125,16 +132,16 @@ Légende :
|
||||
|---|---|---|---|---|
|
||||
| int8 | T | T | T | T |
|
||||
| int16 | E+R | T | T | T |
|
||||
| int32 | E+TR+S | E+R | T | T |
|
||||
| int64 | E+TR+S | E+R | E+R | T |
|
||||
| int128 | E+TR+S | E+R | E+R | E+R |
|
||||
| int256 | E+TR+S | E+TR+S | E+R | E+R |
|
||||
| int32 | E+TR+SR | E+R | T | T |
|
||||
| int64 | E+TR+SR | E+R | E+R | T |
|
||||
| int128 | E+TR+SR | E+R | E+R | E+R |
|
||||
| int256 | E+TR+SR | E+TR+SR | E+R | E+R |
|
||||
| uint8 | T | T | T | T |
|
||||
| uint16 | E+TR+S | T | T | T |
|
||||
| uint32 | E+TR+S | E+R | T | T |
|
||||
| uint64 | E+TR+S | E+R | E+R | T |
|
||||
| uint128 | E+TR+S | E+TR+S | E+R | E+R |
|
||||
| uint256 | E+TR+S | E+TR+S | E+R | E+R |
|
||||
| uint16 | E+TR+SR | T | T | T |
|
||||
| uint32 | E+TR+SR | E+R | T | T |
|
||||
| uint64 | E+TR+SR | E+R | E+R | T |
|
||||
| uint128 | E+TR+SR | E+TR+SR | E+R | E+R |
|
||||
| uint256 | E+TR+SR | E+TR+SR | E+R | E+R |
|
||||
|
||||
Contrats :
|
||||
|
||||
@@ -166,88 +173,128 @@ Légende :
|
||||
| Source \ Destination | float16 | float32 | float64 | float128 |
|
||||
|---|---|---|---|---|
|
||||
| float16 | — | T | T | T |
|
||||
| float32 | E+TR+S | — | T | T |
|
||||
| float64 | E+TR+S | E+TR+S | — | T |
|
||||
| float128 | E+TR+S | E+TR+S | E+TR+S | — |
|
||||
| float32 | E+TR+SR | — | T | T |
|
||||
| float64 | E+TR+SR | E+TR+SR | — | T |
|
||||
| float128 | E+TR+SR | E+TR+SR | E+TR+SR | — |
|
||||
|
||||
Règles :
|
||||
|
||||
- l'élargissement de format est exact au niveau de la valeur IEEE et utilise uniquement `toFloatXX()` ;
|
||||
- la réduction de format propose `tryToFloatXX()` pour exiger l'exactitude, `tryRoundToFloatXX()` pour accepter la perte de précision mais pas le débordement fini, et `saturatingRoundToFloatXX()` pour obtenir une opération totale sur le domaine flottant ;
|
||||
- `NaN`, `+Infinity`, `-Infinity`, `+0` et `-0` restent des catégories IEEE valides dans la destination ;
|
||||
- pour `NaN`, seule la propriété sémantique `isNaN(destination) == true` est garantie ; payload, signe et quiet/signaling bit ne sont pas garantis par une conversion de valeur ;
|
||||
- `tryToFloatXX()` accepte `NaN` et les infinities lorsque la destination est un type flottant Saselang, car ces catégories y sont représentables ;
|
||||
- `saturatingRoundToFloatXX()` ne transforme pas une infinité en valeur finie puisque l'infinité est elle-même représentable dans le format destination ; la saturation explicite concerne les valeurs **finies** hors du domaine fini destination ;
|
||||
- la conservation exacte du payload binaire d'un `NaN` n'est pas garantie par une conversion de valeur ; elle relève d'un éventuel contrat binaire distinct et de `bitcast` lorsque les tailles sont compatibles.
|
||||
- la conservation exacte d'une représentation binaire relève d'un contrat binaire distinct et de `bitcast` lorsque ses propres contraintes sont compatibles.
|
||||
|
||||
## A.8. Flottant -> entier : inventaire des politiques
|
||||
## A.8. Flottant -> entier : composition des politiques
|
||||
|
||||
Il n'existe jamais de simple `toIntXX()` ou `toUintXX()` depuis un flottant.
|
||||
|
||||
La conversion doit annoncer à la fois la politique de passage du réel à l'entier et, lorsque cela est pertinent, la politique de dépassement de domaine.
|
||||
La conversion stricte canonique est :
|
||||
|
||||
### A.8.1. Politique mathématique
|
||||
|
||||
| Famille | Sens |
|
||||
|---|---|
|
||||
| `Exact` | Accepte uniquement une valeur flottante finie déjà mathématiquement entière. |
|
||||
| `Floor` | Plus grand entier mathématique inférieur ou égal. |
|
||||
| `Ceil` | Plus petit entier mathématique supérieur ou égal. |
|
||||
| `Round` | Nearest, ties to even. |
|
||||
| `Truncate` | Suppression de la partie fractionnaire, donc direction zéro. |
|
||||
|
||||
### A.8.2. Politique de domaine destination
|
||||
|
||||
| Politique | Forme | Comportement |
|
||||
|---|---|---|
|
||||
| Checked | `try<Policy>ToTarget()` | `Err` sur `NaN`, infinité ou résultat hors plage. |
|
||||
| Saturating | `trySaturating<Policy>ToTarget()` | `Err` sur `NaN`; les infinités et résultats hors plage saturent aux bornes destination. |
|
||||
| Wrapping | `tryWrapping<Policy>ToTarget()` | `Err` sur `NaN` et infinité; les résultats entiers finis sont réduits modulo `2^N`. |
|
||||
|
||||
La famille complète potentiellement distincte pour une destination entière donnée est donc :
|
||||
|
||||
```saselang
|
||||
value::tryExactToInt32()
|
||||
value::tryFloorToInt32()
|
||||
value::tryCeilToInt32()
|
||||
value::tryRoundToInt32()
|
||||
value::tryTruncateToInt32()
|
||||
|
||||
value::trySaturatingExactToInt32()
|
||||
value::trySaturatingFloorToInt32()
|
||||
value::trySaturatingCeilToInt32()
|
||||
value::trySaturatingRoundToInt32()
|
||||
value::trySaturatingTruncateToInt32()
|
||||
|
||||
value::tryWrappingExactToInt32()
|
||||
value::tryWrappingFloorToInt32()
|
||||
value::tryWrappingCeilToInt32()
|
||||
value::tryWrappingRoundToInt32()
|
||||
value::tryWrappingTruncateToInt32()
|
||||
```text
|
||||
tryToIntXX()
|
||||
tryToUintXX()
|
||||
```
|
||||
|
||||
La même famille est applicable aux douze destinations entières `int8..int256` / `uint8..uint256` et aux quatre sources flottantes.
|
||||
Elle réussit uniquement si la valeur flottante est finie, mathématiquement entière, dans le domaine de la destination et exactement représentable comme entier destination. Sinon elle retourne `Err(NumericConversionError(...))`.
|
||||
|
||||
Cette section est volontairement exhaustive : lors de la stabilisation Core, certaines combinaisons pourront être supprimées si elles n'apportent aucune valeur pratique ou si une composition Core unique est préférée. Elles ne devront en revanche jamais être remplacées par une opération ambiguë.
|
||||
### A.8.1. Politiques mathématiques séparées
|
||||
|
||||
### A.8.3. Matrice flottant -> entier
|
||||
Les opérations Core :
|
||||
|
||||
Toutes les paires source/destination partagent actuellement le même ensemble de politiques candidates ; la table sert à garantir qu'aucun type n'est oublié.
|
||||
```text
|
||||
floor()
|
||||
ceil()
|
||||
round()
|
||||
truncate()
|
||||
```
|
||||
|
||||
restent des opérations sur le flottant et définissent chacune une politique mathématique unique.
|
||||
|
||||
Elles se composent ensuite avec les conversions :
|
||||
|
||||
```saselang
|
||||
value::floor()::tryToInt32()
|
||||
value::ceil()::tryToInt32()
|
||||
value::round()::tryToInt32()
|
||||
value::truncate()::tryToInt32()
|
||||
```
|
||||
|
||||
Cette composition remplace les alias redondants `tryFloorTo...`, `tryCeilTo...`, `tryRoundTo...` et `tryTruncateTo...`.
|
||||
|
||||
`round()` utilise la règle canonique **nearest, ties to even**.
|
||||
|
||||
### A.8.2. Dépassement de domaine
|
||||
|
||||
Les politiques de dépassement restent séparées de la politique mathématique.
|
||||
|
||||
Pour chaque destination entière, le Core peut exposer :
|
||||
|
||||
```text
|
||||
tryToTarget()
|
||||
trySaturateToTarget()
|
||||
tryWrapToTarget()
|
||||
```
|
||||
|
||||
avec les contrats suivants :
|
||||
|
||||
| Opération | Préconditions non liées à la plage | Politique de plage |
|
||||
|---|---|---|
|
||||
| `tryToTarget()` | valeur finie et mathématiquement entière | `Err` si hors plage |
|
||||
| `trySaturateToTarget()` | valeur finie et mathématiquement entière | borne à `Target::Min` / `Target::Max` |
|
||||
| `tryWrapToTarget()` | valeur finie et mathématiquement entière | modulo `2^N` selon le type entier destination |
|
||||
|
||||
Les politiques se composent :
|
||||
|
||||
```saselang
|
||||
value::floor()::trySaturateToInt32()
|
||||
value::round()::trySaturateToUint16()
|
||||
|
||||
value::truncate()::tryWrapToInt8()
|
||||
value::ceil()::tryWrapToUint64()
|
||||
```
|
||||
|
||||
Il n'existe pas de variantes combinées telles que `trySaturatingFloorToInt32()` ou `tryWrappingRoundToInt32()` lorsque la composition ci-dessus possède exactement la même sémantique.
|
||||
|
||||
### A.8.3. Matrice flottant -> entier après élimination des doublons
|
||||
|
||||
Pour chaque paire, la matrice conserve uniquement les politiques dont le résultat peut réellement différer sur une valeur source admissible.
|
||||
|
||||
Légende :
|
||||
|
||||
```text
|
||||
C
|
||||
tryToTarget() uniquement
|
||||
|
||||
CSW
|
||||
tryToTarget()
|
||||
trySaturateToTarget()
|
||||
tryWrapToTarget()
|
||||
```
|
||||
|
||||
| Source \ Destination | int8 | int16 | int32 | int64 | int128 | int256 | uint8 | uint16 | uint32 | uint64 | uint128 | uint256 |
|
||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||
| float16 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 |
|
||||
| float32 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 |
|
||||
| float64 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 |
|
||||
| float128 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 |
|
||||
| float16 | CSW | CSW | C | C | C | C | CSW | CSW | CSW | CSW | CSW | CSW |
|
||||
| float32 | CSW | CSW | CSW | CSW | CSW | C | CSW | CSW | CSW | CSW | CSW | CSW |
|
||||
| float64 | CSW | CSW | CSW | CSW | CSW | CSW | CSW | CSW | CSW | CSW | CSW | CSW |
|
||||
| float128 | CSW | CSW | CSW | CSW | CSW | CSW | CSW | CSW | CSW | CSW | CSW | CSW |
|
||||
|
||||
`F15` désigne les 15 opérations candidates listées en A.8.2 : 5 politiques mathématiques × 3 politiques de domaine.
|
||||
Justification :
|
||||
|
||||
- toutes les valeurs finies et mathématiquement entières de `float16` tiennent dans `int32` et les entiers signés plus larges ; saturation et wrapping n'apportent donc rien pour ces paires ;
|
||||
- toutes les valeurs finies et mathématiquement entières de `float32` tiennent dans `int256`, mais pas dans `int128` ou plus petit ;
|
||||
- pour toute destination non signée, les valeurs négatives rendent checked, saturation et wrapping distincts, même lorsque toute magnitude positive finie tient dans la destination ;
|
||||
- `float64` et `float128` disposent de valeurs finies dépassant le domaine de tous les entiers Saselang V1.
|
||||
|
||||
Cas particuliers :
|
||||
|
||||
- `+0` et `-0` produisent l'entier zéro lorsque l'opération choisie réussit ;
|
||||
- `NaN` n'a jamais de conversion entière implicite ni de valeur saturée/wrappée arbitraire ;
|
||||
- le wrapping est défini sur le résultat entier mathématique fini après application de `Exact/Floor/Ceil/Round/Truncate` ;
|
||||
- pour une destination non signée, la saturation d'une valeur négative aboutit à `0` ;
|
||||
- pour une destination signée, la saturation utilise `Target::Min` / `Target::Max`.
|
||||
- `+0` et `-0` donnent l'entier zéro ;
|
||||
- `NaN`, `+Infinity` et `-Infinity` échouent dans ces familles car ils ne satisfont pas la précondition de valeur finie et mathématiquement entière ;
|
||||
- pour une destination non signée, la saturation d'une valeur négative entière donne `0` ;
|
||||
- pour une destination signée, la saturation utilise `Target::Min` / `Target::Max` ;
|
||||
- le wrapping est appliqué au résultat entier mathématique fini selon modulo `2^N`.
|
||||
|
||||
## A.9. `bitcast` reste hors de cette matrice
|
||||
|
||||
@@ -271,13 +318,15 @@ int32 c = small::toInt32(); // OK
|
||||
|
||||
Les membres de conversion appartiennent au Core des primitives. Le compilateur doit pouvoir reconnaître leur contrat via les métadonnées/Core intrinsics nécessaires sans transformer chaque membre en syntaxe spéciale.
|
||||
|
||||
Une opération Core peut être :
|
||||
Pour les conversions fondamentales de cette matrice :
|
||||
|
||||
- universelle dans le profil Core minimal ;
|
||||
- disponible par émulation logicielle même sans instruction machine native ;
|
||||
- ou conditionnée par une capacité target lorsqu'elle dépend réellement d'une plateforme/backend.
|
||||
> si les types source et destination sont supportés par le target, les opérations non redondantes définies par la matrice sont Core-required.
|
||||
|
||||
Une optimisation matérielle ne constitue pas, à elle seule, une raison de rendre une opération absente : une implémentation logicielle conforme est préférable lorsqu'elle est raisonnable.
|
||||
L'absence d'une instruction matérielle native ne rend pas l'opération optionnelle lorsqu'une émulation logicielle conforme est raisonnablement possible.
|
||||
|
||||
Un target réduit peut ne pas exposer un type fondamental donné. Dans ce cas, l'indisponibilité doit porter sur le type/capacité fondamentale, pas sur une sélection arbitraire de ses conversions.
|
||||
|
||||
La nomenclature générale des capabilities et leurs niveaux sont définis au chapitre 40.
|
||||
|
||||
## A.12. Hiérarchie documentaire cible
|
||||
|
||||
@@ -294,15 +343,40 @@ Saselang Platform Documentation
|
||||
langage + Core + SDKs + extensions de plateforme
|
||||
```
|
||||
|
||||
À partir de `1.0.0-alpha`, la Bible sera distribuée sous forme d'une archive ZIP structurée avec sommaire, chapitres séparés, exemples/DO-DON'T par chapitre et annexes référencées.
|
||||
Depuis `0.2.12`, la Bible est distribuée sous forme d'une archive multifichier structurée avec sommaire, chapitres séparés, exemples/DO-DON'T par chapitre et annexes référencées.
|
||||
|
||||
## A.13. Points encore à valider
|
||||
## A.13. `NumericConversionError`
|
||||
|
||||
Les points suivants restent volontairement ouverts avant de rendre cette annexe normative :
|
||||
`NumericConversionError` est le nom de travail du `ResultError` Core des conversions récupérables.
|
||||
|
||||
1. confirmer la nomenclature exacte des formes composées `trySaturating...` et `tryWrapping...` pour `float -> integer` ;
|
||||
2. décider si les 15 opérations `float -> integer` doivent réellement être exposées directement ou si certaines doivent être obtenues par composition d'opérations Core sans créer d'alias sémantique ;
|
||||
3. préciser le contrat observable des payloads NaN lors des conversions `float -> float` ;
|
||||
4. définir les codes et informations minimales de `NumericConversionError` ;
|
||||
5. classer explicitement les capacités numériques en Core minimal obligatoire ou capacité conditionnelle de target.
|
||||
Les codes sémantiques V1 sont :
|
||||
|
||||
```text
|
||||
NotFinite
|
||||
NotIntegral
|
||||
OutOfRange
|
||||
Inexact
|
||||
```
|
||||
|
||||
L'erreur reste minimale et ne transporte pas automatiquement la valeur source, les types source/destination, le backend, un timestamp ou un mode d'arrondi.
|
||||
|
||||
## A.14. État de l'annexe
|
||||
|
||||
Les principes sémantiques de la matrice sont désormais largement figés :
|
||||
|
||||
```text
|
||||
non-redondance par paire
|
||||
composition plutôt qu'alias combinés
|
||||
règles float -> integer
|
||||
règles NaN / infinities / signed zero
|
||||
NumericConversionError
|
||||
disponibilité Core pour les types supportés
|
||||
émulation logicielle lorsque raisonnable
|
||||
```
|
||||
|
||||
Restent principalement à auditer lors de l'implémentation Core :
|
||||
|
||||
1. le listing mécanique exhaustif des membres concrets exposés par chaque primitive ;
|
||||
2. les noms définitifs des constantes/membres Core associés ;
|
||||
3. la représentation interne exacte des codes `NumericConversionError` ;
|
||||
4. les tests de conformité couvrant toutes les cellules de la matrice.
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
## 1.1 V1 — V1 REQUIS — FIGÉ
|
||||
|
||||
La V1 constitue le premier environnement réellement utilisable de Saselang.
|
||||
V1 constitue la première implémentation cohérente et réellement utilisable de Saselang, mais reste avant tout une **base/POC d'implémentation et de validation**. Elle n'est pas la baseline publique de compatibilité durable.
|
||||
|
||||
Objectifs :
|
||||
|
||||
@@ -15,7 +15,7 @@ analyse sémantique
|
||||
HIR
|
||||
Sase IR
|
||||
interpréteur
|
||||
a backend LLVM
|
||||
backend LLVM
|
||||
Core V1
|
||||
SDK initial
|
||||
manifests et workspaces
|
||||
@@ -29,6 +29,8 @@ LLVM est le premier backend compilé de V1.
|
||||
|
||||
La conception de Saselang ne doit cependant pas faire de LLVM une dépendance sémantique du frontend.
|
||||
|
||||
V1 doit être suffisamment complète pour révéler les erreurs de conception réelles du langage. Des corrections incompatibles restent possibles avant la baseline publique V3 lorsqu'elles sont motivées, documentées et répercutées de façon cohérente dans la Bible, le Core et la toolchain.
|
||||
|
||||
## 1.2 Couverture LLVM — V1 REQUIS — FIGÉ EN PRINCIPE
|
||||
|
||||
Le backend natif V1 doit rester suffisamment générique pour exploiter les architectures, formats objet et capacités que LLVM peut représenter.
|
||||
@@ -42,12 +44,11 @@ représentable par le backend
|
||||
mais non officiellement supportée par la toolchain Saselang
|
||||
```
|
||||
|
||||
## 1.3 V2 — SELF-HOSTING
|
||||
## 1.3 V2 — SELF-HOSTING / SECOND POC
|
||||
|
||||
La V2 reste également une génération interne. Elle a pour objectif principal la réécriture/self-hosting du compilateur, de l'interpréteur et des outils en Saselang. Des corrections architecturales incompatibles avec V1 restent acceptables si elles sont nécessaires et documentées.
|
||||
V2 est principalement la génération de self-hosting et le second POC structurel du langage.
|
||||
|
||||
|
||||
La V2 a pour objectif principal de réécrire progressivement en Saselang les composants réalisés en V1 :
|
||||
Elle a pour objectif de réécrire progressivement en Saselang les composants réalisés en V1 :
|
||||
|
||||
```text
|
||||
compiler frontend
|
||||
@@ -59,14 +60,32 @@ package/build tooling
|
||||
Core/SDK lorsque pertinent
|
||||
```
|
||||
|
||||
La V2 est d'abord une étape de validation du langage par lui-même, pas une excuse pour redéfinir arbitrairement la sémantique V1.
|
||||
Le self-hosting doit révéler les contraintes réelles d'un grand programme Saselang écrit en Saselang lui-même.
|
||||
|
||||
## 1.4 V3+ — FUTUR V3+
|
||||
Des corrections architecturales incompatibles avec V1 restent acceptables lorsqu'un besoin concret les justifie. V2 n'est cependant pas une excuse pour ajouter des mécanismes spéculatifs ou redéfinir arbitrairement la sémantique.
|
||||
|
||||
La première distribution générale du compilateur et de l'écosystème Saselang est envisagée à partir de V3 ou d'une génération ultérieure. C'est à partir de cette baseline publique que la compatibilité source, binaire et de tooling devra être protégée beaucoup plus strictement.
|
||||
Une fonctionnalité future peut être réservée avant son implémentation uniquement lorsqu'un besoin réel est déjà identifié et qu'il est utile de protéger son espace syntaxique ou sémantique. Saselang ne réserve pas des mécanismes purement hypothétiques « au cas où ».
|
||||
|
||||
## 1.4 V3+ — BASELINE PUBLIQUE
|
||||
|
||||
À partir de V3+, les efforts pourront se concentrer sur les autres environnements et backends :
|
||||
V3 est envisagée comme la première génération réellement déterminante pour la stabilité publique du langage et de son écosystème.
|
||||
|
||||
À partir de cette baseline, la compatibilité :
|
||||
|
||||
```text
|
||||
source
|
||||
Core
|
||||
tooling
|
||||
packages
|
||||
artifacts
|
||||
et, lorsque défini, ABI/binaire
|
||||
```
|
||||
|
||||
doit être protégée beaucoup plus strictement.
|
||||
|
||||
Les changements incompatibles deviennent alors des décisions exceptionnelles, versionnées et explicitement justifiées.
|
||||
|
||||
À partir de V3+, les efforts pourront également se concentrer sur les autres environnements et backends :
|
||||
|
||||
```text
|
||||
browser runtime / extension
|
||||
|
||||
@@ -116,7 +116,7 @@ Le modulo euclidien sera une opération explicite du Core/SDK.
|
||||
|
||||
La sémantique flottante suit IEEE pour les représentations et opérations applicables. Les littéraux sont arrondis vers le type flottant cible selon les règles IEEE normales ; Saselang n'exige pas qu'un littéral décimal soit représentable exactement.
|
||||
|
||||
Le tableau exact des cas particuliers, conversions, NaN, infinities, division par zéro et comportement de `%` flottant doit être normatif avant implémentation finale.
|
||||
Les règles de conversion, `NaN`, infinities et zéros signés déjà figées sont détaillées au chapitre 24 et dans l'annexe `A-numeric-conversions.md`. Les règles restantes des opérations flottantes, notamment division par zéro et comportement de `%`, doivent encore être fermées avant implémentation finale.
|
||||
|
||||
## 5.7 Littéraux numériques — V1 REQUIS — FIGÉ EN PRINCIPE
|
||||
|
||||
@@ -215,4 +215,20 @@ bitcast<float16>(value)
|
||||
|
||||
qui réinterprète les bits selon les règles de `bitcast`. Les règles de plage et d'échec des conversions sont différées au groupe casts/conversions.
|
||||
|
||||
## 5.8 Abstraction Core `Numeric` — V1 REQUIS — DIRECTION FIGÉE
|
||||
|
||||
Le Core doit fournir une véritable abstraction nominale `Numeric`.
|
||||
|
||||
`Numeric` n'est pas une catégorie syntaxique spéciale du compilateur et ne remplace pas les types primitifs. Elle sert à exprimer des contrats génériques réels :
|
||||
|
||||
```text
|
||||
where T implements Numeric
|
||||
```
|
||||
|
||||
Les primitives numériques Saselang satisfont le contrat `Numeric` via le Core.
|
||||
|
||||
Les types utilisateurs pourront satisfaire `Numeric` uniquement en implémentant explicitement son contrat lorsque celui-ci sera définitivement spécifié. La présence de méthodes ressemblant à des opérations numériques ne suffit jamais par duck typing.
|
||||
|
||||
La hiérarchie exacte de `Numeric`, ses membres et ses relations éventuelles avec `Comparable<T>` et les interfaces `Op...` restent à fermer lors de la définition exhaustive du Core.
|
||||
|
||||
---
|
||||
|
||||
@@ -16,8 +16,137 @@ enum
|
||||
union
|
||||
```
|
||||
|
||||
Le nom du fichier doit correspondre au nom du type.
|
||||
Le nom du fichier doit correspondre exactement au nom du type.
|
||||
|
||||
Le fichier ne contient pas d'autres types top-level ni de fonctions auxiliaires top-level.
|
||||
|
||||
## 7.3 Ordre source et découverte nominale — V1 REQUIS — FIGÉ
|
||||
|
||||
L'ordre textuel des fichiers ou des déclarations n'a pas de signification sémantique pour la résolution des types.
|
||||
|
||||
Le frontend doit d'abord construire un index des déclarations nominales accessibles avant de finaliser leurs dépendances sémantiques.
|
||||
|
||||
Saselang n'expose pas de syntaxe utilisateur de forward declaration telle que :
|
||||
|
||||
```text
|
||||
class Foo;
|
||||
struct Bar;
|
||||
```
|
||||
|
||||
Une forward declaration manuelle serait redondante avec la collecte nominale du compilateur et réintroduirait des problèmes de cohérence inutiles.
|
||||
|
||||
## 7.4 États conceptuels de complétude — V1 REQUIS — FIGÉ EN PRINCIPE
|
||||
|
||||
La spécification distingue conceptuellement :
|
||||
|
||||
```text
|
||||
nominalement connu
|
||||
identité du type, kind et paramètres génériques connus
|
||||
|
||||
sémantiquement complet
|
||||
déclaration, héritage, interfaces et contrats résolus
|
||||
|
||||
layout-complet
|
||||
représentation by-value, taille et alignement calculables lorsque nécessaires
|
||||
```
|
||||
|
||||
Ces états décrivent le travail du compilateur ; le programmeur n'a pas à gérer explicitement des « types incomplets » comme en C/C++.
|
||||
|
||||
Une déclaration générique peut être sémantiquement complète sans posséder un layout concret unique avant instanciation.
|
||||
|
||||
## 7.5 Dépendances de layout by-value — V1 REQUIS — FIGÉ
|
||||
|
||||
Toute dépendance récursive **par valeur** est interdite, même lorsqu'une instanciation particulière pourrait théoriquement avoir une taille nulle.
|
||||
|
||||
Exemples interdits :
|
||||
|
||||
```text
|
||||
struct A {
|
||||
A value;
|
||||
}
|
||||
```
|
||||
|
||||
```text
|
||||
struct A {
|
||||
B b;
|
||||
}
|
||||
|
||||
struct B {
|
||||
A a;
|
||||
}
|
||||
```
|
||||
|
||||
```text
|
||||
struct A {
|
||||
StaticArray<A, 0> values;
|
||||
}
|
||||
```
|
||||
|
||||
La longueur nulle ne crée aucune exception à la règle.
|
||||
|
||||
Les tuples, payloads d'enums algébriques, structs et autres composants réellement stockés inline participent au graphe de layout. `StaticArray<T,N>` participe également à ce graphe quel que soit `N`.
|
||||
|
||||
Le compilateur doit détecter les cycles directs et indirects du graphe by-value.
|
||||
|
||||
## 7.6 Classes et références — V1 REQUIS — FIGÉ EN PRINCIPE
|
||||
|
||||
Une valeur de type classe représente une référence d'objet et non une copie inline de l'objet complet.
|
||||
|
||||
Ainsi :
|
||||
|
||||
```text
|
||||
class A {
|
||||
B b;
|
||||
}
|
||||
|
||||
class B {
|
||||
A a;
|
||||
}
|
||||
```
|
||||
|
||||
ne crée pas un cycle de layout by-value.
|
||||
|
||||
Une classe peut néanmoins contenir des champs réellement by-value, par exemple un struct ; le layout de ces champs reste soumis aux règles normales du graphe de layout.
|
||||
|
||||
Le modèle mémoire exact des références sera détaillé au chapitre mémoire sans modifier cette propriété sémantique.
|
||||
|
||||
## 7.7 Interfaces et stockage — V1 REQUIS — FIGÉ
|
||||
|
||||
Une interface est un contrat et ne possède pas d'état d'instance propre.
|
||||
|
||||
Le fait qu'une classe, un struct ou un autre type admissible implémente une interface ne change jamais implicitement son modèle de stockage, son identité ou son mode d'indirection.
|
||||
|
||||
Un struct qui implémente une interface reste donc soumis exactement aux mêmes interdictions de récursivité by-value qu'un autre struct.
|
||||
|
||||
## 7.8 Héritage cyclique — V1 REQUIS — FIGÉ
|
||||
|
||||
Le graphe `extends` doit être acyclique.
|
||||
|
||||
Sont interdits :
|
||||
|
||||
```text
|
||||
class A extends B
|
||||
class B extends A
|
||||
```
|
||||
|
||||
et :
|
||||
|
||||
```text
|
||||
interface A extends B
|
||||
interface B extends A
|
||||
```
|
||||
|
||||
ainsi que tout cycle indirect.
|
||||
|
||||
Les diamants non cycliques restent autorisés pour les interfaces. Le fait d'atteindre un ancêtre commun par plusieurs chemins ne constitue pas un cycle.
|
||||
|
||||
Les diagnostics doivent identifier le graphe réellement fautif, par exemple :
|
||||
|
||||
```text
|
||||
cyclic inheritance
|
||||
recursive by-value layout
|
||||
```
|
||||
|
||||
et non produire un message générique de « circular dependency ».
|
||||
|
||||
---
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 14. Generics
|
||||
|
||||
## 14.1 Disponibilité — V1 REQUIS — FIGÉ
|
||||
## 14.1 Disponibilité et syntaxe — V1 REQUIS — FIGÉ
|
||||
|
||||
Les generics font partie de V1.
|
||||
|
||||
@@ -12,23 +12,554 @@ Result<T,E>
|
||||
OpAdd<Lhs,Rhs,Out>
|
||||
```
|
||||
|
||||
## 14.2 Points restant à fermer — V1 REQUIS — À FINALISER
|
||||
|
||||
Doivent encore être spécifiés précisément :
|
||||
Déclarations :
|
||||
|
||||
```text
|
||||
syntaxe des contraintes
|
||||
variance ou absence de variance
|
||||
contraintes multiples
|
||||
specialization éventuelle
|
||||
monomorphisation vs représentation partagée
|
||||
contraintes sur types primitifs
|
||||
const generics pour StaticArray<T,N>
|
||||
generic methods
|
||||
inférence éventuelle des arguments génériques à l'appel
|
||||
wildcards/existentials éventuels
|
||||
class Box<T> {
|
||||
...
|
||||
}
|
||||
|
||||
struct Pair<A, B> {
|
||||
...
|
||||
}
|
||||
|
||||
interface Comparable<T> {
|
||||
...
|
||||
}
|
||||
|
||||
func identity<T>(T value) -> T {
|
||||
return value;
|
||||
}
|
||||
```
|
||||
|
||||
Le type de retour ne doit pas devenir un moyen de résoudre une surcharge ambiguë.
|
||||
Les paramètres génériques sont toujours déclarés explicitement. Un identifiant inconnu n'est jamais transformé implicitement en paramètre générique.
|
||||
|
||||
Les noms de paramètres de type suivent la règle des noms de types et commencent donc par une lettre ASCII majuscule.
|
||||
|
||||
## 14.2 Instanciation explicite et absence de raw type — V1 REQUIS — FIGÉ
|
||||
|
||||
Un type générique doit être instancié avec ses arguments :
|
||||
|
||||
```text
|
||||
Box<int32>
|
||||
Pair<String, uint64>
|
||||
Result<Data, ParseError>
|
||||
```
|
||||
|
||||
La forme brute d'un type générique est invalide :
|
||||
|
||||
```text
|
||||
Box
|
||||
Result
|
||||
```
|
||||
|
||||
Il n'existe pas en V1 de déduction du type nominal à la construction comparable à la class template argument deduction de C++.
|
||||
|
||||
L'identité du type générique construit doit être explicite :
|
||||
|
||||
```text
|
||||
Box<int32> box = Box<int32>(42);
|
||||
```
|
||||
|
||||
## 14.3 Inférence à l'appel — V1 REQUIS — FIGÉ
|
||||
|
||||
L'inférence des paramètres génériques est autorisée pour un appel de fonction ou de méthode lorsque les arguments fournis déterminent directement et sans ambiguïté les paramètres.
|
||||
|
||||
```text
|
||||
func first<T>(T left, T right) -> T;
|
||||
|
||||
int32 a = ...;
|
||||
int32 b = ...;
|
||||
|
||||
int32 c = first(a, b);
|
||||
```
|
||||
|
||||
L'inférence :
|
||||
|
||||
- utilise les types des arguments d'appel ;
|
||||
- n'utilise jamais le type de destination ou le type de retour attendu ;
|
||||
- n'effectue aucune conversion implicite pour rechercher un « meilleur » type ;
|
||||
- reste une commodité locale d'appel et ne déduit jamais l'identité d'un type nominal construit.
|
||||
|
||||
Exemple interdit :
|
||||
|
||||
```text
|
||||
func create<T>() -> T;
|
||||
|
||||
String value = create(); // ERROR
|
||||
```
|
||||
|
||||
Il faut écrire :
|
||||
|
||||
```text
|
||||
String value = create<String>();
|
||||
```
|
||||
|
||||
Exemple sans promotion implicite :
|
||||
|
||||
```text
|
||||
func same<T>(T a, T b) -> bool;
|
||||
|
||||
int16 a = ...;
|
||||
int32 b = ...;
|
||||
|
||||
same(a, b); // ERROR
|
||||
same<int32>(a::toInt32(), b); // OK
|
||||
```
|
||||
|
||||
## 14.4 Contraintes nominales — V1 REQUIS — FIGÉ
|
||||
|
||||
V1 utilise deux formes nominales de contraintes :
|
||||
|
||||
```text
|
||||
where T extends SomeClass
|
||||
where T implements SomeInterface
|
||||
```
|
||||
|
||||
Une ligne `where` porte une contrainte.
|
||||
|
||||
Pour un même paramètre de type :
|
||||
|
||||
- au maximum une contrainte `extends` ;
|
||||
- plusieurs contraintes `implements` sont autorisées ;
|
||||
- toutes les contraintes sont cumulatives.
|
||||
|
||||
Exemple :
|
||||
|
||||
```text
|
||||
func process<T>(T value) -> Void
|
||||
where T extends Entity
|
||||
where T implements Serializable
|
||||
where T implements Comparable<T>
|
||||
{
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
L'ordre textuel des contraintes n'a pas de sémantique. Le formatter peut choisir un ordre canonique, notamment `extends` avant `implements`.
|
||||
|
||||
## 14.5 Contraintes dépendantes et récursives — V1 REQUIS — FIGÉ
|
||||
|
||||
Un paramètre générique peut apparaître dans le contrat portant sur un autre paramètre :
|
||||
|
||||
```text
|
||||
func compare<A, B>(A left, B right) -> Ordering
|
||||
where A implements Comparable<B>
|
||||
{
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
Les contraintes F-bounded sont autorisées :
|
||||
|
||||
```text
|
||||
where T implements Comparable<T>
|
||||
```
|
||||
|
||||
La satisfaction des contraintes est statique et nominale. Il n'existe pas de duck typing.
|
||||
|
||||
## 14.6 `Numeric` et absence de catégories syntaxiques — V1 REQUIS — FIGÉ EN PRINCIPE
|
||||
|
||||
V1 n'introduit pas de contraintes syntaxiques telles que :
|
||||
|
||||
```text
|
||||
where T is numeric
|
||||
where T is primitive
|
||||
where T is struct
|
||||
where T is class
|
||||
```
|
||||
|
||||
Lorsqu'une propriété correspond à une vraie abstraction réutilisable, elle doit être représentée par un contrat Core réel.
|
||||
|
||||
Exemple :
|
||||
|
||||
```text
|
||||
where T implements Numeric
|
||||
```
|
||||
|
||||
`Numeric` est une abstraction Core nominale ; elle n'est pas un prédicat spécial du compilateur.
|
||||
|
||||
Des contraintes intrinsèques peuvent exister dans certaines définitions compiler/Core-known sans devenir automatiquement de nouvelles constructions de la syntaxe utilisateur.
|
||||
|
||||
## 14.7 Contraintes redondantes et héritées — V1 REQUIS — FIGÉ
|
||||
|
||||
Une contrainte nominalement redondante est interdite.
|
||||
|
||||
Si :
|
||||
|
||||
```text
|
||||
interface B extends A {
|
||||
}
|
||||
```
|
||||
|
||||
alors :
|
||||
|
||||
```text
|
||||
where T implements B
|
||||
where T implements A
|
||||
```
|
||||
|
||||
est une erreur de déclaration redondante.
|
||||
|
||||
Lorsqu'un type générique hérite d'un parent générique contraint, les contraintes nécessaires doivent être répétées explicitement dans le contrat du type enfant.
|
||||
|
||||
```text
|
||||
open class Base<T>
|
||||
where T implements Serializable
|
||||
{
|
||||
}
|
||||
|
||||
class Child<T> extends Base<T>
|
||||
where T implements Serializable
|
||||
{
|
||||
}
|
||||
```
|
||||
|
||||
Le compilateur ne rend pas silencieusement le contrat local plus contraint en important des `where` invisibles depuis le parent.
|
||||
|
||||
Lorsqu'un enfant ferme le paramètre sur un type concret, il suffit que ce type concret satisfasse les contraintes du parent.
|
||||
|
||||
## 14.8 Héritage et interfaces génériques — V1 REQUIS — FIGÉ
|
||||
|
||||
Les arguments génériques d'un parent ou d'une interface sont toujours explicites :
|
||||
|
||||
```text
|
||||
class Box<T> implements Iterable<T> {
|
||||
...
|
||||
}
|
||||
|
||||
class StringList implements Iterable<String> {
|
||||
...
|
||||
}
|
||||
|
||||
class StringContainer extends Container<String> {
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
Une transformation finie des paramètres est autorisée lorsqu'elle ne constitue pas une récursivité générique interdite :
|
||||
|
||||
```text
|
||||
class PairBox<T> implements Container<Pair<T, T>> {
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
Après substitution, les règles normales de signature et de contrat s'appliquent.
|
||||
|
||||
Une même interface générique peut être atteinte avec plusieurs spécialisations lorsque les contrats résultants sont compatibles.
|
||||
|
||||
```text
|
||||
Consumer<String>
|
||||
Consumer<Array<uint8>>
|
||||
```
|
||||
|
||||
peuvent par exemple produire deux signatures distinctes.
|
||||
|
||||
Lorsque plusieurs chemins atteignent exactement la même spécialisation depuis la même origine, ils représentent une seule obligation :
|
||||
|
||||
> même contrat provenant de la même origine = une seule obligation, pas de faux conflit.
|
||||
|
||||
## 14.9 Overrides génériques — V1 REQUIS — FIGÉ
|
||||
|
||||
Une implémentation ou un override générique doit conserver une structure générique contractuellement équivalente :
|
||||
|
||||
```text
|
||||
même nombre de paramètres génériques
|
||||
même nature type/const de chaque paramètre
|
||||
mêmes relations de contraintes
|
||||
même contrat callable après substitution
|
||||
```
|
||||
|
||||
Les noms des paramètres génériques peuvent être alpha-renommés.
|
||||
|
||||
Une implémentation ne peut pas ajouter une contrainte qui réduirait l'ensemble des appels autorisés par le contrat parent, ni supprimer une contrainte si cela modifie ce contrat.
|
||||
|
||||
## 14.10 Variance — V1 REQUIS — FIGÉ
|
||||
|
||||
Tous les paramètres génériques sont invariants en V1.
|
||||
|
||||
Même si :
|
||||
|
||||
```text
|
||||
Dog extends Animal
|
||||
```
|
||||
|
||||
cela n'implique pas :
|
||||
|
||||
```text
|
||||
Container<Dog> -> Container<Animal>
|
||||
```
|
||||
|
||||
V1 n'introduit pas :
|
||||
|
||||
```text
|
||||
in T
|
||||
out T
|
||||
+T
|
||||
-T
|
||||
wildcards Java
|
||||
```
|
||||
|
||||
La variance déclarative pourra être réévaluée après le self-hosting ou pour V3 uniquement si un besoin concret est démontré. Elle n'est pas réservée « au cas où ».
|
||||
|
||||
## 14.11 Spécialisation et stratégie d'implémentation — V1 REQUIS — FIGÉ
|
||||
|
||||
V1 n'offre aucune spécialisation sémantique des generics.
|
||||
|
||||
Une définition générique possède une seule sémantique visible.
|
||||
|
||||
Le backend reste libre d'utiliser :
|
||||
|
||||
```text
|
||||
monomorphisation
|
||||
code partagé avec metadata
|
||||
stratégie hybride
|
||||
```
|
||||
|
||||
tant que le comportement observable Saselang reste identique.
|
||||
|
||||
La stratégie peut varier entre LLVM, interpréteur, JVM, WASM ou futurs backends.
|
||||
|
||||
## 14.12 Const generics — V1 REQUIS — FIGÉ
|
||||
|
||||
Syntaxe :
|
||||
|
||||
```text
|
||||
struct StaticArray<T, const uint64 N> {
|
||||
...
|
||||
}
|
||||
|
||||
struct Matrix<T, const uint64 Rows, const uint64 Columns> {
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
Les types admissibles d'un **paramètre const generic V1** sont uniquement :
|
||||
|
||||
```text
|
||||
bool
|
||||
char
|
||||
uint8
|
||||
uint16
|
||||
uint32
|
||||
uint64
|
||||
uint128
|
||||
uint256
|
||||
enum simple sans payload
|
||||
```
|
||||
|
||||
Les `int*` restent naturellement utilisables dans les expressions constantes générales du langage, mais ne sont pas nécessaires comme types de paramètres const generic V1.
|
||||
|
||||
Ne sont notamment pas admis comme types de paramètres const generic V1 :
|
||||
|
||||
```text
|
||||
int8..int256
|
||||
float16..float128
|
||||
String
|
||||
class
|
||||
struct arbitraire
|
||||
tuple
|
||||
enum avec payload
|
||||
```
|
||||
|
||||
Cette liste pourra évoluer en V2/V3 uniquement à partir de besoins concrets.
|
||||
|
||||
## 14.13 Expressions d'arguments const generic — V1 REQUIS — FIGÉ
|
||||
|
||||
Un argument const generic doit être entièrement déterminable à la compilation et produire exactement le type attendu après contextualisation normale des littéraux.
|
||||
|
||||
Sont admissibles directement :
|
||||
|
||||
```text
|
||||
littéraux
|
||||
const nommées déjà résolues
|
||||
paramètres const generic
|
||||
parenthèses
|
||||
opérateurs primitifs purs autorisés sur ces valeurs
|
||||
```
|
||||
|
||||
Exemples :
|
||||
|
||||
```text
|
||||
StaticArray<uint8, 32>
|
||||
StaticArray<uint8, PAGE_SIZE>
|
||||
StaticArray<uint8, PAGE_SIZE * 2>
|
||||
StaticArray<uint8, 1u64 << 12>
|
||||
```
|
||||
|
||||
Aucun appel de callable n'est admis directement dans `<...>` :
|
||||
|
||||
```text
|
||||
StaticArray<uint8, computeSize()> // ERROR
|
||||
StaticArray<uint8, value::toUint64()> // ERROR
|
||||
```
|
||||
|
||||
Sont également interdits directement dans l'argument const generic :
|
||||
|
||||
```text
|
||||
fonction
|
||||
méthode
|
||||
constructeur
|
||||
allocation
|
||||
I/O
|
||||
état runtime
|
||||
exception
|
||||
appel d'intrinsic exposé comme callable
|
||||
```
|
||||
|
||||
S'il faut calculer une valeur par un mécanisme plus élaboré, elle doit d'abord être matérialisée dans une `const` nommée d'un type admissible, selon les règles séparées d'initialisation compile-time :
|
||||
|
||||
```text
|
||||
const uint64 SIZE = ...;
|
||||
|
||||
StaticArray<uint8, SIZE>
|
||||
```
|
||||
|
||||
La validité de l'expression qui initialise `SIZE` relève des règles des `const`, pas des const generics.
|
||||
|
||||
Overflow, division par zéro, shift invalide ou autre faute statiquement prouvable restent des erreurs de compilation ordinaires. Aucun wrapping, saturation ou changement de règle n'est implicite dans un contexte const generic.
|
||||
|
||||
## 14.14 Identité et inférence des const generics — V1 REQUIS — FIGÉ
|
||||
|
||||
L'identité d'une instanciation utilise la valeur constante résultante et son type, pas le texte source.
|
||||
|
||||
Ainsi :
|
||||
|
||||
```text
|
||||
StaticArray<T, 2 + 2>
|
||||
StaticArray<T, 4>
|
||||
```
|
||||
|
||||
désignent la même instanciation lorsque le paramètre attendu est le même.
|
||||
|
||||
L'inférence d'un const generic est uniquement **structurelle**.
|
||||
|
||||
```text
|
||||
func length<T, const uint64 N>(StaticArray<T, N> array) -> uint64
|
||||
```
|
||||
|
||||
peut inférer `T` et `N` depuis un argument `StaticArray<int32, 32>`.
|
||||
|
||||
Le compilateur ne résout pas d'équation algébrique pour déduire un paramètre :
|
||||
|
||||
```text
|
||||
func strange<const uint64 N>(StaticArray<int32, N * 2> value)
|
||||
```
|
||||
|
||||
ne demande pas au compilateur de résoudre `N * 2 = 10`.
|
||||
|
||||
## 14.15 Contraintes de valeurs sur const generics — V1 REQUIS — FIGÉ
|
||||
|
||||
V1 n'introduit pas :
|
||||
|
||||
```text
|
||||
where N > 0
|
||||
where N <= 1024
|
||||
```
|
||||
|
||||
`where` reste réservé aux relations nominales de types.
|
||||
|
||||
Les contraintes de valeur nécessaires à un type Core/compiler-known sont vérifiées par le contrat de ce type sans créer en V1 un système général de preuve ou de contraintes arithmétiques.
|
||||
|
||||
## 14.16 Récursivité générique régulière — V1 REQUIS — FIGÉ
|
||||
|
||||
Une déclaration générique peut se référencer récursivement avec exactement les mêmes arguments :
|
||||
|
||||
```text
|
||||
class Node<T> {
|
||||
Nullable<Node<T>> next;
|
||||
}
|
||||
```
|
||||
|
||||
```text
|
||||
class BufferNode<T, const uint64 N> {
|
||||
Nullable<BufferNode<T, N>> next;
|
||||
}
|
||||
```
|
||||
|
||||
La récursivité reste naturellement soumise aux règles générales de layout : une récursivité by-value reste interdite.
|
||||
|
||||
## 14.17 Récursivité générique transformante — V1 REQUIS — FIGÉ
|
||||
|
||||
Une auto-référence à la même déclaration générique avec des arguments transformés est interdite immédiatement en V1 :
|
||||
|
||||
```text
|
||||
class Node<T> {
|
||||
Nullable<Node<Array<T>>> next; // ERROR
|
||||
}
|
||||
```
|
||||
|
||||
```text
|
||||
class BufferNode<T, const uint64 N> {
|
||||
Nullable<BufferNode<T, N + 1>> next; // ERROR
|
||||
}
|
||||
```
|
||||
|
||||
Pour les cycles indirects, le compilateur rejette le cycle lorsqu'une même déclaration générique est réatteinte avec des arguments différents.
|
||||
|
||||
Valide :
|
||||
|
||||
```text
|
||||
class A<T> {
|
||||
Nullable<B<T>> b;
|
||||
}
|
||||
|
||||
class B<T> {
|
||||
Nullable<A<T>> a;
|
||||
}
|
||||
```
|
||||
|
||||
Invalide :
|
||||
|
||||
```text
|
||||
class A<T> {
|
||||
Nullable<B<Array<T>>> b;
|
||||
}
|
||||
|
||||
class B<T> {
|
||||
Nullable<A<T>> a;
|
||||
}
|
||||
```
|
||||
|
||||
V1 ne tente pas de prouver qu'une transformation particulière finirait éventuellement par se stabiliser.
|
||||
|
||||
## 14.18 Récursivité des callables génériques — V1 REQUIS — FIGÉ
|
||||
|
||||
La récursivité normale des fonctions et méthodes est autorisée et le compilateur ne cherche pas à prouver leur terminaison générale.
|
||||
|
||||
Une callable générique récursive doit cependant rappeler la même instanciation générique.
|
||||
|
||||
```text
|
||||
func recurse<T>(T value) -> Void {
|
||||
recurse<T>(value); // OK
|
||||
}
|
||||
```
|
||||
|
||||
La polymorphic recursion transformante est interdite en V1 :
|
||||
|
||||
```text
|
||||
func recurse<T>(T value) -> Void {
|
||||
recurse<Array<T>>(...); // ERROR
|
||||
}
|
||||
```
|
||||
|
||||
La même règle s'applique aux cycles mutuellement récursifs de callables génériques.
|
||||
|
||||
## 14.19 Parameter packs et mécanismes différés — V1 REQUIS — FIGÉ
|
||||
|
||||
V1 n'introduit pas :
|
||||
|
||||
```text
|
||||
<T...>
|
||||
<const uint64... N>
|
||||
generic parameter packs
|
||||
wildcards
|
||||
specialization
|
||||
variance déclarative
|
||||
contraintes négatives
|
||||
```
|
||||
|
||||
Ces mécanismes ne sont pas réservés sans besoin démontré.
|
||||
|
||||
---
|
||||
|
||||
@@ -87,31 +87,168 @@ Une forme n'existe que si elle apporte une sémantique observable différente d'
|
||||
|
||||
Ainsi, lorsqu'un `toTarget()` exact et total existe, les variantes `tryToTarget()`, `saturateToTarget()` ou `wrapToTarget()` qui produiraient exactement le même résultat pour tout le domaine source sont absentes.
|
||||
|
||||
Règle de composition : deux opérations Core ne sont fusionnées dans un même nom que si leur séparation en opérations successives modifierait la sémantique, perdrait de l'information ou empêcherait d'exprimer le même contrat.
|
||||
|
||||
Lorsqu'une composition existante est strictement équivalente, aucun alias combiné n'est ajouté au Core.
|
||||
|
||||
## 24.6 `float -> integer` — V1 REQUIS — DIRECTION FIGÉE
|
||||
|
||||
Un flottant ne possède jamais un simple `toIntXX()` ou `toUintXX()`.
|
||||
|
||||
La politique de passage du réel à l'entier doit être explicite, par exemple :
|
||||
La conversion exacte stricte utilise :
|
||||
|
||||
```text
|
||||
tryExactToInt32()
|
||||
tryFloorToInt32()
|
||||
tryCeilToInt32()
|
||||
tryRoundToInt32()
|
||||
tryTruncateToInt32()
|
||||
tryToIntXX()
|
||||
tryToUintXX()
|
||||
```
|
||||
|
||||
Les variantes saturantes ou wrapping, lorsqu'elles sont retenues, doivent également annoncer explicitement la politique mathématique appliquée.
|
||||
Elle réussit uniquement si la valeur source est finie, mathématiquement entière et représentable exactement dans le type destination. Sinon elle retourne `Result::Err(NumericConversionError(...))`.
|
||||
|
||||
Les politiques mathématiques de traitement de la partie fractionnaire restent des opérations Core séparées :
|
||||
|
||||
```text
|
||||
floor()
|
||||
ceil()
|
||||
round()
|
||||
truncate()
|
||||
```
|
||||
|
||||
Elles se composent avec la conversion :
|
||||
|
||||
```text
|
||||
value::floor()::tryToInt32()
|
||||
value::ceil()::tryToInt32()
|
||||
value::round()::tryToInt32()
|
||||
value::truncate()::tryToInt32()
|
||||
```
|
||||
|
||||
Saselang n'introduit donc pas les alias redondants `tryFloorToInt32()`, `tryCeilToInt32()`, `tryRoundToInt32()` ou `tryTruncateToInt32()` lorsque ces compositions possèdent exactement la même sémantique.
|
||||
|
||||
Les politiques de dépassement de domaine suivent la même règle :
|
||||
|
||||
```text
|
||||
value::floor()::trySaturateToInt32()
|
||||
value::round()::tryWrapToInt32()
|
||||
```
|
||||
|
||||
`trySaturateToIntXX()` exige une valeur finie et mathématiquement entière, puis sature aux bornes du type destination. Les échecs qui ne relèvent pas de la plage, par exemple `NaN`, une infinité ou une valeur fractionnaire, restent des `NumericConversionError`.
|
||||
|
||||
`tryWrapToIntXX()` exige également une valeur finie et mathématiquement entière, puis applique le wrapping entier modulo `2^N` défini par Saselang.
|
||||
|
||||
Une méthode combinée reste admise lorsqu'une décomposition changerait le contrat ou perdrait l'information nécessaire. C'est notamment le cas de `saturatingRoundToFloat32()` pour certains narrowings flottants : un `roundToFloat32()` séparé pourrait échouer avant que la saturation ne puisse être appliquée.
|
||||
|
||||
Aucun comportement de conversion ne dépend d'un profil, d'un linter ou d'un backend.
|
||||
|
||||
## 24.7 `NumericConversionError` — V1 REQUIS — NOM DE TRAVAIL
|
||||
## 24.7 `float -> float`, valeurs IEEE spéciales — V1 REQUIS — FIGÉ
|
||||
|
||||
Toute conversion de valeur flottante préserve les catégories sémantiques suivantes lorsque la destination est un type flottant Saselang :
|
||||
|
||||
```text
|
||||
NaN -> NaN
|
||||
+Infinity -> +Infinity
|
||||
-Infinity -> -Infinity
|
||||
+0 -> +0
|
||||
-0 -> -0
|
||||
```
|
||||
|
||||
Pour `NaN`, la conversion garantit uniquement que la destination reste `NaN`.
|
||||
|
||||
Elle ne garantit pas lors d'une conversion de valeur :
|
||||
|
||||
```text
|
||||
payload NaN
|
||||
quiet/signaling bit
|
||||
signe du NaN
|
||||
représentation binaire exacte
|
||||
```
|
||||
|
||||
Ces propriétés relèvent d'un éventuel contrat binaire distinct ; `bitcast<T>` ne peut les préserver que lorsque ses propres contraintes, notamment de taille, sont satisfaites.
|
||||
|
||||
`tryToFloatXX()` traite `NaN` et les infinités comme des valeurs sémantiques représentables du type flottant destination. Le mot « exact » désigne ici l'exactitude de la valeur sémantique Saselang, pas l'identité bit-à-bit d'un payload NaN.
|
||||
|
||||
Pour une valeur finie :
|
||||
|
||||
```text
|
||||
tryToFloatXX()
|
||||
exige une représentation exacte
|
||||
|
||||
tryRoundToFloatXX()
|
||||
accepte l'arrondi canonique
|
||||
refuse une valeur finie hors domaine fini destination
|
||||
|
||||
saturatingRoundToFloatXX()
|
||||
accepte l'arrondi canonique
|
||||
sature une valeur finie hors domaine vers +/-Target::Max
|
||||
```
|
||||
|
||||
Les infinités ne sont pas saturées puisqu'elles sont déjà des valeurs représentables du format flottant destination.
|
||||
|
||||
## 24.8 `NumericConversionError` — V1 REQUIS — NOM DE TRAVAIL / CODES FIGÉS
|
||||
|
||||
`NumericConversionError` est retenu comme nom de travail du `ResultError` Core utilisé par les conversions numériques récupérables.
|
||||
|
||||
Son nom définitif, ses codes et son état minimal pourront encore être ajustés lors de la finalisation du Core sans modifier les principes de conversion de ce chapitre.
|
||||
Les catégories sémantiques V1 sont :
|
||||
|
||||
## 24.8 Matrice exhaustive — ANNEXE NORMATIVE EN COURS DE GEL
|
||||
```text
|
||||
NotFinite
|
||||
NotIntegral
|
||||
OutOfRange
|
||||
Inexact
|
||||
```
|
||||
|
||||
Sens :
|
||||
|
||||
```text
|
||||
NotFinite
|
||||
NaN ou +/-Infinity lorsqu'une valeur finie est requise
|
||||
|
||||
NotIntegral
|
||||
float -> integer alors que la valeur n'est pas mathématiquement entière
|
||||
|
||||
OutOfRange
|
||||
valeur mathématique hors du domaine de la destination
|
||||
|
||||
Inexact
|
||||
valeur dans le domaine destination mais non représentable exactement
|
||||
alors que l'opération exige l'exactitude
|
||||
```
|
||||
|
||||
`NumericConversionError` reste volontairement généraliste et minimal. Il n'ajoute pas automatiquement :
|
||||
|
||||
```text
|
||||
sourceType
|
||||
targetType
|
||||
sourceValue
|
||||
timestamp
|
||||
backend
|
||||
roundingMode
|
||||
```
|
||||
|
||||
au-delà de l'état commun fourni par `ResultError`.
|
||||
|
||||
Le nom concret et la représentation numérique interne des codes pourront encore être ajustés avant stabilisation publique, mais les catégories sémantiques ci-dessus font partie du contrat V1.
|
||||
|
||||
## 24.9 Réduction anti-doublon par paire — V1 REQUIS — FIGÉ
|
||||
|
||||
La matrice examine chaque paire `Source -> Target` et n'expose que les opérations dont le comportement peut réellement être distingué sur le domaine source.
|
||||
|
||||
Ainsi, pour une paire `float -> integer` dont toutes les valeurs finies mathématiquement entières sont déjà dans le domaine signé destination, `trySaturateToTarget()` et `tryWrapToTarget()` seraient des doublons de `tryToTarget()` et n'existent pas.
|
||||
|
||||
Pour une destination non signée, les valeurs négatives suffisent généralement à rendre les politiques checked, saturating et wrapping distinctes.
|
||||
|
||||
La matrice exhaustive en annexe est normative sur ce point.
|
||||
|
||||
## 24.10 Disponibilité Core et target — V1 REQUIS — FIGÉ EN PRINCIPE
|
||||
|
||||
Les conversions fondamentales de la matrice sont des capacités Core obligatoires dès lors que les types source et destination sont supportés par le target.
|
||||
|
||||
L'absence d'une instruction matérielle native ne justifie pas l'absence d'une conversion si une émulation logicielle conforme est raisonnablement possible.
|
||||
|
||||
Un target réduit peut ne pas supporter un type fondamental donné. Dans ce cas l'indisponibilité porte sur le type/capacité fondamentale, pas sur une sélection arbitraire de ses méthodes de conversion.
|
||||
|
||||
Voir également le chapitre 40.
|
||||
|
||||
## 24.11 Matrice exhaustive — ANNEXE NORMATIVE EN COURS DE GEL
|
||||
|
||||
L'inventaire source → destination des opérations de conversion est maintenu séparément afin d'éviter les oublis, doublons et incohérences.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
---
|
||||
|
||||
@@ -189,7 +189,76 @@ Le modèle doit aussi permettre de décrire les capacités atomiques pertinentes
|
||||
|
||||
Une capability statique signifie que l'environnement fournit la capacité ; elle ne garantit pas qu'une opération runtime particulière réussira.
|
||||
|
||||
## 40.9 Compatibilité target/dépendance — V1 REQUIS — FIGÉE EN PRINCIPE
|
||||
## 40.9 Propriétaires et identifiants de capabilities — V1 REQUIS — DIRECTION FIGÉE
|
||||
|
||||
Les capabilities utilisent une nomenclature hiérarchique commune, ASCII, en minuscules, séparée par `.`.
|
||||
|
||||
Le premier segment identifie le propriétaire sémantique :
|
||||
|
||||
```text
|
||||
language.*
|
||||
core.*
|
||||
target.*
|
||||
platform.*
|
||||
sdk.*
|
||||
```
|
||||
|
||||
Exemples conceptuels :
|
||||
|
||||
```text
|
||||
language.exceptions
|
||||
core.numeric.float128
|
||||
core.collections.array
|
||||
target.atomic.int64
|
||||
target.simd.float32
|
||||
platform.filesystem
|
||||
platform.network
|
||||
sdk.logging
|
||||
```
|
||||
|
||||
Cette organisation permet de regrouper les capacités par propriétaire et d'éviter un registre global plat.
|
||||
|
||||
Les noms exacts et le registre exhaustif seront stabilisés avec le Core/SDK, mais un même concept ne doit pas recevoir des conventions concurrentes telles que `hasFloat128`, `supports_float128` et `numeric-f128`.
|
||||
|
||||
Les packages utilisateurs ne doivent pas usurper les espaces de noms de capabilities réservés à la toolchain/Core/SDK.
|
||||
|
||||
## 40.10 Niveaux de capacité — V1 REQUIS — FIGÉ EN PRINCIPE
|
||||
|
||||
Trois niveaux conceptuels sont distingués :
|
||||
|
||||
```text
|
||||
Language-required
|
||||
sémantique nécessaire à tout compilateur Saselang conforme
|
||||
|
||||
Core-required-for-supported-type
|
||||
contrat Core obligatoire dès que le type/capacité fondamentale existe
|
||||
sur le target
|
||||
|
||||
Core/target optional capability
|
||||
fonctionnalité réellement optionnelle ou spécifique d'un environnement
|
||||
```
|
||||
|
||||
Exemple : si un target supporte `float128`, les conversions Core fondamentales définies par la matrice numérique pour `float128` doivent être disponibles.
|
||||
|
||||
Le target ne peut pas exposer `float128` tout en supprimant arbitrairement certaines conversions fondamentales simplement parce que le matériel n'offre pas une instruction native correspondante.
|
||||
|
||||
## 40.11 Émulation logicielle — V1 REQUIS — FIGÉ
|
||||
|
||||
Lorsqu'une fonctionnalité fondamentale peut raisonnablement être émulée de façon conforme, l'absence d'un support matériel natif ne la rend pas indisponible.
|
||||
|
||||
```text
|
||||
instruction native disponible
|
||||
lowering/backend direct ou optimisé
|
||||
|
||||
instruction native absente
|
||||
implémentation logicielle conforme
|
||||
```
|
||||
|
||||
La différence doit porter sur les performances, pas sur la sémantique visible.
|
||||
|
||||
Un target réellement contraint peut ne pas fournir un type/capacité fondamentale entière. Dans ce cas, le diagnostic doit porter sur cette capacité ou ce type, plutôt que sur l'absence aléatoire d'une méthode secondaire.
|
||||
|
||||
## 40.12 Compatibilité target/dépendance — V1 REQUIS — FIGÉE EN PRINCIPE
|
||||
|
||||
Un package ou une dépendance peut déclarer des contraintes de target/platform/ABI/capabilities.
|
||||
|
||||
|
||||
@@ -13,21 +13,18 @@ Restent à fermer :
|
||||
- matrice finale des préfixes de littéraux combinables (`i`, `r`, `b`, `c`, `u8/u16/u32`, `t`, etc.) et leur disponibilité V1/V2 ;
|
||||
- limite normative éventuelle du nombre de `#` des raw strings ;
|
||||
- grammaire syntaxique complète au-delà des blocs/statements déjà figés ;
|
||||
- syntaxe exacte des generics et contraintes ;
|
||||
- syntaxe exacte des annotations/métadonnées de code lorsqu'elles seront retenues.
|
||||
|
||||
## 48.2 Types
|
||||
|
||||
- domaine exact des types admissibles à `Nullable<T>` avec le modèle mémoire/FFI ;
|
||||
- finalisation de la matrice exhaustive des conversions numériques Core et de ses noms composés ;
|
||||
- règles de sous-typage interface/class ;
|
||||
- generics complets ;
|
||||
- const generics ;
|
||||
- audit mécanique final de la surface Core des conversions numériques à partir de la matrice désormais largement figée ;
|
||||
- règles de sous-typage interface/class au-delà des règles génériques déjà fixées ;
|
||||
- callable/function types ;
|
||||
- lambdas/closures ;
|
||||
- variadiques (un seul variadique prévu) ;
|
||||
- String/index Unicode ;
|
||||
- exact float semantics.
|
||||
- exact float semantics hors conversions déjà figées (opérations arithmétiques IEEE restantes, `%`, division par zéro, etc.).
|
||||
|
||||
## 48.3 Mémoire
|
||||
|
||||
|
||||
@@ -17,4 +17,8 @@ noms nécessaires pour éviter collisions futures
|
||||
|
||||
Un élément réservé ne doit pas être réutilisé pour une fonctionnalité incompatible.
|
||||
|
||||
Une réservation doit correspondre à un besoin déjà identifié ou à une compatibilité future concrètement anticipée. Saselang ne réserve pas de syntaxe, de types ou de mécanismes purement spéculatifs « au cas où ».
|
||||
|
||||
V1 et V2 servent de bases/POC permettant encore de corriger les choix du langage avant la baseline publique V3.
|
||||
|
||||
---
|
||||
|
||||
@@ -19,5 +19,9 @@ Les futures décisions doivent respecter les invariants suivants :
|
||||
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.**
|
||||
|
||||
---
|
||||
|
||||
@@ -1,23 +1,27 @@
|
||||
# 52. Priorité de spécification après 0.2.12
|
||||
# 52. Priorité de spécification après 0.2.14
|
||||
|
||||
Pour transformer cette Bible en spécification V1 directement implémentable, l'ordre recommandé est :
|
||||
Pour transformer cette Bible en spécification V1 directement implémentable, l'ordre recommandé devient :
|
||||
|
||||
```text
|
||||
1. terminer casts/conversions numériques + matrice Core
|
||||
2. generics + contraintes + const generics
|
||||
3. String/Unicode + collections + Range
|
||||
4. lambdas/closures + callable model
|
||||
5. async/concurrency décision V1
|
||||
6. modèle mémoire + allocator + pointers + unsafe
|
||||
7. fautes runtime + construction/destruction cleanup
|
||||
8. Core V1 exact et capacités target
|
||||
9. SDK V1 initial et frontières Core/SDK
|
||||
10. FFI C exacte
|
||||
11. reflection/metadata/tests/tooling
|
||||
12. grammaire syntaxique complète et audit lexical final
|
||||
1. String/Unicode + collections + Range
|
||||
2. lambdas/closures + callable model
|
||||
3. async/concurrency décision V1
|
||||
4. modèle mémoire + allocator + pointers + unsafe
|
||||
5. fautes runtime + construction/destruction cleanup
|
||||
6. Core V1 exact : Numeric, collections, erreurs, TypeInfo et autres contrats
|
||||
7. capacités target et registre canonique des capability identifiers
|
||||
8. SDK V1 initial et frontières Core/SDK
|
||||
9. FFI C exacte
|
||||
10. reflection/metadata/tests/tooling
|
||||
11. grammaire syntaxique complète et audit lexical final
|
||||
12. audit mécanique des generics/const generics/récursivité et conversions
|
||||
13. audit complet de toutes les sections V1 REQUIS — À FINALISER
|
||||
14. consolidation examples / DO-DON'T / conformance tests
|
||||
15. plan d'implémentation du compilateur/interpréteur V1
|
||||
```
|
||||
|
||||
Les generics, const generics, règles principales de récursivité, casts/conversions et matrice numérique sont désormais suffisamment fermés pour quitter leur phase de conception principale. Ils devront naturellement être réaudités pendant l'implémentation et la préparation de la baseline publique V3.
|
||||
|
||||
La Bible ne doit être déclarée « V1 specification complete » qu'après fermeture de tous les points V1 REQUIS — À FINALISER qui affectent la grammaire ou la sémantique observable.
|
||||
|
||||
---
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Exemples / DO-DON'T — Chapitre 1 — Trajectoire d'implémentation
|
||||
|
||||
> Document compagnon non normatif tant qu'une règle n'est pas explicitement référencée comme normative par le chapitre.
|
||||
> Document compagnon. Les exemples illustrent les règles du chapitre ; la formulation normative reste dans le chapitre lui-même.
|
||||
|
||||
## Exemples actuellement présents dans le chapitre
|
||||
## Exemples extraits du chapitre
|
||||
|
||||
### Exemple 1
|
||||
|
||||
@@ -15,7 +15,7 @@ analyse sémantique
|
||||
HIR
|
||||
Sase IR
|
||||
interpréteur
|
||||
a backend LLVM
|
||||
backend LLVM
|
||||
Core V1
|
||||
SDK initial
|
||||
manifests et workspaces
|
||||
@@ -44,6 +44,17 @@ Core/SDK lorsque pertinent
|
||||
|
||||
### Exemple 4
|
||||
|
||||
```text
|
||||
source
|
||||
Core
|
||||
tooling
|
||||
packages
|
||||
artifacts
|
||||
et, lorsque défini, ABI/binaire
|
||||
```
|
||||
|
||||
### Exemple 5
|
||||
|
||||
```text
|
||||
browser runtime / extension
|
||||
browser chunks/bundling
|
||||
@@ -60,4 +71,4 @@ cibles spécialisées
|
||||
|
||||
## DO / DON'T / WHY / compiler error / edge cases
|
||||
|
||||
La couverture structurée de cette section sera enrichie au fur et à mesure de la fermeture des règles du chapitre. La migration `0.2.12` conserve volontairement les exemples historiques dans le chapitre afin de ne perdre aucun contexte normatif.
|
||||
À consolider progressivement avant la baseline publique V3 et à transformer, lorsque pertinent, en tests de conformité de la toolchain.
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Exemples / DO-DON'T — Chapitre 5 — Types primitifs
|
||||
|
||||
> Document compagnon non normatif tant qu'une règle n'est pas explicitement référencée comme normative par le chapitre.
|
||||
> Document compagnon. Les exemples illustrent les règles du chapitre ; la formulation normative reste dans le chapitre lui-même.
|
||||
|
||||
## Exemples actuellement présents dans le chapitre
|
||||
## Exemples extraits du chapitre
|
||||
|
||||
### Exemple 1
|
||||
|
||||
@@ -144,6 +144,12 @@ f16 f32 f64 f128
|
||||
bitcast<float16>(value)
|
||||
```
|
||||
|
||||
### Exemple 18
|
||||
|
||||
```text
|
||||
where T implements Numeric
|
||||
```
|
||||
|
||||
## DO / DON'T / WHY / compiler error / edge cases
|
||||
|
||||
La couverture structurée de cette section sera enrichie au fur et à mesure de la fermeture des règles du chapitre. La migration `0.2.12` conserve volontairement les exemples historiques dans le chapitre afin de ne perdre aucun contexte normatif.
|
||||
À consolider progressivement avant la baseline publique V3 et à transformer, lorsque pertinent, en tests de conformité de la toolchain.
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Exemples / DO-DON'T — Chapitre 7 — Types nominaux et fichiers `.saseltype`
|
||||
|
||||
> Document compagnon non normatif tant qu'une règle n'est pas explicitement référencée comme normative par le chapitre.
|
||||
> Document compagnon. Les exemples illustrent les règles du chapitre ; la formulation normative reste dans le chapitre lui-même.
|
||||
|
||||
## Exemples actuellement présents dans le chapitre
|
||||
## Exemples extraits du chapitre
|
||||
|
||||
### Exemple 1
|
||||
|
||||
@@ -14,6 +14,87 @@ enum
|
||||
union
|
||||
```
|
||||
|
||||
### Exemple 2
|
||||
|
||||
```text
|
||||
class Foo;
|
||||
struct Bar;
|
||||
```
|
||||
|
||||
### Exemple 3
|
||||
|
||||
```text
|
||||
nominalement connu
|
||||
identité du type, kind et paramètres génériques connus
|
||||
|
||||
sémantiquement complet
|
||||
déclaration, héritage, interfaces et contrats résolus
|
||||
|
||||
layout-complet
|
||||
représentation by-value, taille et alignement calculables lorsque nécessaires
|
||||
```
|
||||
|
||||
### Exemple 4
|
||||
|
||||
```text
|
||||
struct A {
|
||||
A value;
|
||||
}
|
||||
```
|
||||
|
||||
### Exemple 5
|
||||
|
||||
```text
|
||||
struct A {
|
||||
B b;
|
||||
}
|
||||
|
||||
struct B {
|
||||
A a;
|
||||
}
|
||||
```
|
||||
|
||||
### Exemple 6
|
||||
|
||||
```text
|
||||
struct A {
|
||||
StaticArray<A, 0> values;
|
||||
}
|
||||
```
|
||||
|
||||
### Exemple 7
|
||||
|
||||
```text
|
||||
class A {
|
||||
B b;
|
||||
}
|
||||
|
||||
class B {
|
||||
A a;
|
||||
}
|
||||
```
|
||||
|
||||
### Exemple 8
|
||||
|
||||
```text
|
||||
class A extends B
|
||||
class B extends A
|
||||
```
|
||||
|
||||
### Exemple 9
|
||||
|
||||
```text
|
||||
interface A extends B
|
||||
interface B extends A
|
||||
```
|
||||
|
||||
### Exemple 10
|
||||
|
||||
```text
|
||||
cyclic inheritance
|
||||
recursive by-value layout
|
||||
```
|
||||
|
||||
## DO / DON'T / WHY / compiler error / edge cases
|
||||
|
||||
La couverture structurée de cette section sera enrichie au fur et à mesure de la fermeture des règles du chapitre. La migration `0.2.12` conserve volontairement les exemples historiques dans le chapitre afin de ne perdre aucun contexte normatif.
|
||||
À consolider progressivement avant la baseline publique V3 et à transformer, lorsque pertinent, en tests de conformité de la toolchain.
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Exemples / DO-DON'T — Chapitre 14 — Generics
|
||||
|
||||
> Document compagnon non normatif tant qu'une règle n'est pas explicitement référencée comme normative par le chapitre.
|
||||
> Document compagnon. Les exemples illustrent les règles du chapitre ; la formulation normative reste dans le chapitre lui-même.
|
||||
|
||||
## Exemples actuellement présents dans le chapitre
|
||||
## Exemples extraits du chapitre
|
||||
|
||||
### Exemple 1
|
||||
|
||||
@@ -15,18 +15,424 @@ OpAdd<Lhs,Rhs,Out>
|
||||
### Exemple 2
|
||||
|
||||
```text
|
||||
syntaxe des contraintes
|
||||
variance ou absence de variance
|
||||
contraintes multiples
|
||||
specialization éventuelle
|
||||
monomorphisation vs représentation partagée
|
||||
contraintes sur types primitifs
|
||||
const generics pour StaticArray<T,N>
|
||||
generic methods
|
||||
inférence éventuelle des arguments génériques à l'appel
|
||||
wildcards/existentials éventuels
|
||||
class Box<T> {
|
||||
...
|
||||
}
|
||||
|
||||
struct Pair<A, B> {
|
||||
...
|
||||
}
|
||||
|
||||
interface Comparable<T> {
|
||||
...
|
||||
}
|
||||
|
||||
func identity<T>(T value) -> T {
|
||||
return value;
|
||||
}
|
||||
```
|
||||
|
||||
### Exemple 3
|
||||
|
||||
```text
|
||||
Box<int32>
|
||||
Pair<String, uint64>
|
||||
Result<Data, ParseError>
|
||||
```
|
||||
|
||||
### Exemple 4
|
||||
|
||||
```text
|
||||
Box
|
||||
Result
|
||||
```
|
||||
|
||||
### Exemple 5
|
||||
|
||||
```text
|
||||
Box<int32> box = Box<int32>(42);
|
||||
```
|
||||
|
||||
### Exemple 6
|
||||
|
||||
```text
|
||||
func first<T>(T left, T right) -> T;
|
||||
|
||||
int32 a = ...;
|
||||
int32 b = ...;
|
||||
|
||||
int32 c = first(a, b);
|
||||
```
|
||||
|
||||
### Exemple 7
|
||||
|
||||
```text
|
||||
func create<T>() -> T;
|
||||
|
||||
String value = create(); // ERROR
|
||||
```
|
||||
|
||||
### Exemple 8
|
||||
|
||||
```text
|
||||
String value = create<String>();
|
||||
```
|
||||
|
||||
### Exemple 9
|
||||
|
||||
```text
|
||||
func same<T>(T a, T b) -> bool;
|
||||
|
||||
int16 a = ...;
|
||||
int32 b = ...;
|
||||
|
||||
same(a, b); // ERROR
|
||||
same<int32>(a::toInt32(), b); // OK
|
||||
```
|
||||
|
||||
### Exemple 10
|
||||
|
||||
```text
|
||||
where T extends SomeClass
|
||||
where T implements SomeInterface
|
||||
```
|
||||
|
||||
### Exemple 11
|
||||
|
||||
```text
|
||||
func process<T>(T value) -> Void
|
||||
where T extends Entity
|
||||
where T implements Serializable
|
||||
where T implements Comparable<T>
|
||||
{
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
### Exemple 12
|
||||
|
||||
```text
|
||||
func compare<A, B>(A left, B right) -> Ordering
|
||||
where A implements Comparable<B>
|
||||
{
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
### Exemple 13
|
||||
|
||||
```text
|
||||
where T implements Comparable<T>
|
||||
```
|
||||
|
||||
### Exemple 14
|
||||
|
||||
```text
|
||||
where T is numeric
|
||||
where T is primitive
|
||||
where T is struct
|
||||
where T is class
|
||||
```
|
||||
|
||||
### Exemple 15
|
||||
|
||||
```text
|
||||
where T implements Numeric
|
||||
```
|
||||
|
||||
### Exemple 16
|
||||
|
||||
```text
|
||||
interface B extends A {
|
||||
}
|
||||
```
|
||||
|
||||
### Exemple 17
|
||||
|
||||
```text
|
||||
where T implements B
|
||||
where T implements A
|
||||
```
|
||||
|
||||
### Exemple 18
|
||||
|
||||
```text
|
||||
open class Base<T>
|
||||
where T implements Serializable
|
||||
{
|
||||
}
|
||||
|
||||
class Child<T> extends Base<T>
|
||||
where T implements Serializable
|
||||
{
|
||||
}
|
||||
```
|
||||
|
||||
### Exemple 19
|
||||
|
||||
```text
|
||||
class Box<T> implements Iterable<T> {
|
||||
...
|
||||
}
|
||||
|
||||
class StringList implements Iterable<String> {
|
||||
...
|
||||
}
|
||||
|
||||
class StringContainer extends Container<String> {
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
### Exemple 20
|
||||
|
||||
```text
|
||||
class PairBox<T> implements Container<Pair<T, T>> {
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
### Exemple 21
|
||||
|
||||
```text
|
||||
Consumer<String>
|
||||
Consumer<Array<uint8>>
|
||||
```
|
||||
|
||||
### Exemple 22
|
||||
|
||||
```text
|
||||
même nombre de paramètres génériques
|
||||
même nature type/const de chaque paramètre
|
||||
mêmes relations de contraintes
|
||||
même contrat callable après substitution
|
||||
```
|
||||
|
||||
### Exemple 23
|
||||
|
||||
```text
|
||||
Dog extends Animal
|
||||
```
|
||||
|
||||
### Exemple 24
|
||||
|
||||
```text
|
||||
Container<Dog> -> Container<Animal>
|
||||
```
|
||||
|
||||
### Exemple 25
|
||||
|
||||
```text
|
||||
in T
|
||||
out T
|
||||
+T
|
||||
-T
|
||||
wildcards Java
|
||||
```
|
||||
|
||||
### Exemple 26
|
||||
|
||||
```text
|
||||
monomorphisation
|
||||
code partagé avec metadata
|
||||
stratégie hybride
|
||||
```
|
||||
|
||||
### Exemple 27
|
||||
|
||||
```text
|
||||
struct StaticArray<T, const uint64 N> {
|
||||
...
|
||||
}
|
||||
|
||||
struct Matrix<T, const uint64 Rows, const uint64 Columns> {
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
### Exemple 28
|
||||
|
||||
```text
|
||||
bool
|
||||
char
|
||||
uint8
|
||||
uint16
|
||||
uint32
|
||||
uint64
|
||||
uint128
|
||||
uint256
|
||||
enum simple sans payload
|
||||
```
|
||||
|
||||
### Exemple 29
|
||||
|
||||
```text
|
||||
int8..int256
|
||||
float16..float128
|
||||
String
|
||||
class
|
||||
struct arbitraire
|
||||
tuple
|
||||
enum avec payload
|
||||
```
|
||||
|
||||
### Exemple 30
|
||||
|
||||
```text
|
||||
littéraux
|
||||
const nommées déjà résolues
|
||||
paramètres const generic
|
||||
parenthèses
|
||||
opérateurs primitifs purs autorisés sur ces valeurs
|
||||
```
|
||||
|
||||
### Exemple 31
|
||||
|
||||
```text
|
||||
StaticArray<uint8, 32>
|
||||
StaticArray<uint8, PAGE_SIZE>
|
||||
StaticArray<uint8, PAGE_SIZE * 2>
|
||||
StaticArray<uint8, 1u64 << 12>
|
||||
```
|
||||
|
||||
### Exemple 32
|
||||
|
||||
```text
|
||||
StaticArray<uint8, computeSize()> // ERROR
|
||||
StaticArray<uint8, value::toUint64()> // ERROR
|
||||
```
|
||||
|
||||
### Exemple 33
|
||||
|
||||
```text
|
||||
fonction
|
||||
méthode
|
||||
constructeur
|
||||
allocation
|
||||
I/O
|
||||
état runtime
|
||||
exception
|
||||
appel d'intrinsic exposé comme callable
|
||||
```
|
||||
|
||||
### Exemple 34
|
||||
|
||||
```text
|
||||
const uint64 SIZE = ...;
|
||||
|
||||
StaticArray<uint8, SIZE>
|
||||
```
|
||||
|
||||
### Exemple 35
|
||||
|
||||
```text
|
||||
StaticArray<T, 2 + 2>
|
||||
StaticArray<T, 4>
|
||||
```
|
||||
|
||||
### Exemple 36
|
||||
|
||||
```text
|
||||
func length<T, const uint64 N>(StaticArray<T, N> array) -> uint64
|
||||
```
|
||||
|
||||
### Exemple 37
|
||||
|
||||
```text
|
||||
func strange<const uint64 N>(StaticArray<int32, N * 2> value)
|
||||
```
|
||||
|
||||
### Exemple 38
|
||||
|
||||
```text
|
||||
where N > 0
|
||||
where N <= 1024
|
||||
```
|
||||
|
||||
### Exemple 39
|
||||
|
||||
```text
|
||||
class Node<T> {
|
||||
Nullable<Node<T>> next;
|
||||
}
|
||||
```
|
||||
|
||||
### Exemple 40
|
||||
|
||||
```text
|
||||
class BufferNode<T, const uint64 N> {
|
||||
Nullable<BufferNode<T, N>> next;
|
||||
}
|
||||
```
|
||||
|
||||
### Exemple 41
|
||||
|
||||
```text
|
||||
class Node<T> {
|
||||
Nullable<Node<Array<T>>> next; // ERROR
|
||||
}
|
||||
```
|
||||
|
||||
### Exemple 42
|
||||
|
||||
```text
|
||||
class BufferNode<T, const uint64 N> {
|
||||
Nullable<BufferNode<T, N + 1>> next; // ERROR
|
||||
}
|
||||
```
|
||||
|
||||
### Exemple 43
|
||||
|
||||
```text
|
||||
class A<T> {
|
||||
Nullable<B<T>> b;
|
||||
}
|
||||
|
||||
class B<T> {
|
||||
Nullable<A<T>> a;
|
||||
}
|
||||
```
|
||||
|
||||
### Exemple 44
|
||||
|
||||
```text
|
||||
class A<T> {
|
||||
Nullable<B<Array<T>>> b;
|
||||
}
|
||||
|
||||
class B<T> {
|
||||
Nullable<A<T>> a;
|
||||
}
|
||||
```
|
||||
|
||||
### Exemple 45
|
||||
|
||||
```text
|
||||
func recurse<T>(T value) -> Void {
|
||||
recurse<T>(value); // OK
|
||||
}
|
||||
```
|
||||
|
||||
### Exemple 46
|
||||
|
||||
```text
|
||||
func recurse<T>(T value) -> Void {
|
||||
recurse<Array<T>>(...); // ERROR
|
||||
}
|
||||
```
|
||||
|
||||
### Exemple 47
|
||||
|
||||
```text
|
||||
<T...>
|
||||
<const uint64... N>
|
||||
generic parameter packs
|
||||
wildcards
|
||||
specialization
|
||||
variance déclarative
|
||||
contraintes négatives
|
||||
```
|
||||
|
||||
## DO / DON'T / WHY / compiler error / edge cases
|
||||
|
||||
La couverture structurée de cette section sera enrichie au fur et à mesure de la fermeture des règles du chapitre. La migration `0.2.12` conserve volontairement les exemples historiques dans le chapitre afin de ne perdre aucun contexte normatif.
|
||||
À consolider progressivement avant la baseline publique V3 et à transformer, lorsque pertinent, en tests de conformité de la toolchain.
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Exemples / DO-DON'T — Chapitre 24 — Casts et conversions
|
||||
|
||||
> Document compagnon non normatif tant qu'une règle n'est pas explicitement référencée comme normative par le chapitre.
|
||||
> Document compagnon. Les exemples illustrent les règles du chapitre ; la formulation normative reste dans le chapitre lui-même.
|
||||
|
||||
## Exemples actuellement présents dans le chapitre
|
||||
## Exemples extraits du chapitre
|
||||
|
||||
### Exemple 1
|
||||
|
||||
@@ -66,19 +66,112 @@ wrapToTarget()
|
||||
### Exemple 6
|
||||
|
||||
```text
|
||||
tryExactToInt32()
|
||||
tryFloorToInt32()
|
||||
tryCeilToInt32()
|
||||
tryRoundToInt32()
|
||||
tryTruncateToInt32()
|
||||
tryToIntXX()
|
||||
tryToUintXX()
|
||||
```
|
||||
|
||||
### Exemple 7
|
||||
|
||||
```text
|
||||
floor()
|
||||
ceil()
|
||||
round()
|
||||
truncate()
|
||||
```
|
||||
|
||||
### Exemple 8
|
||||
|
||||
```text
|
||||
value::floor()::tryToInt32()
|
||||
value::ceil()::tryToInt32()
|
||||
value::round()::tryToInt32()
|
||||
value::truncate()::tryToInt32()
|
||||
```
|
||||
|
||||
### Exemple 9
|
||||
|
||||
```text
|
||||
value::floor()::trySaturateToInt32()
|
||||
value::round()::tryWrapToInt32()
|
||||
```
|
||||
|
||||
### Exemple 10
|
||||
|
||||
```text
|
||||
NaN -> NaN
|
||||
+Infinity -> +Infinity
|
||||
-Infinity -> -Infinity
|
||||
+0 -> +0
|
||||
-0 -> -0
|
||||
```
|
||||
|
||||
### Exemple 11
|
||||
|
||||
```text
|
||||
payload NaN
|
||||
quiet/signaling bit
|
||||
signe du NaN
|
||||
représentation binaire exacte
|
||||
```
|
||||
|
||||
### Exemple 12
|
||||
|
||||
```text
|
||||
tryToFloatXX()
|
||||
exige une représentation exacte
|
||||
|
||||
tryRoundToFloatXX()
|
||||
accepte l'arrondi canonique
|
||||
refuse une valeur finie hors domaine fini destination
|
||||
|
||||
saturatingRoundToFloatXX()
|
||||
accepte l'arrondi canonique
|
||||
sature une valeur finie hors domaine vers +/-Target::Max
|
||||
```
|
||||
|
||||
### Exemple 13
|
||||
|
||||
```text
|
||||
NotFinite
|
||||
NotIntegral
|
||||
OutOfRange
|
||||
Inexact
|
||||
```
|
||||
|
||||
### Exemple 14
|
||||
|
||||
```text
|
||||
NotFinite
|
||||
NaN ou +/-Infinity lorsqu'une valeur finie est requise
|
||||
|
||||
NotIntegral
|
||||
float -> integer alors que la valeur n'est pas mathématiquement entière
|
||||
|
||||
OutOfRange
|
||||
valeur mathématique hors du domaine de la destination
|
||||
|
||||
Inexact
|
||||
valeur dans le domaine destination mais non représentable exactement
|
||||
alors que l'opération exige l'exactitude
|
||||
```
|
||||
|
||||
### Exemple 15
|
||||
|
||||
```text
|
||||
sourceType
|
||||
targetType
|
||||
sourceValue
|
||||
timestamp
|
||||
backend
|
||||
roundingMode
|
||||
```
|
||||
|
||||
### Exemple 16
|
||||
|
||||
```text
|
||||
annexes/A-numeric-conversions.md
|
||||
```
|
||||
|
||||
## DO / DON'T / WHY / compiler error / edge cases
|
||||
|
||||
La couverture structurée de cette section sera enrichie au fur et à mesure de la fermeture des règles du chapitre. La migration `0.2.12` conserve volontairement les exemples historiques dans le chapitre afin de ne perdre aucun contexte normatif.
|
||||
À consolider progressivement avant la baseline publique V3 et à transformer, lorsque pertinent, en tests de conformité de la toolchain.
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Exemples / DO-DON'T — Chapitre 33 — Imports et résolution des noms
|
||||
|
||||
> Document compagnon non normatif tant qu'une règle n'est pas explicitement référencée comme normative par le chapitre.
|
||||
> Document compagnon. Les exemples illustrent les règles du chapitre ; la formulation normative reste dans le chapitre lui-même.
|
||||
|
||||
## Exemples actuellement présents dans le chapitre
|
||||
## Exemples extraits du chapitre
|
||||
|
||||
### Exemple 1
|
||||
|
||||
@@ -38,10 +38,62 @@ import type foo.Token as FooToken;
|
||||
### Exemple 5
|
||||
|
||||
```text
|
||||
saselang.compiler.lexer.Token
|
||||
saselang.compiler.lexer::tokenize(...)
|
||||
src/foo/A.saseltype
|
||||
src/foo/B.saseltype
|
||||
```
|
||||
|
||||
### Exemple 6
|
||||
|
||||
```text
|
||||
import type foo.A;
|
||||
```
|
||||
|
||||
### Exemple 7
|
||||
|
||||
```text
|
||||
namespace foo;
|
||||
```
|
||||
|
||||
### Exemple 8
|
||||
|
||||
```text
|
||||
charger le fichier immédiatement
|
||||
exécuter le fichier
|
||||
initialiser le fichier
|
||||
compiler ce fichier avant le fichier courant
|
||||
```
|
||||
|
||||
### Exemple 9
|
||||
|
||||
```text
|
||||
A imports B
|
||||
B imports A
|
||||
```
|
||||
|
||||
### Exemple 10
|
||||
|
||||
```text
|
||||
A imports B
|
||||
B imports C
|
||||
C imports A
|
||||
```
|
||||
|
||||
### Exemple 11
|
||||
|
||||
```text
|
||||
cycle de références de classes
|
||||
autorisé
|
||||
|
||||
cycle d'appels
|
||||
autorisé
|
||||
|
||||
cycle d'héritage
|
||||
ERROR
|
||||
|
||||
cycle de layout by-value
|
||||
ERROR
|
||||
```
|
||||
|
||||
## DO / DON'T / WHY / compiler error / edge cases
|
||||
|
||||
La couverture structurée de cette section sera enrichie au fur et à mesure de la fermeture des règles du chapitre. La migration `0.2.12` conserve volontairement les exemples historiques dans le chapitre afin de ne perdre aucun contexte normatif.
|
||||
À consolider progressivement avant la baseline publique V3 et à transformer, lorsque pertinent, en tests de conformité de la toolchain.
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Exemples / DO-DON'T — Chapitre 40 — Targets, plateformes, architectures, ABI, distributions et capabilities
|
||||
|
||||
> Document compagnon non normatif tant qu'une règle n'est pas explicitement référencée comme normative par le chapitre.
|
||||
> Document compagnon. Les exemples illustrent les règles du chapitre ; la formulation normative reste dans le chapitre lui-même.
|
||||
|
||||
## Exemples actuellement présents dans le chapitre
|
||||
## Exemples extraits du chapitre
|
||||
|
||||
### Exemple 1
|
||||
|
||||
@@ -143,6 +143,53 @@ StandardError
|
||||
|
||||
### Exemple 13
|
||||
|
||||
```text
|
||||
language.*
|
||||
core.*
|
||||
target.*
|
||||
platform.*
|
||||
sdk.*
|
||||
```
|
||||
|
||||
### Exemple 14
|
||||
|
||||
```text
|
||||
language.exceptions
|
||||
core.numeric.float128
|
||||
core.collections.array
|
||||
target.atomic.int64
|
||||
target.simd.float32
|
||||
platform.filesystem
|
||||
platform.network
|
||||
sdk.logging
|
||||
```
|
||||
|
||||
### Exemple 15
|
||||
|
||||
```text
|
||||
Language-required
|
||||
sémantique nécessaire à tout compilateur Saselang conforme
|
||||
|
||||
Core-required-for-supported-type
|
||||
contrat Core obligatoire dès que le type/capacité fondamentale existe
|
||||
sur le target
|
||||
|
||||
Core/target optional capability
|
||||
fonctionnalité réellement optionnelle ou spécifique d'un environnement
|
||||
```
|
||||
|
||||
### Exemple 16
|
||||
|
||||
```text
|
||||
instruction native disponible
|
||||
lowering/backend direct ou optimisé
|
||||
|
||||
instruction native absente
|
||||
implémentation logicielle conforme
|
||||
```
|
||||
|
||||
### Exemple 17
|
||||
|
||||
```text
|
||||
TargetFamily
|
||||
Platform
|
||||
@@ -153,4 +200,4 @@ Distribution
|
||||
|
||||
## DO / DON'T / WHY / compiler error / edge cases
|
||||
|
||||
La couverture structurée de cette section sera enrichie au fur et à mesure de la fermeture des règles du chapitre. La migration `0.2.12` conserve volontairement les exemples historiques dans le chapitre afin de ne perdre aucun contexte normatif.
|
||||
À consolider progressivement avant la baseline publique V3 et à transformer, lorsque pertinent, en tests de conformité de la toolchain.
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
# Exemples / DO-DON'T — Chapitre 48 — Inventaire des points V1 encore OUVERTS
|
||||
|
||||
> Document compagnon non normatif tant qu'une règle n'est pas explicitement référencée comme normative par le chapitre.
|
||||
> Document compagnon. Les exemples illustrent les règles du chapitre ; la formulation normative reste dans le chapitre lui-même.
|
||||
|
||||
## Exemples actuellement présents dans le chapitre
|
||||
## Exemples extraits du chapitre
|
||||
|
||||
Aucun bloc d'exemple explicite n'est encore présent dans ce chapitre.
|
||||
Aucun bloc d'exemple explicite dans cette révision.
|
||||
|
||||
## DO / DON'T / WHY / compiler error / edge cases
|
||||
|
||||
La couverture structurée de cette section sera enrichie au fur et à mesure de la fermeture des règles du chapitre. La migration `0.2.12` conserve volontairement les exemples historiques dans le chapitre afin de ne perdre aucun contexte normatif.
|
||||
À consolider progressivement avant la baseline publique V3 et à transformer, lorsque pertinent, en tests de conformité de la toolchain.
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Exemples / DO-DON'T — Chapitre 49 — Éléments V1 RÉSERVÉS mais non obligatoires à implémenter immédiatement
|
||||
|
||||
> Document compagnon non normatif tant qu'une règle n'est pas explicitement référencée comme normative par le chapitre.
|
||||
> Document compagnon. Les exemples illustrent les règles du chapitre ; la formulation normative reste dans le chapitre lui-même.
|
||||
|
||||
## Exemples actuellement présents dans le chapitre
|
||||
## Exemples extraits du chapitre
|
||||
|
||||
### Exemple 1
|
||||
|
||||
@@ -23,4 +23,4 @@ noms nécessaires pour éviter collisions futures
|
||||
|
||||
## DO / DON'T / WHY / compiler error / edge cases
|
||||
|
||||
La couverture structurée de cette section sera enrichie au fur et à mesure de la fermeture des règles du chapitre. La migration `0.2.12` conserve volontairement les exemples historiques dans le chapitre afin de ne perdre aucun contexte normatif.
|
||||
À consolider progressivement avant la baseline publique V3 et à transformer, lorsque pertinent, en tests de conformité de la toolchain.
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
# Exemples / DO-DON'T — Chapitre 51 — Invariants de conception
|
||||
|
||||
> Document compagnon non normatif tant qu'une règle n'est pas explicitement référencée comme normative par le chapitre.
|
||||
> Document compagnon. Les exemples illustrent les règles du chapitre ; la formulation normative reste dans le chapitre lui-même.
|
||||
|
||||
## Exemples actuellement présents dans le chapitre
|
||||
## Exemples extraits du chapitre
|
||||
|
||||
Aucun bloc d'exemple explicite n'est encore présent dans ce chapitre.
|
||||
Aucun bloc d'exemple explicite dans cette révision.
|
||||
|
||||
## DO / DON'T / WHY / compiler error / edge cases
|
||||
|
||||
La couverture structurée de cette section sera enrichie au fur et à mesure de la fermeture des règles du chapitre. La migration `0.2.12` conserve volontairement les exemples historiques dans le chapitre afin de ne perdre aucun contexte normatif.
|
||||
À consolider progressivement avant la baseline publique V3 et à transformer, lorsque pertinent, en tests de conformité de la toolchain.
|
||||
|
||||
@@ -1,24 +1,24 @@
|
||||
# Exemples / DO-DON'T — Chapitre 52 — Priorité de spécification après 0.2.9
|
||||
# Exemples / DO-DON'T — Chapitre 52 — Priorité de spécification après 0.2.14
|
||||
|
||||
> Document compagnon non normatif tant qu'une règle n'est pas explicitement référencée comme normative par le chapitre.
|
||||
> Document compagnon. Les exemples illustrent les règles du chapitre ; la formulation normative reste dans le chapitre lui-même.
|
||||
|
||||
## Exemples actuellement présents dans le chapitre
|
||||
## Exemples extraits du chapitre
|
||||
|
||||
### Exemple 1
|
||||
|
||||
```text
|
||||
1. terminer casts/conversions numériques + matrice Core
|
||||
2. generics + contraintes + const generics
|
||||
3. String/Unicode + collections + Range
|
||||
4. lambdas/closures + callable model
|
||||
5. async/concurrency décision V1
|
||||
6. modèle mémoire + allocator + pointers + unsafe
|
||||
7. fautes runtime + construction/destruction cleanup
|
||||
8. Core V1 exact et capacités target
|
||||
9. SDK V1 initial et frontières Core/SDK
|
||||
10. FFI C exacte
|
||||
11. reflection/metadata/tests/tooling
|
||||
12. grammaire syntaxique complète et audit lexical final
|
||||
1. String/Unicode + collections + Range
|
||||
2. lambdas/closures + callable model
|
||||
3. async/concurrency décision V1
|
||||
4. modèle mémoire + allocator + pointers + unsafe
|
||||
5. fautes runtime + construction/destruction cleanup
|
||||
6. Core V1 exact : Numeric, collections, erreurs, TypeInfo et autres contrats
|
||||
7. capacités target et registre canonique des capability identifiers
|
||||
8. SDK V1 initial et frontières Core/SDK
|
||||
9. FFI C exacte
|
||||
10. reflection/metadata/tests/tooling
|
||||
11. grammaire syntaxique complète et audit lexical final
|
||||
12. audit mécanique des generics/const generics/récursivité et conversions
|
||||
13. audit complet de toutes les sections V1 REQUIS — À FINALISER
|
||||
14. consolidation examples / DO-DON'T / conformance tests
|
||||
15. plan d'implémentation du compilateur/interpréteur V1
|
||||
@@ -26,4 +26,4 @@
|
||||
|
||||
## DO / DON'T / WHY / compiler error / edge cases
|
||||
|
||||
La couverture structurée de cette section sera enrichie au fur et à mesure de la fermeture des règles du chapitre. La migration `0.2.12` conserve volontairement les exemples historiques dans le chapitre afin de ne perdre aucun contexte normatif.
|
||||
À consolider progressivement avant la baseline publique V3 et à transformer, lorsque pertinent, en tests de conformité de la toolchain.
|
||||
|
||||
Reference in New Issue
Block a user