今のところ大なり小なり手をつけているものだけです。
結果的に現状見えているD言語の問題点のリストっぽくなっています。
DIP49,53
http://wiki.dlang.org/DIP49
http://wiki.dlang.org/DIP53
Qualified postblitとconstructorを統一的に改良するための提案です。
簡単な説明をここでしています。
実装についてはローカルで動くものはあるものの、DIPに対する議論がforum上で進んでいるため、それを取り込んだ上でbrush upしていく必要があるという状況です。
inout const型修飾子
Issue 6930 - combined type of immutable(T) and inout(T) should be inout(const(T))
https://github.com/D-Programming-Language/dmd/pull/2992
今のinout型修飾子周りの実装は自分がほぼ全面的に手を入れているので、この問題についてもかなりかなり早い時期に認識していました。とはいえあくまで機能拡張なので優先度が低かったのですが、しばらく前にDIP49,DIP53の関連で、inout constという属性が「uniqueなデータ」というコンセプトと密接にかかわりがあることに気づいたため、これを実装する運びになりました。
ちなみに、配列のdupプロパティをライブラリで実現する、という機能拡張も、6930によってシンプルに表現できることがわかってます。
Issue 8409 - Proposal: implement arr.dup in library
websiteのドキュメントの改善
今のdlang.orgは言語仕様を表現する、という目的に於いて結構書きづらい・わかりづらい構成になっています。自分が考えている問題は「言語の構文(grammar)と意味論(semantic)が分離されてない」です。
たとえば http://dlang.org/declaration は、ページの半分が構文の定義に割かれており、肝心の「宣言」- 変数、関数、alias、などの説明が不十分です。
この状況を改善するため、つい先日grammar部分を分離するためのPRを提出し、マージされました。
まだページを追加しただけで他ページからのリンク等は未整備なのですが、内容は最新のコンパイラ実装に追従したものになっています。
今後の予定としては、文法への言及は全てこのページへのリンクへ置き換え、各ページはより詳しいsemanticの解説を行うものに改善していきたいと思っています。
pure,nothrow,@safeの推論機構の改良
Issue 10329 - Attributes not inferred for indirectly templated methods
https://github.com/D-Programming-Language/dmd/pull/2832
テンプレートによって実体化される全ての関数は、それがネストしたスコープにあるかどうかに関わりなく属性推論が有効になるべき、という機能です。PRの取り込み待ちです。
delegateのコンテキストの取り扱い、pure関数内関数の挙動の改善
Dのdelegateはコンテキストに対してconstなどの型が付きますが、現状の言語仕様はこのコンテキストの属性に対して妥当な定義を行っていません。このことが、オブジェクトのメンバ関数とネスト関数の挙動の差異の原因になっています。
類似の問題として、現在pure属性をメンバ関数につけるとweak purityな関数として扱われるのに対して、ネスト関数にpureをつけるとstrong purityを持つ関数として扱われてしまう、という問題があります。
この問題自体は実装の不備なので改善可能なのですが、impureなdelegateを引数として取る関数はpureになりうるのかどうか、というsemantic上の不明点が自分の考察の中で見えています。
int foo()(int val, int delegate(int) dg) { // dg is impure
return dg(val);
}
struct S {
static ing g;
int calc(int n) { g = n; return n * 2; }
}
void main() pure {
S s;
assert(foo(10, n => n * 2) == 20); // pure
assert(foo(10, &s.calc) == 20); // impure!
}
これはたとえばstd.range.putや、void toString(void delegate(char[]) sink)などで問題になり、定義方法を出来るだけ簡単に保ったまま属性推論の利点を享受する方法・定義についての推論が不足している状態です。
sharedが付くdelegateについても考察が必要なのですが、この辺りは@mono_shooさんの協力を仰いだほうがいいのかもしれません。
NRVO、inlining周りの改良
NRVOは言語仕様上はまだ最適化の一種とされていますが、現状はDでオブジェクトを生かしたままコピーなしで関数から返すための唯一の機能です。
またstd.typecons.scopedなど、NRVOがないと事実上実装不可能なPhobosの機能もあります。なので正式に言語仕様として定義するためにかなり昔からこの機能の改良には着手してきました。
またNRVOを言語仕様に含めるには、その挙動がinline時も保証される必要があり、その結果inline周りも触るようになってきました。(結果として、過去にあったネスト関数をinline化したときの問題をかなり解決できています)
NRVO周りは今手持ちの問題がないので、当面の課題はこの問題です
Issue 10985 - Compiler doesn't attempt to inline non-templated functions from libraries (even having the full source)
https://github.com/D-Programming-Language/dmd/pull/2561
直接コンパイルされていない、importのみのモジュールにある関数がinline化されないという問題で、Phobosを使ったコードのかなり深刻な性能問題の一因になっています。
現状は、PRを投げたはいいが、自分のbackendへの理解が不足しているせいで正しいバイナリが各Platformで生成できず、仕方なく放置状態になっています。年末年始辺りに時間を取れるかな？
テンプレートオーバーロードセット機能の改良
D言語でオーバーロード可能なエンティティには、関数とテンプレートの2種類があります。これらのオーバーロードをモジュール機能と絡めて正しく取り扱うためのD特有の機能がオーバーロードセットという概念であり、これは関数もテンプレートも同じように動作すべきです。
未実装の機能として、テンプレートオーバーロードセットをaliasでマージする機能がPRのマージ待ちです。
https://github.com/D-Programming-Language/dmd/pull/2417
機能としては2.064から入ったのですが、まだまだ実装がこなれていません。同じく2.064から入った、通常関数と関数テンプレートをオーバーロードできる機能ともコンパイラ内部ではかなり密接に関連しているため、今後継続してrefactoringを進めるべき点であります。
オーバーロードの問題はモジュールシステム、Protection属性、aliasによる別名に深く関わっています。
module a;
void foo(alias func)() { func(1); }
private void bar(int) {}
void bar(string);
void testA() {
foo!bar(); // func(1) calls private void bar(int).
}
module b;
import a;
void testB() {
foo!bar(); // func(1) calls private void bar(int).
}
別名の問題の具体例としては、オーバーロードされたシンボルにaliasで別名を付けたらどうなるのか、privateな関数のpublicな別名をつけたら、モジュールの外から元の関数を呼べるのか、などがあります。
モジュールシステムと名前探索、Protectionの問題
Issue 313 - [module] Fully qualified names bypass private imports
Issue 314 - [module] Static, renamed, and selective imports are always public
https://github.com/D-Programming-Language/dmd/pull/2256
PRの議論の中で、モジュールを越える名前探索におけるprivateなシンボルの可視性の問題が議題に挙がったため中断状態です。
関連リンク：
DIP22
https://github.com/D-Programming-Language/dmd/pull/739
PS: 昨日AndreiがPRにコメントしたためか、DIP22が更新されたようです。これを書いた後読みにいきます。
Propery enforcement
https://github.com/D-Programming-Language/dmd/pull/2305
自分が出している実装は基本的にDIP23に基づいたものです。継続的にメンテナンスはしているのですが、ここ最近はあんまり反応がないですね。
近々pingを投げてみます。(2.065リリース直後当たりがいいかな?)
scopeの定義
オブジェクトのescapeと@safeなコードの問題は、未だ十分にsemanticの議論がなされていない領域です。
Dにはscopeという属性が(D1の頃から!)用意されていますが、実装どころかその意味すら十分に定義されていない状況です。
今のところ一番「まとも」な提案は、AndreiのDIP25ぐらいだと自分は認識しています。
他にもこの問題へのDIPは提出されていますが、実装可能性や定義の複雑さ、問題領域の網羅性などからいまいちな物ばかりだと思っています。(「思っています」なのは、私自身がこの問題への考察を十分に行えていないからです)
どなたかこの問題に取り組んでみませんか。今なら第一人者になれますよ！
こんなとこでしょうか。
見えているだけの課題ならもっとあるのですが(multiple alias thisとか)、全部書くと多すぎるだろう、ということで範囲を絞りました。