ピックアップRoslyn 4/25

C# 7 Work List of Features #2136

https://github.com/dotnet/roslyn/issues/2136

C# 7に向けた作業項目リストを公開。

関心度合いや実現性の確度に応じてある程度は分類。C# 7（あるいはもっと先のバージョン）に必ずしも入るとは限らないもの(上ほど期待度高そう。中にはすでに「やらない」判定を受けたものもあり)。提案 issueページへのリンク付き。

変更やより良いアイディアがあれば随時更新したいそうなので、定期的に見てみるとよさそう。

ほとんどの項目は、詳細な説明がある提案ページへのリンクがあるし、リンクがないものも大体は意味が分かるんですが。１個だけ、「Supersedes」ってなんだろう。単語的には「下克上」というか、新しいものが古いものに取って代わるって意味なので、後方互換性をいくらか捨てれるような機能とかですかねぇ。コンパイラーに組み込むんじゃなくてコード解析プラグインにしたり(例えば https://github.com/dotnet/roslyn/issues/2119)、Warning Waves (https://github.com/dotnet/roslyn/issues/1580)導入したりとか。

Proposal: Allow unsafe code in iterators #2143

https://github.com/dotnet/roslyn/issues/2143

イテレーターや非同期メソッド内でも部分的にunsafeコードを認めようという提案。

イテレーターや非同期メソッドみたいに、中断・再開があるような状況でポインターを使うのは危険なので今は認めていないわけですが。ただ、yield や await さえ囲まなかったら問題は起きないので、その場合に限り、イテレーター、非同期メソッド内でも unsafe コンテキスト認めてもよいという話。

Cp1252 #2120

https://github.com/dotnet/roslyn/pull/2120

最近、Roslyn は .NET Core 対応がらみの作業がちらほらあって、その中で、Encoding がらみのコードが結構削られています。

ただ、欧米の開発者から「コメント中に … (HORIZONTAL ELLIPSIS )を書けなくなった」とバグ報告が入ったり。原因は、Windows-1252 の「…」(0x85)が、Latin-1 扱いでデコードすると改行にマッピングされるせい。2010年台も半ばになって今更この手の文字コード問題を見るとは…

日本語の場合、Visual Studio 2005 以降、ソースコードを基本的に UTF8 で保存してくれるようになったので、今となってはそんなに問題が起きることは少ないわけですが(外部ツールでソースコードを作ったりするといまだ Shift JIS とかになって問題出ることがあったり)。

で、今回、この問題の回避方法が… CodePage1252Encoding クラスを自前実装したって…

Unicode 使えよ…

Make the command-line compilers able to generate reference assemblies #2184

https://github.com/dotnet/roslyn/issues/2184

Roslyn コンパイラーに、参照アセンブリを出力するオプションを追加したそうです。

参照アセンブリは、メソッド シグネチャだけ入ってて、中身のILコードがない(メタデータだけ入った)アセンブリのこと。いわゆる facade アセンブリ。C++ でヘッダーファイルだけあって、cpp ファイルがないような状態。ビルド時にどのクラス・どのメソッドが使えるかを判定したり、IDE 上でのコード補完に使います。

今までは、普通のアセンブリを出力したあと、わざわざILコードを削るような後処理をかけてたはず。

C# Essentials Analyzer

こんなコメントが。

https://github.com/dotnet/roslyn/issues/2235#issuecomment-96043488

ほんとだ、ちゃんと公開されてた。

Dustin はC#/VB チームの人(確か元々VB系だったような)。C# Essentials は C# 6.0 でよりよい書き方・シンプルな書き方に書き替えれるコードを探してくれるコード解析プラグイン。もちろん、Roslyn 製。

この C# Essentials の GitHub リポジトリ自体は前から公開されていたんですが、つい最近、ビルド済みの Visual Studio 拡張を VS Gallary に置いてもらえたそうです。

GitHub から一式 Clone してきて、ビルドして、できた vsix パッケージをインストールして… とかいう手順やりたくないですしね。ありがたい。

ピックアップ Rolsyn 2015/4/23: Nullability

null許容性の検証に関するC# デザイン ミーティングの議事録3週(issue的には2ページ)分。

C# Design Notes for Apr 1 and 8, 2015 #2119

https://github.com/dotnet/roslyn/issues/2119

低コストでnull許容性関連の実験をする手段として、Roslynアナライザーを書いてみたという話。このアナライザーの発展のさせ方や、それがC#の言語設計にどう影響していくかなどを検討。

フロー ベース

null検証は、フロー解析ベース、つまり、変数などを使う場所の手前で代入があったかとか、if での非nullチェックがあったかとかを調べる方法でやろうとしている。

ローカル変数やメソッドの引数についてはそんなに障壁はなくて、問題になりそうなのはせいぜいラムダ式でキャプチャする場合(匿名クラスのフィールドに昇格して、メソッドの外での書き換えの可能性がある)くらい。

一方で、フィールド、プロパティ、配列の中身などのnull許容性を追おうとすると難しい。ローカル変数とメソッド引数を追えるだけでも大きな価値になると思うけども、少なくとも、「dotted chain」(a.b.c() みたいなの)だけでも追えると便利だろう。

属性 vs 構文

今回作ったアナライザーは属性を使ってnull許容かどうかを指定しているけども、C#の構文レベルで対応するのと比べて、以下の様な問題がある。

• 書くのが面倒
• ローカル変数に属性は付けれない
• 型引数や配列の要素に属性は付けれない

今は実験的にやっているのでしょうがないけども、この先C#の構文レベルで対応することになれば、この問題を解消するやり方はわかっている。今も、dynamicで似たようなことをやっている。

アナライザー vs 組み込みルール

null検証をアナライザーで(コンパイラー自身じゃなくて、プラグイン的に)やるのには利点も欠点もある。

利点は

• 言語機能にしてしまうと、明確な仕様と合理的な説明が必要。アナライザーであればもっと経験則的な手段が取れる
• 言語機能には後方互換性が必要。アナライザーなら今必要なコードに対してだけ診断をかけれる
• アナライザーなら徐々に発展させていける
• アナライザーなら個々人の要件に応じてルールのオンオフができる。言語機能だと万人の要求に合わないといけない

一方、欠点として

• 言語機能のほうが高効率に実装しやすい
• 言語機能のほうが何が良くて何が悪いか、ルールを標準化しやすい
• アナライザーだと拾えない文脈でも、言語に組み込むなら拾える
• 構文(syntax)的に T? とか T! とかを足すのに、意味論(semantics)的な診断だけアナライザーでやるのは気持ち悪いといえば気持ち悪い
• 「warning wave」(#1580)を導入するなら、後方互換性を気にする必要性は下がる

単純なnull検証だけ言語機能に組み込んで、追加でアナライザーを使った経験則的な検証を行うというのももちろんあり得る。この場合、言語機能の方でwarningになっている検証結果を、アナライザーの方ではwarningを消したい場合も出てくるけども、今、そういう機能は足りていない。

ちょっと使ってみた感じ

(原文に幾つかコード例あり)

既存コードは大部分、属性をつけるだけでそのまま動きそうだし、便利そう。

結論として

よい実験だった。null許容性の検証をフロー ベースやることに強い関心が持てる。

C# Design Notes for Apr 15, 2015 #2133

https://github.com/dotnet/roslyn/issues/2133

こちらは、null検証とジェネリックの検討。この2つを合わせて使う場合、いろいろ課題あり。

制約なしのジェネリック

どんな型でも ToString メソッドは使えるわけだけども、これを default(T) に対して呼ぶと、null許容型ならエラーに、非null型なら問題なく使えたりする。ただ、T! (非null型)に対してdefault(T)を認めないようにできるかというと難しい。

例えば、List とか Dictionary は内部的に配列でデータを持っていて、一旦は中身は default(T) な状態になっている。List<string!> などでは、入力も出力も非nullにできるけども、内部ではnullがある。こういう挙動は認めたい。

注釈の上書き

ジェネリック型引数 T に対して、T が参照型だとわかっているなら、null許容性の上書きを許す実装もできる。T に与える型が string でも string! でも string? でも、T? と書いたら元のnull許容性を上書きして使いたい。

これはいくつかのシナリオで有益だけども、多くのジェネリック利用場面では、型引数が参照型かどうかわからない。

FirstOrDefault

FirstOrDefault みたいに default(T) を返すものの場合、「参照型の時だけ nullable」ということがあり得る。これを [NullableIfReference] 属性を導入することでうまく扱うことはできる。「なんとかなる」という意味ではこの方法でいいんだけども、複雑性を増やしてまでこれをやりたいかというと疑問。

TryGet

int.TryParse みたいなメソッドでは、戻り値が true の時だけout引数で受け取る値の非null保証がほしい場合もある。これも、[NullableIfFalse] みたいな属性の導入でなんとかできるけど、価値が得られるかは疑問。

ピックアップRoslyn 4/22: Expression Trees

先週末はあんまり拾うところがなくて定期ポストをサボっていたら、月曜日にまとめて大量の C# Design Meeting Notes が公開されていたり。ということで、今週は週末にまとめてじゃなくてちょっとずつ。

とりあえず今日は1件だけ。

C# Design Meeting Notes for Apr 14, 2015 #2134

https://github.com/dotnet/roslyn/issues/2134

Bart De Smet(Bing チームの方。ググったら、C# Unleashed の著者で、今は Cortana がらみの仕事してるっぽい雰囲気)が来て、式ツリーの利用方法についてディスカッションをしたそうです。

要するに、

• 式ツリーにはいろいろ足りない
  • C# 3.0で導入されて、C# 4.0で少し追加はあったけども、それ以降止まっている
  • 現状の C# の言語機能に対して、そもそも対応するクラスがないものがある
  • ラムダ式からの Expression 型生成はさらに制限がきつい
• Bing 内の分散コンピューティングで、ノードをまたいだ処理をするために式ツリーを使っている
  • (独自方式で)シリアライズして、他のノードに送る
  • 受け取った側でデシリアライズして、Compile してから実行する
  • 足りない機能を埋めてほしい
• Bing チームは非常に重要なユーザーだけども、典型的なユーザーとは言い難い(結構特殊な用途)
  • Bing チームの要望は受け入れるつもりだけども、問題は他の機能との優先度付け
  • 広く意見を求めたい

という話。

以下、今の式ツリーに何が足りてないか / 何が埋まれば Bing チームが喜ぶかというものの説明。

Expression Tree API の問題

まず、式ツリー API (System.Linq.Expression 名前空間以下の各種クラス/メソッド)自体の問題。

Dynamic

.NET 4 での式ツリーの拡充は C# 4.0 の dynamic を実装するのに大いに役立ったものの、皮肉なことに、その C# 4.0 の dynamic 構文自体は式ツリー化できない。

Bing チームとしては、ノード間を祖結合にするために、緩い型付けで式ツリーをシリアライズしたいことがあって、ぜひとも dynamic に対応してほしそう。あるいは、何らかの「lightweight dynamic」(現状の dynamic ほど大掛かりな仕組みじゃなくて、もっと軽量な緩い型付けの仕組みが)があれば、それを式ツリーでも対応してほしい。

Await

await 演算子は、式ツリーを得るだけならおそらく簡単なものの、それを Compile しようと思うと結構な複雑さ(現状の C#/VB コンパイラーがやってるのと同程度には)になるはず。

言うまでもなく、Bing みたいな分散シナリオでは、await を大量に使う。

Null conditional operators and string interpolation

この辺りは式ツリー ノードに加えるべきだと思う。たぶん、Compile 前にちょっとしたノード置き換え(reduce)を行うだけでよくて、Compile メソッドや、(LINQ to Entities とかの)式ツリーを使う側は、直接この新しいノードに対応しないでも大丈夫にできそう。(こういう置き換え可能なノードを reducible node っていう)

Higher level statements

式ツリーは制御構文も書けるものの、低レベルなものしかない。要するに、ｌoop はあっても(C# でいうと while 程度)、for や foreach ノードはない。この辺りも、reducible (loop への置き換えで対応できる)なはず。

言語機能的な問題

.NET 4 で、式ツリーのノードは種類を増やしたけども、ラムダ式から式ツリー化できる構文は増やさなかった。

当時、ラムダ式での対応を増やさなかった理由の1つは、既存の LINQ プロバイダー(式ツリーを解釈して動的にクエリを発行する、LINQ to Entities とかみたいなライブラリ)が対応しかねるという問題があったから。

これに対して、Roslyn がある今なら、アナライザーを書くことで、「このライブラリではこの式ツリー ノードだけを受け付けます」みたいな診断ができるようになったので、この問題をクリアできるはず。C#/VB の文法上は任意のラムダ式を式ツリー化できるようにして、各ライブラリがその手のアナライザーを付属させて配布すればいい。

制限を緩めるだけなので、新しい文法は必要としないし、割かし素直にできるはず。

結論

式ツリーの拡充、ラムダ式からの式ツリー構築の制限緩和は、「やるべきではない」といえる理由がもうない。

問題は単純に手間で、結構大きな請負仕事になりそう。他の新文法がらみの作業との兼ね合いを考えた上でも、この作業を正当化できるかどうかは確証を得てない。Bing チームは重要なユーザーの1人だけども、典型的なユーザーとは言えない。

言語デザイン チームとしては、こういう要望をかなえることは確約したい。あくまで優先度付けの問題として、広く意見を求めたい。

LLILC (ライラック: LLVM ベースの IL コンパイラー)

なんか割かしひっそりと公開されていましたが、.NET Foundation 配下で、LLVM ベースの IL コンパイラー(.NET の IL コードをネイティブ コード化)が出てきました。

プロジェクト名 LLILC。LLVM な IL Compiler で LL IL C でしょうし割かし安直なんですが、「lilac」(普通に花のライラック)と読ませるそうで読み方的には結構おしゃれ。縦棒並びすぎロシアの筆記体かよとか、L 並びすぎ呪文かよとか思ったりもしますが。

LLVM

大きなイベントで発表があったわけではなく、MSDN Blogs で取り上げられるでもなく(.NET Foundation のブログ記事はあり)、LLVM Project Blog でブログ記事が上がるってあたりが何か新しい。

マイクロソフトが LLVM を使うこと自体は少し前から前兆みたいなものはあって、例えば、去年、インターンで来た学生が、.NET Native のコード生成部分での LLVM 利用について調査してたとかがあったりします。

LLILC (JIT)と RyuJIT

LLILC は、予定としては JIT と AOT の両方を提供するそうですが、最初のターゲットは JIT だそうです。つまるところ、やってること自体は RyuJIT (マイクロソフトの最新の JIT 実装)と同じになります。

LLILC と RyuJIT は求めるものが異なっていて相補的な立ち位置にあります。

RyuJIT は高いパフォーマンスを求めていて、.NET 特有の(特に、C# 特有の)最適化をガチガチに掛けます。

一方で、LLILC は、LLVM の中間形式を経るので(Clang などの実績があってかなりよい最適化がかかるとはいえ)、RyuJIT ほどのパフォーマンスは出ないはずです。パフォーマンスよりも、より多くの環境で .NET プログラムが動くという点を求めています。

LLILC の現状の進捗としては Windows のみ。当面の目標としては Linux と Mac OS を狙っているそうです。また、LLILC が見本となることで、他の開発者による LLVM 実装が容易になればという期待もあるそうです。

LLILC (AOT)と .NET Native

(予定には含まれている) AOT 対応では、今度は .NET Native に近い土俵になります。ただ、.NET Native は単に IL からのネイティブ コード生成すること以外にも、より多くの仕事を担っています:

1. (JIT の場合動的にやっている)マーシャリング向けのコードをコンパイル時に生成する
2. (これも通常は動的にやる)シリアライズ用のコードを生成する
3. 複数のアセンブリ(DLL, EXE)を1つにまとめる(アセンブリをまたいだ最適化が掛かるようにする)
4. AOT 向けに IL コードを書き替え・最適化する
5. 使われていないコード・型情報を削除する
6. ネイティブ コード化する

(詳しくは .NET Native Performance and Internals を参照)

このうち、LLILC (AOT)が担える仕事は 6. の部分になります。今の .NET Native はこの部分にマイクロソフト製 C++ コンパイラー(cl.exe)と共通のインフラを使っているそうです。当然、この部分は LLILC での置き替えも考えられます。おそらくは、LLILC (JIT)と RyuJIT と同じような、高いパフォーマンスと、多くの環境で動くことのトレードオフになるでしょう。

マイクロソフト以外による LLVM 実装

Mono のランタイムは今、IL のコンパイル(JIT も AOT も)に LLVM を使って(使えるオプションを提供して)います。他にも、SharpLang とか LLVMSharp とか、いくつかの実装があるみたいです。それにマイクロソフト自身も、内部的には(たぶん、研究目的)LLVM 実装を持っていたそうです。

これらをそのまま使わなかった理由は、CoreCLR のインターフェイスに合わせるためとのこと。なので、LLILC のインターフェイスは RyuJIT のものとそろっているそうです。

LLILC と Roslyn (コンパイラーのフロントエンドとバックエンド)

RyuJIT が出た時にも詳しくない人は少し混乱したみたいなんですが、コンパイラーにはフロントエンドとバックエンドがあります。

フロントエンドの仕事は、高級言語から何らかの中間形式(抽象構文木(AST: abstract syntax tree)とか、仮想マシン語コード(.NET でいう IL、LLVM でいう BitCode)とか)に変換するところまで。バックエンドの仕事は、その中間形式から何らかの成果物(特定 CPU のマシン語コード化や、他の高級言語への変換)を得ることです。

フロントエンドとバックエンドが分かれていることで、高級言語の専門家と、CPU コード生成の専門家が分業できるというメリットがあります。分業によって、いろんな高級言語を、いろんな環境に対応させやすくなります。また、多くの場合、それぞれの専門家の努力によって、高級言語から一気に CPU コードを生成するよりも、中間形式を挟む方がよりよいコード生成ができたりします。

Roslyn (C#/VB コンパイラー)の仕事はフロントエンドです。C#/VB のソースコードを、IL (.NET の中間言語)に変換するところまでが仕事です。この範疇でやれることは、例えば以下のようなものです。

• 高級言語の構文ハイライト
• 警告やエラーが出ている箇所を(下線を引くなどして)表示
• 変数やメソッドなどの「定義へ移動」「参照の検索」
• ソースコードのリファクタリングや整形
• 静的ソースコード分析(人的ミスを起こしやすそうなコードの発見や、コーディング規約への準拠チェックなど)

一方、LLILC の仕事はバックエンドで、CPU コード生成に加えて、以下のようなものが含まれ得ます。

• プロファイリング、コード追跡、デバッグなど用の IL コード追加
• 自動ベクトル化(SIMD 命令や GPU の活用)や自動並列化
• テストケース削減(コード分析によってある程度のテストケースを自動的に作る。この手の機能は、Visual Studio 2015 にも載る予定: Smart Unit Tests)

LLILC がやっていること

LLILC は、要するに以下のような仕事をします。

• IL (.NET の中間形式)の読み込み
• IL から BitCode (LLVM の中間形式)への変換
• .NET 固有な機能の提供

.NET 固有な機能には例えば以下のようなものがあります。

• COFF (Common Object File Format: 実行形式ファイル中の情報)ローダー
• ガベージ コレクション(.NET は強い型情報を持っているので、この情報に基づいて効率よくガベージ コレクションを提供できる)
• 型情報に基づく最適化
• 例外処理機構

ピックアップRoslyn 4/12

C# Design Meeting Notes for Mar 24, 2015

https://github.com/dotnet/roslyn/issues/1898

今回は、これまで C# 7.0 に向けて提案されてきた内容について、issue ページでの議論の結果、今後どう取り組んでいくかを「色分け」(信号の青(green)、黄、赤の3色に)しています。

• 青: 興味あり、引き続き検討
• 黄: 何か取り組むべきものはあるけども、既存提案の方式ではやらない
• 赤: たぶんやらない

何がどう色分けされたかというと:

1. ref returns and locals <青> (#118)
2. readonly locals and parameters <青> (#115)
3. Method contracts <青> (#119)
4. Does not return <青> (#1226)
5. Slicing <青> (#120)
6. Lambda capture lists <黄 – ラムダ式に属性を付けれるようにするだけでたぶん解決> (#117)
7. Immutable types <黄 – 今の形ではやらない。けど何かしらの保証方法は考えたい> (#159)
8. Destructible types <黄 – 決定論的な破棄処理自体には興味あり> (#161)
9. Move <赤> (#160)
10. Exception contracts <赤>
11. Static delegates <赤>
12. Safe fixed-size buffers in structs <赤> (#126)

6番くらいまではもうちょっと詳細な現状説明あり。

ここでは、気になったところだけ:

2. に関して、「readonly var」の短縮形は、今のところ val が有力らしい… 僕は v だけ打って後は IntelliSense 補完で var を書いてるんで、個人的には val はやめてほしい… 英語的には val が一番自然に見えるらしいんですけども。

4. に関して、never 型(絶対に例外を投げて終わるか、永久ループで終わるメソッドの戻り値に指定する型)を導入する方向で進んでいます。この型が指定できるようになると、「throw ステートメント」を「throw 式」に変えれるというメリットもあります。つまり、() => throw new Exception() みたいなラムダ式も書けるようになります(今は、こういう式が書けない。throw が式じゃないので)。

C# Language Design Review, Mar 25, 2015

https://github.com/dotnet/roslyn/issues/1921

C#チームは最近、Design ミーティングの方法を少し変えたみたいです(開発速度を上げる目的)。C# チームの一部だけが集まって個別機能について話す会を週に1・2回、そして、全員が集まってレビューする会を月に1回程度行うつもりだそうです。で、そのレビュー会の第1回をやったそうで、これはその議事録。

今回は以下のような議題。

1. Overall direction
2. Nullability features
   • val / readonly
   • ref return / locals
   • Never type
   • Method contracts
   • Slices
3. Performance and reliability features
4. Tuples
5. Records
6. Pattern matching

前節の #1898 とも被るので「詳しくはそっちを見て」で済ませてる項目も結構ありますが。

全体的な方向性、「野心的に、難しい問題を解決していこうという合意は得られた」としています。

おまけ: corefx-progress

https://github.com/dotnet/corefx-progress

「ピックアップRoslyn」内で紹介するのもなんですが、今回は他の .NET プロジェクトの話をついでに紹介。

今、.NET Core の標準ライブラリは、オープンソース化作業のまっただ中にあるわけですが。そのオープンソース化作業の進捗状況を見えるようにするために、この corefx-progress リポジトリを作ったそうです。1リポジトリ使って、これから公開予定のAPI、公開が完了したAPI、その差分をアセンブリごとに取れるようにしています。

myget からのパッケージ取得

Roslyn など、オープンソースで開発されている .NET ライブラリについて、最新版の機能を試してみる方法について、そういえば説明したことないなぁとか思って、今、書いてみることに。要するに、myget サービスから、毎夜ビルド版の最新ライブラリをとってくる方法について。

最新版で何が嬉しいか

Visual Studio 2015 のリリースも近づいてきて、Roslyn プロジェクトも最近は、とにかくリリースに向けた品質担保が急務になっています。Visual Studio 2015 に含めないことになった機能については、作業が止まったりしています。

C# のスクリプト利用が最たる例で、Roslyn プロジェクトの最終ゴールの1つには含まれていますが、今はまだ NuGet Gallary 上にリリースされていません。しばらく表立った動きが全くなかったんですが、最近になってようやく動き始めました。

こういう、NuGet Gallary へのリリースがまだの最新の機能も、myget から取得できることがあります。

NuGet

ここ数年、.NET 開発では、ライブラリの参照に NuGet を使います。NuGet について改めて簡単に説明しておくと、

• NuGet パッケージ: ライブラリ配布のためのパッケージ仕様(所定のパスに必要なファイルを置いた上で ZIP 化したもの)
• NuGet リポジトリ: パッケージの置場。パッケージを検索したり、バージョン指定してパッケージをダウンロードしたりできるAPIを提供。仕様に沿ったAPIさえ公開すれば、誰でもリポジトリ サーバーを立てれる
• NuGet パッケージ マネージャー: Visual Studio 付属の、NuGet リポジトリ クライアント
• The NuGet Gallary: 公式 NuGet リポジトリ

というような、ライブラリ配布・参照のための一連の仕組みです。

myget

NuGet Gallary へのアップロードは、「リリース作業」に当たります。数週とか数か月に1度、動作保証が(たとえベータ版であってもある程度は)ある状態で行うものです。

これに対して、NuGet パッケージの CI (継続的インテグレーション)サービスを提供しているのが myget です(正確には、NMP や Bower パッケージなどにも対応した、パッケージの CI サービスです)。myget は NuGet リポジトリ機能も提供していて、CI でビルドしたパッケージなどもここからダウンロードして利用できます。

Roslyn とか ASP.NET とか、いくつかのマイクロソフト製ライブラリは、この myget 上で毎夜ビルドしていて、最新の状態のパッケージを取得できるようになっています。

myget 参照

Visual Studio 上で、プロジェクトに対して「Manage NuGet Packages…」(NuGet パッケージの管理)を選ぶと以下のような画面が出ます(Visual Studio 2015 での画面。2013 まではもうちょっとしょぼいダイアログが出ます)。

ここで、歯車マーク()を押して、設定画面を開きます(2013 の場合は「設定」ボタンがあるのでそれを押す)。

「Package Sources」ページを開いて、＋ボタンを押して、myget 公開されているリポジトリを「パッケージの取得元」に追加します。Roslyn の毎夜ビルドの場合、

https://www.myget.org/F/roslyn-nightly/

が、リポジトリの Source URL になります(myget の Roslyn のページ内に「NuGet feed URL」として載っています)。

これで、NuGet Gallary へのリリース前の、最新の NuGet パッケージがとれるようになります。例えば、C# スクリプトがらみのパッケージ「Microsoft.CodeAnalysis.Sctipting.Csharp」なども今すぐ参照できます。

dotNetConf 2015 Japan with JXUG

dotNetConf 2015 Japan で登壇してきました。

OneDrive にも: https://onedrive.live.com/view.aspx?cid=5C622397E11C979D&resid=5c622397e11c979d%21224309&app=PowerPoint

祝15周年

自己紹介に、しばらく入ると思います。祝15周年。

うちのサイト、ほんとに C# が表に出たのと同じ年からやってる(2000年に発表、CTP提供)ので、C#が15周年ならうちも15周年。正確に言うと、C# のプレスリリースが出たのが6月で、うちのサイトがパブリックになったのは年末なので、半年程度のラグはあるんですが(サイト作った当初は当時在籍中の大学内ローカルだった)。

そりゃおっさんにもなるわ。

.NET 系の勉強会もやっぱり .NET と共に平均年齢上がってたりして、たまーに見かける若い人が委縮していたり(というのが今日もいらっしゃったり)しますが。今、マイクロソフト自身も、.NET も、新しい世代が新しいことやってる勢いがあるので、若い人もおっさんに負けずに紛れ込んでほしいなぁと思ったり。あと、.NET 系(も取り上げる)勉強会で言うと、プロ生とかUnity部とかはかなり若い感じするので、そういうところに行ってみるのもおすすめ。

個人的には、代替わりって結構好きでして。代替わりが好きというか、世代間断絶みたいなのが嫌いというか。.NET の偉大なる父というと Anders ですけども、応援したいのはむしろ ScottGu (Azure 系の偉い人)とか Mads (C# の偉い人)だったり。

もう1回

4/17 にも、【第９回 Sansan .NET勉強会】dotNetConf 2015を振返る とか言うのやります。

僕のやつ、今日はスライド資料見せて話すだけで、デモとか一切なかったですが。あるいは、「時間が余ったら話す」的なスライドが結構ありまして、その辺りも「やり残し」ではあります。この辺り、4/17 に話すかも！（実際のところ、ノープラン。その場の空気見て具体的にどう話すか考えようかと）

まあ、正直なところ、今、時期が大変よいので、C# 6.0とか7.0がらみはノープランでもいくらでも話すことがあったりして。ゴールデンウィークは(引きこもりとしては大変遺憾ながら帰省するついでに)大阪で ++C++とC#++について駄弁る会- #vshtc とかもやったりします。

nameof

そうそう。おまけ。

世の中には、社内で「int 派 VS System.Int32 派」とかいう派閥争いをしている会社があるそうでして。

C# 6.0 で(というか Roslyn 化で)、以下のような地味ーーな新機能も実は入っていたりします。つまり、今までは Int32派の分が悪かった。

地味なので、僕なんかも「ああ、言われてみれば」くらいの感想だったんですけども、Int32派曰く「当然知っていたけども、言うと立場が悪くなるだけだから黙ってた」そうでして。

さて、今日のスライドで、nameof のところで特に触れなかった話題が1つ。↓これ。

nameof 式の中に書けるのは識別子(変数名とかプロパティ名とか)だけで、キーワードは書けない。結果、nameof(int) はコンパイルできないわけですが。これを、件のInt32派がInt32擁護に使ったりするそうで。

いや、その理屈はおかしいだろ。

nameof はリファクタリング都合で使うものです。nameof(X) に対して、X を一斉リネームした時に、リファクタリング漏れがないように使うもの。nameof(int) って。int (キーワード)をリネームする気かよ。

まあ、そんな問題よりも、今日話せなかった nameof 式の問題として、実は以下のようなものがあったり。

nameof 式、結局、C# 6.0 ではメソッドのオーバーロードを解決できません。例えば、以下のようなコード(メソッド X のオーバーロードが2つある)を書いて、X をリネームしても、nameof(X) のところは変化させれなかったりします。nameof(X) だけではどっちのXなのか区別がつかないので。