Issue #15973 has been updated by Dan0042 (Daniel DeLorme).


akr (Akira Tanaka) wrote:
> The lambda-ness of Proc object affects control flow: the behavior of "return" and "break".
> 
> If lambda(&b) changes the lambda-ness of b, two control flow can exist.
> I think no programmer want to consider two control flow when implementing one block.

I think everyone can agree with that. The issue I guess is **should it be allowed to define a lambda using block syntax**, with the two main viewpoints being

A. `lambda()` and `define_method()` already allow this, so it's a well established pattern. So why not allow `my_anonymous_function_dsl{  }` ? In this case the one writing the block knows it's supposed to have lambda semantics. In 2.5 it became allowed in certain circumstances but that was apparently unintended (#15620)? A search through major gems showed no incompatibilities. Numerous tickets through the years indicate current behavior is surprising to many.

B. `lambda()` and `define_method()` should never have allowed this; proc/lambda semantics should be defined **lexically**. Changing it dynamically is surprising. We can't break compatibility but we should not dig ourselves any deeper. Use `my_anonymous_function_dsl&->{  }` instead. It's a change in behavior so there may be incompatibility issues.

Does this seem like an accurate summary?

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

* Author: alanwu (Alan Wu)
* Status: Assigned
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* 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>