From: jacobevelyn@... Date: 2020-03-25T15:31:39+00:00 Subject: [ruby-core:97596] [Ruby master Feature#16739] Allow Hash#keys and Hash#values to accept a block for filtering output Issue #16739 has been updated by jacobevelyn (Jacob Evelyn). > All it does is saves you from typing `select`. It does not look like the proposed feature makes much difference unless such situation is frequently met. Do you have any use case? I see code that could be improved with this all the time, including in projects like [Ruby](https://github.com/ruby/ruby/blob/master/lib/reline/key_stroke.rb#L19-L35), [JRuby](https://github.com/jruby/jruby/blob/master/lib/ruby/stdlib/ffi/enum.rb#L247-L283), [Rails](https://github.com/rails/rails/blob/master/actionview/lib/action_view/renderer/partial_renderer/collection_caching.rb#L38), [Discourse](https://github.com/discourse/discourse/blob/master/lib/stylesheet/manager.rb#L22-L30), [GitLab](https://github.com/gitlabhq/gitlabhq/blob/master/app/models/repository.rb#L919), [Metasploit](https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/scanner/snmp/snmp_enumusers.rb#L41), [Active Admin](https://github.com/activeadmin/activeadmin/blob/master/lib/active_admin/resource.rb#L191-L195), and [Airbnb's Nerve](https://github.com/airbnb/nerve/blob/master/lib/nerve.rb#L100-L115) (see links). As I mentioned in my original post, it does not just save you from typing `select`���it also *avoids an unnecessary Hash allocation*, making it **more efficient** as well as more concise. > If you want to avoid an intermediate array, you may want to use `.each_key` or `.filter_map`. Many of these use cases aren't supported by `.each_key` or `.each_value` because they require looking at the one that's not being returned (or both keys and values). Honestly I wasn't aware of `.filter_map`; you're right that it's an option but I find it a bit verbose and hard to read. > the purpose of a block following the methods keys and values does not seem to be immediately clear. Obviously we can disagree about this. I think about it like `Enumerable#count`, where *what the method returns* does not change (an `Integer`) but the method becomes more flexible and powerful when you use a block. ---------------------------------------- Feature #16739: Allow Hash#keys and Hash#values to accept a block for filtering output https://bugs.ruby-lang.org/issues/16739#change-84780 * Author: jacobevelyn (Jacob Evelyn) * Status: Open * Priority: Normal ---------------------------------------- I often see code like the following: ``` ruby hash.select { |_, v| v == :some_value }.keys hash.keys.select { |k| k.nil? || k.even? } hash.select { |k, v| valid_key?(k) && valid_value?(v) }.values ``` Each of these code snippets must allocate an intermediate data structure. I propose allowing `Hash#keys` and `Hash#values` to accept optional block parameters that *take both key and value*. For example, the above code could be rewritten as: ```ruby hash.keys { |_, v| v == :some_value } hash.keys { |k, _| k.nil? || k.even? } hash.values { |k, v| valid_key?(k) && valid_value?(v) } ``` This behavior: 1. Does not break any existing code (since `Hash#keys` and `Hash#values` do not currently accept blocks). 2. Is very readable���it's obvious what it does at a glance. 3. Is more efficient than current alternatives. 4. Is more concise than current alternatives. 5. Is flexible and useful in a variety of scenarios, because the block has access to both key and value (unlike the behavior proposed in #14788). -- https://bugs.ruby-lang.org/ Unsubscribe: