++C++; // 未確認飛行 C ブログ

http://ufcpp.net/

ピックアップRoslyn 3/22

leave a comment »

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

今週は、今月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参照例外を減らせるようなアプローチができないとは言わない。引き続き検討を続けたい。

Written by ufcpp

2015年3月22日 @ 19:36

カテゴリー: 未分類

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。