いくつかの理由で、私はこの変更に反対します。

1）これは比較的重要な構文上の変更です。 これは開発者との混乱を引き起こし、Pythonが経験したのと同じ混乱にGoを導くことに貢献する可能性があります。

2）役に立たないと思いますが、なぜ彼らは価値があるよりも厄介なのですか？ いたるところにあるreturn nilは少し冗長ですよね？

@awnumar for 2これは＃21182とうまくペアになります

いたるところにあるリターンニルは少し冗長ですよね。

シンプルさは冗長性を打ち負かします。 return nilの束は、変数の最新の値を追跡し、それが（意図的にまたはによって）シャドウされていないことを確認する必要があるreturn束よりもはるかに理解しやすいです。間違い。）

ネイキッドリターンを使用すると、他の方法では達成できない1つのことを実行できることに注意してください。それは、deferで戻り値を変更することです。 コードレビューコメントウィキを引用

最後に、場合によっては、遅延クロージャで変更するために結果パラメータに名前を付ける必要があります。 それはいつでも大丈夫です。

ネイキッドリターンを排除するための完全な提案では、代わりにそのような使用法をどのように書くべきか、そしてなぜ代替形式が望ましい（または少なくとも受け入れられる）のかを説明する必要があります。 明らかな書き直しは、多くの定型文と繰り返しを伴う傾向があり、通常はエラー処理を伴いますが、メカニズムは一般的です。

私はこれはないと思います

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

より読みやすい

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

、ごめん。

OTOH-はい、シャドウイングは最悪です。 それを完全に非合法化することは意味がありません（生成されたコードが思い浮かびます）が、少なくとも戻り値の名前のシャドウイングの禁止に喜んで投票します。 ああ、そしてコンパイラに他のすべての場合にいくつかの診断を生成させるのもいいでしょう:)

編集：どうやらそれについて話している＃377があります

@josharian私は、据え置き関数がまだ戻り変数を変更できると思っていました。 そのセマンティクスは、returnステートメントの構文とほぼ直交しているように見えます。

@josharian遅延関数でそれらを変更できるようにするには、名前付きの戻りパラメーターが必要です。 そのためにネイキッドリターンを使用する必要はありません。 明示的な値を指定して返すと、遅延関数が実行される前に、値が名前付きの戻り値にコピーされます。

@bcmills @dominikhそう、ばかげた私。 精神的失効; 私をまっすぐにしてくれてありがとう。

戻り値のない関数は、 returnを「むき出し」にすることができるはずです：

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

私は1.5分かけてGo標準ライブラリ（ 4年前の/ cc @bradfitz）にある次のGoコードを見て、悪いバグがあるのではないかと信じていませんでした。

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

具体的には、この部分：

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

一見したところ、最初の行で、新しい変数tcとerrが、名前付きのerr error returnとは異なる短い変数宣言構文を使用して宣言されているように見えました。変数。 その後、それは裸のリターンが効果的に戻ったように私には見えたnil, nilではなく、よりnil, errそれがしてきたはずですと。

それについて非常に熱心に考えた約90秒後、私はそれが実際に正しいコードであることに気づきました。 名前付きerr error戻り値は関数本体と同じブロックにあるため、短い変数宣言tc, err := ...は、 tcを新しい変数として宣言するだけで、新しいerr宣言しません。 err error戻り変数はln.AcceptTCP()の呼び出しによって設定されているため、裸のreturn実際にはnil以外のエラーを返します。したほうがいい。

（新しいブロックにある場合、実際には「エラーはリターン中にシャドウされます」というコンパイルエラーになります。ください。）

これはもっと明確で読みやすいコードだったと思います。

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

この話を共有したかったのは、プログラマーの時間を無駄にするベアリターンの良い例だと思うからです。 私の意見では、ベアリターンはわずかに記述しやすいですが（数回のキーストロークを節約するだけです）、フルリターンを使用する同等のコード（ベア以外）と比較して、コードが読みにくくなることがよくあります。 Goは通常、読み取りを最適化する正しいことを行います。これは、書き込みよりもはるかに頻繁に（より多くの人が）行うためです。 ベアリターン機能は読みやすさが低下する傾向があるように思われるため、Go2で削除すると言語が改善される場合があります。

