Guildについて
さて、Ruby3については今言ったように、パフォーマンスであるとかコンカレンシーであるとか、静的解析であるとか、改善について非常にがんばってきました。さらに互換性も維持したいので、互換性を維持しながら機能を改善していくのも、また難しい感じです。
あ、そうそう、Guildも最初デザインしたときよりも、Guildに対するメンバーシップという考え方がだいぶ弱くなってきました。Deeply Frozen Objectがあれば普通にシェアできるので、「Guildじゃないよね」って思ったんですけど、そしうたら「Guild」って名前についてゲーム業界から反対が出まして……。
（会場笑）
「俺たち、このクラス使ってるんだけど」って言われて。
（会場笑）
難しいもんですよね、本当に（笑）。いずれにしても互換性を維持するように最大限努力をしながら、Rubyをグレートにしようとずっと考えています。
（会場笑）
Ruby3であきらめたこと
今まで「やる」と言っていたものの、やらないものもいくつかあります。「Frozen String Literals」ですけども、今、マジコメで使うやつですよね。Ruby3ではデフォルトになるんじゃないかとずっと言われていましたが、Ruby3では諦めました。残念。
簡単に言うと、互換性を維持するのがすごく大変なんですね。Frozen String Literalsのマジックコメントはこれまで通り残っているので、どうぞ積極的に使っていっていただきたいんですが、こいつをデフォルトにするのは諦めました。残念。
もしかしたらRuby3.5ぐらいで開発が復活するかもしれませんが、3.0ではFrozen String Literalsは導入されません。
それから、みんな知らない「クエスチョン文字列」というのがあるんですが（笑）。「?A」とやると、「A」という文字列ができる文法があるんですね。Emacsからもらってきたんですけど、失敗でしたね（笑）。
（会場笑）
なので、こいつは地上げしようと内心画策してきたんですが、ちょっと無理そうなので、少なくとも3.0では「'?' Literals」は、なくなりません。
それから「Backquotes」の地上げも考えていたんですけども、Backquotesをするとシェルで実行して結果を文字列で返すってやつですね。
（参加者から「いける、いける」の声）
まつもと：なんかあの辺で「いける、いける」って言ってる人がいますけど、信じない（笑）。なので、これももうちょっと先で、もう1回くるかもしれませんが、少なくとも3.0では死なないということです。
というわけで、すごい保守的な感じで……。保守的で変えないと言ったわりには「Keyword Arguments」は変える予定です。Keyword Argumentsの仕様なんですが、ある部分についてはConfusingなところがあるので、後悔しているところがあります。
例えばこんな感じ？ 「Key5」って渡すと何が起きるの？
ってことが起きるんですけど、これはですね……（笑）。
あと、静的型と解析の相性悪いような気がして、この辺をちょっと整理しようという話になっています。
これで残念ながら幾ばくかの非互換が起きます。こいつはRuby3.0での大きな非互換で唯一のものになるんじゃないかなと思っています。
Numbered Block Parameters
次、みんな大好き「Numbered Block Parameters」。
（会場笑）
RubyRedmineの一部で非常にホットな話題になっているんですが、mapのブロックの中で「＠1」とかやると、1番目のブロックパラメータに宣言なしでアクセスできるというのがすでにtrunkでは導入されています。
昨日せっかくRuby会議で集まったんだからということで開発者会議をしたんですが、大紛糾しました。「様々なご意見ありがとうございます。最終的には僕が考えさせてください」と言って預かったんですが、いろいろ紛糾しまして、「見にくい」とか、「＠ってインスタンスにするじゃん」とか、まぁ「確かにわかる」という感じですけども。ちょっと考えさせてください（笑）。
最終的に導入されると約束できないところがツライところです。
「Pattern Matching」。「Regular Expression」の話ではありません。関数型言語に含まれているようなパターンマッチングを導入する予定になっています。現時点での文法はこんな感じ。
なんか「in」を使うのが見にくい感じがしますけど。まぁ、パターンマッチですね。これでできるという感じです。パターンマッチは別にセッションがあるので、そちらで聞いていただければと思います。
このパターンマッチのプルリクエストが、昨日trunkにマージされました。試してみてください。最終的にこの文法のまま通るかどうか自信がありませんが、使ってみてください。いろいろコーナーケースもあるので、秘孔を突いていただいて「ここ落ちました」みたいなレポートを歓迎します。
愛すべきプログラミング言語をなくしたくない
いずれにしてもわれわれは生き残らなければいけません。なぜかというと、すでにRubyで書いた資産がたくさんあるのもそうですし、われわれのご飯の食い上げになるということもありますが、何より「私たちはRubyが好きだから」ですね。この愛すべきプログラミング言語がなくなったり、時代遅れのものになったりしてほしくないんですね。正直言うとみなさんはいいですよ。Rubyが無くなってもPythonでもJavaScriptでもいったらいいと思うんですけど（笑）。
（会場笑）
私や一部のコアコミッターは職業なので、Rubyが無くなったら本当に困るんですよ（笑）。それで、みなさんの困るの程度はともかくとして、Rubyは生き残ったほうがいいと思うんですよ。……よね!?（笑）。
（会場拍手）
そのために、いろんなことをしようと思っています。基本的には、ユーザに対して利益を「Rubyを使い続けてよかった」「新しいRubyを使ったらもっとよかった」ということを提供し続けていきたいなと思っています。そうやって私たちの生活を維持していきたいと思っています（笑）。ご飯が食べれないと困るので。
そのためにも前進し続けたい。「仕様を決めました。これでもう変化しません」と、「安心して使い続けてください」というのではなくて、「バグは直します。機能は改善します。パフォーマンスは改善します」そういうことを続けていって、Rubyをより良い言語、より楽しい言語、より生産的な言語にして、Rubyでプログラミングすることが、あなたにとっていつもメリットになるような言語であり続けたいと。
そのために、ただ闇雲に前に進むのではなく、賢く前に進んでいきたいと考えています。それって1人ではできないんですよね。私自身もたくさん後悔してることもあります。中でいろいろ言いましたが、例えばスレッド入れたことやKeyword Argumentsの仕様について後悔しているとかあるんですね、正直ね。天才ではないので、やっぱりちょっと間違いするんですよ。
ただ、今のRubyって間違えると直しづらいんですよね。誰か使っちゃうので。
（会場笑）
「こんな些細な機能とか使わなくてもいいじゃん」という機能を使っている人もいるんですよね。まぁ、作ったの僕なんですけど（笑）。
（会場笑）
そうなると直せないんですよ。最初から間違いを犯さないようにするためには、素早さは失いますが、より慎重に検討しながら着実に進む必要があります。一つひとつの判断を蔑ろせずに、よく考えながらする必要があるということです。
そのためにも、私のアイディアだけでなく、みなさんからの意見やアイディアを蔑ろにしない、と考えています。さっきのNumbered Block Argumentsもそうですけど、「僕はこれは気に入らない」とか、「ここのこういうところがダメだと思う」など、まだ決まっていない部分については積極的に言ってくださったほうが、私としてはありがたいです。
決まってしまったことについて文句を言われてもなかなか変えられないので、決まる前にぜひ文句を言っていただければと思います。ただし、投票は受け付けません。
（会場笑）
そして「どうしてRubyを変えるか」と言ったら、やっぱり「私たちをハッピーにするため」です。「みなさんをハッピーにしたい、私たち自身をハッピーにしたい」と。そして、Rubyを使っていろんなものを作ることによって、「世界をもっと良い場所に変えられるようにしたい」と、思っています。
これこそが、私たちがRubyを作り続けて改善し続けている最大の理由だと思います。
ちからを集結して、世界をもっと良い場所に
今年は、私が勝手にコンカレンシーしている時に思ったんですけど、今年コンカレンシーがんばって来年の最初2.7が出て、来年最後にひと働きして……2020年の12月にRuby3.0が出ることを心から希望しております（笑）。
（会場笑）
すごくもどかしいのが、最近私、Rubyのコードを直接書いてないんですよね。「こういうデザインにしよう」というのはいいんだけど、実際にはみんなにお願いしてやってもらっているので、Cookpadのフルコミッターの笹田さんや遠藤さんであるとか、Money Forwardのフルコミッターの卜部（昌平）さんとか、Speeeeのフルコミッターのムラケン（村田賢太）さん、あとはのフルタイムコミッターの中田さんにお願いしてるところが非常に多いです。
その他フルタイムでなくてもRubyを開発してくださっている方がたくさんいます。全員の名前を暗唱できる自信がないので言いませんが（笑）、たくさんの方々に手伝っていただいて、本当に感謝しています。彼らの働きによってRubyの世界が本当によくなってきました。これからもずっとずっとよくなっていくと思います。みんなのちからを集結することによって、世界はもっとよい場所になるのではないかと思っています。
ぜひ！ あぁそうね、みなさんの中にも、もしCが書ける人がいたら参加していただきたいですし、たとえCが書けなくても「私の書きたいRubyはこれだ！」と意見を述べるだけでも、われわれにとって重要なインプットになるので、積極的にいろんな意見を……できればうちのRedmineで述べていただければなと思います。
そうすると、世界はもっといい場所になると、固く固く信じています。
ちょっと早いですが、今日はもう以上で終わります。ありがとうございました。
（会場拍手）
メソッドオブジェクトを取り出す方法について
司会者：まつもとさんありがとうございました。So,I guess we've got nine minutes for please question and name? で、いいですか？
まつもと：いいですよ。That's right.
司会者：Questions.few question please are make online up microphone view are there.
質問者1：Rubyコミッターの西島です。
まつもと：ありがとうございます。
質問者1：メソッドを今「::」で呼ぶ方法と、「.」で呼ぶ方法があって、「.」で呼ぶ方法のほうが圧倒的に多いと思うんですけど、この「::」で呼べるものをデプリケートする方法ってあんまり考えてないんですか？
まつもと：現地点では考えてないんですけど……変えたい？
質問者1：なんでそれを思っているかというと、次のRubyのバージョンでメソッドオブジェクトを取り出す方法を追加しようとしてると思うんですけど。
まつもと：はい。
質問者1：「.:」があんまり好きじゃない人がいて、他の案で3つ「:::」で呼ぶという提案もあったと思うんですけど。
まつもと：うん、あった。
質問者1：今、そのメソッドを「::」で呼べる方法を、デプリケートして、5年後か10年後かぐらいに、またその「::」でメソッドオブジェクトを取り出せるって方法をまた戻すというのは、互換性的になかなか難しいですかね？
まつもと：今すぐはちょっとわからないなぁ。ただ、今パッっと考えただけだと、その今の動き？ つまりメソッドを呼び出す動きと、将来のメソッドオブジェクトを取り出す動きというのが、同じ文法になる……よね？
質問者1：将来的には、そうですね。
まつもと：10年後ぐらいスパンを空けても。
質問者1：デプリケートして、完全に動かなくなってまた別の機能を同じシンタックスで出すという……。
まつもと：そう。それってけっこう厳しいかもしれないねぇ。
質問者1：なるほど。
まつもと：その記号を使うのは、ぜんぜんOKなんだけど、同じ文法で違う動きをするようにすると、例えば、時を超えてRubyのプログラムを動かす人がいないわけではないので……。それは、ちょっと慎重になるかもしれない。
質問者1：ありがとうございます。
まつもと：でも「..」で長期的にデプリケートすることについては、検討の余地はあると思います。
司会者：今だと、メソッドは大文字で始まれるからトップレベルのコンストミッシングになりますよね。それがメソッドミッシングになる？ と、挙動変わりますよね。
まつもと：うん、違う。いや、カッコが付いてなかったらコンスタントだけど、カッコが付いているか引数が指定されているとメソッド呼び出しになっているような気がする。
ひどい。誰だ、これ決めたやつ（笑）。
（会場笑）
（英語での質疑応答のため省略）
言語の性質を変えてしまうわけにはかない
質問者5：Rubyでは先ほどから話に出ましたが、メソッドのオブジェクトを簡単に取れるようなシンタックスとか、Numbered Parametersが入ってきていて、ちょっと関数型っぽい渡し方が新しく組み込まれている感じがありそうなんですけど、そういうことをやりだすと部分適用とかメソッドの引数の順番を入れ替えるとかが、どうしてもほしくなると思うんですよね。
そういう記号が足りない問題はあると思いますが、どうもissueを見る限り「そう簡単にはいかないのかな？」という感じがありますが、将来的に入ったり入らなかったりという展望はあったりしますか？
まつもと：とりあえず、現時点ではないですね。唯一あるのはなんだっけ？ 「Proc#curry」というものがあり、明示的にカリー化するってメソッドがあります。それ以外は、現地点では予定はありません。
質問者5：たまに、あれを使って無理矢理部分適用しているんですけど、今のところはないってことですよね。
まつもと：そうですね。それ以上の記号を導入するという話は今のところありません。
質問者5：わかりました。ありがとうございます。
まつもと：関数型プログラミングは非常にホットトピックなので、参考にしたいところはたくさんありますが、とはいってもやはり筆致が違うので、言語の性質をまるまる変えてしまうわけにはいきません。なにかを適用するにしてもすごくゆっくりという感じになりますね。
質問者5：ありがとうございます。
（英語での質疑応答のため省略）
司会者：はい。では、以上でよろしいでしょうか。……OK！
まつもと：yeah, Thank you everybody.
司会者：Thank you very much.
（会場拍手）
