Ruby

lambda(&proc{}).lambda? returns false because I think the rule is:
once a Proc is created, it never changes its lambda-ness.

So the only way to create a lambda is passing a block directly to lambda (or through send), or using ->.

So I think direct_pass above should create a non-lambda Proc, and I would argue it's a bug it creates a lambda since MRI 2.5.

Eregon (Benoit Daloze) wrote:

lambda(&proc{}).lambda? returns false because I think the rule is:
once a Proc is created, it never changes its lambda-ness.

Right. I was wondering why this is the "rule", what's the rationale. It makes lambda(&...) equivalent to ...to_proc but less clear. I was thinking only in terms of parameter passing (in which case the rule feels counter productive), but there's also handling of break and return (in which case the rule makes more sense I guess, still not convinced).

Note that the rule can be broken, for example with:

def transform_proc_into_lambda(&proc) o = Object.new o.singleton_class.define_method(:foo, &proc) o.method(:foo).to_proc end transform_proc_into_lambda{}.lambda? # => true 

Right, define_method is kind of an exception.
However, it doesn't mutate the lambda-ness of the Proc, it creates a new Proc from that block with lambda semantics.

It's still confusing for the user though, as a given literal block could be used as both Proc and lambda, which is likely unexpected (e.g. break/return cannot work correctly in that block).
This can also be achieved with send(:proc or :lambda) { ... }, but that case is more explicit about it.

Since normal Ruby methods can't differentiate between a literal block and a block pass, having #lambda behave like a normal method gives us more consistency.
#lambda doesn't need to mutate its argument, it could return a lambda proc based on the block-passed proc.

we will fix it.

@nobu (Nobuyoshi Nakada) should this one be closed too?

I propose we fix the regression first, the optimization introduced let's fix that, regardless of desired semantics in the future.

I posted more thoughts on #15973. Maybe we should simply raise when not giving a literal block to lambda/proc, since it's useless or dangerous (changes semantics of code) otherwise.

Here is a patch which restores the 2.4 behavior:

https://github.com/ruby/ruby/pull/2289

Passes make check with VM_CHECK_MODE=1.