免責事項：私が最も頻繁に書いたり読んだりするGoコードでは、（読みにくいと思うので）ベアリターンを避ける傾向があります。 しかし、それは私がベアリターンを読んだり理解したりする経験が少ないことを意味し、それはそれらを読んだり解析したりする私の能力に悪影響を与えるかもしれません。 それはちょっとしたキャッチ22です。

@shurcooL 、私もtcとcがあるという事実cがあるはずですtc 。 そのコードが何をするのかを理解するのにほぼ同じ時間がかかりました。

これはおそらく関連しています：

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

そして関連する議論：

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

記事から：

Golangが提供するネイキッドリターンが気に入らない、または好まない場合は、次のように同じメリットを享受しながらreturn oiを使用できます。

名前付きの戻り値は素晴らしいです！ 名前付き戻り値のベアリターンが問題です。 :-)

@awnumar 、それは関係ありません。 Hacker Newsに関する私のコメントを参照してください： https ：

これらを削除することは、明示的なエラー処理のアプローチに従うと思います。 私はそれらを使用しません。

ベアリターンのあるgolang-nutsについてレビューしたコードは理解するのが難しいことではありませんが、変数スコープの解析は読者にとって不必要な追加の作業です。

特に関数に複数のリターンがある場合、私はベアリターンが大好きです。 コードをよりクリーンにするだけです。 最大の理由は、goで作業することを選択したことです。

Go tool vet shadowは、潜在的なシャドウ変数を検出できます。 ファンクの循環的複雑度が低い場合、およびいくつかのテストケース。 トラブルになるとは思えませんでした。 私は間違っている可能性がありますが、むき出しのリターンがいかに悪いかを示すためにいくつかの例を見たいと思います。

むき出しのリターンがいかに悪いかを示すいくつかの例を見たいと思います。

@kelwang上記の7つのコメントからln.AcceptTCP()についての私の例を見ましたか？

こんにちは、 @ shurcooL 、thx

ええ、あなたは素晴らしいポイントを作ったと思います。
しかし、あなたが言ったように、それは4年になります。 すでに慣れているのではないかと思います。

むき出しの返品の問題ではないと思います。 しかし、複数の変数の初期化で混乱が生じます。

私にとって、シャドウ獣医ツールは通常非常にうまく機能します。 私はそれについて本当に心配することはありません。
たぶん、そのような混乱を避けるために、golinterでチケットを記入する必要があります。 エラーの名前を変更するか、最初にtcを上に宣言するか。 リンターの提案で十分だと思います。

@kelwang私の意見では、関数がreturnステートメントが醜くなるポイントに複数のリターンがある場合、構造体/構造体へのポインターは、ベアリターンではなく返される必要があります。

＃377が言及されているので、 ln.AcceptTCP例での混乱の原因は、ベアリターン自体ではなく、 :=背後にある魔法に関するものであると主張します。

ln.AcceptTCP場合は、より明示的な形式の短い宣言（参照されている問題で

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

多変数:=を見ただけでは、どの変数が宣言されているかわかりません。それを知るには、ブロックの前の部分をすべて考慮する必要があります。
ブロック境界がどこにあるかについての見落とし、そしてあなたは見つけにくいバグに終わるかもしれません。
また、多変数:=を修正して、必要なものを正確に宣言することはできません。 短い宣言をあきらめるか、コードを再編成する必要があります。

これの特定の結果に対処しようとする多くの提案を見てきましたが、問題の根本は:=の明示性の欠如にあると思います（シャドウイングが落とし穴と見なされるときはいつでも、それは実際には多変数:=のせいです）。

ベアリターンが必ずしも価値があると言っているのではなく、私たちが見ているのは複合的な問題だと言っているだけです。

読みやすさの議論に関係なく、ベアリターンは論理的に一貫性がなくエレガントではないと思います。 それはどういうわけか不安定な見方です。 ただし、ここで主観的なのは明らかに私だけではありません。

@tandr小さな構造体オブジェクトを返すことは、3つ以上の戻り値を持つよりもはるかに明確だと思います。

