Project

General

Profile

Actions

Bug #16004

closed

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

Added by alanwu (Alan Wu) over 4 years ago. Updated almost 4 years ago.

Status:
Closed
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 1 (0 open1 closed)

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

Updated by Eregon (Benoit Daloze) over 4 years ago

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

Updated by Eregon (Benoit Daloze) over 4 years 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 4 years 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) almost 4 years 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.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0