ES6 クイズの答え

ES6 クイズ は、俺自身が「いずれ引っかかりそうだな」と思ったもの。
「そう見えるのは俺だけかも。。」と思って何人かにクイズとして出してみたら、意外と引っかかったので俺だけじゃなさそうと思って書いた。

クイズ1

var a = 1;
if (a => 2) {
 console.log('bigger');
} else {
 console.log('smaller')
};

// bigger

a => 2 は比較演算ではなく、 arrow function なので常に true になる。
念のため言うと、本来比較演算の greater than は a >= 2。

クイズ2

var a = 1, b = 2, c = 3, d = 4;
var f = a => b ? c: d;

// f = ?

1 と全く同じで、 f は arrow function になる。
(a と b の比較なら a >= b)

わかりやすく書くとこう。

var f = (a) => { b ? c: d; }

つまり、 f を実行すると、 b が truthy なので c が返る。

f(); // 3

ちなみに AST レベルでは 和田さんが調べてた のでそちらを参照。

本当の問題

この問題、単なる引っ掛けで済めば良いけど、
実際にだれかがこのコードをしれっと入れてしまったときに、気づくのって簡単だろうか。
(たとえ、このエントリを読んで、問題を知っていたとしても。)

特に初心者は、 <= の反対は => だろと思うのは無理も無いと思う。
というかそっちの方が直感的な気もするし。

本当の問題は、「今まで => はエラーだった」ということだ。
構文的に間違っていることを処理系が教えてくれたから、俺らは自然とそれを避けてこれた。

でも、 arrow function が有効な環境では、もうこれは Valid なものとして解釈されてしまう。
自分でそれに気づく仕組みを持っておきたいと思うのが、自然なアプローチのように思う。

対策

個人的には、以下のスタイルを強制するのが一番楽だと思う。
(もちろん、テストは書こう。でもその話はしてない。)

arrow function の引数は必ず `()` で囲む

そして、それを強制するための eslint plugin を書いた。

[追記] @teppeis さんの PR で、 Condition が期待される部分のみ検出するルールを追加しました。 no-condition

これを入れれば、以下のようなコードは全て怒られる。

a => {}
a => a
a => {\n}
a.then(foo => {});
a.then(foo => a);
a(foo => { if (true) {}; });

こう直すと通る。

() => {}
(a) => {}
(a) => a
(a) => {\n}
a.then((foo) => {});
a.then((foo) => { if (true) {}; });

このルールを導入していると、クイズのコードはこう書かないと動かなくなり、
もし比較演算を意図していたなら、おかしいことに気づけると思う。

if ((a) => 2) {
  // snip
}

var f = (a) => b ? c: d;

中括弧や return まで強制すればもっと良いかもしれないけど、それは arrow function の旨味まで消えている気がするので、
スタイルで強制するのはこのくらいがちょうどいいと思う。今のところ違和感は感じてない。

なお、「今まで動かなかったコードが動くようになる」ということがもたらす問題に、これからもっと直面するだろうなと思う。