From: zverok.offline@... Date: 2021-02-10T09:32:52+00:00 Subject: [ruby-core:102437] [Ruby master Feature#7394] Enumerable#find ifnone parameter could be non-callable Issue #7394 has been updated by zverok (Victor Shepelev). What's the point of the "default value" as compared to just `find { ... } || default`? * Would it be more performant? (I believe no) * Would it read more naturally? I believe no, the statement reads "find (and if not found, use that) by this condition..." * Would it be readable at all?.. I believe barely, actually `find(10) { condition }` can be misunderstood as "find, starting from index 10", and something like `find(:delete) { condition }` can be read as some local DSL for "find&delete". Keyword argument will improve it, of course, but looks unlike any other core API, and still reads "find, else `default`, by this condition...". But the question for me is still: why is it necessary at all? what exactly it achieves? ---------------------------------------- Feature #7394: Enumerable#find ifnone parameter could be non-callable https://bugs.ruby-lang.org/issues/7394#change-90321 * Author: zzak (Zachary Scott) * Status: Assigned * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- from github: https://github.com/ruby/ruby/pull/186 In trunk the `Enumerable#find` method `ifnone` parameter has to be callable or `nil`. I found that sometimes I want to return a simple value without wrapping it in a proc. This pull request adds support for non-callable defaults when no items match. ```ruby a = [1, 2, 3] ``` The current behavior ```ruby a.find(proc { :foo }) { |x| x > 3 } #=> :foo ``` With patch ```ruby a.find(0) { |x| x > 3 } #=> 0 ``` ---Files-------------------------------- enumerable_find_noncallable.patch (3.45 KB) -- https://bugs.ruby-lang.org/ Unsubscribe: