次の方法で共有

シフト オペレーターの要件の緩和

  • [アーティクル]

メモ

この記事は機能仕様についてです。 仕様は、機能の設計ドキュメントとして使用できます。 これには、提案された仕様の変更および機能の設計と開発時に必要な情報が含まれます。 これらの記事は、提案された仕様の変更が決定され、現在の ECMA 仕様に組み込まれるまで公開されます。

機能の仕様と行われた実装では、いくつかの違いがあることがあります。 これらの違いは、関連する言語設計ミーティング (LDM) メモに取り上げられています。

機能仕様を C# 言語標準に導入するプロセスの詳細については、仕様に関する記事を参照してください。

チャンピオン号: https://github.com/dotnet/csharplang/issues/4666

まとめ

シフト演算子の要件が緩和され、右側のオペランドが int のみに制限されなくなります。

目的

int以外の型を使用する場合、leading zero count に基づいてシフトするなど、別の計算の結果を使用してシフトすることは珍しくありません。 leading zero count などの自然型は入力型 (TSelf) と同じであるため、多くの場合、結果が既に範囲内にある場合でも、シフトする前にその結果を int に変換する必要があります。

ライブラリでの公開が計画されている汎用的な数学インターフェイスのコンテキスト内では、型が十分に知られておらず、int への変換が不可能であるか、明確に定義されていない可能性があるため、問題になる可能性があります。

詳細な設計

シフト演算子

§12.11 は、次のように修正する必要があります。

- When declaring an overloaded shift operator, the type of the first operand must always be the class or struct containing the operator declaration,
and the type of the second operand must always be int.
+ When declaring an overloaded shift operator, the type of the first operand must always be the class or struct containing the operator declaration.

つまり、最初のオペランドは演算子宣言を含むクラスまたは構造体でなければならないという制限は残ります。 一方、2 番目のオペランドが int でなければならないという制限は削除されます。

バイナリ演算子

§14.10.3 は、次のように修正する必要があります。

-*  A binary `<<` or `>>` operator must take two parameters, the first of which must have type `T` or `T?` and the second of which must have type `int` or `int?`, and can return any type.
+*  A binary `<<` or `>>` operator must take two parameters, the first of which must have type `T` or `T?`, and can return any type.

つまり、最初のパラメーターを T または T? にするという制限は残ります。 一方、2 番目のオペランドが int または int? でなければならないという制限は削除されます。

二項演算子オーバーロードの解決

§11.4.5 の箇条書きの最初の項目は、次のように修正する必要があります。

  • 演算 operator op(x,y) の X および Y によって提供される候補ユーザー定義演算子のセットが決定されます。 このセットは、X によって提供される候補演算子の和集合と、演算子がシフト演算子でない限り、Yによって提供される候補演算子で構成されます。候補演算子はそれぞれ、候補のユーザー定義演算子 §11.4.6 の規則を使用して決定されます。 X と Y が同じ型の場合、または X と Y が共通の基本型から派生している場合、共有候補演算子は結合セット内に 1 回だけ出現します。

つまり、シフト演算子の場合、候補の演算子は型 X によって提供される演算子のみになります。

デメリット

ユーザーは、C# で cout << "string" を実装するなど、推奨ガイドラインに従わない演算子を定義できるようになります。

代替

ライブラリで公開される汎用的な数学インターフェイスは、代わりに名前付きメソッドを明示的に公開することもできます。 これにより、コードの読み取り/保守が困難になる可能性があります。

汎用的な数学インターフェースでは、シフト操作で int が必要とされ、且つ変換を実行する必要がある場合があります。 この変換は、問題の種類によってはコストがかかったり、不可能になったりする場合があります。

未解決の質問

2 番目のオペランドが int に制限された理由についての「intent」を保持することについて懸念がありますか？

デザインミーティング

https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-02-09.md