ここでいう「上に構築」とは「あれば作れる」くらいの意味。eachメソッドが定義してあるクラスはEnumerableになれるし、succメソッドが定義してあるクラスはRangeになれる...なれるの意味がちょっと違うけど...ということ)。ところで、今だとRangeオブジェクトは、範囲なんだから当然、始まりがあって終わりがあるわけですけれども、succメソッドそのものは別段、終わりがあることを要請しているわけではありません。1..-1のような(直感に反する)Rangeを受け付けることがありますが。この-1というのは、なんか知らんけど必要なだけ無限に最後まで的な意味のマーカーになっているという事実があります。終わりは、ないことがある。今だと終わりがないとRangeにできないから、とりあえずくっつけてあるけど、本当は不要。6])とか書けるわけですが。これはPythonではsliceと呼ばれているやつですけれども、意味としては「はじまりも終わりもないRange」っぽく解釈してもさほど、違和感がない。したがってRubyにおいてRangeの終わりが、なくても良いのではないかというのは、実はさほど突拍子もない意見ではありません。いうものの新しい文法を入れるのであれば、やはりPythonでは書けるんだから1:2:3みたいにstepを書きたくなるのが人情で、そうするとこの提案のように(1..)という拡張にしてしまうと、拡張する余地がないということになってしまって、これはよくなさそうです。意味はあってもいいと思うんだけど、文法をどうするかが悩みどころですね。$!.messageendこれが書けるようになった。拡張だけにフォーカスしており影響範囲も明確、パッチも1行できれいに当たるという「行儀の良さ」にあるとおもいます。新機能、とくに新文法の追加は気宇壮大になりがちですが、大きな変更になればなるほど入れるのが大変なわけでして、あくまで着地が目標なのであれば、こういうふうに小さくまとめるのが重要なんだなと改めて思いました。SipHash13Hashクラスで使われているハッシュ関数を変えようという提案です。これですが、ハッシュ関数は一様に分布すればいいよという時代はかなり昔に終了していまして、いまどきはハッシュ関数を意図的に衝突させてDoSに使うというhashDoS攻撃が知られているので、一様な分布だけでなく、DoS耐性も求められています。いえ、もちろんたとえばSHA3とかのHMACだと衝突耐性はものすごく高いだろうと思われる反面、そういうのはそんなに速くないので、実用上はHashのハッシュ関数として使うのは難しい。DoS耐性と高速性はある程度相反する要件なので、バランスが難しいわけです。利点はもちろん高速化です。最初の時点で「なんでそれで平気なの」が書かれておらず、ちょっと判断つかなくて迷走してしまったのはよくなかったですね。「作者が大丈夫って言ってるから」じゃあちょっとねえ。結局、第三者による解析結果の論文が出てきて、「今のところ、SipHash13を解析して意図的に衝突を作る場合、最良の確率(2-167)で衝突させても誕生日攻撃(2-128)よりも確率が低い」という結果のようなので、誕生日攻撃は防ぎようがないし、まあそれより効率的な攻撃がないのなら良いのでは、ということになって、この提案は採用になりました。これは将来方向に向けて絶対大丈夫という意味ではありませんが、ハッシュ関数の攻撃耐性というのはそういうもので、なんか見つかったら対策するしかないのは何を使ってても同じなので、それはしょうがないかな、と。friendshipある程度大きなクラスになってくると、内部で使うだけのユーティリティ的な用途のメソッドと、外部に公開する用途のものができてくる。これは良いと思うのですが、さらに大きくなってくると複数のクラスから使われるユーティリティ的なメソッドというものも発生してくることがあります。それはあくまでユーティリティなので、あまり外部に公開したいものではない。今だとそういうものも全部publicにするしかない。この用途をどうにかして明確に表現したい。このリクエストが解決したい問題はそういう状況で、したがってfriendという表現になっているのだと思います。いうものの、protectedを使おうという発想はよくなかった。既存のprotectedの挙動を変えるのは影響が大きすぎるし、そもそもprotectedは失敗だったと繰り返し語られているので、今更便利に使おうと主張しても通りづらいですね。[#9992]のほうが、まだめがありそうに思いました。crystal単項のマイナスと累乗の演算子がどっちが強いかという話です。?もちろん報告者はRubyとCrystalで振る舞いが違うと報告してきていて、まあそこで「他の言語なんか知らん」と返しても良かったのですが、ふと調べてみるとこれは、ある程度どちらの側の例もあって、片方が間違いとも言えないようなのですね。興味深かったのはHaskellはRubyと同じだがOCamlはCrystalと同じで、両者が異なる(意外だ)JSは明示的に括弧をつけないと通らない(賢い!)あたりでしょうか。overheadRubyの場合lambdaのほうが普通のメソッドより有意に遅いという問題が指摘されています。これは、何が違うかというと、もちろんlambdaには環境が閉包されていることが原因で、逆に言うとRubyのメソッドは環境を持っていない分、スコープの検索などが軽いということができます。実際Lisp系言語だったらclosureに中で使ってない不要な変数束縛を残しとくような無駄な実装には普通はならんわけです。いうのプログラマ側に押し付けるんじゃなくて、勝手に処理系でやったほうがいいに決まってますよね。いうのが背景にあって、今の言語仕様だとlambdaを作った後でそのbindingを外部から抽出したり注入したりできちゃう。lambdaのスコープから見える変数は全部残しておかないと、lambdaのプログラム部分で使ってなくてもbindingからそこをたどって取得できちゃう。ここをどうにかする必要があるというのが、ささださんの意見で、どうにかする提案が、この後来ることになってるようです。最後にマネーフォワードでは、ruby-coreが気になって夜も眠れないエンジニアを募集しています。ご応募お待ちしています。