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

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

[ko1]

Issue #15574 has been reported by ko1 (Koichi Sasada).

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

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

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

[Webhostingonedollar102]

Issue #15574 has been updated by bican304 (josef bican).


I extremely like your article. I had numerous helpful things from this article. I truly value your endeavors "99 rs domain godaddy":https://www.webhostingonedollar.com/godaddy-rs-99-web-hosting-domain.html for compose this post. A debt of gratitude is in order for offering that enlightening post to us.

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

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

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

[Webhostingonedollar102]

Issue #15574 has been updated by bican304 (josef bican).


I extremely like your article. I had numerous helpful things from this article. I truly value your endeavors [99 rs domain godaddy](https://www.webhostingonedollar.com/godaddy-rs-99-web-hosting-domain.html) for compose this post. A debt of gratitude is in order for offering that enlightening post to us.

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

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

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

[eregontp]

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


I would think this is tricky for compatibility (there is definitely code relying on it), but let's see.

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

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

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

[ruby-core]

Issue #15574 has been updated by marcandre (Marc-Andre Lafortune).


I agree with Eregon that it would be a compatibility nightmare.

Moreover I rather like this quirk.

Is there an actual use case for thinking about removing it (besides it being quirky)?

I would bet that there are way more methods calling super with the block intact than the reverse. I will frequently prepend a method that intercepts a parameter, for example, deals with it and call `super` with the rest:

``` ruby
def foo(*args, **options, extra_opt: nil)
  puts "extra!" if extra_opt
  super(*args, **options)
end
```

 I don't recall passing a different (or no) block to `super`, but my memory isn't very good ;-)

In short, I'm against this proposal.

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

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

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

[ko1]

Issue #15574 has been updated by ko1 (Koichi Sasada).


marcandre (Marc-Andre Lafortune) wrote:
> Is there an actual use case for thinking about removing it (besides it being quirky)?

I assume this spec is because of historical reason. Block parameter is introduced ruby-1.1b9_01, but maybe Matz wanted to pass block to initialize method (it's my speculation).

Exceptional rule is difficult to learn, so if we have no reason to keep compatibility, I want to remove this exceptional rule.

> I would bet that there are way more methods calling super with the block intact than the reverse. I will frequently prepend a method that intercepts a parameter, for example, deals with it and call `super` with the rest:
> 
> ``` ruby
> def foo(*args, **options, extra_opt: nil)
>   puts "extra!" if extra_opt
>   super(*args, **options)
> end
> ```

I want to clarify this spec is desired or not.

Why don't you pass a block parameter explicitly?
Because you know the spec and intentional, or simply forget to pass it (and working it with this spec fortunately)?


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

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

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

[duerst]

Issue #15574 has been updated by duerst (Martin Dürst).


ko1 (Koichi Sasada) wrote:

> Why don't you pass a block parameter explicitly?
> Because you know the spec and intentional, or simply forget to pass it (and working it with this spec fortunately)?

Until quite recently, using an explicit block parameter was (considered to be?) less efficient than an implicit block parameter.

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

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

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

[sawadatsuyoshi]

Issue #15574 has been updated by sawa (Tsuyoshi Sawada).


duerst (Martin Dürst) wrote:
> ko1 (Koichi Sasada) wrote:
> 
> > Why don't you pass a block parameter explicitly?
> > Because you know the spec and intentional, or simply forget to pass it (and working it with this spec fortunately)?
> 
> Until quite recently, using an explicit block parameter was (considered to be?) less efficient than an implicit block parameter.

But we can explicitly pass `yield`, can't we?

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

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

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

[mail]

Issue #15574 has been updated by sos4nt (Stefan Schüßler).


I prefer the current behavior. Passing along a block is much more common than removing a block.

Let's say I have a class which yields `self` during initialization:

```ruby
class A
  def initialize(foo)
    # ...
    yield self if block_given?
  end
end
```

I can easily subclass the above and add an extra argument via:

```ruby
class B < A
  def initialize(foo, bar = nil)
    # ...
    super(foo)
  end
end
```

I don't even have to know whether `A` takes a block or not, Ruby takes care of it.

With the proposed change however, it becomes my responsibility. Almost every time I use `super(...)` I have to remember passing the block. The above code would become:

```ruby
class B < A
  def initialize(foo, bar = nil, &block)
    # ...
    super(foo, &block)
  end
end
```

Adding an explicit `&block` (and therefore creating a `Proc` object) for the sake of passing it along is something I'd like to avoid.

---

BTW, if you really have to remove all arguments including the block argument, it's merely:

```ruby
super(&nil)
```

That looks just fine to me.

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

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

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

[sawadatsuyoshi]

Issue #15574 has been updated by sawa (Tsuyoshi Sawada).


sos4nt (Stefan Schüßler) wrote:
> With the proposed change however, it becomes my responsibility. Almost every time I use `super(...)` I have to remember passing the block. The above code would become:
> 
> ```ruby
> class B < A
>   def initialize(foo, bar = nil, &block)
>     # ...
>     super(foo, &block)
>   end
> end
> ```

In such case, i.e., when you don't want to take the responsibility of managing the arguments and blocks, I think you should use `super`, not `super(foo, &block)`. Using `super()` is a way to explicitly take care of the arguments, and it is counter-intuitive and inconsistent to let only the block be passed automatically.

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

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

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

[mail]

Issue #15574 has been updated by sos4nt (Stefan Schüßler).


sawa (Tsuyoshi Sawada) wrote:
> In such case, i.e., when you don't want to take the responsibility of managing the arguments and blocks, I think you should use `super`, not `super(foo, &block)`

Calling `super` (without parentheses) would pass two arguments (`foo` and `bar`) to the super method which only takes one argument, resulting in an `ArgumentError`.

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

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

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

[sawadatsuyoshi]

Issue #15574 has been updated by sawa (Tsuyoshi Sawada).


sos4nt (Stefan Schüßler) wrote:
> Calling `super` (without parentheses) would pass two arguments (`foo` and `bar`) to the super method which only takes one argument, resulting in an `ArgumentError`.

In such case, you do need explicit control of which arguments to pass. And it is inconsistent that you want to take care of the arguments but not the block.


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

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

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

[eregontp]

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/

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

[mail]

Issue #15574 has been updated by sos4nt (Stefan Schüßler).


sawa (Tsuyoshi Sawada) wrote:
> [...] it is inconsistent that you want to take care of the arguments but not the block.

When overriding a method, I try to preserve its signature. Therefore, I usually use `super` and I sometimes use `super(...)` with *optional* arguments as shown above. But having to unset a block via `super(&nil)` happens once in a blue moon.

My point is: it might be inconsistent, but it is a good inconsistency. It does what you almost always want.

And since `super` is a *keyword*, I think it can get away with it.

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

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

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

[ko1]

Issue #15574 has been updated by ko1 (Koichi Sasada).

Status changed from Open to Rejected

it seems difficult to apply this proposal because of compatibility (and productivity). rejected.

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

* Author: ko1 (Koichi Sasada)
* Status: Rejected
* 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/