読者です 読者をやめる 読者になる 読者になる

Rustにpull request送った話

ここ数ヶ月ほど、個人的な趣味としてRustを触ってみている。業務(Treasure Data)ではJavaRubyが普段使いの言語(僕の場合、たまにObjective-CとCが含まれるけど...)で、自宅でたま〜に気分転換でOCamlで適当なのを書いてみる、という生活がここ数年間続いているので、久しぶりに新しい言語に触れてみないとなぁと思ったのが発端。言語の趣味的にはOCaml等の堅めなやつが好みなのと、これまであまり厳密に意識してこなかった変数の所有権や生存期間という概念が面白そうだったため、Rustに興味を持ったと思う。

Rustの関数は型に厳格なので、柔らかめなことをする場合はマクロを使う(と思っている)。単体テスト用の assert!() や assert_eq!() もマクロとなっており、名前から推測できるように前者は第一引数が真であること、後者は第一・第二引数が等しいことを検証する。

assert_eq!()を使って単体テストを書いていた際、検証失敗時のメッセージに比較対象の値だけではなくテスト文脈的な情報を含ませたいことがあった。しかし、assert!()には第二引数として付加的なメッセージを表示させる機能があるが、assert_eq!()にはその機能が提供されていなかった。僕は単純に実装漏れだと思い、適当にマクロの書き方を覚えてpull requestを投げた。

github.com

p-rを送ったら、すぐにRustの中の人からマージしてくれそうな雰囲気の対応を受けたが、@rust-lang/coreチームにも見てもらったほうが良いと言われた。さらに別のRust界隈人達からは@rust-lang/libsチームにも見てもらうべき、とか、それは既に Accept extra parameters in assert_eq!, pass them to panic! · Issue #1604 · rust-lang/rfcs · GitHub で議論中である、というコメントが来たりして「なんだか面倒なことになってきたなぁ」と思い始めたのであった。

さらに「そんな場合はassert!()の方を使って付加的なメッセージを出せば良いじゃない」というassert_eq!()の存在意義を揺るがすフィードバックもあったりと、この時点で完全に面倒臭さが高まっていた。なので「それではそもそもassert_eq!()要らないのかなw」&「JavaRubyOCamlユニットテストフレームワークでは対応してるのにRustでは未対応なので実装漏れかと思ったw」等の軽い煽りを入れて様子を見ることに。

その後、しばらく進展が無く、間が空いたためモチベーションも下がってきたため、このp-rを閉じることを打診してみると、急に議論が活発になり、さらにはポジティブな意見が増えてきた。続いて、実装に関するフィードバックを頂いたり、手直し等を経て無事マージされたのであった。

今回のp-rはマージされるまでに三週間かかっており、個人的にはちょっと遅めな印象なのだけど、open中のissueや GitHub - rust-lang/rfcs: RFCs for changes to Rustでの議論を見ると全体的に慎重に進んでいくようなので、今回のp-rは早めにマージされたとも見れる。

そして、先日リリースされたRust 1.11には当該p-rが含まれており、"Contributors to 1.11" の所に名前が載っていることに気がついた。こういうのは素直に嬉しい。

blog.rust-lang.org

現在は、先日リリースした
github.com
を時間を見つけてはいじるようにしている。未だに、Rustで書きたい処理を書こうとしてはコンパイラに怒られ凹む日々だけど、しばらく地道に続けてみようかなと思っている。