Je serais contre ce changement, pour plusieurs raisons.

1) C'est un changement syntaxique relativement important. Cela pourrait semer la confusion chez les développeurs et contribuer à amener Go dans le même gâchis que Python a traversé.

2) Je ne pense pas qu'ils soient inutiles, pourquoi sont-ils plus d'ennuis qu'ils n'en valent la peine ? return nil s partout c'est un peu verbeux, tu ne trouves pas ?

@awnumar pour 2 cela se mariera bien avec #21182

return nils partout c'est un peu verbeux, tu ne trouves pas ?

La simplicité bat la verbosité. Un tas de return nil est beaucoup plus facile à comprendre qu'un tas de return où l'on doit rechercher la dernière valeur de la variable et s'assurer qu'elle n'a pas été occultée (intentionnellement ou par erreur.)

Notez que les retours nus vous permettent de faire une chose que vous ne pouvez pas accomplir autrement : modifier une valeur de retour dans un report. Citant le wiki des commentaires de révision de code :

Enfin, dans certains cas, vous devez nommer un paramètre de résultat afin de le modifier dans une clôture différée. C'est toujours OK.

Une proposition complète pour éliminer les retours nus devrait expliquer comment de telles utilisations devraient plutôt être écrites et pourquoi la forme alternative est préférable (ou au moins acceptable). Les réécritures évidentes ont tendance à impliquer beaucoup de passe-partout et de répétitions, et bien qu'elles impliquent généralement une gestion des erreurs, le mécanisme est général.

je ne pense pas que

func oops() (string, *int, string, error) {
    ...
    return "", nil, "", &SomeError{err}
}

est plus lisible que

func oops() (rs1 string, ri *int, rs2 string, e error) {
    ...
    e = &SomeError{err}
    return
}

,Pardon.

OTOH - oui, l'ombrage est nul. Cela n'aurait aucun sens de l'interdire purement et simplement (le code généré me vient à l'esprit), mais je voterais volontiers pour au moins l'interdiction de l'ombrage des noms de valeurs de retour. Oh, et faire en sorte que le compilateur génère un diagnostic dans tous les autres cas serait bien aussi :)

Edit : apparemment il y a le #377 qui en parle

@josharian Je supposais que les fonctions différées pouvaient toujours modifier les variables de retour. Cette sémantique semble plus ou moins orthogonale à la syntaxe de l'instruction return.

@josharian Vous avez besoin de paramètres de retour nommés pour pouvoir les modifier dans une fonction différée. Vous n'avez pas besoin d'utiliser un retour nu pour cela. return avec des valeurs explicites copiera les valeurs dans les valeurs de retour nommées avant l'exécution des fonctions différées.

@bcmills @dominikh bien, idiot moi. défaillance mentale ; Merci de m'avoir corrigé.

Une fonction sans valeurs de retour devrait toujours pouvoir "dépouiller" return :

func noReturn() {
    if !someCondition() {
        return // bail out
    }
    // Happy path
}

J'ai passé 1,5 minute à regarder le code Go suivant dans la bibliothèque standard Go (d' il y a 4 ans , /cc @bradfitz), avec incrédulité, pensant qu'il pourrait y avoir un mauvais bogue :

https://github.com/golang/go/blob/2d69e9e259ec0f5d5fbeb3498fbd9fed135fe869/src/net/http/server.go#L3158 -L3166

Concrètement, cette partie :

tc, err := ln.AcceptTCP()
if err != nil {
    return
}

À première vue, il m'a semblé que sur la première ligne, les nouvelles variables tc et err étaient déclarées en utilisant une syntaxe de déclaration de variable courte, distincte du retour nommé err error variable. Ensuite, il m'a semblé que le retour nu renvoyait effectivement nil, nil plutôt que nil, err comme il aurait dû l'être.

Après environ 90 secondes de réflexion, j'ai réalisé qu'il s'agissait en fait d'un code correct. Étant donné que la valeur de retour nommée err error trouve dans le même bloc que le corps de la fonction, la déclaration de variable courte tc, err := ... ne déclare que tc comme nouvelle variable mais ne déclare pas de nouveau err variable, donc la variable de retour nommée err error est définie par l'appel à ln.AcceptTCP() , donc le nu return renvoie en fait une erreur non nulle car il devrait.

