4.2 KiB
39. Features, module.saselmod et compilation conditionnelle
39.1 Features — V1 REQUIS — FIGÉES EN PRINCIPE
Une feature est une capacité optionnelle déclarée par un package.
Elle peut notamment :
activer une dépendance optionnelle
activer un module
sélectionner une capacité/backend fonctionnel de library
contraindre d'autres features
Une feature ne représente jamais une plateforme/architecture à la place du modèle de target.
39.2 Contraintes de features — V1 REQUIS — FIGÉES EN PRINCIPE
V1 doit pouvoir exprimer au minimum :
requires
conflicts
one-of
at-least-one
all-of est redondant avec plusieurs requires et n'est pas requis comme primitive distincte.
provides/replaces ne sont pas introduits sans besoin concret démontré.
Les groupes et contraintes globales appartiennent au manifest du package.
39.3 Dépendances optionnelles — V1 REQUIS — FIGÉES EN PRINCIPE
Une feature peut activer une dépendance déjà déclarée comme optionnelle dans le manifest. La dépendance garde une définition unique ; la feature ne duplique pas sa source, version ou son mapping.
Les features demandées à une dépendance doivent être déclarables dans l'entrée de dépendance correspondante.
La suppression/renommage d'une feature publique d'un package peut constituer une rupture de compatibilité SemVer.
39.4 module.saselmod — V1 REQUIS — FIGÉ EN PRINCIPE
module.saselmod reste totalement optionnel.
S'il existe, sa première déclaration après éventuel en-tête/documentation est obligatoirement :
namespace ...;
et doit correspondre au chemin du module relativement au source_root.
Il ne contient ni exports, ni réexports, ni dépendances de package, ni configuration générale de build.
Il peut porter des propriétés réellement module-wide, notamment :
doc ...
deprecated ...
forbid unsafe
requires feature ...
requires capability ...
requires target ...
La syntaxe finale de ces directives reste à figer.
39.5 Héritage des politiques de module — V1 REQUIS — FIGÉ EN PRINCIPE
Les contraintes/politiques structurelles telles que :
forbid unsafe
requires feature
requires capability
requires target
sont héritées par les sous-modules, sauf règle future explicitement plus restrictive.
doc n'est pas hérité.
deprecated ne constitue pas une copie automatique du texte de dépréciation dans tous les sous-modules ; l'utilisation d'un chemin passant par un module déprécié doit néanmoins pouvoir produire le diagnostic approprié.
39.6 compile if — V1 REQUIS — SQUELETTE FIGÉ, SYNTAXE À FINALISER
Saselang V1 conserve une compilation conditionnelle structurelle intégrée au parser/AST.
Ce n'est jamais un préprocesseur textuel.
Le compile if :
ne produit jamais de valeur ;
ne peut jamais être utilisé comme expression ;
ne peut dépendre que d'informations déterminables à la compilation.
En V1 il peut sélectionner :
des déclarations top-level complètes ;
des blocs d'implémentation dans le corps d'une callable.
Il ne doit pas servir à modifier conditionnellement les champs/membres structurels internes d'un type déjà déclaré.
Le bloc non sélectionné est éliminé avant HIR/Sase IR. Il doit néanmoins être suffisamment lexé/parsé pour rester syntaxiquement valide.
La syntaxe exacte (compile if (...), forme de else, etc.) reste à finaliser.
39.7 Environnement de compilation — V1 REQUIS — SQUELETTE FIGÉ
Le compilateur/Core doit pouvoir exposer dans les contextes de compilation conditionnelle des informations déterministes telles que :
language version
compiler version
Core/SDK version
package identity/version
features actives
dépendances résolues
profile
artifact
target family
platform
architecture
ABI
endianness
pointer width
capabilities
Les informations doivent être typées lorsque possible.
Le code applicatif normal n'obtient pas pour autant un accès arbitraire au filesystem, au réseau ou aux variables d'environnement pendant l'évaluation de compile if.
Les chemins workspace/package/build sont réservés aux outils de build lorsqu'ils sont réellement nécessaires et ne deviennent pas une dépendance sémantique portable du programme.