今年の build、思ってたよりも .NET がらみが盛沢山…
Windows TerminalとかVisual Studio Onlineとかの方がさらにインパクト強そう？ ですけど、 .NET がらみもだいぶ。 まあ、3.0 が今年こそ見えてきましたからね。
-
Introducing .NET 5
- .NET Core 4 は Framework 4.X と紛らわしいから欠番にして、次は「5」
-
徐々に .NET Core に一本化して、名前も「.NET」に
- .NET Framework は 4.8 を最後のバージョンにすると明言
- Mono の機能は徐々に取り込むとのこと
-
これからは年に1回、毎年11月にメジャー リリースする
- 2019/9 に .NET Core 3.0
- 2019/11 に .NET Core 3.1
-
2020/11 に .NET 5、以降毎年6, 7, 8, ...
- 5 以降、Long Term Support は偶数番だけ
-
Announcing .NET Core 3.0 Preview 5
- Preview 4 との差分
- 差分のみだけど今回結構大きそう
- 令和対応とか混ざっててちょっと受ける
-
Visual Studio 2019 version 16.1 Preview 3
-
IntelliCode が GAだって
- 何を持って GA なんだろう… 「16.1 Preview 3 からはオプション指定なしでデフォルトでオン」の意味？
-
IntelliSense、 using してない名前空間の型も補完候補に出てくるように
- IntelliCode のおかげで候補が賢くなってるおかげか、候補が多過ぎてつらい問題はそこまでなさそう？
-
IntelliCode が GAだって
-
https://online.visualstudio.com/ 発表
- 今のところ上記 URL は発表ブログに転送
-
将来的には「ブラウザー版 Visual Studio Code」になる予定
- 今もう、実は try.dot.netとかが Blazor ベースで動いてたりするので、布石はあった
- Blazor 自体も「プレビュー」に(早期開発版フェーズは通過)
-
名前の再利用やめろ… Surface といい docs といい…
- ALM とか Team Services とか DevOps とか呼ばれてるやつの名称が「Visual Studio Online」だった時期がある
「11月って言うと、確かにホリデーシーズン直前で、アメリカ製品はその時期に出るものが一番安定してるけど」とか、「build で毎年11月とかそんなタイトな公約掲げちゃって大丈夫？」とかは思ったり思わなかったり。
まあ、この辺りは他の人がまとめてるので概要のみにして。
C# 8.0 in Visual Studio 16.1 Preview 3
最近はすっかり C# 中心の話ばっかりなわけですが。
今回の Preview 3 では、新機能は特に増えていないんですが、ちょこっと修正があります。 前々から「.NET Core 3.0 依存だから安定してない」って言っていた機能に、予定通り変更あり。
-
非同期イテレーターに
CancellationTokenを渡せる手段ができました- 例を gist にアップロード: EnumeratorCancellation.cs
EnumeratorCancellation属性を付ければいいらしい- 後述しますがちょこっと挙動変更される予定がすでにあり
-
Index/Range がらみのコード生成結果変更
- 2月にブログにした通り
-
変更内容に関する提案ドキュメント: Index and Range Changes
- 旧仕様: コレクション側が
Index/Range構造体を受け付けるオーバーロードを用意 - 新仕様: C# コンパイラーが
Index.GetOffsetを呼んでintに変換
- 旧仕様: コレクション側が
ピックアップ Roslyn 5/7
で、3日ほど前に1個、C# の Design Notes のアップロードがありました。
base(T)
一昨日、インターフェイスのデフォルト実装の話を書いたところなんですよ。
その中には base(T) アクセスの話もあります。
これを書いてから上記の Desing Notes に気づいたわけですが。
「base(T)、C# 8.0 からは外して、ランタイムのサポート込みで C# 9.0 に回したい」ですって。
書き直さなきゃ…
非同期イテレーターのキャンセル
この話は前述のgist に上げた例にも書いてあるんですけども。 以下のような非同期イテレーターを書いた場合、
async IAsyncEnumerable<int> X([EnumeratorCancellation]CancellationToken ct = default)
CancellationToken は、X(ct) というのと、X().WithCancellation(ct) というの、どちらで書いても最終的に X の引数に渡ってきます。
で、両方指定できちゃう。X(ct1).WithCancellation(ct2) が合法。
この時どういう挙動をすべきかという話です。
- 現状:
ct2が優先で上書きされる - 提案:
ct1とct2をリンクさせたものを新たに作る
CancellationToken だけじゃなくて CancellationTokenSource にも依存するとか、
コード生成が複雑になるとか、
CancellationTokenSource を持つためのフィールドも増えてメモリ的にも優しくないとか、
デメリットもあるんですが、さすがに上書き挙動はまずそう。
トリアージュ
buildで、.NET Core 3.0 のリリースが今年の7月にRC、9月にGA、11月に3.1と明言されたわけですが。 C# 8.0 はこれに追従する予定です。 要するに C# 8.0 にもスケジュールが切られました。 逆算すると、「C# 8.0 に何を入れて何を入れないか」の決断のタイムリミットが今。
ということで、なんかむっちゃ仕分けされてました。 仕分け結果は csharplang 内の GitHub Projectにも、 Roslyn 内の Language Feature Statusにも反映済み。 多少この2つに不整合があるんで、たぶんまだもうちょっと整理中のはずです。
前々から「8.0 タグが付いてるけど怪しくない？」みたいに思ってたものはやっぱり外れました。 急ぎ、自分用のタスク リストにも反映。
ローカル関数に対する属性
非同期イテレーター、属性ベースで CancellationToken を渡すようになったわけですが。
そこで「ローカル関数にも属性付けれないとまずいじゃない」という話になったみたいです。
ということで、それも実装予定に。