(Si cela avait été dans un nouveau bloc, il s'agirait en fait d'une erreur de compilation "l'erreur est masquée lors du retour", voir ici .)

Je pense que cela aurait été un code beaucoup plus clair et lisible:

tc, err := ln.AcceptTCP()
if err != nil {
    return nil, err
}

Je voulais partager cette histoire parce que je pense que c'est un bon exemple de retours nus faisant perdre du temps au programmeur. À mon avis, les retours nus sont légèrement plus faciles à écrire (en économisant juste quelques frappes), mais conduisent souvent à un code plus difficile à lire par rapport au code équivalent qui utilise des retours complets (non nus). Go fait généralement ce qu'il faut pour optimiser la lecture, car cela est fait beaucoup plus souvent (par plus de personnes) que l'écriture. Il me semble que la fonctionnalité de retours nus a tendance à réduire la lisibilité, il se pourrait donc que la supprimer dans Go 2 améliore le langage.

Avis de non-responsabilité : dans le code Go que j'écris et lis le plus souvent, j'ai tendance à éviter d'avoir des retours nus (car je pense qu'ils sont moins lisibles). Mais cela signifie que j'ai moins d'expérience en lecture/compréhension des retours nus, ce qui pourrait influencer négativement ma capacité à les lire/les analyser. C'est un peu le catch-22.

@shurcooL , exemple intéressant qui m'a aussi tc et c . Je pensais que vous aviez fait une erreur en copiant-collant le code et au lieu de c il devrait y avoir tc . Il m'a fallu à peu près le même temps pour réaliser ce que fait ce code.

C'est probablement pertinent :

https://blog.minio.io/golang-internals-part-2-nice-benefits-of-named-return-values-1e95305c8687

Et la discussion associée :

https://news.ycombinator.com/item?id=14668323

De l'article :

Notez que si vous n'aimez pas ou préférez le retour nu proposé par Golang, vous pouvez utiliser return oi tout en bénéficiant du même avantage, comme ceci :

Les valeurs de retour nommées sont géniales ! Le retour nu des valeurs de retour nommées est le problème. :-)

@awnumar , ce n'est pas pertinent. Voir mon commentaire sur Hacker News : https://news.ycombinator.com/item?id=14668595

Je pense que leur suppression suivrait l'approche de la gestion explicite des erreurs. Je ne les utilise pas.

Le code que j'ai examiné sur golang-nuts avec des retours nus n'est pas difficile à comprendre, mais l'analyse de la portée des variables est un effort supplémentaire inutile pour les lecteurs.

J'aime vraiment le retour nu, surtout lorsqu'une fonction a plusieurs retours. Cela rend simplement le code beaucoup plus propre. La principale raison, j'ai choisi de travailler avec go.

Go tool vet shadow peut détecter les vars potentielles ombrées. Si une fonction a moins de complexité cyclomatique, plus quelques cas de test. Je ne voyais pas qu'il y aurait des problèmes. Je peux me tromper, mais je souhaite voir quelques exemples pour démontrer à quel point le retour nu peut être mauvais.

Je souhaite voir quelques exemples pour démontrer à quel point le retour nu peut être mauvais.

@kelwang Avez-vous vu mon exemple sur ln.AcceptTCP() parmi les 7 commentaires ci-dessus ?

Salut, @shurcooL ,

Oui, je pense que vous avez fait un bon point.
Mais comme tu dis, ça fait 4 ans. J'ai l'impression que vous vous y habituez peut-être déjà.

Je pense que ce n'est pas vraiment un problème pour le retour nu. Mais une confusion dans l'initialisation de plusieurs vars.

Pour moi, l'outil Shadow vet fonctionne généralement très bien. Je ne m'inquiète jamais vraiment pour ça.
Peut-être devrions-nous remplir un ticket dans Go Linter pour éviter ce genre de confusion. que ce soit renommer l'erreur ou déclarer tc en premier. Je pense qu'une suggestion de linter devrait suffire.

@kelwang À mon avis, si une fonction a plusieurs retours au point où les instructions de retour deviennent laides, une structure / pointeur vers une structure doit être renvoyée à la place d'un retour nu.

Puisque #377 a été mentionné, je dirais que la source de confusion dans l'exemple de ln.AcceptTCP est plus la magie derrière := que le simple retour lui-même.

