Meetingで拡張メンバーの検討をしてたみたい。everything」(なんでも拡張)って言ってたやつ。10現状、以下のような感じ。classってキーワードで、通常のクラスを継承したような構文で作る定義したメンバーは拡張メソッド同様、静的メソッド化されるプロパティは、「インデックス付きプロパティ」(ILレベルとかVBにはある。#11475C#では書けないものまず、「ILを使えば書けるけど、C#では書けない」みたいなのの例。アセンブラーを実装するのはコストに見合わないというか、混ぜるのよくない。コンパイラーが内在して持ってる実装)。いくつかのC++コンパイラーは、プログラマーがSSE命令とかAVX命令みたいな特殊な命令を使えるように、コンパイラー組み込みの特殊なメソッドを提供してたりします。C#でもそういう特殊なメソッドを用意して、上記のような通常のC#では書けない場面に対処すればいいんじゃないかという提案を出してきています。文法的にはexternメソッドを使うだけ。メソッドを呼ぶ代わりに、コンパイラーが直接その場所にIL命令を出力するというもの。これなら今から新文法について考える必要もないし、簡単に目的が達成できそう。bool型やenum型のswitchの完備性bool型にはtrueとfalseしかないはずなんだから、以下のdefault句は不要にできないかという話。code?}これ、昔から要望としては頻出なんですが、できない理由もあります。ILは結構低級機能を提供しているので、bool型の変数を無理やり書き換えて、trueでもfalseでもない値を作れて、上記default句に来ちゃう場合があったり。いうか、C#でも、以下のような書き方でそういう値を作れます。unsafeで値を書き換えStructLayoutで値を書き換えそれに、後方互換性を考えると、既存のswitchには警告も出せないです。いう背景の中、今後導入予定のmatch式(switchの式バージョン)ではこういう普通はあり得ないdefault句に対する警告がほしいですか?という質問。(廃止したい、もう使ってほしくない)なメンバーにはObsolete属性を付けて対処しています。この属性ベースのやり方じゃなくて、C#の言語機能としてobsoleteキーワードが必要かもという話が。#11583シナリオ的には以下のようなもの。g()を使いたい(呼び分けどころか今はそもそも定義すら不可能)これに対して、v1側にobsolete修飾子を付けることで、v2側の新メソッドの追加・オーバーロード解決できるようにしたいとのこと。TryRoslynRoslynリポジトリの各ブランチの最新版でのコンパイルを、オンラインで試して見れるサイト作ってる人がいた。http://tryroslyn.azurewebsites.net/C#チームの公式提供じゃないし、まだまだ作業途中みたいですけども。(TryRoslyn作ってる人)が、そのLucianの個人リポジトリのブランチをTryRoslynに追加してくれたLucian、早速利用みたいな感じになってた。ついて運営者について。