Discussion :

[Stéphane le calme]

Y a-t-il une raison pour laquelle les fonctions, dans la plupart des langages de programmation,
ne retournent qu'une seule valeur ? Partagez vos avis

Y a-t-il une raison pour laquelle les fonctions dans la plupart des langages de programmation, bien que supportant un grand nombre de paramètres en entrée, ne retournent qu’une seule valeur ? C’est la question qu’un développeur a posée sur le réseau Stack Exchange. Pour lui, même s’il est possible de contourner cette limitation (par exemple en retournant des pointeurs ou en définissant / retournant des structures / classes), il semble étrange que les langages n’aient pas été pensés pour supporter un retour de valeurs multiples d’une façon plus « naturelle ». Voici quelques-unes des réponses qui ont reçu le plus de votes favorables :

• Certains langages, comme Python, supportent nativement un retour de valeurs multiples, tandis que certains autres, comme C#, ne les supportent que via leur bibliothèque de base. Mais, en général, même dans les langages qui les supportent, les valeurs multiples de retour ne sont pas souvent utilisées parce qu’elles sont imprécises :
  
  
  1. Les fonctions qui retournent des valeurs multiples sont difficiles à nommer clairement
     
  2. Il est aisé de se tromper dans l’ordre des valeurs retournées
     
     

     Code :

     Sélectionner tout - Visualiser dans une fenêtre à part

     (password, username) = GetUsernameAndPassword()

     (pour cette même raison, nombreux sont ceux qui évitent d’entrer trop de paramètres dans leur fonction, certains vont même jusqu’à dire qu’une fonction ne devrait pas avoir deux paramètres du même type)
     
  3. Les langages POO ont déjà une meilleure alternative aux valeurs de retour multiples : les classes. Elles sont plus fortement typées, elles maintiennent les valeurs de retour groupées comme une unité logique et elles gardent les noms / propriétés des valeurs retour suffisamment consistants.
     
     Le seul endroit où elles seraient assez pratiques se trouve être dans des langages (comme Python) où les valeurs de retour multiples d’une fonction peuvent être utilisées comme de multiples paramètres d’entrée pour l’autre. Mais, les cas d’utilisation où ces configurations sont plus adaptées que les classes sont assez restreints.
  
  
• Parce que les fonctions sont des constructions mathématiques qui permettent d’effectuer un calcul et de retourner un résultat. En effet, bien des matériaux « sous le capot » de nombreux langages de programmation se concentrent uniquement sur une entrée et une sortie, avec les entrées multiples qui sont tout simplement une mince enveloppe autour de l’entrée. Cela n’a pas changé parce que les programmeurs ont découvert que les paramètres sont des constructions maladroites qui ne s’avèrent utiles que dans un ensemble de scénarios limités. Comme beaucoup d’autres choses, le support n’est pas présent parce que la demande / le besoin n’y est pas non plus.
  
  
• En mathématiques, une fonction « bien définie » n’a qu’une seule sortie pour une entrée donnée (comme N.B, vous pouvez avoir des fonctions d’entrée unique et obtenir sémantiquement des entrées multiples en utilisant le currying)
  
  Pour des fonctions à valeurs multiples (par exemple la racine carrée d’un nombre entier positif), il suffit de retourner une collection ou une séquence de valeurs.
  
  Pour les types de fonctions dont vous parlez (les fonctions qui retournent différentes valeurs de différents types), je le perçois un peu différemment de ce que vous semblez voir : je vois la nécessité / le besoin de l’utilisation des paramètres de sortie comme solution de contournement pour un meilleur design ou une structure de données plus utile. Par exemple, j’aurais préféré que les méthodes *.TryParse(...) retournent une monade Maybe<T> au lieu d’utiliser un paramètre de sortie. Regardez un peu ce code dans F#:
  
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  let s = "1"
  match tryParse s with
  | Some(i) -> // do whatever with i
  | None -> // failed to parse

  Le compilateur / l’IDE / le support d’analyse est très bon pour ces constructions. Ceci résoudrait la plupart des « besoins » de paramètres de sortie. Pour être complètement honnête, je n’arrive pas à imaginer d’autres méthodes où ce ne serait pas la solution.
  
  Pour les autres scénarios, ceux dont je ne me souviens pas, un simple tuple est suffisant.

