新しいコードのほぼすべての場所でC ++ 17の[[nodiscard]]を使用しない理由は何ですか？

C ++ 17には[[nodiscard]]属性が導入されており、プログラマーは、返されたオブジェクトが呼び出し元によって破棄された場合にコンパイラーが警告を生成する方法で関数をマークできます。同じ属性をクラスタイプ全体に追加できます。

私は元の提案でこの機能の動機について読んだことがあり、C ++ 20が属性をのような標準関数に追加することを知っていますstd::vector::empty。その名前は戻り値に関する明確な意味を伝えません。

これはクールで便利な機能です。実際、それはほとんど便利すぎるようです。私が読んだ[[nodiscard]]すべての場所で、人々はあなたがそれを選択したいくつかの関数または型に追加し、残りを忘れるかのように議論しています。しかし、特に新しいコードを書くとき、なぜ破棄不可能な値が特別な場合である必要がありますか？通常、破棄された戻り値はバグではなく、少なくともリソースの無駄ではありませんか？

そして、コンパイラができるだけ多くのエラーをキャッチする必要があるというのは、C ++自体の設計原則の1つではありませんか？

もしそうなら[[nodiscard]]、独自の非レガシーコードをほぼすべての非void関数とほぼすべてのクラスタイプに追加してみませんか？

私は自分のコードでそれをやろうとしましたが、非常に冗長で、Javaのように感じ始めることを除いて、うまく動作します。意図をマークする他のいくつかの場合を除いて、デフォルトで破棄された戻り値について コンパイラーに警告させるほうがはるかに自然に思えます^[*]。

標準提案、ブログエントリ、Stack Overflowの質問、またはインターネット上の他の場所では、この可能性に関する議論がゼロであるため、何かが足りないはずです。

新しいC ++コードでは、なぜそのような仕組みが意味をなさないのでしょうか？冗長性は、[[nodiscard]]ほとんどどこでも使用しない唯一の理由ですか？

^{[*]理論的には、[[maydiscard]]代わりに属性のようなものがありprintf、標準ライブラリの実装のように関数にさかのぼって追加することもできます。}

古い標準との互換性を必要としない新しいコードでは、賢明な場合は常にその属性を使用してください。しかし、C ++の場合、[[nodiscard]]デフォルトは不適切です。あなたが提案する：

意図をマークする他のいくつかの場合を除いて、デフォルトで破棄された戻り値についてコンパイラーに警告させる方がはるかに自然に思えます。

これにより、既存の正しいコードが突然多くの警告を発します。既存のコードはすべて正常にコンパイルされるため、このような変更は技術的に下位互換性があると見なすことができますが、実際にはセマンティクスの大きな変更になります。

非常に大規模なコードベースを持つ既存の成熟した言語の設計決定は、完全に新しい言語の設計決定とは必然的に異なります。これが新しい言語である場合、デフォルトの警告は賢明です。たとえば、Nim言語では、不要な値を明示的に破棄する必要があります。これは、C ++のすべての式ステートメントをcastでラップすることに似てい(void)(...)ます。

[[nodiscard]]属性には、2つの場合に最も有用です：

• 関数が特定の結果を返す以外の効果を持たない場合、つまり純粋な場合。結果が使用されない場合、呼び出しは確かに役に立たない。一方、結果を破棄することは正しくありません。

• 戻り値をチェックする必要がある場合、たとえば、スローする代わりにエラーコードを返すCのようなインターフェイスの場合。これが主な使用例です。慣用的なC ++の場合、これは非常にまれです。

これらの2つのケースでは、値を返す不純な関数の巨大なスペースが残ります。例えば：

• .pop()要素を削除し、削除された要素のコピーを返すメソッドを持つキューデータ型を検討します。そのような方法はしばしば便利です。ただし、コピーを取得せずに要素のみを削除したい場合があります。それは完全に合法であり、警告は役に立たないでしょう。別の設計（などstd::vector）はこれらの責任を分割しますが、それには他のトレードオフがあります。

  場合によってはコピーを作成する必要があるため、RVOのおかげでコピーが無料で返されることに注意してください。

• 流fluentなインターフェイスを検討してください。各操作ではオブジェクトが返され、さらに操作を実行できます。C ++での最も一般的な例は、ストリーム挿入演算子<<です。[[nodiscard]]各<<オーバーロードに属性を追加するのは非常に面倒です。

これらの例は、「デフォルトでnodiscardを使用したC ++ 17」言語で警告なしに慣用的なC ++コードをコンパイルするのは非常に退屈であることを示しています。

光沢のある新しいC ++ 17コード（これらの属性を使用できる場所）は、古いC ++標準を対象とするライブラリと一緒にコンパイルされる場合があります。この後方互換性は、C / C ++エコシステムにとって重要です。そのため、nodiscardをデフォルトにすると、一般的な慣用的な使用例に対して多くの警告が発生します。この警告は、ライブラリのソースコードに大幅な変更を加えなければ修正できません。

おそらく、ここでの問題はセマンティクスの変更ではなく、各C ++標準の機能がファイルごとのスコープではなく、コンパイル単位ごとのスコープに適用されることです。将来のC ++標準がヘッダーファイルから遠ざかる場合、そのような変更はより現実的です。

私が[[nodiscard]]ほとんどどこにもいなかった理由：

1. （主要:)これは導入する方法私のヘッダにあまりにも多くのノイズを。
2. （メジャー:)他の人のコードについて強い投機的な仮定を立てるべきだとは思わない。あなたは私があなたに与えた戻り値を捨てたいですか？いいよ、ノックアウト。
3. （マイナー:) C ++ 14との非互換性を保証します。

ここで、デフォルトにした場合、すべてのライブラリ開発者に、すべてのユーザーに戻り値を破棄しないように強制することになります。それは恐ろしいことです。または[[maydiscard]]、無数に多くの関数を追加するように強制しますが、これも一種の恐ろしいことです。

例として：operator <<には、絶対に必要なコールまたは絶対に役に立たないコールに依存する戻り値があります。（std :: cout << x << y、最初のストリームはストリームを返すため必要であり、2番目はまったく役に立ちません）。ここで、エラーチェックのために存在する戻り値を全員が破棄するprintfと比較してください。したがって、どちらの場合も、nodiscardは損害を与えるだけです。