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 
Updated by 
Updated by