Visual Studio 2015 関連作業が終わって、その次っぽい動きがちらほら。
Make Features Layer Portable #3998
Feature API = リファクタリングとか、コード解析からのコード修正とか、そのレイヤーのAPIのこと。
これを、OmniSharp、Visual Studio Codeで使うためにポータブル化作業をしようという Issue ページが立ちました。
ほぼ、
- 今、internal で作ってあるものを public にするだけ(とはいえ、それが大変)
- 何年も保守していくものになるものをうかつに全部はpublicにできない
- public にするには耐ええない作りの箇所があるからその修正が必要
という感じの様子。
Interactive Design Meeting Notes - 7/8/15 #3927
スクリプト向けC#方言の仕様レビューしてたみたい。その議事録なので、割かしC#スクリプトがどうなりそうかのまとめになってる。
#rでDLLの参照、#loadで他のスクリプトの取り込み。スクリプトの一番上にだけ書ける#loadな、「その場所にそのスクリプトをコピー＆ペーストしてきたかのような挙動」。shとかでいうところの.の方(&の方じゃなく)-
トップ レベルに変数とか関数を書けるわけだけど、
- static スクリプト変数には、
awaitを含む初期化子を書けない - 普通のスクリプト変数(あるいは、トップ レベル変数って呼ぶ)にはそういう制限ない
- interactive window とかで実行してる際には、
awaitした時点でUIをブロックする(バックグラウンド実行にはしない)
- static スクリプト変数には、
-
「C#スクリプト」は、普通のC#ソースコードからコピー&ペーストして来たらそれがそのまま動くようにする
- Copy/Paste Prinsible of Scripting (CPPoS: スクリプトのコピー&ペースト原則)って呼んでる
その他、最近、C# 7.0向けにローカル関数の仕様が出始めているものの、それとトップ レベル関数は別物で、C#スクリプトは両方サポートすることになると思う。
スクリプトは常に async な文脈で実行される。どこにでも await 書ける。1つもawaitを書いてないときにはステートマシン(非同期メソッド内部実装の、仰々しいコード生成)は作らない最適化は掛ける。
static スクリプト変数は、スクリプトが何回実行されても1回だけ初期化が走るようにというのもあるけど、その主たる目的は CPPoS のため(どこからコピペしてもスクリプト実行できるようにするためには、staticフィールドもコピペで動く必要がある)。
トップ レベルのメソッド、プロパティ、型、スクリプト変数のスコープは既定で public (通常のC#は、アクセシビリティ修飾子を省略すると private/internal だけど、スクリプトの場合は public)。スクリプトの外(#loadで呼び出す側)からは隠したい場合、「ファイルprivate」って概念を実装したい。現状でも、変数やメソッドを1段階 {} で覆ってしまえば外からアクセスできなくなる実装にはなってる。
#load するとその中のトップレベル要素は全部取り込まれる(トップ レベルの識別子には、特に何の修飾もなくアクセスできる)。#load intoを使うと、そのスクリプトに名前を付けれるけども、これはエイリアス的な動作。2回、別名で#load intoすると、その指す先は一緒。別インスタンスが作られたりはしない。
Ability to classify fields, locals and parameters differently #3976
おまけ。
今、Visual Studioのコードの色分けでは、識別子にはあまり色が付かない(たぶん、色が付くのは型名だけ？)わけですが、フィールドとか変数の色分けには興味ある？という調査的な issue が立ったみたい。
これまで、大きく取り扱ってこなかったけども、おそらく実装しても実行性能的に目立った影響はないだろうし。とのこと。
例えば、以下のようなの。
readonlyかどうか(get-only自動プロパティも)での色分け欲しい？eventも？- (クラス/構造体直下の)定数と、ローカル定数の区別とか要る？
- 未初期化変数の警告にも色分けとか使うのどう？
- C#スクリプトができたら、トップ レベル変数とかトップ レベル メンバーもできるけども、それも別扱いしたい？
- 組み込み演算子と、オーバーロード(ユーザー定義演算子)の区別とか便利そうじゃない？