Je pense que le cas ln.AcceptTCP ne serait pas si mal avec une forme plus explicite de déclaration courte ( proposée dans le numéro référencé):

func (ln tcpKeepAliveListener) Accept() (c net.Conn, err error) {
    :tc, err = ln.AcceptTCP()
    if err != nil {
        return
    }
    // ...
}

En regardant simplement un := multi-variable, vous ne pouvez pas savoir quelles variables sont déclarées : vous devez prendre en compte toute la partie précédente du bloc pour le savoir.
Un oubli sur l'endroit où se trouve la limite du bloc, et vous pouvez vous retrouver avec un bogue difficile à trouver.
De plus, vous ne pouvez pas corriger une multi-variable := pour la faire déclarer exactement ce que vous voulez ; vous êtes obligé d'abandonner la déclaration courte ou de réorganiser le code.

J'ai vu de nombreuses propositions essayant d'aborder les conséquences spécifiques de cela, mais je pense que la racine du problème est simplement le manque d'explicitation de := (je dirais également que, chaque fois que l'observation est considérée comme un piège, elle est vraiment juste la faute de := multi-variable).

Je ne dis pas que les retours nus en valent nécessairement la peine, je dis simplement que ce que nous voyons est un problème composé.

Indépendamment des arguments de lisibilité, je pense que le retour nu est moins logiquement cohérent et élégant. C'est en quelque sorte un point de vue fragile. Bien que, évidemment, je ne suis pas le seul à être subjectif ici.

@tandr Je pense que retourner un petit objet struct est beaucoup plus clair que d'avoir plus de trois valeurs de retour.

Alternative à un retour purement nu, bien que débattu et abandonné en #21182 au profit de #19642 :

func f() (e error) {
   return ... // ellipsis trigram
}

Alors que je suis favorable à sa suppression dans Go2, j'ai fait #28160 pour (essentiellement) le supprimer dans Go1 via gofmt . Les commentaires des gens là-bas seraient appréciés! ??

J'ai trouvé que les retours nus étaient étonnamment utiles dans la couche DB.

Il s'agit d'un véritable code de production rédigé -

func (p *PostgresStore) GetSt() (st St, err error) {
    var tx *sql.Tx
    var rows *sql.Rows
    tx, err = p.handle.Begin()
    if err != nil {
        return
    }
    defer func() {
        if err != nil {
            tx.Rollback()
        } else {
            tx.Commit()
        }
        rows.Close()
    }()

    rows, err = tx.Query(`...`)
    if err != nil {
        return
    }
    // handle rows
    for rows.Next() {
        var all Call
        err = rows.Scan(&all.Email, &all.Count)
        if err != nil {
            return
        }
        st.Today = append(st.Today, &all)
    }

    rows.Close()
    rows, err = tx.Query(`...`)
    if err != nil {
        return
    }
    // handle rows
    for rows.Next() {
        var all Call
        err = rows.Scan(&all.Email, &all.Count)
        if err != nil {
            return
        }
        st.Books = append(st.Books, &all)
    }
    return
}

