Project

General

Profile

Bug #16004

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

Added by alanwu (Alan Wu) 12 months ago. Updated 22 days ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
ruby -v:
ruby 2.7.0dev (2019-07-15T00:58:26Z master 223854ebe8) [x86_64-linux]
[ruby-core:93774]

Description

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
#1

Updated by Eregon (Benoit Daloze) 12 months ago

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

Updated by Eregon (Benoit Daloze) 12 months 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) 12 months 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. Proc.new 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:

method(:lambda).call

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
assumption/expectation.

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
showed.

Updated by jeremyevans0 (Jeremy Evans) 22 days 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