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>