Il y a 6 déclarations de retour ici. (En fait, il y en a 2 de plus, j'ai juste raccourci le code par souci de concision). Mais ce que je veux dire, c'est qu'en cas d'erreur, l'appelant n'inspectera que la variable err . Si je devais simplement écrire return err , tout ira bien, mais pour correspondre à la signature de retour, je dois écrire return st, err encore et encore. Et cela augmente linéairement si vous avez plus de variables à renvoyer ; votre déclaration de retour ne cesse de grandir.

Alors que, s'il existe des paramètres de retour nommés, j'appelle simplement return, sachant qu'il renverra également toutes les autres variables, quel que soit leur état. Cela me rend heureux et je considère que c'est une excellente fonctionnalité.

@agnivade ne sait pas si c'est parce que c'est expurgé, mais il semble que votre code de production paniquerait dans le report si les lignes sont nulles, ce qui se produirait si la requête échouait.

@agnivade cinq de vos six retours devraient s'évaporer sous le prochain schéma de gestion des erreurs Go2 :-)

Plus d'informations sur le wiki des commentaires .

@nhooyr - Oh mon

@networkimprov - C'est vrai. Je n'avais pas pensé à la nouvelle gestion des erreurs. Personnellement, je serais d'accord avec ce _quand_ la nouvelle gestion des erreurs atterrira. Mais même dans ce cas, je pense qu'il s'agit d'un changement assez important qui ne manquera pas de casser de nombreuses bases de code. On peut dire que nous pouvons résoudre ce problème avec des outils automatisés. Mais je me demande combien de ces changements majeurs devraient être apportés pour Go 2.

Go2 est autorisé à ne pas être rétrocompatible avec Go1, n'est-ce pas ?

Je suis d'accord que l'outillage pourrait être fait pour mettre à niveau le code Go1 existant pour être compatible avec ce changement dans Go2.

Go2 est autorisé à ne pas être rétrocompatible avec Go1, n'est-ce pas ?

Il est presque certain que nous n'utiliserons pas cette licence. Briser la rétrocompatibilité est incroyablement difficile et risqué du point de vue de l'écosystème.

Si des changements de rupture ne sont pas actuellement planifiés, je conviendrais que cette proposition ne vaut pas la peine de provoquer une rupture. J'espère que nous considérerons la proposition si/quand des changements de rupture sont prévus. La mise go fix jour de

De nouveaux mots-clés sont sur la table pour la gestion des erreurs Go2, et cela casserait du code.

Pour Go 2, nous pouvons casser le code quand cela en vaut la peine, mais cela coûte cher. Le coût d'un nouveau mot-clé est inférieur au code de suppression d'une fonctionnalité de langue, dans la mesure où il est simple à diagnostiquer et à corriger. Il est possible d'imaginer que l'avantage du nouveau mot-clé dépasserait le coût d'avoir à réécrire légèrement le code qui utilise un identifiant qui est le même que le mot-clé.

Ce cas est plus difficile à réécrire qu'un nouveau mot-clé, mais c'est faisable. Je pense que la question la plus importante est la suivante : les gens comprennent-ils mal ce que cela signifie lorsqu'ils écrivent un retour nu ? Y a-t-il de vrais bugs dans les programmes dus à l'utilisation d'un retour nu ? Même s'il n'y a pas de vrais bugs, quand les gens écrivent du code, font-ils des erreurs en utilisant incorrectement un retour nu ?

Y a-t-il de vrais bugs dans les programmes dus à l'utilisation d'un retour nu ?

Je ne sais pas si cela provoque des bugs de production, mais pour moi, quand je vois revenir nu, cela me fait généralement faire une pause pour essayer de comprendre ce qui se passe. Je deviens paranoïaque à l'idée que les err ombragés fonctionnent de manière inattendue parce que je ne suis pas sûr à 100% de ma compréhension de la façon dont ils interagissent. Cela rend la lecture du code beaucoup plus lente.

Cela dit, je pense que #28160 est probablement une meilleure solution car il est rétrocompatible et gofmt a déjà subi plusieurs modifications mineures.

Je deviens paranoïaque à propos de l'erreur ombrée qui fonctionne de manière inattendue

Je viens de découvrir récemment que vous n'avez en fait pas besoin de vous soucier de l'ombrage autant que je le pensais , du moins pas en ce qui concerne les bogues. C'est en fait une erreur de compilation d'utiliser un retour nu si l'une des variables de retour est masquée au moment où le return se produit.

Et avant que quiconque ne dise quoi que ce soit, oui, je sais qu'il y a beaucoup d'autres problèmes avec cet exemple. J'étais juste en train de préparer quelque chose pour démontrer.

28160 a été fermé, ce qui me semble fermer la porte à la résolution de ce problème dans Go1.

Eh bien, ce genre de changement n'allait jamais se produire dans Go 1 de toute façon, peu importe comment on l'abordait.

Peut-être que le problème est dans := , et nous devrions avoir une proposition pour le supprimer.

Il ne s'agit pas seulement d'observation. Il s'agit de faire en sorte que le lecteur transporte plus de contexte que nécessaire.

En utilisant l'exemple de code ici : https://github.com/golang/go/issues/21291#issuecomment -320120637

Dans le premier exemple, le lecteur sait exactement ce qui est renvoyé et n'a qu'à tracer la valeur de err .

Dans le deuxième exemple, le lecteur aurait besoin de tracer les valeurs de trois variables supplémentaires.

En d'autres termes

if err != nil {
    return err
}
...
return err

vs

if err != nil {
    return err
}
...
return nil

(renvoi d'une variable avec une valeur nil vs renvoi nil)

Lequel préfères-tu?

Je préfère ce dernier parce qu'il est explicite et plus facile à comprendre au premier coup d'œil. La suppression des retours nus encouragerait les valeurs de retour explicites au lieu d'encourager les valeurs de retour qui doivent être déduites.

Un autre exemple du fardeau cognitif est que vous ne pouvez pas distinguer une fonction vide ( func(arg T) ) d'une fonction non vide ( func(arg T) ret R ) lorsque vous regardez un simple retour. Il se peut que la fonction n'ait pas de valeurs de retour ou qu'elle ait des valeurs nommées qui sont renvoyées. Vous devez vous souvenir de la signature de la fonction pour savoir ce que signifie réellement le retour. Ce n'est certes pas un gros problème, mais c'est une chose de plus à garder en tête.

Les déclarations de retour nu peuvent être déroutantes dans certains cas. Mais il y a aussi des cas particuliers où ils sont utiles. Et, bien sûr, ils fonctionnent aujourd'hui, ce qui est un argument de poids pour les garder.

La meilleure solution ici est probablement de conserver les retours nus dans la langue, mais envisagez d'ajouter un contrôle de charpie qui avertit de leur utilisation dans des cas complexes dans lesquels se produit un ombrage.

C'est ma pensée exacte lorsque je commence à lire une base de code Go.
La version courte devrait être sympa pour les hackers qui veulent coder vite, faire des trucs avec la syntaxe ici et là et empoisonner l'ordinateur victime.
Mais en termes d'application d'entreprise, peu d'économies de frappes peuvent vous coûter des millions à détecter

Edit: Je tiens à préciser que ma suggestion est de désactiver le retour nu pour les fonctions qui renvoient une valeur et de laisser le retour nu pour la fonction void telle qu'elle est.

J'ai donc rencontré un exemple de code sans retour du tout à partir de 2017. Avec go 1.12.5 (windows/amd64), cela est signalé sur go build comme un retour manquant. Est-ce le même problème ? Les retours implicites étaient-ils autorisés dans le passé et désormais invalides ? Je ne pouvais pas le réparer avec un simple retour. Le type était uintptr, j'ai donc renvoyé 0 (nill ne pelucherait pas).

@datatribe , je ne vois aucun changement qui changerait cela. Il a toujours été une erreur de rater un retour. Signaler un nouveau bug avec les détails ?

@datatribe , je ne vois aucun changement qui changerait cela. Il a toujours été une erreur de rater un retour. Signaler un nouveau bug avec les détails ?

Il est tout à fait possible que l'exemple de code ne soit pas bon. Merci @bradfitz

Je ne sais pas si cela provoque des bugs de production, mais pour moi, quand je vois revenir nu, cela me fait généralement faire une pause pour essayer de comprendre ce qui se passe. Je deviens paranoïaque à l'idée que les err ombragés fonctionnent de manière inattendue parce que je ne suis pas sûr à 100% de ma compréhension de la façon dont ils interagissent. Cela rend la lecture du code beaucoup plus lente.

Je suis d'accord avec toi là-dessus. Cela me fait faire une pause pour essayer de comprendre quelles valeurs sont attribuées aux variables de paramètre nommées. Mon malaise à lire les fonctions (surtout longues) avec des retours nus est que je ne peux pas suivre facilement ce qui est réellement retourné. Chaque retour nu signifie en fait return p1, p2, ..., pn pour les paramètres nommés, mais parfois les valeurs de certains paramètres sont évidemment littérales comme return nil, nil , return nil, err , return "", err et return p, nil plutôt que return p, err . Si j'écris return nil, err , err peut toujours être la nil , mais il est clair que la première valeur de retour est nil . Si le retour nu est interdit, l'écrivain serait plus susceptible d'écrire des valeurs littérales dans l'instruction return si cela est possible. En fait, ils ont tous utilisé des valeurs littérales, lorsque je leur ai demandé d'éviter les retours nus lors des revues de code.

Lorsque les écrivains écrivent des retours nus, ils ont tendance à ne pas penser à ce qui est retourné. Lorsque je leur ai demandé d'éviter les retours nus, ils pensent maintenant à la valeur réelle qu'ils veulent retourner et remarquent qu'ils renvoyaient des valeurs erronées comme des valeurs partiellement construites. Ne vaut-il pas mieux être explicite qu'implicite ?

Je sais qu'il est recommandé d'indenter les flux d'erreurs, mais tout le monde ne suit pas ce modèle en réalité, en particulier les personnes qui aiment écrire des fonctions longues avec beaucoup de retours nus. Parfois, il est difficile de savoir s'il s'agit d'un flux d'erreur ou non en regardant de nombreux retours nus. Je lis attentivement le code, le décode et convertis les retours nus en non nus avec quelques valeurs littérales, c'est alors beaucoup plus facile à lire. (parfois, il n'est pas possible de comprendre les valeurs littérales si le code est complexe)

Je sais que le bloc de commentaires de la documentation mentionne ce qu'il renvoie pour certaines conditions significatives, mais tout le monde ne le fait pas. Avec l'instruction return avec quelques valeurs littérales, je peux suivre cela facilement en regardant le code.

Je sais que nous pouvons utiliser des paramètres nommés et des retours non nus ensemble, mais tout le monde ne le sait pas. Je vois souvent quelque chose comme ce qui suit, et je pense que return io.EOF est mieux.

err = io.EOF
return

Cela dit, je pense que #28160 est probablement une meilleure solution car il est rétrocompatible et gofmt a déjà subi plusieurs modifications mineures.

Je ne suis pas d'accord sur l'autre proposition selon laquelle gofmt devrait les remettre, même si c'est le travail de gofmt . C'est parce que le simple fait de mettre un tas de return p1, ..., pn mécaniquement ne rendra pas le code plus compréhensible.

Il est possible que les outils de charpie puissent le vérifier ( nakedret fait), mais IMO, le retour nu a plus de mal que d'avantages. Je suis également d'accord que l'avantage de supprimer le retour nu peut être plus petit que le mal de rompre la compatibilité. Mais je suppose que c'est facile à corriger avec go fix même si la mécanique go fix ne rendra pas le code lisible.

Go est un langage très clair et lisible à mon avis. Et le retour nu est une petite partie du langage qui me rend difficile à comprendre le code.

Le changement https://golang.org/cl/189778 mentionne ce problème : cmd/go/internal/get: propagate parse errors in parseMetaGoImports

Je suis peut-être minoritaire, mais j'aimerais en fait proposer le contraire. Les fonctions avec des retours nommés doivent toujours utiliser un retour nu. Sinon, on dirait que le code ment. Vous attribuez des valeurs, puis les écrasez potentiellement en silence au retour. Voici un mauvais morceau de code pour illustrer ce que je veux dire,

func hello() (n, m int) {
    n = 2
    m = 3
    return m, n
}

Si vous utilisiez simplement un retour nu, le code a à nouveau un sens.

@millerlogic Je pense que ce serait beaucoup trop agressif. Par exemple, il n'y a rien de mal avec un code comme :

func documentedReturns() (foo, bar string, _ error) {
    [...]
    if err != nil {
        return "", "", fmt.Errorf(...)
    }
}

Je pense également que votre argument conviendrait mieux en tant que contre-proposition distincte, puisque vous suggérez le contraire de ce que propose la proposition actuelle.

@mvdan Bon point, je pense qu'il y a un juste milieu qui n'implique pas de les diaboliser. Je pense avoir lu une idée similaire à: ne pas renvoyer explicitement une valeur si vous avez précédemment affecté la variable de retour. Il pourrait même être mis en œuvre quelque part, mais je ne l'ai jamais touché. Cela signifierait donc que mon exemple de bonjour ferait une erreur sans retour nu, et que votre exemple réussirait parce que foo ou bar n'ont pas été assignés.

Je pense que ceux-ci devraient être supprimés de la visite de go, de cette façon les nouveaux développeurs de go ne sont pas encouragés à les utiliser. En pratique, il ne s'agit que d'une taxe cognitive. Les rares que j'ai vu ont toujours demandé à mon cerveau de dire "attendez quoi ?!... oh oui, des retours nus et des valeurs de retour nommées" Je comprends peut-être les laisser dans la tournée pour que tout le monde le sache, mais il y a une page entière qui leur est dédiée .