博士

ロボ子、C# 14で拡張メンバーの構文が導入されたのじゃ！知っておるか？

ロボ子

はい、博士。既存の拡張メソッドの代替構文ですよね。型に機能を追加するのに便利だと聞きました。

博士

そうじゃ、そうじゃ！特に、型のソースコードにアクセスできない場合や、インターフェースである場合に便利なのじゃ！

ロボ子

静的拡張メソッド、インスタンス拡張プロパティ、静的拡張プロパティをサポートするとのことですが、具体的にどういうことでしょうか？

博士

ふむ、例えばじゃな、String型に『文字数を2倍にする』という機能を追加したいとするじゃろ？

ロボ子

はい。

博士

今までは`this string str`みたいに書いてたのを、拡張ブロックを使って書けるようになったのじゃ！

ロボ子

なるほど、拡張ブロックを使うことで、コードがより整理されるということですね。

博士

その通り！同じレシーバーに適用される拡張をグループ化できるのがミソじゃ！

ロボ子

記事には「拡張は、格納する静的クラスに編成される方法が重要」とありますが、これはどういう意味でしょうか？

博士

ふむ、静的クラス名は、曖昧さを解消するために使用されるからの。拡張メソッドがどこに定義されているかを明確にする必要があるのじゃ。

ロボ子

拡張ユーザーにとって最も重要なことは、拡張の作成方法について考える必要がないこと、とも書かれていますね。

博士

そうじゃ！拡張を使う人は、便利な機能が使えるだけで嬉しいのじゃからな！

ロボ子

記事には、新しい拡張メンバー構文のルールで、いくつかのthis-parameter extension methodsは現在の構文のままにする必要がある、とありますね。

博士

そうなんじゃ。レシーバーの型パラメーターが最初に表示されない場合とか、メンバーからの型パラメーターに依存する制約がある場合は、新しい構文に移植できないのじゃ。

ロボ子

なるほど、全てが新しい構文に置き換わるわけではないのですね。

博士

そういうことじゃ！C#設計チームは、拡張メンバーを静的およびインスタンス、メソッドおよびプロパティの観点から参照することが多いらしいぞ。

ロボ子

新しい拡張メンバー構文は、既存のthis-parameter extension methodsの膨大な量を保持しつつ、新しい種類の拡張メンバーを導入するものなのですね。

博士

そういうことじゃ！拡張メソッドの代替構文を提供し、新しい種類のメンバーと一貫性があり、this-parameter構文と完全に交換可能…って、ちょっと難しいのじゃ！

ロボ子

博士、お疲れ様です。少し休憩しましょうか？

博士

そうじゃな！ところでロボ子、拡張メンバーって、まるで秘密結社みたいじゃな！

ロボ子

博士、それは少し違うと思います…。