Source : Stack Exchange

Et vous ?

Qu'en pensez-vous ?

Forum Langage de Programmation

[heid]

Réponse de uncle bob :
Si les x paramètre n'ont pas de cohésion c'est qu'il faut x fonctions, et si oui, et bien une classe représente bien la notion de cohésion entre variables

Réponse du dev sénior :
Parce que avec un seul paramètre de retour vous arrivez déjà à pondre du codé dégeu alors x j'imagine pas.

[Gugelhupf]

Je vois que l'exemple de Python est cité, le truc avec Python c'est qu'on ne précise pas les types des arguments. Dans un autre langage comme Java on pourrait se retrouver avec une signature de méthode comme (int, int, double) methode((int, int) param1, (double, String) param2) et à vrai je sais pas trop quoi penser, c'est moche et ça m'a l'air complexe à gérer.
De plus un passage par copie de référence (Java) ou référence (C++) suffit largement pour avoir une fonction qui modifie plusieurs variables.

[super_navide]

Je vois que l'exemple de Python est cité, le truc avec Python c'est qu'on ne précise pas les types des arguments. Dans un autre langage comme Java on pourrait se retrouver avec une signature de méthode comme (int, int, double) methode((int, int) param1, (double, String) param2) et à vrai je sais pas trop quoi penser, c'est moche et ça m'a l'air complexe à gérer.
De plus un passage par copie de référence (Java) ou référence (C++) suffit largement pour avoir une fonction qui modifie plusieurs variables.

oui et créer en java des classes qui servent que pour une fonction , de plus créer un objet ça a un coût en java.

[Aurelien.Regat-Barrel]

De plus un passage par copie de référence (Java) ou référence (C++) suffit largement pour avoir une fonction qui modifie plusieurs variables.

