From: "bughit (bug hit)" Date: 2021-11-18T22:35:09+00:00 Subject: [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: