Issue #12165 has been updated by bughit (bug hit). nobu (Nobuyoshi Nakada) wrote in #note-5:
Although I've not thought about `Hash#last`, once when `st_table` got keeping the insertion order I proposed `Hash#reverse_each` (`st_reverse_foreach` for it precisely) to matz, but was rejected.
Is it not reasonable for a user to expect that core/std lib code will be at least not, knowingly, intentionally, horribly sub-optimal? Since at least two people tried to fix `Hash#reverse_each` and were rejected, that's exactly what it is at this point, knowingly, intentionally, horribly sub-optimal. ---------------------------------------- Feature #12165: Hash#first, Hash#last https://bugs.ruby-lang.org/issues/12165#change-103100 * Author: stillhart (Fabian Stillhart) * Status: Open * Priority: Normal ---------------------------------------- Just run into a simple problem with a colleague and was wondering why there is no Hash#last method? ~~~ruby {a: true, b: false}.last NoMethodError: undefined method 'last' for {:a=>true, :b=>false}:Hash ~~~ Interestingly I while playing arround I found out that the Hash#first method works. But why is it not in the ruby-doc? ~~~ruby {a: true, b: false}.first => [:a, true] ~~~ I would assume the Hash#last method would work like the Hash#first method: ~~~ruby {a: true, b: false}.last => [:b, false] ~~~ If I am not wrong the order of a Hash is always the same when calling Hash#each. So wouldn't it make sense to have Hash#last method? I tested it in Ruby 2.2.4 and Ruby 2.3.0. -- https://bugs.ruby-lang.org/