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: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>