[ruby-core:103360] [Ruby master Feature#17785] Allow named parameters to be keywords

[duerst@it.aoyama.ac.jp]

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


I think it's not a good idea to introduce special syntax such as `class_` just for the case where arguments are named with keywords. First, the number of keywords is very low, which means that the cases where using a keyword as an argument name makes sense is also very low. Second, there are keywords such as `if` and `else` that are of very doubtful use as variable names anyway. Third, using keywords as variable names inherently increases the cognitive load on the reader and is a source for confusion.

Also, the special meaning of the trailing underscore will be difficult to recognize and understand for most people because it will appear so rarely. And the `_` doesn't match well with the `:` in the argument list. And `_` also is already allowed, so at least in theory, there's a chance of compatibility problems.

And then there's good old `klass`, which did the job for decades. And for those who don't like `klass`, there's `class_`. What's the problem of using `class_` in the argument list if your plan is to use it in the body of the method anyway?

marcandre (Marc-Andre Lafortune) wrote in #note-3:
> Clearly, `class_` is much simpler and much faster than `binding.local_variable_get(:class)`...

What about finding something in between the two? E.g. even just introducing `variable_get` as an alias to `binding.local_variable_get` would make this easier to use. And if this really needs optimization, it could be done, too, but using a different argument name would solve the problem.

With respect to `\`, it reminds me of older languages (such as m4, C, and TeX) where there's a purely string-based level below (or before) the usual structured syntax. Do we want Ruby to descend to that level? Escaping exists inside strings because you don't want the range of data you can handle with a programming language to be restricted by the syntax of the language itself. Also, escaping inside strings is frequent enough for everybody, and occurs in a very similar form across a wide range of programming languages, so that every programmer knows it. Backslashes in front of keywords would be a whole different matter.

There are programming languages where there are no reserved keywords. The one I know and have used is PL/1. If not having any keywords would have been a design goal of Ruby, I'm sure Matz would have found a way to get there. But it wasn't, and I guess it isn't. And as far as I understand, this proposal doesn't get us there.

In conclusion, I think this issue chases a phantom. The trade-off (rarely used obscure syntax to solve a rarely occurring pseudo-problem) is not good. It would introduce some very rarely used edge-case syntax, and wouldn't really make the language any better.

If there are no more urgent kinds of improvements to Ruby syntax that this one, then we know Ruby is in a pretty good place!

----------------------------------------
Feature #17785: Allow named parameters to be keywords
https://bugs.ruby-lang.org/issues/17785#change-91451

* Author: marcandre (Marc-Andre Lafortune)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
----------------------------------------
We should allow named parameters to be keywords and use add a trailing `_` to the corresponding variable:

```ruby
def check(arg, class:)
  arg.is_a?(class_)
end

check(42, class: Integer) # => true
```

Currently, if we want such an API we have to use `**rest`:

```ruby
def check(arg, **rest)
  class_ = rest.fetch(:class) { raise ArgumentError('missing keyword: :class')}
  if rest.size > 1
    unknown = rest.keys - [:class]
    raise ArgumentError("unknown keyword(s): :#{unknown.join(', :')})
  end

  arg.is_a?(class_)
end
```

This is very verbose, much less convenient, much less readable, prevents `steep` from generating the proper signature, etc.

We should do the same for pattern match.



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