4.2 KiB
15. Fonctions, méthodes et clsmethod
15.1 Catégories — V1 REQUIS — FIGÉ
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 :
func readConfig(String path) -> Config
throws IOException
method elementAt(uint64 index) -> T
faults IndexOutOfBoundsFault
Result<T,E> est utilisé lorsque l'échec doit être transporté explicitement comme une valeur et inspecté par l'appelant :
func parseExternalInput(String input) -> Result<Value, ParseError>
Les combinaisons sont indépendantes :
T
T throws SomeException
T faults SomeFault
T throws SomeException faults SomeFault
Result<T,E>
Result<T,E> throws SomeException
Result<T,E> 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.
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.
class User {
const method getName() -> String {
return this::name;
}
method setName(String name) -> Void {
this::name = name;
return Void;
}
}
Usage :
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 :
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 :
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 :
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 :
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.