Dart型システムの動向

# はじめに
Dartは[2015年3月にそのVMをChrome他ブラウザに組み込むことを諦めて](http://news.dartlang.org/2015/03/dart-for-entire-web.html "Dart News & Updates: Dart for the Entire Web")以来、JavaScript(JS)との相互運用性向上やプラットフォーム拡大をより重視するかたちで方向転換を行っています。結果として、Dartは[よりAOTコンパイルに適した言語](http://news.dartlang.org/2016/11/dart-strong-mode-and-ahead-of-time_30.html "Dart News & Updates: Dart Strong Mode and ahead-of-time compilation")になろうとしているように見えます。これにともない主に型システム周りで大きな変更をしつつ有るので、ここでまとめたいと思います。

Dartは元々、既存JSへの機能追加では解決できないJSの歴史的負債(Bool比較、thisスコープ、prototype chain、eval、...)を清算するために新規に開発されました。同時にコンパイルターゲットとしてのJSを強化することにも当初からコミットしています。機能はJSに素直にコンパイル可能なことを条件とし、JSと比較した強化機能もES6以降向けの提案を先取りする形で進められてきました(例:class、Promise(Future)、async/await、generator(async*、sync*)、import、tailing comma等)。型システムもJSに寄り添う形で実行時には変数が全て動的型付け(dynamic)です。つまり、変数の型はchecked modeでさえ完全にオプショナルで、単にIDEやAnalyzer等のツール向けのアノテーションでしかなかったと言えます。しかし、これが前述の方針転換の課題にもなっているようです。

Dartのもう一つの設計思想には、既存エコシステムの親和性の重視があります。これまでDartが考えていた親和性とは、ソフトウェア業界全体でみた開発者の多い既存言語(C、Java等)と構文的、意味的に類似性をもたせるということでした。Dartから外れますが、Androidでアプリ開発言語としてJavaを選んだのもそのためでしょう。しかし、新興プログラミング言語であるTypeScript、Swift、Kotlinを見る限り構文的、意味的類似性はさほど重要ではないようです。むしろ、モダンな言語機能を導入するためには構文的、意味的な変更を積極的に採用し、それが受け入れられているように思います。他方で、これら言語の共通点は各分野でデファクトとなっている言語との相互運用性が高いことでしょう。つまり、重要なのは、構文や意味論が近いことではなく、その分野のデファクト言語との相互運用性だった、ということで、Dartチームもそれに気が付いたようです。

参考にTypeScript、Swift、Kotlinがどれぐらい元気が有るかを[Google Trends](https://www.google.com/trends/explore?date=2014-08-01%202016-12-23&q=%2Fm%2F0h52xr1,%2Fm%2F010sd4y3,%2Fm%2F0n50hxv,%2Fm%2F0_lcrx4 "Dart, Swift, TypeScript, Kotlin - 調べる - Google トレンド")で見てみます。

![Dart, Swift, TypeScript, Kotlin - 調べる.png](https://qiita-image-store.s3.amazonaws.com/0/37980/ac7ee844-cdcf-2e90-53a8-b5fda3be2a39.png)

SwiftとTypeScriptの元気が良すぎて一見Kotlinが元気ないように見えますが、SwiftとTypeScriptを除いてElmを追加してみると[こんな感じ](https://www.google.com/trends/explore?date=2014-08-01%202016-12-23&q=%2Fm%2F0h52xr1,%2Fm%2F0_lcrx4,%2Fm%2F0ncc1sv "Dart, Kotlin, Elm - 調べる - Google トレンド")です。

![Dart, Kotlin, Elm - 調べる - Google トレンド.png](https://qiita-image-store.s3.amazonaws.com/0/37980/a3957f09-2423-7e77-504f-2ce0b210540d.png)

KotlinはDartより後発であるにも関わらずDartより元気があります。
Elmは当初とても元気が良かったのですが、早くも失速気味でしょうか。私はJS、HTML、CSSの既存資産との相互運用性に課題が有るから(と単なるBreaking Changeではないパラダイムシフトを強要するから)と見ています。
Dart頑張れ。

## DartのAOTコンパイルのターゲット
### [Dart Dev Compiler](https://github.com/dart-lang/sdk/tree/master/pkg/dev_compiler "sdk/pkg/dev_compiler at master · dart-lang/sdk") (DDC)
ChromeへのDart VM組込みを諦めた代わりに取り組んでいるDart to JavaScript(ES6)トランスパイラです。既存のdart2jsと異なり、可読性の有るJSを吐くことを意識しています。また、アプリ単位ではなくモジュール単位でトランスパイルでき、これをJSから利用することが可能です。加えて、DartからのJS利用の改善([新JS相互運用ライブラリ](http://news.dartlang.org/2015/11/dart-113-brings-improved-javascript.html "Dart News & Updates: Dart 1.13 brings improved JavaScript interoperability and more")、[TypeScriptの型定義ファイル ``.d.ts`` の活用](http://news.dartlang.org/2016/10/dart-in-2017-and-beyond.html "Dart News & Updates: Dart in 2017 and beyond")等)をすることでJS相互運用性の向上を図っています。なお、可読性のあるJSを吐くために既存のDartの意味論に一部制約を掛け、ほぼソース **前方** 互換のまま型安全を実現するStrong Modeを導入しています。

### [Flutter](https://flutter.io/ "Welcome to Flutter! - Flutter")
[Dart Developer Summit 2015でプレアルファデビュー](https://www.youtube.com/watch?v=PnIWl33YMwA&index=18&list=PLOU2XLYxmsIIQorIS8gagUiMau9S84vZV&t=1285s "Sky: An Experiment Writing Dart for Mobile (Dart Developer Summit 2015) - YouTube")したAndroid、iOSのアプリ開発クロスプラットフォームです。当初は[AndroidではVM](https://github.com/flutter/website/blob/c65c581e48123a921a32317302e98763810806e0/faq.md#how-does-flutter-run-my-code-on-android "website/faq.md at c65c581e48123a921a32317302e98763810806e0 · flutter/website")、[iOSではAOTコンパイル](https://github.com/flutter/website/blob/c65c581e48123a921a32317302e98763810806e0/faq.md#how-does-flutter-run-my-code-on-ios "website/faq.md at c65c581e48123a921a32317302e98763810806e0 · flutter/website")したネイティブコードをデプロイするものでした。iOS向けに効率的なAOTコンパイル結果を出力するために、ここでもStrong Modeが採用されています。現在はDart VMを変更して[Android向けにもAOTコンパイル](https://flutter.io/faq/#how-does-flutter-run-my-code-on-android "Flutter FAQ - Flutter")できるようにしていますが、さらに[AOTコンパイル向けに独立した言語フロントエンド(New Front End)](https://github.com/dart-lang/sdk/issues/28051 "Add support in flutter tools for incremental compilation of sources using the new Dart Front End · Issue #28051 · dart-lang/sdk")を開発中のようです。
他にも、Flutter絡みの修正(GCのレスポンス最適化、[ホットリロード](https://github.com/dart-lang/sdk/issues?q=is%3Aissue+hot+reload+label%3Avm-hot-reload "Issues · dart-lang/sdk")、[ユーザメッセージ付きassert](https://github.com/dart-lang/sdk/issues/24213 "Implement assert() messages · Issue #24213 · dart-lang/sdk")、[他多数](https://github.com/dart-lang/sdk/issues?utf8=%E2%9C%93&q=is%3Aissue%20label%3ACustomer-Flutter%20 "Issues · dart-lang/sdk"))がDart SDK側にも取り込まれていることからも、本気で取り組んでいるプロジェクトのようです。
また、Googleからまだ正式発表のない謎のOS [Fuchsia](https://github.com/fuchsia-mirror "Fuchsia")でも一級市民として[Flutterが採用されている](http://www.androidauthority.com/we-compiled-fuchsia-os-710491/ "What we learned from running Fuchsia, the mysterious new OS from Google | AndroidAuthority")ようです。FuchisaはMobile(Androidの代替?)に加え、PC(Chrome OSの代替?)やIoT(Android Things、Brilloの代替?)での活用も噂されています。Flutter、FuchsiaともGitHubのコミットは非常に高いペースを保っているので期待しています。

## 新興言語で破壊的に導入する言語機能 (型関係)
元気の有るTypeScript、Swift、Kotlinが、比較対象である各分野のデファクト言語(括弧内)に対して破壊的に導入した言語仕様の状況を確認してみます。Javaが既にそうであったKotlinの型安全、JSでは前も後もなかったTypeScriptの後置型修飾に括弧を付けていますが、要するに、ここで挙げた言語機能は、ここで挙げたすべての言語で全部取りです。
Dartも追随しようとしているようです。

|機能|Dart|TypeScript<br>(JS)|Swift<br>(Objective-C)|Kotlin<br>(Java)|備考|
|:--|:--:|:--:|:--:|:--:|:--|
|型安全|×→✔|✔|✔|(✔)|Javaが既に型安全|
|Null安全|×→✔|✔|✔|✔|TSは2.0から|
|型推論|×→✔|✔|✔|✔||
|後置型修飾|×→✔?|(✔)|✔|✔|JSには型修飾が無い|

# Dartで導入される見込みの型機能
## 型安全 ([Strong Mode](https://github.com/dart-lang/sdk/blob/master/pkg/dev_compiler/STRONG_MODE.md "sdk/STRONG_MODE.md at master · dart-lang/sdk")) [実装済み]
Dart 1の仕様のままトランスパイルしようとすると、型安全でない JSをターゲットとした場合でさえ[ヘルパー関数だらけ](https://github.com/dart-lang/sdk/blob/master/pkg/dev_compiler/doc/JS_CODEGEN.md "sdk/JS_CODEGEN.md at master · dart-lang/sdk")になってしまします。

```dart:dart
var x = a.bar;
b.foo("hello", x);
```

```js:JS
var x = getInterceptor(a).get$bar(a);
getInterceptor(b).foo$2(b, "hello", x);
```

これは、ディスパッチセマンティクスがDartとJSで異なるからです。例えば、該当するメソッドが無かった場合、Dartでは(あれば) ``noSuchMethod()`` を呼び出すか ``NoSuchMethodError`` をスローしますが、JSでは単にこれを無視します。
Strong Modeで型安全を確保し、``bar`` や ``foo()`` が有ることを担保できればDartと同一のJSを吐くことが出来ます。

Strong Modeは既に実装済みです。以前はDDCとともに[別リポジトリ](https://github.com/dart-lang/dev_compiler "dart-lang/dev_compiler: DEPRECATED - Moved to main SDK")で開発されていましたが、現在は[Dart-SDKのメインリポジトリ](https://github.com/dart-lang/sdk/tree/master/pkg/dev_compiler "sdk/pkg/dev_compiler at master · dart-lang/sdk")にマージされています。Web上のお試し環境の[DartPad](https://dartpad.dartlang.org/ "DartPad")にもStrong Modeは実装されています(右下のチェックボックス)。

なお、前述のソース前方互換は、今から積極的にStrong Modeを利用して慣れてもらうための措置、すなわちProduction Modeにいつでも戻れるでっかい避難口を設ける事で心理的安全を確保する措置だと思います。
他方で、一般的にはより重要なソース **後方** 互換は **確保されない** (Breakin Change)ので、Strong Modeがデフォルトになることが有るとすれば、Dart 2.0でしょう。

## Null安全 ([Non-null By Default (NNBD)](https://github.com/chalin/DEP-non-null "chalin/DEP-non-null: Dart DEP for Non-null Types and Non-null By Default (NNBD)")) [[DEPレビュー待ち](https://github.com/dart-lang/dart_enhancement_proposals/issues/30 "Non-null types and non-null by default (NNBD) · Issue #30 · dart-lang/dart_enhancement_proposals")、実装中]
Dart 1の仕様のままトランスパイルしようとすると、Null安全でないJSをターゲットとした場合でさえ[ヘルパー関数だらけ](https://github.com/chalin/DEP-non-null/blob/master/doc/dep-non-null-AUTOGENERATED-DO-NOT-EDIT.md#21-dart-improving-compilation-to-javascript "DEP-non-null/dep-non-null-AUTOGENERATED-DO-NOT-EDIT.md at master · chalin/DEP-non-null")になってしまします。

```dart:dart
return (a + b) * a * b;  // a and b are declared as int
```

```js:js
return dart.notNull(dart.notNull((dart.notNull(a) + dart.notNull(b)))
     * dart.notNull(a)) * dart.notNull(b);
```

これは、null評価時のセマンティクスがDartとJSで異なるからです。Dartでは ``NoSuchMethodError`` をスローしますが、JSでは単にこれを無視します。
Null安全を確保し、``a`` や ``b`` がnullでないことを担保できればDartと同一のJSを吐くことが出来ます。

どっかで既に話しました?

Null安全については下記が詳しいです。

- [null安全でない言語は、もはやレガシー言語だ - Qiita](http://qiita.com/koher/items/e4835bd429b88809ab33 "null安全でない言語は、もはやレガシー言語だ - Qiita")
- [null安全を誤解している人達へのメッセージ - Qiita](http://qiita.com/omochimetaru/items/ee29d4c6eb0d78f02b15 "null安全を誤解している人達へのメッセージ - Qiita")

かくいう私もNull安全には無知で、DartにNon-null **by Default** とかあり得ないでしょ、と思っていたくちです。
しかし、上記を読んでその考えを完全に改めました。

Dartはもともと全てがオブジェクトで ``null`` も ``Null`` のインスタンスであり、 ``Null`` は ``Object`` の直下のクラスです。すなわち ``int a = null`` は本来は代入互換性違反です。そうなっていない理由は、一つは前述の型安全をまだデフォルトとして導入していないからです。型安全を導入したStrong Modeでも ``int a = null`` が通るのは(``Null`` ではなくて) ``null`` にすべてのクラスに代入互換性有り、という特別ルールを設けているからです。NNBDではその特別ルールを廃止します。簡単ですね。
ただ、こうしても ``Object`` だけは相変わらずnullableのままになってしまいます。そこで、新ルートクラス ``_Anything`` を導入し、その直下に ``Null`` を ``Object`` とともに移動します。

ところで、[``Null`` をボトム(全てのクラスのサブクラス)にする提案](https://github.com/dart-lang/sdk/issues/28024 "Move Null to the bottom of nullable types · Issue #28024 · dart-lang/sdk · GitHub")もあり、Dart SDK 1.22で採用される予定です。
これは、NNBDの ``Null`` を新ルート直下に移動するという議論と将来衝突するかもしれない、と一見した時思いました。しかし、NNBDにおける ``_Anything`` - ``Null`` のブランチは ``Null``がボトムでもあります。問題は ``_Anything`` - ``Object`` のブランチで全ての非Null型のサブタイプとなり得る ``Null``に変わる何かが必要になるということです。このために [``Nothing`` (``Null`` と同様に、``_Anything`` とは異なってユーザから見える)を導入](https://github.com/dart-lang/sdk/issues/27488 "Make bottom a user-visible type · Issue #27488 · dart-lang/sdk")するようですが、これが新ボトムとして ``Null`` を引き継ぐのでしょう。さて、 ``Nothing`` は実際、いつ、どうやって使うのでしょう。おそらくそのインスタンスが必要となるケースはほぼ(?)無いはずです。``Nothing`` はあくまで ``<Nothing>[]`` や [``PopupMenuDivider implements PopupMenuItem<Nothing>``](https://github.com/dart-lang/sdk/issues/27488 "Make bottom a user-visible type · Issue #27488 · dart-lang/sdk") のように、実コンテンツを持たないジェネリクス型インスタンスを生成するための型引数として利用されるのだと思います。

Null安全 (NNBD) は現時点でDart Enhancement Proposals (DEP)においてレビュー待ち(awaiting review)ですが、採用されることはほぼ間違いないように思います。[Dart Developer Summit 2016](https://youtu.be/DKG5CMyol9U?t=25m1s "Sound Dart (Dart Developer Summit 2016)")でも紹介していました。また、本質的には後方非互換な変更ですが、それを極力抑えるように注意深く設計されています。提案書には[移行戦略](https://github.com/chalin/DEP-non-null/blob/master/doc/dep-non-null-AUTOGENERATED-DO-NOT-EDIT.md#part-g-migration-strategy-sketch "DEP-non-null/dep-non-null-AUTOGENERATED-DO-NOT-EDIT.md at master · chalin/DEP-non-null")も記載されています。[移行ステップ](https://github.com/chalin/DEP-non-null/blob/master/doc/dep-non-null-AUTOGENERATED-DO-NOT-EDIT.md#g4-migration-steps "DEP-non-null/dep-non-null-AUTOGENERATED-DO-NOT-EDIT.md at master · chalin/DEP-non-null")は下記の通り。

- (SDK) アノテーション ``@nullable_by_default`` 、 ``@non_null_by_default`` の導入
- (Tooling) 下記をサポート:
  - 構文のサポート (多くの構文糖衣を除く).
  - 静的チェック (上記アノテーションに従う)
  - 型オペレータ( ``?`` ,  ``!`` )の実行時サポートと動的チェック
- (SDK) クラス階層のルート変更 (先述の ``_Anything`` 関係)
- (Tooling) NNBDのグローバルなフラグ (ローカルなアノテーションに対してグローバル)
- …

…の部分ですが、グローバルフラグの指定もなしにデフォルトでNull安全が実現されるのは少なくともDart 2.0になるでしょう。

ついでに、「[null安全でない言語は、もはやレガシー言語だ - Qiita](http://qiita.com/koher/items/e4835bd429b88809ab33 "null安全でない言語は、もはやレガシー言語だ - Qiita")」で挙げていたNull安全をサポートする言語機能について見てみます。

| 言語 | `!`, `!!` | `?.`, `?->` | `?:`, `??` | `map` | `flatMap` | `do` 記法 | `?` | 型推論 |
|:--|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
| Dart | ×→✔ | ✔ | ✔ |  |  |  | ×→✔ | ×→✔ |
| TypeScript | ✔ |  |  |  |  |  |  | ✔ |
| Swift | ✔ | ✔ | ✔ | ✔ | ✔ |  | ✔ | ✔ |
| Kotlin | ✔ | ✔ | ✔ | ✔ | ✔ |  | ✔ | ✔ |

改めて見ると、Dartはそこそこ良い線いっています。JS対応待ちのTypeScriptよりもこの点ではリードしています。[Dartに `?.` 、 `??` を導入](http://news.dartlang.org/2015/08/dart-112-released-with-null-aware.html "Dart News & Updates: Dart 1.12 Released, with Null-Aware Operators and more")した当時は、なんて無意味なものを導入したんだろうと思っていましたが、これもNull安全への布石なのだと思えば納得です。

## 型推論 [実装済み]
「[null安全でない言語は、もはやレガシー言語だ - Qiita](http://qiita.com/koher/items/e4835bd429b88809ab33 "null安全でない言語は、もはやレガシー言語だ - Qiita")」を読んだ方にはもうおわかりと思いますが、Null安全と型推論は実質的に不可分です。これにはNull安全特有の事情もあります。Null型から非Null型への妥当な変換をもプログラマに依存するとしたら、システムは不当な変換を見抜けないことを、またレビューアは危険なコードを一見して見抜けないことを同時に意味し、Null安全的にはナンセンスです。また、Null安全の前提でもある型安全に共通の事情もあります。厳密な型修飾を強要する煩わしさからその言語が普及しないとしたら、結果的に型安全、Null安全を実現できませんので。これはDartのように動的型付けを起源とする言語の場合に、特に重要になるでしょう。つまり、動的型付け言語だから型修飾を省略できたというメリットを静的型付け言語でも享受するために機械が型を推論する、ということです。

ところで、業界有名人のHixieさんは [``var`` は従来通り ``dynamic`` と解釈されるべき](https://github.com/dart-lang/sdk/issues/27422 "'var' in strong mode has unexpected semantics · Issue #27422 · dart-lang/sdk")とかなり強固に主張していますね。その理由が、JSからの開発者移行を重視するため、というもの。ここまで見てきた通り、構文的、意味的類似性はそこまで重要ではないと個人的には思います。それに、型安全、Null安全をどうやって実現しようとしているんでしょうね。Null安全は比較的新しい概念だからからか、[Wikipedia(英語版)](https://en.wikipedia.org/wiki/Void_safety "Void safety - Wikipedia")も全然充実していません。「[null安全でない言語は、もはやレガシー言語だ - Qiita](http://qiita.com/koher/items/e4835bd429b88809ab33 "null安全でない言語は、もはやレガシー言語だ - Qiita")」を英訳して読んでもらいたいぐらいです。
ちなみに、[HixieさんはHTML5のキーパーソン](http://www.publickey1.jp/blog/13/hixie_html5hixie.html "なぜHixieはいつも“ノー”と言い続けるのか？ HTML5仕様のキーパーソン、Hixieへのインタビュー（前編） － Publickey")ですが、いまやDartで[Flutterなキーパーソン](https://github.com/Hixie "Hixie (Ian Hickson)")で、[Flutterのマイルストーン名](https://github.com/flutter/flutter/milestone/1 "4: Make Hixie proud Milestone")にまで登場します。

## Union Type [検討中]
Union Typeの導入は[2015年1月の段階](http://news.dartlang.org/2015/01/dart-language-evolution-discussed-in.html "Dart News & Updates: Dart Language Evolution Discussed in Ecma TC52")で既に何度も話題に挙がっていたようですが、DEPにすら挙がっていません。しかし、先述の方向転換で状況は変わっています。Union Type無しでは、動的言語が享受してきた便利な言い回しか、せっかく導入した型安全やNull安全で得られるはずのメリットの一部のどちらかを犠牲にしなくてはならなくなるからです。したがって、Union Typeはなんらか形で導入されることになるでしょう。

例えば、``Future<T>.then()`` は ``(T a) -> dynamic`` 型のコールバックを引数に取ります。コールバックは実際には ``T`` または ``Future<T>`` のどちらでも返すことが出来ます。この柔軟さを維持しつつ型安全を導入する、すなわち ``T|Future<T>`` 型の必要性もUnion Type導入の一つの動機です。もっとも、Dart SDK 1.22ではどりあえず [``FutureOr<T>`` ](https://github.com/dart-lang/sdk/issues/28006 "Add FutureOr<T> · Issue #28006 · dart-lang/sdk") を導入するようです。

また、Null安全の ``?int`` は内部的には ``int|Null`` のUnion Typeを想定しているようです。代案として ``Nullable<int>`` の構文糖衣とする案も検討していますが、既存言語システムに無用な複雑さを導入するという理由で先述のUnion Type案を推しています。ということは、NNBDの文脈で想定しているUnion Typeはタグ無しUnionですね、たぶん。

2017/01/11 追記
[`FutureOr<T>` の仕様(仮)](https://gist.github.com/lrhn/d6815f9556acb3dc8f91d2c680ea0e54#union-types-in-general "Dart FutureOr Design and Discussion Document")を見つけました。一見すると単なるジェネリッククラスですが、 `T|Future<T>` の歴としたUnion Types (のエイリアス相当)です。また、自動的にFlatteningされる点からも、ここでは明確にタグ無しUnionを想定していますね。

## Generic Method [[一部実装済み](http://news.dartlang.org/2016/12/dart-121-generic-method-syntax.html "Dart News & Updates: Dart 1.21: Generic Method Syntax")]
さきほどの ``Feature<T>.then()`` におけるコールバックの型 ``(T a) -> dynamic`` もそうですが、Dartの現状のジェネリクスはメソッドに関して貧弱でした。意図的にdynamicを指定しているのではなく、パラメタ型を指定できないのです。

```dart
Future then(dynamic onValue(T value), {Function onError})
```

これを補強しようというのがGeneric Methodです。

```dart
Future<S> then<S>(FutureOr<S> onValue(T value), {Function onError}) // 1.22～ ?
```

具体的には、[Dart SDK 1.21リリース関連のBlog](http://news.dartlang.org/2016/12/dart-121-generic-method-syntax.html "Dart News & Updates: Dart 1.21: Generic Method Syntax") のGifアニメを見れば一目瞭然です。

## 後置型修飾 ([Right Hand Types](https://github.com/emilniklas/dep-right-hand-types/blob/master/proposal.md "dep-right-hand-types/proposal.md at master · emilniklas/dep-right-hand-types")) [[DEP提案中](https://github.com/dart-lang/dart_enhancement_proposals/issues/42 "Right Hand Types · Issue #42 · dart-lang/dart_enhancement_proposals")]
前置型修飾は可読性がよろしくないので、個人的には大歓迎です。自分がC言語を学んだ際、関数型他の複雑な ``typedef`` でコンパイラの気持ちを理解するまでひとしきり時間を要したのを思い出します。
また、前置型修飾の表現力の問題もあります。

```dart
typedef int Comparator(int a, int b);
Comparator c;
```

とは書けますが、同じことを

```dart
int c(int a, int b);
```

とは書けません。関数定義と思われてボディが無いと怒られていしまいます。

```dart
var c: (a: int, b: int) -> int;
```

なら行けそうです。
しかし、これ、どうなんでしょうね。というのも、

- Breaking Change自体が目的であるし、
- DEPではawaiting reviewにもなっていないので。
  - とはいえ、DEPに挙がっている時点で見込みは有るし、 (Union TypesはDEPに挙がってもいない)
  - DEPで門前払いのClosedにされた多くの提案に仲間入りしていないだけマシかも。

少なくとも、NNBDと類似の移行戦略は必須になるでしょうね。

希望もありそうです。
関数の名前付きオプション引数のデフォルト値区切りには従来はマップリテラルのアナロジーから ``:`` を用いてきましたが、[Dart SDK 1.21](http://qiita.com/Cat_sushi/items/9df10c7433a65a1b9b0a "dart 1.21.0 CHANGELOGを勝手なことをつぶやきながら訳してみた - Qiita")では新たに ``=`` も利用可能になりました。

```dart
enableFlags({bool hidden: false}) { /* … */ }
```

```dart
enableFlags({bool hidden = false}) { /* … */ }  // Dart SDK 1.21以降はこれも可能
```

こんなしょうもないエンハンスをマイナーバージョンに突っ込む動機は、時間を稼ぎつつ将来的に識別子宣言の右側から ``:`` を一掃するつもりではないでしょうか。つまり、[そこに``:`` で分離した後置型修飾を置く](https://github.com/emilniklas/dep-right-hand-types/blob/master/proposal.md#with-named-parameters "dep-right-hand-types/proposal.md at master · emilniklas/dep-right-hand-types")布石と。ちょっと、穿った見方をしすぎですかね。

2017/01/09 追記
Right Hand Typesは「[近いうちに採用される予定はないと思う](https://github.com/dart-lang/dart_enhancement_proposals/issues/42#issuecomment-270885364 "Right Hand Types · Issue #42 · dart-lang/dart_enhancement_proposals")」、とDartチームのメンバが言っていました。
代わりに(?)、1.22で[関数の型宣言シンタックスを拡張](https://github.com/dart-lang/sdk/issues/27527 "Meta issue tracking implementation of generic function type syntax in Dart 1.5 · Issue #27527 · dart-lang/sdk")するようです。

[名前付きオプション引数のデフォルトセパレータ `:` は既にほとんどDeprecated](https://www.dartlang.org/guides/language/language-tour#default-parameter-values "Language Tour | Dart")でした。

# Dart VMへの考慮 [2017/01/15 追記]
冒頭でDartはよりAOTコンパイルに適した言語になろうとしていると書きましたが、引き続きDart VMも重要な役割を担います。サーバーサイドDartはVM上で動作しますし、[Dartium](https://webdev.dartlang.org/tools/dartium "Dartium | webdev.dartlang.org")もあります。また、Dart SDKのツール群はそのほぼ全てがDartで実装され、VM上で動作します。他にもVMを選択する積極的な理由があります。VMにおけるウォームアップ(JIT最適化コンパイル)後のネイティブコードはAOTコンパイルによるネイティブコードよりも[ずっと高速に動作](https://youtu.be/lqE4u8s8Iik?t=9m40s "AOT compiling Dart for iOS Android (Dart Developer Summit 2016) - YouTube")するようです。ちょっと驚きですが、JITなら実行時に収集する派生型情報を利用できるからとか。

このDart VMの存在がAOT向けの型機能拡張に、他の言語にはない微妙な影響を与えているようです。VMでは基本的にコンパイルの全てのステップが実行時に行われます([スナップショット](https://www.dartlang.org/articles/dart-vm/snapshots "Snapshots in Dart | Dart")は有りますが)。特にスタートアップ時にはパースや静的チェックの多くが行われるので、これらの高速性が重要となります。型推論のような比較的重い処理をVMが単に無視することができれば、そのままproduction modeで実行できます。先述のStrong Modeにおける前方互換性のもう一つの理由がここにあるようです。NNBDやジェネリックメソッドの様な構文の拡張(前方非互換)も、単に読み飛ばすことが出来ればそれにこしたしたことがありません。

幸いなことに、新たに拡張される型機能の多くはAOTコンパイルでこそ意味が有るものであり、その他もIDEと連携したAnalyzerがコーディング時に行うことが出来ます。実際に現在のVM上では拡張型機能の多くが単に無視され、JITコンパイル時の最適化で効果があるもの(実行時チェックコードの省略等)だけが解釈されるようです。


# さいごに
ChromeにVM組込みを諦めて以来、Dartの人気はだだ下がりで残念ですが、Googleは諦めるどころか重要なプロジェクトに位置付けているようです。それは開発リソースに現れていて、GitHubにおける開発活性度は2016年平均で150 commits/week程度とハイペースです。これはswift、kotlinのそれにほぼ匹敵し、TypeScriptの約倍です。また何と言っても、世界で最も稼いでいるであろうWebシステムのトップ2、[AdWords](http://news.dartlang.org/2016/03/the-new-adwords-ui-uses-dart-we-asked.html "Dart News & Updates: The new AdWords UI uses Dart — we asked why")と[AdSense](http://news.dartlang.org/2016/10/google-adsense-angular-dart.html "Dart News & Updates: The new Google AdSense user interface: built with AngularDart")の大事な顧客(スポンサー)向けUIの再構築で利用したことに、DartのGoogle内でのポジションが現れています。まあ、だからと言って一般に普及する理由にはなりませんが、少なくともその必要条件である継続的なエンハンスが期待できます。

また、AndroidでJavaに変わるべき言語として、[Kotlin、Swift、C#(Xamarin)、Go、Rust等、みなさん好き勝手](https://www.reddit.com/r/programming/comments/5ixmrj/the_future_of_android_development_is_dart/ "The Future of Android Development is... Dart? : programming")言っていますが、Dart以外が市民権を得るのは現実的ではないでしょう。Androidは「オープン」であると同時に「完全」にGoogleのコントロール下にあります。そのアプリ開発言語も然り。GoogleのAndroidにおける影響力は、誰のものでもないWebにおけるそれとは比べ物にならないでしょう。そしてGoogleはFlutterにも相当のリソースを掛けており、50 commits/weekぐらいでしょうか。先述のHixieさんの位置付け(マイルストーン名)も象徴的です。他方で、他の言語をAndroidに持ち込むことに投資している様子はありません。

ところで、ソフトウェア開発コミュニティ全体に及ぼす影響力はモバイルの開発者コミュニティがWeb開発者コミュニティを凌いでNo.1では無いではないでしょうか。これは、開発者人口からはほぼiOS専用であろうObjective-Cと、同じくその置き換えであるSwiftが[TIOBE Index](http://www.tiobe.com/tiobe-index/ "TIOBE Index | TIOBE - The Software Quality Company")において10位前後で仲良く肩を並べていることからの推測です。二大モバイルOSのもう一方、AndroidでDartが一級市民になれば(仮に、iOSとのクロスプラットフォームとして認められなくとも)、Swiftと同様に急速に知名度が上がるはずです。そうなればDartのお家芸であるWeb開発業界、ひいてはソフトウェア開発業界全体でも知名度が上がりTIOBEでJSと肩を並べる日も遠く無いように思います。
※ TypeScriptが50位以内にランクされないTIOBEにどれほどの意味があるかはさておき。

2017/01/04追記
[Hixieさん曰く](https://github.com/dart-lang/sdk/issues/27422#issuecomment-270063328 "'var' in strong mode has unexpected semantics · Issue #27422 · dart-lang/sdk")、[Stack Overflow Developer Survey 2016 Results](http://stackoverflow.com/research/developer-survey-2016#developer-profile-developer-occupations "Stack Overflow Developer Survey 2016 Results")によると、Web開発者はモバイル開発者の3倍居る、とのことです。

# 蛇足
## undefined
`Nothing` で思い出したのですが、Dartには一時期 `undefined` がありました。これは、関数のデフォルト値無しのオプションナル引数が省略された場合に取りうる特別な値でした。クラス階層を無視したハンドクラフトな値だったようですが、別の関数に引き渡す際にはさらなる特別扱いが必要になったとか。必要性が希薄なわりに無用な複雑さをどんどん増し兼ねないということから[Dart 1.0以前に仕様から削除](https://github.com/dart-lang/sdk/issues/9097 "Remove the ?check operator · Issue #9097 · dart-lang/sdk · GitHub")されました。そんなこんなで、先述の「`Nothing`」を `undefined` と命名するのは歴史的にも、JSのアナロジー的にも無しですね、きっと。

## ChromeとかWebAssemblyとかOilpanとか
Chrome 50でDOMオブジェクトのメモリ管理方法が被参照カウンタからGCに変わったことをご存知でしょうか。この長寿だったプロジェクトはOilpanと呼ばれ、日本人の[haraken](https://twitter.com/xharaken "Kentaro Hara (@xharaken) | Twitter")さんがリードしていましたが、その[歴史的な開始動機はDart VMをChromeに搭載すること](https://docs.google.com/presentation/d/1YtfurcyKFS0hxPOnC3U6JJroM8aRP49Yf0QWznZ9jrk/present?slide=id.g255803d1d_1673 "Oilpan: GC for Blink (public) - Google スライド")だそうです。先述の通りDart VMの組込み計画はなくなりましたが、Oilpanのお陰でChromeの性能(速度、メモリ)は向上し、Use-after-free in Blink な賞金首は鳴りを潜めました。
ところで、今考えるとDart VMをChromeに搭載しなくて良かったと思います。というのも、Oilpan導入後もV8(JS)のGCとBlink(DOM)のGCは連携した別々のGCであり、今でもより良い連携を模索しています。それだけ複数のGCを持つというのは難しいことなんだと思います。かつてはブラウザ上で全盛を誇ったFlashも、いまやブラウザたちに煙たがられて静かに死を待つのみですし、.NET(CLE)に至っては... 

ブラウザに別言語の実行環境を持ち込むといえば[WebAssembly](http://webassembly.org/ "WebAssembly")も有りますが、こちらはプログラマがメモリ管理をする必要がある言語が当面のターゲットです。加えて、WebAssemblyの処理系バックエンド(下層部分)はJSのそれと共通化できるように最初から考慮されています。Chromeで言うと[Turbo Fan以下](http://v8project.blogspot.jp/2016/03/experimental-support-for-webassembly.html "V8 JavaScript Engine: Experimental support for WebAssembly in V8")がWebAssemblyと共通になるようです。GCがない言語であっても、処理系は共通化すべき(複数持つべきではない)ということだと思います。
なお、WebAssemblyは将来的には[GC言語をサポート](http://webassembly.org/docs/gc/#native-gc "GC / DOM / Web API Integration :unicorn: - WebAssembly")するようです。そうなると、Dartを「ネイティブ」にブラウザで実行しようという機運が再び高まることでしょう。