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

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

[jeremyevans0 (Jeremy Evans)]

Issue #11256 has been updated by jeremyevans0 (Jeremy Evans).


Looks like @matz approved this, but it was never committed.  I've submitted a pull request for this that is based on the patches provided by @mame and @nobu: https://github.com/ruby/ruby/pull/5051

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

* Author: bughit (bug hit)
* Status: Assigned
* 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/

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

[mame (Yusuke Endoh)]

Issue #11256 has been updated by mame (Yusuke Endoh).


@matz accepted this, but said that the formal argument must explicitly receive a anonymous block parameter, i.e.

```
def foo(&) = bar(&) # OK
def foo = bar(&)    # NG
```

In the future, matz wants to make it more explicit whether a method accepts a block or not.

@jeremyevans0 Could you remove my diff from your PR?

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

* Author: bughit (bug hit)
* Status: Assigned
* 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/

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

[jeremyevans0 (Jeremy Evans)]

Issue #11256 has been updated by jeremyevans0 (Jeremy Evans).


mame (Yusuke Endoh) wrote in #note-16:
> @matz accepted this, but said that the formal argument must explicitly receive a anonymous block parameter, i.e.
> 
> ```
> def foo(&) = bar(&) # OK
> def foo = bar(&)    # NG
> ```
> 
> In the future, matz wants to make it more explicit whether a method accepts a block or not.
> 
> @jeremyevans0 Could you remove my diff from your PR?

Sure, I updated the pull request.  This made the pull request much simpler: https://github.com/ruby/ruby/pull/5051

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

* Author: bughit (bug hit)
* Status: Assigned
* 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/

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

[bughit (bug hit)]

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


mame (Yusuke Endoh) wrote in #note-16:
> @matz accepted this, but said that the formal argument must explicitly receive a anonymous block parameter, i.e.
> 
> ```
> def foo(&) = bar(&) # OK
> def foo = bar(&)    # NG
> ```
> 
> In the future, matz wants to make it more explicit whether a method accepts a block or not.
> 

Where is the naked ampersand in def foo(&) described? 

Don't see it here: https://docs.ruby-lang.org/en/master/doc/syntax/methods_rdoc.html

Does it mean the block is required?

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?



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

* Author: bughit (bug hit)
* Status: Assigned
* 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/

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

[jeremyevans0 (Jeremy Evans)]

Issue #11256 has been updated by jeremyevans0 (Jeremy Evans).


bughit (bug hit) wrote in #note-18:
> mame (Yusuke Endoh) wrote in #note-16:
> > @matz accepted this, but said that the formal argument must explicitly receive a anonymous block parameter, i.e.
> > 
> > ```
> > def foo(&) = bar(&) # OK
> > def foo = bar(&)    # NG
> > ```
> > 
> > In the future, matz wants to make it more explicit whether a method accepts a block or not.
> > 
> 
> Where is the naked ampersand in def foo(&) described? 
> 
> Don't see it here: https://docs.ruby-lang.org/en/master/doc/syntax/methods_rdoc.html

This hasn't been committed yet, so you wouldn't see it on the website yet.  The pull request already includes updates to the documentation: https://github.com/ruby/ruby/pull/5051/files#diff-d2caf8d6be0d2ccf90ff06a49bd1b4e4738588b4d5332954d57640e6fce0fd88

> Does it mean the block is required?

No, just as `&block` doesn't mean the block is required.

> 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.`  I assume that means that we could see future changes in Ruby that better align with requiring `&` as a parameter, even if currently it seems reasonable that it would not be required.

In terms of gain currently, if `&` is required, the code to implement the feature is much simpler.  Ruby is already very complex internally.  If we can reduce the amount of complexity added, that is a good reason.

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

* Author: bughit (bug hit)
* Status: Assigned
* 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/

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

[bughit (bug hit)]

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/

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

[Eregon (Benoit Daloze)]

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


bughit (bug hit) wrote in #note-21:
> 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.

It's extremely useful documentation/reading help that the method accepts a block.
If people have to scan for `&` in the whole method to know if a method accepts a block, it's really annoying (a `yield` keyword is much easier to spot).
I strongly agree with matz on this, methods taking a block should be clear about it, including in the parameters.

> 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.

matz said no.
Please have some understanding that people implementing Ruby might know better about this and complexity.

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

* 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/

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

[bughit (bug hit)]

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


> I strongly agree with matz on this, methods taking a block should be clear about it, including in the parameters.

I never said I disagree. Requiring a naked `&` in the signature to signal "block allowed" and perhaps `&!` for `block required` would be better. But "block allowed" will break lots of code so I don't see it happening. So as long as "block allowed" is the default, forwarding should be possible. `...` forwards blocks with 0 indication that the method takes a block, should it be illegal without a naked `&` in the signature?

> Please have some understanding that people implementing Ruby might know better about this and complexity.

This is my feature request, so please don't tell me not to advocate for my vision.

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

* 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/

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

[mame (Yusuke Endoh)]

Issue #11256 has been updated by mame (Yusuke Endoh).


bughit (bug hit) wrote in #note-21:
> That only makes sense if `def foo` comes to mean the block is not allowed.

From what I understand, matz is for this. Passing a block to `def foo` might be prohibited in the future (I guess it is very far even if possible, though). If a method receives a block, it should have a `&block` parameter or `...` argument forwarding. For the compatibility, a method whose body has `yield` or `super` keywords might be also allowed.

Actually @ko1 tried it in #15554. He withdrew the proposal because he have discovered a code pattern that makes false positives inevitable, but if matz accepts the incompatibility, the proposal might be a good first step.

Matz said he will create a ticket to discuss it, so please wait for him about the details.

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

* 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/