# 15. Fonctions, méthodes et `clsmethod` ## 15.1 Catégories — V1 REQUIS — FIGÉ ```text func fonction libre method méthode d'instance clsmethod méthode de classe operator implémentation d'un contrat opérateur ``` ## 15.2 Retours directs, `Result`, `throws` et `faults` — V1 REQUIS — FIGÉ Le type de retour et le mécanisme d'échec sont des dimensions distinctes. Une callable peut retourner directement `T` même si elle peut produire une `Exception` checked ou un `Fault` unchecked : ```text func readConfig(String path) -> Config throws IOException method elementAt(uint64 index) -> T faults IndexOutOfBoundsFault ``` `Result` est utilisé lorsque l'échec doit être transporté explicitement comme une valeur et inspecté par l'appelant : ```text func parseExternalInput(String input) -> Result ``` Les combinaisons sont indépendantes : ```text T T throws SomeException T faults SomeFault T throws SomeException faults SomeFault Result Result throws SomeException Result faults SomeFault ``` Saselang ne force donc plus une callable à retourner `Result` uniquement parce qu'elle peut échouer. À l'inverse, une API ne doit pas remplacer systématiquement un échec normal du domaine par un `Fault` si `Option` ou `Result` exprime mieux le contrat. Le Core ne crée pas mécaniquement des paires `op()` / `tryOp()` ayant pour seule différence « valeur directe avec fault » versus « même opération dans Result ». Deux opérations distinctes doivent porter des sémantiques réellement distinctes. ## 15.3 Retour explicite — V1 REQUIS — FIGÉ Pas de retour implicite de dernière expression. ```text return value; return Result::Ok(value); return Result::Ok(Void); ``` `return` quitte la fonction/méthode. ## 15.4 Surcharge — V1 REQUIS — FIGÉ Surcharge autorisée pour fonctions et méthodes. La signature ne contient pas le type de retour. Il ne peut donc pas exister deux overloads distingués uniquement par leur retour. ## 15.5 Résolution de surcharge — V1 REQUIS — À FINALISER Les règles exactes de préférence entre exact match, conversions explicites/contextuelles, generics et variadiques doivent être figées. Objectif : aucune résolution basée sur le type de retour et aucune conversion implicite ambiguë. ## 15.6 `const method` — V1 REQUIS — FIGÉ Une `method` ordinaire peut modifier l'état accessible via `this`. Une `const method` reçoit un accès `const` à `this` et peut être appelée depuis un accès mutable ou const. ```text class User { const method getName() -> String { return this::name; } method setName(String name) -> Void { this::name = name; return Void; } } ``` Usage : ```text User a = ...; const User b = a; a::setName("John"); // OK a::getName(); // OK b::getName(); // OK b::setName("John"); // ERROR ``` Une `const method` ne peut pas : ```text réassigner un champ via this appeler une method non-const via this obtenir puis exposer comme mutable un accès disponible uniquement via this const ``` `const method` ne signifie pas `pure`. Elle peut notamment, sous réserve des contrats normaux : ```text allouer des valeurs locales modifier des valeurs locales mutables faire de l'I/O faire du logging lever une Exception déclarée modifier un état externe auquel elle possède indépendamment un accès mutable ``` La garantie porte uniquement sur la mutation via `this` et les accès dérivés de ce `this` const. ## 15.7 Paramètres et retours `const` — V1 REQUIS — FIGÉ EN PRINCIPE Un paramètre `const` reçoit un accès non mutable : ```text func display(const User user) -> Void ``` Un argument mutable peut être fourni à un paramètre const, car cela réduit les permissions. Un argument const ne peut pas être fourni à un paramètre mutable lorsqu'il s'agit d'un accès référence, car cela augmenterait les permissions. Une callable peut retourner un accès const : ```text const method getOwner() -> const User { return this::owner; } ``` Une callable ne peut pas convertir un accès dérivé uniquement d'un receiver const en accès mutable lors du retour. Une valeur indépendante nouvellement créée dans la callable peut naturellement être retournée mutable. ---