数日前、いくつかの新機能について、仕様書のドラフト案が上がっていました。
どちらも、これまであった Design Meeting の議事録通りな感じ。
あと、ちょこっと変更が検討されて、結局元さやに納まったものが1件。
base(T)
これは、C# によるプログラミング入門に説明を書いた直後に「やっぱり C# 8.0 ではやめておく」となってしまったやつ。 (しょうがないんで「C# 8.0 から外れました」って書き足してそのまま残してあったり。)
まあ、.NET ランタイムのレベルで対応してもらう予定だそうです。
base(T).M()
と書いたとき、T
自体に M
の実装がなくても基底クラスをたどって最初に見つかった M
を呼んでもらえるという仕様。
UTF-8 String Literals
待望の。
といっても、Utf8String
自体についてはまだいくつか悩ましいポイントがあり…
-
string
(今は UTF-16)自体を UTF-8 に切り替えるオプションがやっぱりほしい- とはいえ、インデクサー(UTF-16 での i 文字目を
s[i]
で定数時間アクセスできる)を期待しているコードが壊れる - unsafe に
fixed (char* p = s)
しているコードも壊れる
- とはいえ、インデクサー(UTF-16 での i 文字目を
-
System.String
に対して C# キーワードのstring
があるけどUtf8String
に対してはどうするべきか- キーワード足さない?
ustring
?utf8
?
-
クラス名自体まだ悩ましい
- 今回のドラフト案も冒頭に「corert 側が今のところその名前になってるのでそれに従う」との注釈がまだ必要な段階
というのもあって、C# vNext で検討されているのは本当に「手始め」という感じのものだけ。
- (今ある) 文字列リテラルをそのまま使う
-
以下のようなルールだけ C# に追加
- 文字列リテラルから
Utf8String
への暗黙の型変換を認める Utf8String
はconst
にできて、それに渡せるのはconst
な文字列のみ+
演算子はUtf8String.Concat
として解釈する
- 文字列リテラルから
-
コンパイル結果としても
string
(UTF-16) のままプログラムにデータを埋め込む- 読み込み時に .NET ランタイム組み込みのヘルパー関数を呼んで UTF-8 に変換する
- 将来的には直接 UTF-8 なデータをプログラムに埋め込めるように改修する可能性はあり
まあ、Utf8String
クラスが標準ライブラリに入ってくれるだけでも随分助かりはするんですが…
既存のコードベースが string
だらけなのがだいぶやっぱりネックになりそうな感じ。
Discard parameters
この issue の趣旨自体は、Action<T, T> a = (_. _) => { };
みたいな書き方を認めたいというもの。
2個以上の引数が _
の時、それはdiscard扱いにします。
ラムダ式の中で _
を普通の変数のように触ろうとするとコンパイル エラー。
一方で、1引数の _
は今現在有効は引数名として使えてしまっているので、破壊的変更を避けるために今のまま。
で、ここ数日で、一瞬、「ラムダ式以外、普通のメソッドの引数やローカル関数にも適用してもいいんじゃないか」というのが議題に上がりました。 でも、名前付き引数がある以上、引数の名前は API の一部分であり、メソッドの外から見えてしまう情報になります。 そこを省略するのはあんまりお行儀がよくない。
なので結局、当初予定通り匿名関数(ラムダ式と匿名メソッド式)でだけ、_
のdiscard扱いをしたいという結論に。