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


FWIW, I'm still quite negative on this, especially for metaprogramming methods like `respond_to?`/`methods`/etc, which are or might be affected by refinements, and so need caller information and might actually be executed in the caller.
Having to deal with keyword arguments + caller information/execute in the caller seems really messy implementation-wise.
At least I know it is for TruffleRuby and I suspect it is for CRuby as well.

----------------------------------------
Feature #17938: Keyword alternative for boolean positional arguments
https://bugs.ruby-lang.org/issues/17938#change-92787

* Author: matheusrich (Matheus Richard)
* Status: Open
* Priority: Normal
----------------------------------------
Some Ruby methods accept optional boolean arguments. This kind of parameter is known to be confusing since you cannot tell just looking at the method call what the parameter mean. For example:

```ruby
object.respond_to?(:symbol, false) # what does `false` mean?
object.methods(true) # what does `true` mean?
```

Now compare that to

```ruby
object.respond_to?(:symbol, include_all: false)
object.methods(regular: true)
# or
object.methods(only_public: true)
# or
object.methods(include_all: false)
```

I know Matz doesn't like breaking changes, so maybe we could have both to not break current calls, but allow a nicer syntax in newer Ruby? I don't know the depths of the Ruby C implementation, so here's what I thought in plain Ruby:

```ruby
def respond_to?(symbol, include_all_positional=false, include_all: nil)
  include_all ||= include_all_positional

  # ...
end
```

I'm willing to tackle this, if approved.

---Files--------------------------------
Screenshot from 2021-06-06 11-37-44.png (5.63 KB)


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

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