＃19642を支持して＃21182で議論され放棄されたが、純粋に裸のリターンの代替：

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

Go2で削除することに賛成ですが、 gofmt介してGo1で（基本的に）削除するように＃28160を作成しました。 人々のコメントをいただければ幸いです！ 😄

DBレイヤーでは、ネイキッドリターンが驚くほど役立つことがわかりました。

これは実際に編集された製品コードです-

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
}

ここには6つのreturnステートメントがあります。 （実際にはさらに2つありますが、簡潔にするためにコードを短くしました）。 しかし、私のポイントは、エラーが発生した場合、呼び出し元はerr変数のみを検査するということです。 return errを書き込む必要がある場合でも問題はありませんが、戻り署名と一致させるには、 return st, errを何度も書き込む必要があります。 そして、返す変数がもっとある場合、これは直線的に増加します。 あなたのreturnステートメントはどんどん大きくなっています。

一方、名前付きのreturn paramsがある場合は、returnを呼び出すだけです。これは、他の変数がどのような状態であっても返されることを知っています。 これは私を幸せにし、それは素晴らしい機能だと思います。

@agnivadeは、これが編集されたためかどうかは

@agnivade 6つのリターンのうち5つは、次のGo2エラー処理スキームの下で蒸発するはずです:-)

フィードバックウィキの詳細。

@ nhooyr-ああ親愛なる..今日は製品プッシュをしているようです..：man_facepalming ：： sweat_smile：

@ networkimprov-その通りです。 私は新しいエラー処理について考えていませんでした。 個人的には、この新しいエラー処理が開始されたときは問題ありません。 しかし、それでも、これはかなり大きな変更であり、多くのコードベースを壊すことになります。 間違いなく、自動ツールでこれを修正できます。 しかし、Go 2では、これらの主要な変更をいくつ行う必要があるのでしょうか。

Go2には、Go1との下位互換性がないというライセンスが与えられていますね。

Go2でのこの変更と互換性があるように、既存のGo1コードをアップグレードするためのツールを作成できることに同意します。

Go2には、Go1との下位互換性がないというライセンスが与えられていますね。

上記のライセンスを使用しないことはほぼ確実です。 下位互換性を破ることは、エコシステムに関して非常に困難でリスクがあります。

重大な変更が現在計画されていない場合、この提案は中断を引き起こす価値がないことに同意します。 重大な変更が計画されている場合は、提案を検討してください。 この提案に対応するためにgo fixを更新するの

Go2エラー処理のための新しいキーワードがテーブルにあり、それはいくつかのコードを壊すでしょう。

Go 2の場合、価値があるときにコードを解読できますが、コストがかかります。 新しいキーワードのコストは、診断と修正が簡単であるという点で、言語機能を削除するコードよりも少なくなります。 新しいキーワードの利点は、キーワードと同じ識別子を使用するコードをわずかに書き直さなければならないコストを超えると想像することができます。

このケースは、新しいキーワードよりも書き直すのが難しいですが、実行可能です。 最も重要な質問は、裸のリターンを書くときにそれが何を意味するのかを人々が誤解しているのかということだと思います。 ネイキッドリターンの使用によるプログラムの本当のバグはありますか？ 実際のバグがなくても、コードを書いているときに、ネイキッドリターンを誤って使用して間違いを犯していませんか？

ネイキッドリターンの使用によるプログラムの本当のバグはありますか？

それが本番環境のバグを引き起こすかどうかはわかりませんが、私にとっては、裸のリターンを見ると、通常、何が起こっているのかを理解しようと一時停止します。 シャドウされたerr予期しない方法で機能することに偏執的になります。これは、シャドウされた

とはいえ、下位互換性があり、gofmtにはすでにいくつかの小さな変更が加えられているため、＃28160の方がおそらくより良い修正だと思います。

シャドウエラーが予期しない方法で機能していることに偏執的になります

私は最近、少なくともバグを引き起こすという点では、私が思っていたほどシャドウイングについて心配する必要がないことreturnが発生した時点で戻り変数のいずれかがシャドウされている場合、ベアリターンを使用するのは実際にはコンパイル時エラーです。

