orange @[email protected]

Dictionary をストレージとする getter はあります。例えば JSON を辞書に変換したものをバックに持ち、それが持っているであろうフィールドをメソッドとして提供するなどが考えられます。裏側を動的なデータ構造にしつつ、メソッドとして提供することはあるかと

C# の文脈だと
public string this[string key] {
return this.dict[key];
}
が存在するので別名を付けたくないモチベーションはある

さっきも書いたけどそういうのは lookup とかそういう別名がちゃんと付けられるはずで，基本的に setter/getter ってただのフィールドアクセスだと思ってたのだけれども

それ getter ではなくない

100倍遅いのはデータ構造が悪いけど、でも getter の中身がフィールドアクセスとは限らない、例えば Dictionary のルックアップなこともあるでしょ？

代入式が使えるプロパティより、 GetHoge, SetHoge メソッドの形式を推すのは、どちらにしてもメソッド呼び出しだからです。メソッドの契約は名前だけ（言い過ぎ）であって、内部の実装はなんでもいい、例えば通常の変数へのアクセスより、その getter のほうが 100 倍遅い可能性だってあるわけで、それをばんばか使われるわけには行かない。そういう意味で、メソッド形式であるべきで、呼び出した結果は、呼び出し元がしばらく持っておけと思うわけです。

プロパティ自体はあんまり好きじゃなくて、 GetHoge, SetHoge のほうが好きなんですけどね。メソッド呼び出し感があるので。それはそれとして自動実装プロパティは、 public メンバーとしてあるべき契約のあり方（つまり getter, setter。値を記録するストレージを隠蔽する）でフィールドを公開できるという点でうまい

getter, setter が必要か、わからないから必要なのであって、そういう意味で自動実装プロパティというのは正解

たとえば
*foo(a, b) += 1;
のような式は += がないと一時変数を用意することになってしまうので、そこはさすがに

たとえば Rust でも ++ 演算子がなくて += 1 を使えみたいなデザインだったり、条件演算子がなくて if の値を使えという感じだったりして、あまり本質的でない拡張を言語機能から除外するというのはアリなのかなと最近は思っている