Issue #19979 has been updated by Eregon (Benoit Daloze).
This leads to subtle user errors, where the author of
some code assumes a method call uses a block, but the block passed to the method call is
silently ignored.
Is this a frequent error?
I think the only times I saw it is due to confusion of the priority of `do/end` vs `{/}`
(which needs to be learned separately anyway), and for some poorly-designed `open` methods
which don't take a block.
Note that this can already be done in a way that runs on older Rubies too with `raise
ArgumentError, 'this method does not accept a block' if block_given?`.
I think even if it was accepted it would be very unlikely for gems to use `&nil`,
first they would need to require Ruby 3.3+ and second it's extra noise in the source
code with almost no benefit for the gem.
So I think in practice this would not achieve much.
For methods which sound like they might take a block but don't, the `raise
ArgumentError, ...` above seems a good existing solution.
----------------------------------------
Feature #19979: Allow methods to declare that they don't accept a block via
`&nil`
https://bugs.ruby-lang.org/issues/19979#change-105113
* Author: ufuk (Ufuk Kayserilioglu)
* Status: Open
* Priority: Normal
----------------------------------------
## Abstract
This feature proposes new syntax to allow methods to explicitly declare that they
don't accept blocks, and makes passing of a block to such methods an error.
## Background
In #15554, it was proposed to automatically detect methods that do not use the block
passed to them, and to error if a block was passed to such methods. As far as I can tell,
it was later on closed since #10499 solved a large part of the problem.
That proposal has, as part of [a dev meeting
discussion](https://github.com/ruby/dev-meeting-log/blob/b4357853c03dfe71b6…,
a proposal from @matz to allow methods to use `&nil` to explicitly declare that they
don't accept a block. At the time, the proposal was trying to solve a bigger problem,
so this sub-proposal was never considered seriously. However, notes in the proposal say:
It is explicit, but it is tough to add this `&nil`
parameter declaration to all of methods (do you want to add it to `def []=(i, e,
&nil)`?). (I agree `&nil` is valuable on some situations)
This proposal extracts that sub-proposal to make this a new language feature.
## Proposal
In Ruby, it is always valid for the caller to pass a block to a method call, even if the
callee is not expecting a block to be passed. This leads to subtle user errors, where the
author of some code assumes a method call uses a block, but the block passed to the method
call is silently ignored.
The proposal is to introduce `&nil` at method declaration sites to mean "This
method does not accept a block". This is symmetric to the ability to pass `&nil`
at call sites to mean "I am not passing a block to this method call", which is
sometimes useful when making `super` calls (since blocks are always implicitly passed).
Explicitly, the proposal is to make the following behaviour be a part of Ruby:
```ruby
def find(item = nil, &nil)
# some implementation that doesn't call `yield` or `block_given?`
end
find { |i| i == 42 }
# => ArgumentError: passing block to the method `find' that does not accept a
block.
```
## Implementation
I assume the implementation would be a grammar change to make `&nil` valid at method
declaration sites, as well as raising an `ArgumentError` for methods that are called with
a block but are declared with `&nil`.
## Evaluation
Since I don't have an implementation, I can't make a proper evaluation of the
feature proposal. However, I would expect the language changes to be minimal with no
runtime costs for methods that don't use the `&nil` syntax.
## Discussion
This proposal has much smaller scope than #15554 so that the Ruby language can start
giving library authors the ability to explicitly mark their methods as not accepting a
block. This is fully backward compatible, since it is an opt-in behaviour and not an
opt-out one.
Future directions after this feature proposal could be a way to signal to the VM that any
method in a file that doesn't explicitly use `yield`/`block_given?` or explicitly
declared a block parameter should be treated as not accepting a block. This can be done
via some kind of pragma similar to `frozen_string_literal`, or through other means.
However, such future directions are beyond the scope of this proposal.
## Summary
Adding the ability for methods to declare that they don't accept a block will make
writing code against such methods safer and more resilient, and will prevent silently
ignored behaviour that is often hard to catch or troubleshoot.
--
https://bugs.ruby-lang.org/