Issue #15723 has been updated by DarkWiiPlayer (Dennis Fischer).


I fail to see how the downsides outweigh the problems. The @-syntax looks ugly, misleading and adds even more complexity to the language. The `\1`, `\2`, etc. syntax makes much more sense if you deal with regular expressions a lot, but otherwise just looks weird. Using some other random symbol doesn't make it any better at the end of the day.

My opinion: the best compromise would be to add a keyword like `that`; it instantly reminds of `this` and has a very similar meaning to it as well. `it` would be my second pick, for the same reason. For multiple argumets I really think people should just name them; or an alternative syntax could be used. *that seems like a good way to collect all the arguments into an array, but it's ambiguous with the * operator applied to the first argument as an array.

One other thing that could work is copy Luas vararg syntax and make it implicit: When no |<arglist>| is given, `...` becomes the first argumet. This would of course look very ugly when calling methods.

As a last idea, any otherwise used character could be chosen, with the rule that, in case of ambiguity, the older meaning always gets chosen, like with the example of using `.`, so to call and print the `foo` method, one would have to write `puts (.).foo`, otherwise Ruby would interpret it as a range.

Ultimately, I really think this feature should just be left out alltogether.

And, just for fun, I will end this on the worst possible idea: use the characters ,  and  (Superscript 1, 2 and 3). They are 1. not ascii, 2. incredibly hard to type and 3. small and hard to miss. A true compromise of all ideas, combining the worst of all and the best of all.

----------------------------------------
Misc #15723: Reconsider numbered parameters
https://bugs.ruby-lang.org/issues/15723#change-77435

* Author: sos4nt (Stefan Schler)
* Status: Feedback
* Priority: Normal
* Assignee: 
----------------------------------------
I just learned that *numbered parameters* have been merged into Ruby 2.7.0dev.

For readers not familiar with this feature: it allows you to reference block arguments solely by their *index*, e.g.

```ruby
[1, 2, 3].each { |i| puts i }

# can become

[1, 2, 3].each { puts @1 }
```

I have an issue with this new feature: I think **it encourages sloppy programming** and results in **hard to read code**.

---

The [original proposal](https://bugs.ruby-lang.org/issues/4475) was to include a special variable (or keyword) with a **readable name**, something like:

```ruby
[1, 2, 3].each { puts it }

# or

[1, 2, 3].each { puts this }
```

Granted, that looks quite lovely and it actually speaks to me  I can *understand* the code. And it fits Ruby: (quoting the website)

> [Ruby] has an elegant syntax that is natural to read and easy to write.

But the proposed `it` / `this` has limited application. It's only useful when dealing with a single argument. You can't have multiple `it`-s or `this`-es. That's why `@1`, `@2`, `@3` etc. were chosen instead.

However, limiting the usefulness to a single argument isn't bad at at. In fact, a single argument seem to be the limit of what makes sense:
```
h = Hash.new { |hash, key| hash[key] = "Go Fish: #{key}" }

# vs

h = Hash.new { @1[@2] = "Go Fish: #{@2}" }
```
Who wants to read the latter? That looks like an archaic bash program (no offense). We already discourage Perl style `$`-references: (from [The Ruby Style Guide](https://github.com/rubocop-hq/ruby-style-guide#no-perl-regexp-last-matchers))

> Don't use the cryptic Perl-legacy variables denoting last regexp group matches (`$1`, `$2`, etc). Use `Regexp.last_match(n)` instead.

I don't see how our code can benefit from adding `@1` and `@2`.

Naming a parameter isn't useless  it gives context. With more than one parameter, naming is crucial. And yes, naming is hard. But avoiding proper naming by using indices is the wrong way.

So please reconsider numbered parameters.

Use a readable named variable (or keyword) to refer to the first argument or ditch the feature entirely.



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