From: eregontp@... Date: 2019-12-25T11:51:08+00:00 Subject: [ruby-core:96469] [Ruby master Feature#15973] Let Kernel#lambda always return a lambda Issue #15973 has been updated by Eregon (Benoit Daloze). zverok (Victor Shepelev) wrote: > Seem it will have an awful impact on any DSLs?.. Which is IMHO a perfect example of how dangerous that is. What if it's `skip_if { |user| return 42 }`? Do you expect that to return from the surrounding method or to return from the block? For any non-lambda Proc it should mean return from the surrounding method, `define_method` breaks that (by converting a proc to a lambda implictly). ```ruby # Assuming your definition of skip_if skip_if { |user| return 42 } # should return from the surrounding method but does not skip?(1) # but it does not, it just returns from the block! proc { |user| return 43 }.call # returns from the surrounding method raise "unreachable" # never reached, as expected ``` There is an easy workaround: ```ruby def skip_if(&condition) define_method(:skip?, -> *args { condition.call(*args) }) end ``` With that `skip?(1)` returns from the surrounding method, as it should like every other literal block. ---------------------------------------- Feature #15973: Let Kernel#lambda always return a lambda https://bugs.ruby-lang.org/issues/15973#change-83396 * Author: alanwu (Alan Wu) * Status: Assigned * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) * Target version: 2.8 ---------------------------------------- When Kernel#lambda receives a Proc that is not a lambda, it returns it without modification. l propose to change `Kernel#lambda` so it always returns a lambda. Calling a method called lambda and having it do nothing in effect is not very intuitive. https://github.com/ruby/ruby/pull/2262 Judging from marcandre's investigation here: https://bugs.ruby-lang.org/issues/15620#note-1, changing the behavior should not cause much breakage, if any. This also happens to fix [Bug #15620] -- https://bugs.ruby-lang.org/ Unsubscribe: