Why does yielding to lambda splat array arguments in Ruby?

Question

In Ruby, calling a lambda with the wrong number of arguments results in an ArgumentError:

l = lambda { |a, b| p a: a, b: b }
l.call(1, 2) 
# {:a=>1, :b=>2}

l.call(1)
# ArgumentError: wrong number of arguments (given 1, expected 2)

Passing an array instead doesn't work either: (because an array is just a single object, right?)

l.call([3, 4])
# ArgumentError: wrong number of arguments (given 1, expected 2)

Unless I use a splat (*) to convert the array to an argument list, but I didn't.

But ... if I call the lambda implicitly via yield, something unexpected happens:

def yield_to
  yield(1, 2)
  yield([3, 4])
end

yield_to(&l)
# {:a=>1, :b=>2}
# {:a=>3, :b=>4}   <- array as argument list!?

What's even more confusing, a lambda derived via Method#to_proc does work as expected:

def m(a, b)
  p a: a, b: b
end

yield_to(&method(:m))
# {:a=>1, :b=>2}
# ArgumentError: wrong number of arguments (given 1, expected 2)

What's going on here?

Answer 1

I'm answering my own question here, because this is a known bug:

https://bugs.ruby-lang.org/issues/12705

And it was fixed in Ruby 2.4.1 (thanks @ndn)

Answer 2

Obviously implementation spelunking is the way. Firstly why does #call raise exceptions for lambdas with incorrect arguments? Proc::call explicitly checks for lambdas.

Now lets trace yield. It's completely separate from Proc::call. Starts here, then, then, then (VM_BH_FROM_PROC just checks that the thing is indeed a proc), then (due to the goto). I couldn't trace exactly the magic that happens in the second run of the switch, but it only makes sense that it goes through the block_handler_type_iseq case or exits the switch. Point is, invoke_block_from_c_splattable is aware of the lambda status of the supposed proc, but it doesn't use it for anything other than to verify that it is indeed a lambda. It doesn't prevent splatting the arguments.

---

As for the why portion - I'm not sure it's even intentional, the fork in the logic for procs is just missing. Lambdas are mainly advertised as method-like ¯\_(ツ)_/¯

Answer 3

The differences might come from the way to_proc is written: for a simple lambda or proc, it just returns self. For a method, it sets is_from_method flag to true, and this comes into play when the proc is invoked in the VM:

if (proc->is_from_method) {
    return vm_invoke_bmethod(th, proc, self, argc, argv, passed_block_handler);
}
else {
    return vm_invoke_proc(th, proc, self, argc, argv, passed_block_handler);
}

It looks like if the proc was created from a method, the arguments will be checked.

Answer 4

After looking in the docs, I think it is a bug in Ruby. Proc class docs explicitly say that:

The & argument preserves the tricks if a Proc object is given by & argument.

By that docs are saying that the way of handling params should be preserved even when lambda is passed with & to a method.

Following code

l = lambda { |a, b| p a: a, b: b }

def yield_to(&block)
  yield([3, 4])
  p block.lambda?
end

yield_to(&l)

outputs

{:a=>3, :b=>4}
true

Which is mutually exclusive.

What is interesting, is that this code fails with ArgumentError

l = lambda { |a, b| p a: a, b: b }

def yield_to(&block)
  block.call([3, 4])
  p block.lambda?
end

yield_to(&l)