Issue #17785 has been updated by duerst (Martin D=FCrst).


I think it's not a good idea to introduce special syntax such as `class_` j=
ust 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 keyword=
s such as `if` and `else` that are of very doubtful use as variable names a=
nyway. Third, using keywords as variable names inherently increases the cog=
nitive load on the reader and is a source for confusion.

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

And then there's good old `klass`, which did the job for decades. And for t=
hose 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_var=
iable_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, to=
o, but using a different argument name would solve the problem.

With respect to `\`, it reminds me of older languages (such as m4, C, and T=
eX) where there's a purely string-based level below (or before) the usual s=
tructured 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 wit=
h a programming language to be restricted by the syntax of the language its=
elf. Also, escaping inside strings is frequent enough for everybody, and oc=
curs in a very similar form across a wide range of programming languages, s=
o 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 o=
ne 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 propo=
sal doesn't get us there.

In conclusion, I think this issue chases a phantom. The trade-off (rarely u=
sed 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 re=
ally 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) # =3D> true
```

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

```ruby
def check(arg, **rest)
  class_ =3D rest.fetch(:class) { raise ArgumentError('missing keyword: :cl=
ass')}
  if rest.size > 1
    unknown =3D 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 `s=
teep` 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=3Dunsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>