そして、誰かが何かを言う前に、ええ、私はその例には他にもたくさんの問題があることを知っています。 デモンストレーションのために何かを一緒に投げていました。

28160が閉じられました。これは、Go1でこれを修正する際にドアを閉じるように見えます。

さて、この種の変更は、どのようにアプローチしても、Go1では決して起こりませんでした。

たぶん、たぶん、問題は:=にあり、それを削除する提案が必要です。

これはシャドウイングだけではありません。 それは、読者に必要以上の文脈を持たせることです。

ここでのコード例の使用： https ：

最初の例では、読者はerr値をトレースするだけで、何が返されるかを正確に把握できます。

2番目の例では、リーダーは3つの追加変数の値をトレースする必要があります。

別の言い方をすれば

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

vs

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

（値がnilの変数を返す場合とnilを返す場合）

どっちがいい？

私は後者の方が好きです。なぜなら、それは明確で一見理解しやすいからです。 ベアリターンを削除すると、推定する必要のあるリターン値を奨励するのではなく、明示的なリターン値を奨励します。

認知的負担のもう1つの例は、ベアリターンを見ると、void関数（ func(arg T) ）と非void関数（ func(arg T) ret R ）を区別できないことです。 関数に戻り値がないか、返される名前付きの値がある可能性があります。 戻り値が実際に何を意味するかを知るには、関数のシグネチャを覚えておく必要があります。 確かに大きな問題ではありませんが、頭に入れておかなければならないことがもう1つあります。

ベアリターンステートメントは、場合によっては混乱を招く可能性があります。 しかし、それらが役立つ特定のケースもあります。 そしてもちろん、それらは今日機能します。これは、それらを維持するための強力な議論です。

ここでの最善の解決策は、言語でベアリターンを維持する可能性がありますが、シャドウイングが発生する複雑なケースでそれらを使用することを警告するリントチェックを追加することを検討してください。

これは、Goコードベースを読み始めたときの私の正確な考えです。
短いバージョンは、コードを高速化し、あちこちで構文をだまして、被害者のコンピューターを毒殺したいハッカーに適しているはずです。
しかし、エンタープライズアプリケーションの観点からは、キーストロークを少し節約するだけで、検出に数百万のコストがかかる可能性があります

編集：私の提案は、値を返す関数のベアリターンを無効にし、void関数のベアリターンをそのままにすることであることを明確にしたいと思います。

そのため、2017年からまったくリターンのないサンプルコードに遭遇しました。go1.12.5（windows / amd64）では、これはgoビルドでリターンがないというフラグが立てられます。 これは同じ問題ですか？ 過去に暗黙の返品が許可されていましたが、現在は無効ですか？ ベアリターンでは直せませんでした。 タイプはuintptrだったので、0を返しました（nillはlintしません）。

@datatribe 、それを変えるような変化は考えられません。 返品を逃すのは間違いでした。 詳細を記載した新しいバグを報告しますか？

@datatribe 、それを変えるような変化は考えられません。 返品を逃すのは間違いでした。 詳細を記載した新しいバグを報告しますか？

サンプルコードが良くなかった可能性は十分にあります。 ありがとう@bradfitz

それが本番環境のバグを引き起こすかどうかはわかりませんが、私にとっては、裸のリターンを見ると、通常、何が起こっているのかを理解しようと一時停止します。 シャドウされたerr予期しない方法で機能することに偏執的になります。これは、シャドウされた

私はそれについてあなたに同意します。 名前付きパラメーター変数に割り当てられている値を理解しようとすると、一時停止します。 裸のリターンでの私の不快な読書（特に長い）関数は、実際に返されるものを簡単に追跡できないことです。 各ネイキッドリターンは、実際には名前付きパラメーターのreturn p1, p2, ..., pnを意味しますが、一部のパラメーターの値は、 return nil, nil 、 return nil, err 、 return "", err 、 return p, nilように明らかにリテラルである場合があります。 return p, err return p, nilではなくreturn p, err 。 return nil, errと書いた場合、 errまだnil値である可能性がありますが、最初の戻り値がnilことは明らかです。 ネイキッドリターンが許可されていない場合、可能であれば、ライターはreturnステートメントにリテラル値を書き込む可能性が高くなります。 実際、コードのレビュー中に裸のリターンを避けるように依頼したとき、それらはすべてリテラル値を使用していました。

