[ruby-core:91566] [Ruby trunk Feature#15574] Prohibit to pass a block on super() implicitly

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


duerst (Martin D端rst) wrote:
> Until quite recently, using an explicit block parameter was (considered to be?) less efficient than an implicit block parameter.

I think this is a relevant point and might be part of the reason many codebases don't use an explicit block parameter to call `super()`.

sawa (Tsuyoshi Sawada) wrote:
> But we can explicitly pass `yield`, can't we?

That creates another block as overhead, if you mean `super(a, b) { yield }`, and that doesn't forward block arguments correctly, so it's not a solution.

In any case, I think before taking any final decision on this proposal we need to test multiple gems to estimate the compatibility impact.
Fixing stdlib for this change might also illustrate how much has to be fixed, although stdlib is very little Ruby code compared to all gems.

----------------------------------------
Feature #15574: Prohibit to pass a block on super() implicitly
https://bugs.ruby-lang.org/issues/15574#change-76829

* Author: ko1 (Koichi Sasada)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: 
----------------------------------------
As described in [Feature #15554], `super()` (not `super`) pass the given block.

```
class C
  def foo
    p block_given?
  end
end

class C1 < C
  def foo
    super   #=> true
    super() #=> true
  end
end

C1.new.foo{}
```

`super` (without parameters) passes all passed parameters so it is no surprise to pass given block. 

However, `super()` (with parameters. In this case, it passes 0 parameters) also pass given block implicitly.

I'm not sure who use this behavior, but I think it is simple to prohibit such implicit block passing.




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

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