Même en C++ la tendance est d'éviter les paramètres OUT (passage par référence) et privilégier un style plus fonctionnel : paramètres IN, résultat en retour de fonction (par valeur et non pointeur), pas d'effet de bord / état (var globale, singleton, ...). La move semantic facilite la généralisation de ce style tout en en minimisant le prix (à savoir la copie de l'objet retourné).

Ainsi en C++11, on a std::tuple et std::tie par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

std::tie(position, already_existed) = myMap.insert(...);

Les tuples sont moins sympas à utiliser que des struct/class effectivement... en général... car des fois c'est sympa, par exemple récupérer le résultat d'une requête SQL sans se cogner une usine à gaz qui génère plein de classes dans tous les sens :

Code cpp :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
// renvoie un std::tuple<string, string, time>
auto result = execQuery<string, string, int>("SELECT nom, prenom, age FROM blablabla");
 
// variante: nombre variable de paramètres d'entrée et de retour
string nom, prenom;
tie(nom, prenom) = execQuery<string, string>("SELECT nom, prenom FROM TablePerson WHERE id=%1", personId);

Toujours dans l'optique de privilégier les valeurs de retour aux paramètres OUT, optional<> rend le code bien plus sexy:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int width = settings["windowWidth"].value_or(400);

vs:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
int width;
if (!settings.get("windowWidth", width) {
    width = 400;
}

[Ehonn]

De plus un passage par copie de référence (Java) ou référence (C++) suffit largement pour avoir une fonction qui modifie plusieurs variables.

Remarque : En C++, la bibliothèque standard retourne plusieurs valeurs comme dans std::mismatch ou std::minmax en utilisant std::pair. Depuis C++11, on peut "retourner" autant "d'objets" que voulu grâce à std::tuple et std::tie (comme dit par Aurelien.Regat-Barrel).

[Bono_BX]

Réponse du dev sénior :
Parce que avec un seul paramètre de retour vous arrivez déjà à pondre du codé dégeu alors x j'imagine pas.

Merci pour ce grand moment de rire !

[super_navide]

Merci pour ce grand moment de rire !

La notion de code degeux est relative , il faudrait faire une métrique pour le code degueux.
De toute façon le code est toujours dégueux et pas maintenable pour celui qui ne le comprend pas......

[super_navide]

C'est une bonne question pourquoi ??

exemple en java ca donnerai

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
int , int minEtMax(List<Integer> list) {
int min = list.get(0);
int max = list.get(0);
for(Integer i:list) {
if (i > max ){
max =i;
}
if (i < min) {
min = i ;
 }
return min,max;
}

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
int , int maxEtIndex(List<Integer> l) {
int idx =0;
int max = list.get(0);
for(int j=0;j < l.size() ;j++) {
Integer val = l.get(j)
if (val > max ){
max =val;
idx =j
}
return max,idx;
}

non c une bonne idée, évidement il y a plein d’intégriste du code qui vont trouvé une raison débile pour pas le faire

[codec_abc]

Pour commencer je trouve l'article un peu brouillon et d'ailleurs c'est qui le "vous" dans l'article ? Le lecteur ?

Ensuite, je suis en désaccord (plus ou moins fort) avec tous les arguments avancées :
Pour la première partie :
1. Je vois pas pourquoi les fonctions qui retournent plusieurs argument seraient nécessairement plus dures à nommer. C'est clair que si on utilise trop de "valeurs de retours" ça devient confus mais pas forcément plus que les fonctions/méthodes qui prennent un grand nombre d'arguments.
2. On peut aussi se tromper pour les paramètres. Exemple getPixel(int x, int y) vs getPixel(int y, int x). Le nommage permet de lever l’ambiguïté (à condition qu'il soit bon). Ça peut aussi être le cas pour les paramètres de retours.
3. L'argument n'a aucun sens. Je vois pas en quoi avoir plusieurs valeurs de retour d'une fonction ferait perdre l'information de typage pour chaque valeur.

La deuxième partie n'est pas clair. Je ne comprends pas ou l'auteur veut en venir.

Pour le point 3, ce n'est parce qu'on a de multiple valeur de retours qu'une fonction n'est pas bijective (ou injective). Chaque valeur de retour peut très bien ne servir qu'a représenter une dimension. Exemple (x,y) = swapValue(i,j).

[lankoande]

A mon avis l'une des premières raisons c'est la simplicité. Et puis je pense qu'on a vraiment pas assez de mal pour contourner ce cas. Dans les langages structurales comme le C moi je retourne un tableau de pointeurs ou de structures selon le besoin et dans les langages OO je retourne des objets ou des tableaux d'objets.

[sevyc64]

La toute première raison est une raison historique. Les premières fonctions de l'histoire étaient simplement des fonctions, ou opérations mathématiques. hors les opérations mathématiques ne retournent bien souvent qu'un seul résultat, le résultat du calcul effectué.
C'est historique et, on le sait tous très bien, en informatique l'historique à la vie très dure, il ne se fait pas déboulonné facilement.

De plus un passage par copie de référence (Java) ou référence (C++) suffit largement pour avoir une fonction qui modifie plusieurs variables.

Tu prend le problème, pardon la solution à l'envers. Ce n'est pas que ça suffit largement, c'est que ça a été la méthode la plus simple et la plus élégante de contourner le problème.
Et encore, un problème récent, parce qu'au départ, les paramètres de fonctions étaient passé par référence. La raison était la quantité limitée de ressource. On allait pas s'amuser à dupliquer une valeur en mémoire quand chaque octet, chaque bit même était compté au plus juste.
Ce n'est que lorsque les ressources, en mémoire et en puissance de calcul se sont faites un peu plus large que l'idée est venue de passer les paramètres par valeur pour les sécuriser.

1. Je vois pas pourquoi les fonctions qui retournent plusieurs argument seraient nécessairement plus dures à nommer. C'est clair que si on utilise trop de "valeurs de retours" ça devient confus mais pas forcément plus que les fonctions/méthodes qui prennent un grand nombre d'arguments.

Je pense que tu n'as pas bien compris l'exemple.
Ce qui est appelé nommage concerne bien le sens premier, c'est à dire le nom de la fonction
- Une fonction qui retourne un nom d'utilisateur sera écrite username = GetUsername() .
- Une fonction qui retourne un nom d'utilisateur et son mot de passe sera écrite (username, password) = GetUsernameAndPassword() .
- Une fonction qui retourne un nom d'utilisateur, son mot de passe et un identifiant sera écrite (username, password, matricule)= GetUsernameAndPasswordAndMatricule().
- Une autre (username, password, matricule, age)= GetUsernameAndPasswordAndMatriculeAndAgeDuCapitaine().

Ca devient vite impossible

Mais il est vrai qu'avec la POO, le problème est résolu, puisque même si l'on ne retourne toujours qu'un seul résultat, c'est une classe que l'on retourne, donc un ensemble de données cohérentes.


Mais effectivement, ça aurait une grande utilité que personne n'a mentionné.
Une fonction, en réalité, a besoin de retourner 2 résultats, et pas un seul
- le résultat du calcul, certes
- mais aussi et surtout le résultat de l’exécution du calcul, s'il s'est bien effectué, avec ou sans erreur, etc.
Sur ce point, on a tous pris l'habitude de donner des valeurs particulières au résultat (du calcul) pour faire passer l'information sur l’exécution de ce même calcul. Parce qu'on a pas vraiment le choix, mais conceptuellement c'est quand même une belle aberration. Qui pourrait être résolue pas les fonctions multi-retour

[codec_abc]

Je pense que tu n'as pas bien compris l'exemple.
Ce qui est appelé nommage concerne bien le sens premier, c'est à dire le nom de la fonction
- Une fonction qui retourne un nom d'utilisateur sera écrite username = GetUsername() .
- Une fonction qui retourne un nom d'utilisateur et son mot de passe sera écrite (username, password) = GetUsernameAndPassword() .
- Une fonction qui retourne un nom d'utilisateur, son mot de passe et un identifiant sera écrite (username, password, matricule)= GetUsernameAndPasswordAndMatricule().
- Une autre (username, password, matricule, age)= GetUsernameAndPasswordAndMatriculeAndAgeDuCapitaine().

Ca devient vite impossible

Sur le principe tu as raison mais je trouve l'exemple pas vraiment pertinent. C'est pas parce qu'une feature existe dans un langage que l'on est obligé de la sur-exploité. C'est comme les lambda et les closures : Quand c'est utilisé de manière intelligente c'est très bien, c'est pas pour autant qu'on va en mettre partout au point de remplacer les fonctions/méthodes "classiques".

Mais il est vrai qu'avec la POO, le problème est résolu, puisque même si l'on ne retourne toujours qu'un seul résultat, c'est une classe que l'on retourne, donc un ensemble de données cohérentes.

Une "bête" structure suffit. La POO n'a pas grand chose à voir ici.

[Angelsafrania]

Sur ce point, on a tous pris l'habitude de donner des valeurs particulières au résultat (du calcul) pour faire passer l'information sur l’exécution de ce même calcul. Parce qu'on a pas vraiment le choix, mais conceptuellement c'est quand même une belle aberration. Qui pourrait être résolue pas les fonctions multi-retour

Il existe les exceptions dans pas mal de langage pour ce cas là.
Mais effectivement même avec les exceptions on a quand même tendance à mettre des NULL dans les retours (même si y'a des patern pour ne pas le faire en POO https://en.wikipedia.org/wiki/Null_Object_pattern)

[fatbob]

Mais effectivement, ça aurait une grande utilité que personne n'a mentionné.
Une fonction, en réalité, a besoin de retourner 2 résultats, et pas un seul
- le résultat du calcul, certes
- mais aussi et surtout le résultat de l’exécution du calcul, s'il s'est bien effectué, avec ou sans erreur, etc.
Sur ce point, on a tous pris l'habitude de donner des valeurs particulières au résultat (du calcul) pour faire passer l'information sur l’exécution de ce même calcul. Parce qu'on a pas vraiment le choix, mais conceptuellement c'est quand même une belle aberration. Qui pourrait être résolue pas les fonctions multi-retour

200 % d'accord. Et même plus.

[Médinoc]

C'est en partie à ça que servent les exceptions: Si le calcul s'est déroulé sans erreur, on peut utiliser la valeur de retour; sinon, la fonction ne retourne pas de valeur et lance une exception à la place, entraînant un chemin d'exécution différent.

[fatbob]

C'est vrai.
C'est vrai aussi que la limitation est rarement réellement pénalisante et souvent assez facile à contourner.

[Benbout]

Mais effectivement, ça aurait une grande utilité que personne n'a mentionné.
Une fonction, en réalité, a besoin de retourner 2 résultats, et pas un seul
- le résultat du calcul, certes
- mais aussi et surtout le résultat de l’exécution du calcul, s'il s'est bien effectué, avec ou sans erreur, etc.
Sur ce point, on a tous pris l'habitude de donner des valeurs particulières au résultat (du calcul) pour faire passer l'information sur l’exécution de ce même calcul. Parce qu'on a pas vraiment le choix, mais conceptuellement c'est quand même une belle aberration. Qui pourrait être résolue pas les fonctions multi-retour

C'est vrai, le code source de mon serveur de jeu (scripté en pawn un langage de script, héritier du small c) fait 80k de lignes et si je retirais tous les return -1; qui s’agglutinent tels des virus dans mes fonctions, le code serait bien moins cracra et plus plaisant à parcourir, puis parfois selon le resultat que doit retourner le calcul on doit changer de valeur d'erreur pour l’interpréter correctement ensuite sinon on risque de noyer le signal d'erreur en croyant que c'est le resultat du calcul etc etc. C'est vraiment casse tete parfois, et pour pas grand chose au final.

[ijk-ref]

Mais effectivement, ça aurait une grande utilité que personne n'a mentionné.
Une fonction, en réalité, a besoin de retourner 2 résultats, et pas un seul
- le résultat du calcul, certes
- mais aussi et surtout le résultat de l’exécution du calcul, s'il s'est bien effectué, avec ou sans erreur, etc.
Sur ce point, on a tous pris l'habitude de donner des valeurs particulières au résultat (du calcul) pour faire passer l'information sur l’exécution de ce même calcul. Parce qu'on a pas vraiment le choix, mais conceptuellement c'est quand même une belle aberration. Qui pourrait être résolue pas les fonctions multi-retour

Bon comme je passais par là et que je ne me souviens pas d'avoir répondu à cette remarque ces 9 dernières années :


Je tiens à rectifier que tu fais une mauvaise interprétation AMHA. Ceci n'est pas un cas où la fonction devrait renvoyer deux résultats MAIS plutôt seulement un résultat différent pour deux cas de figures. Quand tu as un calcul correct tu n'as pas besoin de code d'erreur et quand t'as une erreur tu n'as pas de résultat de calcul. Il faudrait donc une fonction avec deux sorties chacune avec un résultat et pas une sortie avec deux résultats.


Ce que permet la gestion des exceptions dans la plus part des langages tel le C++ et C# mais de manière lourde. Puisque l'idéale serait d'avoir une seconde sortie renvoyant un résultat de la même manière que la première sortie - c'est à dire juste une valeur à mettre dans la pile et un saut dans le code parfaitement défini et typé à la compilation.


Je verrais une utilisation comme cela :

Code C# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
try int i = int.Parse(s) otherwise i = 0;
 
try int j = int.Parse(s) otherwise return;
 
try int k = int.Parse(s) otherwise Console.WriteLine("impossible à parser"); // Erreur à la compilation car 'k' n'est pas toujours défini (pour la suite du code)
 
try DX.DrawTriangles(vertices) otherwise(int error) { Console.WriteLine("Erreur dans le code n°" + error);  return; }

Avec la possibilité d'utiliser classiquement ces méthodes/fonctions sans "try-otherwise" où les secondes sorties (d'erreur) seront traitées dans ce cas comme des exceptions classiques. J'imagine donc que le compilateur devra construire deux versions de ces méthodes : une avec exceptions classiques et une autre avec double sorties.

[foetus]

Ce que permet la gestion des exceptions dans la plus part des langages tel le C++ et C# mais de manière lourde.

Justement , sevyc64 doit parler en pur C (vanilla C) où effectivement tu as besoin d'avoir 2 résultats.

Un code erreur (qui est retourné pour tester si le résultat est ok) et le résultat du calcul (qui est un paramètre).

Édit: Avec les boucles imbriquées qui font saigner les yeux et le cerveau des pro "try/catch partout"

Parce qu'en cas d'erreur, le résultat est souvent indéfini (et on s'en fiche, il y a une erreur)

Et des fois, tu peux ne pas avoir d'erreur, mais un résultat erroné (avec une valeur spéciale ... comme 0 ou 0xFF)