[ruby-core:106162] [Ruby master Feature#11256] anonymous block forwarding

Issue #11256 has been updated by bughit (bug hit).


jeremyevans0 (Jeremy Evans) wrote in #note-19:
>
> > Does it mean the block is required?
> 
> No, just as `&block` doesn't mean the block is required.

`&block` serves a purpose in the code, binding the block to a named proc.

A naked `&` is just documentation then. It has not material effect. It makes no sense to force such a noop modifications of method signatures to be able to forward blocks anonymously. If the block can be present it should be forwardable.


> 
> > What is the reason for the restriction?
> > 
> > The block may or may not be passed to `def foo`, so what is wrong with forwarding it or its absence with `&`? It reduces the utility of this feature, for what gain?
> 
> `In the future, matz wants to make it more explicit whether a method accepts a block or not.` 

That only makes sense if `def foo` comes to mean the block is not allowed. It seems doubtful that will ever happen and until then anon forwarding should be possible without `&` in the signature.

> If we can reduce the amount of complexity added, that is a good reason.

The result of this complexity reduction is an incoherent restriction that cannot be justified logically. Considering that the more complex proper implementation already exists, it's worth keeping it.

----------------------------------------
Feature #11256: anonymous block forwarding
https://bugs.ruby-lang.org/issues/11256#change-94765

* Author: bughit (bug hit)
* Status: Closed
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
----------------------------------------
since capturing a block into a proc is slow: foo(&block)
and creating chains of blocks is kind of ugly and ultimately also inefficient: foo{yield}
why not allow block forwarding without capturing: foo(&) foo(1, 2, &)



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

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