Bug #16004

Kernel#lambda captured with Kernel#method doesn't create lambdas

Added by alanwu (Alan Wu) over 1 year ago. Updated 4 months ago.

Target version:
ruby -v:
ruby 2.7.0dev (2019-07-15T00:58:26Z master 223854ebe8) [x86_64-linux]


ruby -e 'p method(:lambda).call{}.lambda?' prints false on 2.3.x-master(223854ebe8).
I think it should create lambdas.

Related issues

Related to Ruby master - Feature #15973: Let Kernel#lambda always return a lambdaClosedmatz (Yukihiro Matsumoto)Actions

Updated by Eregon (Benoit Daloze) over 1 year ago

  • Related to Feature #15973: Let Kernel#lambda always return a lambda added

Updated by Eregon (Benoit Daloze) over 1 year ago

I would guess this is because Method#call introduces an extra frame:

$ ruby -e 'def foo; yield; end; method(:foo).call { raise "bar" }'    
Traceback (most recent call last):
    3: from -e:1:in `<main>'
    2: from -e:1:in `call'
    1: from -e:1:in `foo'

Basically, lambda only works as a literal lambda { ... }, similarly to -> { ... } which clearly can only be used with a literal block.

Like in #15973, I think this is just an incorrect usage of #lambda.
What's the use case for this?

Updated by shevegen (Robert A. Heiler) over 1 year ago

I think this requires matz to determine which behaviour is the valid or the
better one (as from the other linked discussion too).

I myself almost never use lambdas and only very rarely proc deliberately
so (via e. g. or proc {}), but from the syntax example given by
alanwu, I actually agree that I would have assumed there to be a lambda.

At the same time, though:


without {} leads to

ArgumentError (tried to create Proc object without a block)

so I think it just needs consistency either way (and perhaps
may be backwards incompatible if changed?).

Either way I agree with alanwu here at the least from my initial

benoit wrote:

Like in #15973, I think this is just an incorrect usage of #lambda.

Well, we can say that of course, but then we have to look at example(s)
given by alanwu like this one here, and I think his example makes
sense (to me). But admittedly I so rarely use lambdas or procs
deliberately that it would not affect me either way; I am using
ruby mostly in an oldschool OOP fashion (aside from blocks of course,
which I use a LOT, so I sort of use procs too, I guess) where I
rarely have procs/lambdas directly within the code itself. I used
to use them in the past in ruby-gtk + callbacks, but I found it a
bit too cumbersome compared to just using objects and methods
directly. .call() can still be useful of course, e. g. as rack

Updated by jeremyevans0 (Jeremy Evans) 4 months ago

  • Status changed from Open to Closed

With the changes in #15973, method(:lambda).call{} warns. I think that is sufficient to handle this issue. If you disagree, please reopen with a use case.

Also available in: Atom PDF