(グロサミ)に行ってきてたわけですが。PM)を捕まえて「こんな問題見つけちゃって、昨日ちょうどissue立てたんだけどどうしよう?」みたいな話を振ってきたり。(先に具体例を書いておけば、どれだけ英語がつたなくても結構意図は伝えられる。)(ちなみに、元々は帰国後にゆっくりページ書くつもりだったんだけど、なんかグロサミ参加の妙なテンションに任せて、kekyoさん、藤原さん、室星さんとかと部屋の飲みの最中にこの方々も巻き込んでissue書きました。2パートに分けた方が良さそう。以下、改めて要約した内容(英語に訳して再投稿予定)。2つの提案nullの取り扱いと関連して、以下の2つを提案する。Contracts、特に参照型の非null保証を入れようと思うと、確実な初期化処理が必須になる。構造体の場合、defautl(T)など、既定値によって初期化処理を通らない「0/nullクリア」が発生する。既定値の「0/nullクリア」のせいで、Contractsや非null保証のフロー解析が狂う可能性がある。非null保証パフォーマンスのために、参照型を1つだけ持つようなラッパーを構造体で作ることがある。ImmutableArray、)今、パフォーマンスはC#の1つの大きなテーマであり、こういうケースは今後より一層増えるだろう。例として以下のような構造体を考える。}}レコード型や非null保証が入れば、単に以下のように書けるだろう。class単にTと書けば非nullとなり、nullを受け付けたければT?と書くようになる。(本来は非nullであるはず)がnullになってしまうことである。以下のような、値に制約の入った構造体を考える。この例は、正の数しか受け取れない数値型である。Contractsが入ると、この構造体はおそらく以下のように書ける。0;これでValueプロパティが常に0より大きいことが保証できているように見えるが、default(PositiveInt)のせいで、Valueに0が入ることがあり得る。この値は無効なはずである。現在提案されている参照型の非null保証は、フロー解析に基づいている。値型が既定値でないことも、同じフロー解析で行えるはずである。typesを提案したい。何らかのアノテーション、例えば[NonDefault]属性を付けた構造体は既定値を取ってはいけないとするのはどうだろうか。typesに倣って、以下のように警告を出す。typesに対するT?はNullable<T>を必要としない。default(T)で値を持っていないことが確認できるからである。typesに対してはnullをdefault(T)と同一視してもいいかもしれない。typesのメンバーを持てないようにすべきだろう。typesのみである。現在、参照型とNullable<T>構造体はC#コンパイラーによって特別な地位を与えられている。null条件演算子(?.)とnull合体演算子(??)の利用である。これらの型以外にも、無効なインスタンスを?.や??で伝搬/差し替えしたいことがある。この挙動はmonad的であり、LINQやTask-likeを使って無理やり解決しようとしている例もある。悪用・乱用の類であり、決して読みやすいコードにはならないだろう。無効なインスタンスの伝搬/差し替えは、やはり、?.や??を使うべきである。nullが真になる)。参照型に対する?.や??では、オーバーロードした==は呼ばれない(brtrue命令によるnullチェックに展開される)。そのため、以下のように、?.を使ったコードが正しく動かない。6.0に対応しようとしている。この?.の挙動がはまるポイントになるだろう。Expected無効な値としてnullを使うことを嫌う人が一定数いるが、その理由の1つが、「なぜ無効な値を返す必要があったのか」という原因に関する情報が消えることである。そのため、Nullable<T>の代わりに、Tと例外のunion型にあたるExpected<T>のような型を作って使おうとする人がいる。C++でそういう動きがみられる。}}もしC#でもそういう型を作るのであれば、?.を使った例外の伝搬や、??を使った例外からの復帰があってもいいのではないだろうか。所定のパターンを実装した型であれば?.および??を使えるようにすることを提案する。Task-likeに倣ってこれをnullable-likeと呼ぼう。以下のようなパターンはどうだろうか。Propagate();}これで、先ほどのExpected<T>の例であれば、以下のように展開する。"";ちなみに、このパターンに沿ったExpected<T>の実装は以下のようになる。ついて運営者について。