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チェックがあったかとかを調べる方法でやろうとしている。 ローカル変数やメソッドの引数についてはそんなに障壁はなくて、問題になりそうなのはせいぜいラムダ式でキャプチャする場合(匿名クラスのフィールドに昇格して、メ

先週末はあんまり拾うところがなくて定期ポストをサボっていたら、月曜日にまとめて大量の 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# の言語機能に対

なんか割かしひっそりと公開されていましたが、.NET Foundation 配下で、LLVM ベースの IL コンパイラー(.NET の IL コードをネイティブ コード化)が出てきました。 プロジェクト名 LLILC。LLVM な IL Compiler で LL IL C でしょうし割かし安直なんですが、「lilac」(普通に花のライラック)と読ませるそうで読み方的には結構おしゃれ。縦棒並びすぎロシアの筆記体かよとか、L 並びすぎ呪文かよとか思ったりもしますが。 大きなイベントで発表があったわけではなく、MSDN Blogs で取り上げられるでもなく(.NET Foundation のブログ記事はあり)、LLVM Project Blog でブログ記事が上がるってあたりが何か新しい。 マイクロソフトが LLVM を使うこと自体は少し前から前兆みたいなものはあって、例えば、去年、インター

C# Design Meeting Notes for Mar 24, 2015 https://github.com/dotnet/roslyn/issues/1898 今回は、これまで C# 7.0 に向けて提案されてきた内容について、issue ページでの議論の結果、今後どう取り組んでいくかを「色分け」(信号の青(green)、黄、赤の3色に)しています。 青: 興味あり、引き続き検討 黄: 何か取り組むべきものはあるけども、既存提案の方式ではやらない 赤: たぶんやらない 何がどう色分けされたかというと: ref returns and locals <青> (#118) readonly locals and parameters <青> (#115) Method contracts <青> (#119) Does not return <青> (#1226) Slicing

C# Design Meeting Notes for Mar 18, 2015 https://github.com/dotnet/roslyn/issues/1677 3/18 議事録。今回は、UserVoice (要望アンケート サイト)で、C# がらみの上位に入ってる項目について、現状の取り組み状況を説明。 とりあえず、一覧だけ抜き出し、状況のところだけ和訳。 Non-nullable reference types (すでに取組中) Non-nullary constructor constraints (CLR のサポートが必要) Support for INotifyPropertyChanged (ちょっと目的限定しすぎ。しいていうならメタプログラミング？) GPU and DirectX support (ほとんどライブラリでの仕事。言語的にサポートできるとすると、ジェネ

最近さすがにだいぶ落ち着いて来た感あり。 今週は、今月4日のミーティング議事録が issue 上に上がったくらい。 Design Notes for Mar 4, 2015 https://github.com/dotnet/roslyn/issues/1303 アジェンダは以下の通り。 InternalImplementationOnly attribute <no> Should var x = nameof(x) work? <no> Record types with serialization, data binding, etc. <keep thinking> (引き続き考える) “If I had a billion dollars…”: nullability <daunting but worth pursuing> (手ごわい。でも追及する価値ある) Internal

今週のProposals [Proposal] Add Never type and support for methods that cannot return. #1226 昔、「UnreachableAfter属性」で提案されていたもの。エラーチェックなどの際、必ず例外を投げるようなメソッドを作ることがあります。この場合、そのメソッドよりも後ろは絶対に実行されないわけですが、それをコンパイラーがわかるようにしたい(unreachableコード判定用)という要望があって、その解決策としての提案。 それが今回、属性じゃなくて、System.Neverっていう特別な型を作ってはどうかという提案が出ました。Scalaは、Nothing型で同様のことをしていて、そこからの着想だそうです。 Design Notes for Feb 11 2/11 の C# デザイン ミーティング議事録が今頃公開

割と「週刊」化している、 https://github.com/dotnet/roslyn 内の今週の動き。 Milestone: C# 7 Milestone が「C# 7 and VB 15」なものに2項目追加。 Proposal: Property-scoped fields #850 プロパティ内限定(get と set の両方で使いたいけども、その他のメンバーからは触られたくない)スコープが欲しいという話。 C# 2.0 とか 3.0 の頃から欲しいとは言われていたものの、全然入らなかった機能。当時は自動プロパティ(3.0 で入った T X { get; set; } だけでプロパティが作れるやつ)だけでも、Anders (.NET のものすごく偉い人)がなかなか Go サインを出さなかったらしいですし、時代もだいぶ変わった感が。ここ数年、Anders はご意見番的な立ち位置で、

まだ pull-req 通ってないんですが、Roslyn リポジトリ上にこんなものが。 https://github.com/dotnet/roslyn/pull/536 コンパイラー仕様のドキュメント化、始めました。 “コンパイラー仕様” コンパイラーを作っていると、標準化されている言語仕様では不十分な仕様ってものがどうしても出てきます。C# コンパイラーにもいくつかそういうものがあるんですが、「オープン化したんだからそういう隠れ仕様もドキュメント化しないとダメだよね」という感じで、その手始めに、コンパイラーチームの内部 OneNote で書かれていた仕様を .md 化してリポジトリに追加しようとしているみたい。pull-req が通った暁には、/docs/compilers フォルダー以下にこういう “コンパイラー仕様” が並びます。 具体的にどういうものをドキュメント化しようとしてい

前回でひと段落したC# 7提案関連の話、一応リンクまとめておきますか。 C# Design Notes / デザイン プロセスについて C# Design Notes / テーマ C# Design Notes 1/28版 C# 7に向けて(1): 変数やフィールドの書き換え C# 7に向けて(2): 性能と信頼性 C# 7に向けて(3): その他 C# 7に向けて(4): C# 6に漏れた分 C# 7に向けて(5): Record types C# 7に向けて(6): Pattern matching C# 7に向けて(7): まだ具体案の見えていないもの C# 7に向けて(8): Tuples C# Design Notes 2/4版 C# 7に向けて(9): Method Contracts そして今後は週1程度で個人的に興味持ったものをピックアップしていこうかなぁという感じなわけで

今 issue ページができてて大きめのものはこれが最後のはず。Method Contracts。メソッドに対する「契約」。 Proposal: Method Contracts #119 結構長かった… 結局、全9回に。今後は、「週刊ブログ」程度でよくなるはず。きっと。 契約プログラミング そもそも「contracts」とは何か的な話は、昔書いたスライド貼って済まそう。 (補足: このスライドでは非null制約を例に挙げて説明していますが、非null制約は契約でやるよりも、「非null参照型」を作る方がいいと思います。C# 7向けの提案の中にはこの「非null参照型」も含まれています。) 一応、.NET 4の頃から、ライブラリとツールでのサポートはありました。 This file contains bidirectional Unicode text that may be interp

C# 7 Proposals な内容、あと Method Contracts だけになったと一息ついたところで、新しい Issue ページが立つわけですが。 Tuples #347 タプル、つまり、型名を持たない構造化データ/データの一時的なグループ化の話。 これは結構気合の入った提案文章になっているので、全訳気味に紹介。 System.Tuple のおかげでタプルという言葉だけではあまり期待感が持てないかもしれませんが、C# 開発者的にインパクトのある言葉で表現すると「アセンブリをまたげる匿名型」「メソッド引数・戻り値やフィールドに使える匿名型」です。 背景 「複数の値の一時的にグループ化」が必要な最もよくある例は、メソッドの引数リストでしょう。C# をはじめ、多くのプログラミング言語がこれをサポートしています。要するに、複数の引数を持つメソッドには、F(1, “abc”) というように

新しいC#デザイン ミーティング議事録。 C# Design Meeting Notes for Feb 4, 2015 今回の議題は3つ。大きいのは3つ目の Classes with values です。タプルと関連してのレコード再検討。 あっ、あと、おまけで。Roslyn の RC1 を NuGet 公開したそうです。 Internal implementation only 前にC# 7シリーズその(6)で触れた、 ImternalImplementationOnly 属性に関して、もう少し詳細な検討。 問題点に関しても前の issue ページより少し詳細に。そして、今でもできること、コンパイラーに機能追加すればできること、.NET ランタイムにも手を入れるならみたいな話と、それでどのくらい「穴」が改善するかという話がかかれています。 問題はインターフェイスに後からメソッドを足しにく

「C# Design Notes / テーマ」で「どういうことがしたいか」だけ列挙されているものの、具体的にどういう仕様を追加するかまではまったく決まっていないものがまだまだ結構あります。そんな具体案の見えていないものに対して、いくつか、issue ページができて、オープンなディスカッションを始めたようです。 あと、Issue に対してマイルストーンも切り始めたみたいで、「milestone: “C# 7 and VB 15″」で検索すると一覧が出てきます。 [Proposal] Support System.Delegate as a generic constraint #158 Proposal: bestest betterness #250 Proposal: Declaration Expressions #254 Proposal: support await in Catc

先日の続き、C# 7の目玉になるであろう機能、pattern matching と record types Proposal: Pattern matching and record types #206 の片割れ、pattern matching の話。 昨日の record types (もう、自分が書くクラスの7割くらいは record types で書くことになりそうな勢い)と比べると出番は少ないでしょうが、なかなかに便利そうな機能です。 マッチング構文 以下のような感じで、オブジェクトの型や値のマッチングを、再帰的に行う構文が追加されます。 定数マッチング x is 1 定数との比較 下記の 型マッチング x is T t x が特定の型 T の時にマッチ その時、x を T にキャストしたものが t に入る プロパティ マッチング x is T { X is int , Y

現時点ではC# 7の目玉になるであろう機能として、pattern matching と record types があります。 Proposal: Pattern matching and record types #206 C# 6の機能提案の段階で出てきてはいたものの、期間的な問題で「7送り」になりました。当時と比べて、record types の書き方が少し変わっています。 長くなりそうなので、record types と pattern matching の説明は2回に分けようかと思います。今日は record types の話。 最小限の例 値の書き替えってどのくらいの頻度でやりますか？ 僕の場合だと、自分が書くクラスの半分以上は書き換え不能(先日書いた内容で言うところの immutable)に作っています(参考:C# 7に向けて(1): 変数やフィールドの書き換え)。「めんどく

元々、C# 6として(Visual Studio 2015と同じスケジュールで)入る予定だった機能のうちのいくつかは、期間的な問題でいったん仕様から外れました。そのうちいくつかは本当に単なる工数の問題で、ほぼ当時の仕様そのままに、C# 7に入りそうです。そういった類の機能に関する話も、今日、GitHub 上の issue 化されました。 Proposal: Binary literals #215 Proposal: Digit separators #216 Proposal: Declaration Expressions #254 あと、InternalImplementationOnly 属性ってのが、追加で(こちらはC# 6に間に合わせて)入りそうです。 Add support for InternalImplementationOnly attribute #220 もう1個、

C# 7の提案のうちいくつかを見た瞬間、思ったのは「C++ 11みたい」でした。 まあ、背景には、年々C#の適用範囲が広がっていること、そして、オープンソース化に伴って今後はさらに広がるであろうことがあります。 ゲーム開発の標準言語と言えばC# その広がった先の1つはゲーム開発でしょう。「ゲーム開発の標準言語と言えばC#」なんていう煽り(わりかしほんとに「煽り」ではあると思う。「話題にならないよりは炎上する方がマシ」くらいの覚悟の上の)もあります。まあ、割かし昔から、ゲーム開発者にもC#好きな人はいて、ゲーム会社の社内ツールなんかはC#で書かれることが結構あったみたいです。しかし、「ゲーム自体を」となると、これは割かし最近の話。「XNAがあったし(震え声)」と小声で主張もしたいところですが、実際のところ、割かし皮肉なことに、「C#でゲーム開発」が注目を浴びるようになったのはUnityのおか

プログラムを書くときに、「値が書き変わらないことの保証」(不変性)がほしいことは結構あります。 C# だと、現状(6も含めて)では、const 修飾と、フィールドに対する readonly 修飾くらいしかなくて不便に思うことがありました。 もちろん課題があるからこそのこの現状なんですが、C# 7では、「less ambitious」（野心を抑えて。妥協的）でも、もう少し不変性の保証を増やそうという提案がされています。 Proposal: ‘readonly’ for Locals and Parameters #115 Proposal: Immutable Types #159 readonly は「浅い」不変性 「変数や引数にもreadonlyを付けれるようにしてくれ」という要望は昔からあるものの、これまでやらなかった理由は単純で、そこまで有用でもないから。有用は有用だと思うんですけど

Roslynプロジェクトで、GitHubへの移行後初の「C# Design Notes」が公開されたみたいです。 https://github.com/dotnet/roslyn/issues/98 「続に言うC# 7」(順調に行けばC# 7になるであろうもの)に関する話題も初お目見え。単に「こんな仕様を考えています」という話出はなくて、仕様決定プロセス自体をもっとオープンにしていく話や、どういうテーマを持って決めていこうとしているのかという話が含まれています。 今出ている「新機能候補」については、どうせ変わるだろうし、さらっと流す感じで。ここでは、どちらかというと、デザイン プロセスとかテーマの話を中心に軽く和訳しておこうかと。 とりあえず、デザイン プロセスに関する話を書いてたら、気が付いたら全訳してた。今日はここまで（C# 7 で取り組むテーマや、具体的な機能案の話は後日）。 以下、