ピックアップRoslyn 3/22

最近さすがにだいぶ落ち着いて来た感あり。

今週は、今月4日のミーティング議事録が issue 上に上がったくらい。

Design Notes for Mar 4, 2015

https://github.com/dotnet/roslyn/issues/1303

アジェンダは以下の通り。

1. InternalImplementationOnly attribute <no>
2. Should var x = nameof(x) work? <no>
3. Record types with serialization, data binding, etc. <keep thinking> (引き続き考える)
4. “If I had a billion dollars…”: nullability <daunting but worth pursuing> (手ごわい。でも追及する価値ある)

InternalImplementationOnly属性

2/4 にブログで書いた奴のうちの1つ、InternalImplementationOnly 属性のその後。やっぱりあきらめるって。

今これを足すことで、今後の環境で目的を達成することはできる。でも、古い環境では何も制限をかけれなくて、結局、強制力が弱くてあまり意味がないだろう。という判断。

Should var x = nameof(x) work?

var を使った変数 x 宣言の中で、nameof(x) すると、型推論ができずにコンパイルエラーになるという挙動に関して。これは、仕様意図通りなんですが、この仕様でいいのかという議論が2月中にちょっと出ていました。その結論として、var x = nameof(x) はコンパイルできなくてOK、それが仕様ということに決定。

nameof は、同名のメソッドが定義されている場合や、、そちらが優先的に呼ばれます（後方互換性を保つため）。たぶん、そういう挙動との兼ね合いのせいだと思うんですが、nameof と書かれていても、結果の型が string に確定しません。その結果、var x = nameof(x) を認めるのは、型推論にかかるコスト的に厳しいはず。それで、この書き方を認めない仕様になっています。

Records

レコード型についてのディスカッションをしたそうです。レコード型自体については2/5のブログを参照。今回は、要件整理のみ。

C#でよく言われる課題として、シリアル化とUIデータ バインディングが面倒という話が前々からあります。といっても、これらに特殊対応するような言語機能(JSONリテラルとか、INotifyPropertyChangedの自動実装とか)の追加は得策ではない(きっと陳腐化する)。とはいえ、もっと汎用的な機能として何かできないか考えないと行けない。

シリアル化とかデータ バインディングとかを考えると、「同じ形状の(同じ型、同じ名前のメンバーを並べた)別実装」みたいなものが必要になったりします。

• シリアル化ライブラリは、オブジェクトが mutable であることを期待するものが多い
• データ バインディングでは、値の変更通知が必要
• シリアル化・データ バインディングでは、メタ データを使った処理をしたい
• 一方、実行効率を考えると、ビジネス ロジックでは強い型付けで処理をしたい

このためにとれるアプローチとしては、

• 1つの型に手作業で全要件満たすようなコードを書く
• シリアル化用、ロジック用、データ バインディング用など、複数のオブジェクトを作る
• dictionaryなどを使った、リフレクション不要なやり方でオブジェクトを作る
• F# のType Provider みたいに、型情報を偽装する
• コンパイル時コード生成など、メタプログラミングで複数の型やその相互変換コードを生成する

引き続きこういうシチュエーションに関する考察は続けていく。また、次のステップとして、シリアル化やプレゼンテーション層技術を担当している他のチームともコンタクトをとっていく。

Nullability and reference types

割かしもう繰り返しになっていますが、今から.NETに非null許容参照型を入れたいとなった場合の課題の検討。

• 後方互換性を保たないといけないので、現状の書き方(例えば、stringだけ)で nullable/non-nullable にすることはできない。string? と string! みたいな新しい書き方が必要。
• 非null許容を T! で表すものとして、default(T!) はどうあるべきか。.NET の型は、配列初期化時など、必ず規定値 default(T!) として初期化としてされる。
• T! なフィールドに対して、new した時点で確実に初期化されている保証をどうやって実現するか
• T?, T! を言語的に導入できたとして、既存のライブラリがこれに対応しだすと、破壊的変更になる
  • null チェックなしで T を T! には代入できない
  • メソッド引数の T を T! に変更すると、呼び出し部分がエラーになる
  • 戻り値の T を T! に変更すると、var (型推論)でメソッド戻り値を受けている場合、その先でエラーになる可能性がある

課題は難しくて、非null参照型を強く保証することは無理そう。でも、意味のある範囲で今よりもnull参照例外を減らせるようなアプローチができないとは言わない。引き続き検討を続けたい。