Issue #15973 has been updated by Eregon (Benoit Daloze).


alanwu (Alan Wu) wrote:
> The idea to generate a delegating lambda seems to side-step a lot of the issues posted here.

So then, would it be the same semantics as this?

```ruby
b = proc {|x, y, k:1| x }
l = lambda { |*args, **kwargs, &block| b.call(*args, **kwargs, &block) }
```

I think the lambda cannot have the same (in the code) arguments as the proc, otherwise https://bugs.ruby-lang.org/issues/15973#note-16 would fail too.

@alanwu Can you present use case(s) for turning procs into lambdas?
So far I only see consistency but the delegating lambda is not that consistent with #lambda with a literal block.
Without a good use-case, I think raising on #lambda without a literal block would be the safest and least surprising.

----------------------------------------
Feature #15973: Make it so Kernel#lambda always return a lambda
https://bugs.ruby-lang.org/issues/15973#change-79350

* Author: alanwu (Alan Wu)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
When Kernel#lambda receives a Proc that is not a lambda,
it returns it without modification. l propose changing `Kernel#lambda`
so it always returns a lambda.

Calling a method called lambda and having it effective do nothing was
not very intuitive.

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

Judging from marcandre's investigation here: https://bugs.ruby-lang.org/issues/15620#note-1
changing the behavior should not cause much breakage, if any. 


This also happens to fix [Bug #15620]



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

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>