作家が裸のリターンで書くとき、彼らは何が返されるかについて考えない傾向があります。 私が彼らに裸のリターンを避けるように頼んだとき、彼らは彼らが返したい実際の値について考え、部分的に構築された値のような間違った値を返していることに気づきました。 暗黙的よりも明示的の方が優れているのではないですか？

エラーフローをインデントすることをお勧めしますが、実際にはすべての人がこのパターンに従うわけではありません。特に、多くの裸のリターンを持つ長い関数を作成するのが好きな人はそうです。 多くの裸のリターンを見て、それがエラーフローにあるかどうかを知るのは難しい場合があります。 私はコードを注意深く読み、それを注意深くデコードし、いくつかのリテラル値を使用してネイキッドリターンを非ネイキッドに変換します。そうすれば、はるかに読みやすくなります。 （コードが複雑な場合、リテラル値を把握できない場合があります）

ドキュメントのコメントブロックには、いくつかの意味のある条件に対して何が返されるかが記載されていることは知っていますが、すべての人がそうしているわけではありません。 いくつかのリテラル値を含むreturnステートメントを使用すると、コードを確認することで簡単にそれに従うことができます。

名前付きパラメーターと裸でないリターンを一緒に使用できることは知っていますが、誰もがそれを知っているわけではありません。 私はよく次のようなものを目にしますが、 return io.EOF方が良いと思います。

err = io.EOF
return

とはいえ、下位互換性があり、gofmtにはすでにいくつかの小さな変更が加えられているため、＃28160の方がおそらくより良い修正だと思います。

gofmtの仕事であっても、 gofmtがそれらを元に戻すべきであるという他の提案には同意しません。 これは、 return p1, ..., pn機械的に配置するだけでは、コードが理解しやすくならないためです。

lintツールがそれをチェックできる可能性はありますが（ nakedretはそれを行います）、IMO、ネイキッドリターンはメリットよりも害があります。 また、ネイキッドリターンを削除するメリットは、互換性を損なう害よりも小さい可能性があることにも同意します。 しかし、機械的なgo fixコードが読みやすくならない場合でも、 go fixで簡単に修正できると思います。

私の意見では、Goは非常に明確で読みやすい言語です。 そして、ネイキッドリターンは言語のごく一部であり、コードを理解するのが難しくなります。

変更https://golang.org/cl/189778はこの問題に言及しています： cmd/go/internal/get: propagate parse errors in parseMetaGoImports

私は少数派かもしれませんが、実際には反対のことを提案したいと思います。 名前付きリターンを持つ関数は、常にベアリターンを使用する必要があります。 それ以外の場合は、コードが嘘をついているように見えます。 値を割り当ててから、戻ったときにサイレントに上書きする可能性があります。 これは私が何を意味するかを説明するための悪いコードです、

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

そこでベアリターンを使用するだけの場合、コードは再び意味をなします。

@millerlogic私はそれがあまりにも攻撃的だと思います。 たとえば、次のようなコードには何の問題もありません。

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

また、現在の提案が提起しているものとは反対のことを提案しているので、あなたの主張は別の反対提案として最もよく当てはまると思います。

@mvdan良い点ですが、悪魔化を伴わない中間点があると思います。 以前に戻り変数に割り当てた場合、値を明示的に返さないという次のような考えを読んだと思います。 どこかに実装されているかもしれませんが、私はそれをヒットしたことはありません。 つまり、私のhelloの例は、ネイキッドリターンなしでエラーになり、fooまたはbarが割り当てられていないため、例は成功します。

これらはgoのツアーから削除する必要があると思います。そうすれば、新しいgo開発者はこれらを使用することが推奨されません。 実際には、それらは単なる認知税です。 私が見たいくつかの人はいつも私の脳に「何を待つの？！...そうそう、裸のリターンと名前付きのリターン値」と言う必要がありました。 。