こんにちは、hachi8833です。
昨日BPS社内で「週刊Railsウォッチ」のつっつき会をZoom開催する2時間ほど前に、@_ko1さんの以下のツイートを目にしました。
[New 2.7/3.0 keyword argument pain point – Ruby on Rails Discussions](https://t.co/M4zP3yeFQi)
— _ko1 (@_ko1) May 14, 2020
その後Matz自身もツイートしているのを見つけました。
Link: New 2.7/3.0 keyword argument pain point – Ruby on Rails Discussions: https://t.co/ngpHvWjeT7
— Yukihiro Matsumoto (@yukihiro_matz) May 14, 2020
今回取り急ぎ記事にしましたが、もちろん具体的な方法やスケジュールはこれからですし、今後状況が変わる可能性もあります。キーワード引数の仕様変更はいずれは必要なものだと自分も思います。
誤りや見落としなどありましたら@hachi8833までお知らせください。
参考: Separation of positional and keyword arguments in Ruby 3.0 — 昨年12月時点のキーワード引数変更に関する一次ドキュメントです
参考: キーワード引数の現状と将来構想 - HackMD — キーワード引数の仕様変更前のアジェンダです
discuss.rubyonrails.orgへのMatzの投稿
投稿の大意
Matzです。
Railsコア開発者数人（DHH自身も含む）から、最近のキーワード引数の仕様変更がつらいという連絡をいただきました。キーワード引数の移行に伴う痛みの見積もりが不足していたと自分でも思います。熟考の末、移行スケジュールを変更/延期することを決心しました。Ruby 3.0に「本物のキーワード引数」が入らなくなることについて大変申し訳無く思います。
今後取り得る選択肢があまりに多すぎるのが問題です。私たちが正しい決定を下すために、キーワード引数移行のどこがどのぐらいつらいかについて（Rails）コミュニティの皆さまからご意見をいただく必要があります。Ruby 2.7
- 現在のRuby 2.7ではキーワード移行に関するwarningを表示しているが、これがノイズになっていることを認識している。
- おそらくだが、近々リリース予定の2.7.2ではキーワード引数がらみのwarningを消すか削減する予定。
- 2.7.2における
ruby2_keywordメソッドの扱いについても決定が必要。Ruby 3.0
- 既に
masterブランチでは、キーワード引数を通常の（位置）引数から分離している。おそらくこれはユーザーにとってつらくなる可能性がある。- 移行を延期（または取りやめ）にすることについて私たちの方はOK。
- しかしRuby 3.0でどこまで進めるかについては私たちの方で決定する必要がある。
- 2.7の（一種生焼けの）ソリューションをRuby 3でも維持する方法も選択肢のひとつとしてありうる。
- 他にも（もう少しうまい）妥協案を出せるかもしれない。
そういったわけで、キーワード引数に関連する懸念やご意見、あるいはRuby 2.7に移行するうえでつらかった部分についてこちらにコメントいただければと思います。
Matz.
同投稿より大意
苦渋の決断を下した心中、お察しいたします。
なお、議論については以下のbugs.ruby-lang.orgでお願いしますとのことです（#5）。今チェックしたら、以下のissueが立てられていましたので後で読んでみます。
反応
同投稿への現時点のコメントから目についたものをいくつか抜き出してみました。
- @mameが#27のコメントに特定のケースでとても有用な方法を書いてくれている。これは他のライブラリ作者にとっても有用そう。大感謝！（#2）。
- frozen string literalと同じようにファイルごとに
# keyword_arguments: trueのようなフラグを指定できるようにしてはどうか？（#3）– 賛同多し - RSpecメンテナーの主なつらみは自分らのライブラリでユーザーからの引数を透過的にユーザーのコードに引き渡している点（#4）。
- キーワード引数の移行の段階をもっと細かくすべきだと思う（#6）。
- 委譲がブラインド状態になるのがつらい。新しい
...が有用な場合もあるがpublic_sendやsendで委譲した場合は使えないなどのいろんな制約がある。この制約がなくなればかなり助かると思うが、それもアプリケーションコードの場合に限る。gemでは古いRubyをサポートすることも期待されるので使えない（#7）。 - 今回の決定について心から賛同する。今使えるツールや移行ガイドのような情報が欲しい（#10）。
- キーワード引数でシンボル以外のキーを許すのはやって欲しくなかった（#13）。
- 以下のツイートスレッドでいくつかのケースでやれることが見つかった。自分たちはこれでだいぶ痛みを軽減できた（#8）。
Has anyone upgraded to Ruby 2.7 in their app and are running in production? We're finding this upgrade to be incredibly difficult due to the kwargs changes. Anyone have protips for this upgrade yet?
— Eileen M. Uchitelle (@eileencodes) May 6, 2020
- 手順
- 1.
Double splat with an empty hash ( **{} ) passes no arguments絡みのエラーをまず修正する。 - 2. このGistでwarningを抑制し、production環境やdevelopment環境でログがあふれないようにする。
- 3. Shopifyのdeprecation_toolkitで、既存のwaringを表示したり、新たなwarningの追加を回避できる。このGistでgemのwarningではなく自分たちのコードベースのwarningのみを扱える。
- 4. すべて修正する
- 1.
キーワード引数の変更そのものについては全般に同意されているようです。
以下はツイートで目にした反応です。
Ruby 2.7.2でkwargsのwarning消えてもRuby 2.7.1つかわれたらwarning出てしまうからkwargs対応したコードもまだ消せるわけじゃないし僕の気持ち的にはRuby 2.7以下のサポート切ってRuby 3.0以上サポートにしたらkwargs対応コード全部消せる世界がはやく来てほしい
— Ryuta Kamizono (@kamipo) May 14, 2020