[ruby-core:92214] [Ruby trunk Misc#15723] Reconsider numbered parameters

[ruby-core@marc-andre.ca]

Issue #15723 has been updated by marcandre (Marc-Andre Lafortune).


sawa (Tsuyoshi Sawada) wrote:
> Marc, regarding `|x, |`, I see plenty of cases like `map(&:first)` (or `map(&:last)`). Probably taking care of these cases is more important than the explicit `|x, |` cases. If you are going to count, you better count these in. And if directly using an implicit block variable `@1` is more efficient than calling `first` (which probably is the case), then replacing `map(&:first)` with `map{@1}` would make sense.

Did you try to verify any your assertions before commenting?

1) `&:first` and `{ @1 }` are not always equivalent, where `{ @1 }` could fail to show an error in the code or data. The "gain" is very disputable.

2) I got 174 occurrences of `&:first`, which adds to a negligible 0.03% contribution and is 5x less frequent that `|x, |`

3) There is no noticeable speed difference between `map(&:first)` and `map{ @1 }`

> At the same time, this would also mean that, if we are going to have the `@1` notation, then there would be a desire to count the arguments from the end as well using a negative number `n` in order to replace `map(&:last)` with something like `map{@n}`. (Note that `n = -1` would not work here since that conflicts with the 1-origin numbering.)

I don't know if you are serious or are trolling. This thread is about showing that `@1`, `@2` are not really useful and potential source of confusion / errors. I feel that proposing instead to extend this notation for accessing arguments in reverse order is not appropriate.
 
> If we are to adopt named implicit block variables instead, then we might simply name these something like `first` and `last`, and perhaps `whole` for the `x` in `|x|`.

Again, it's not clear to me if you are seriously proposing to add a source of incompatibility for something that I showed to be of little use.

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

* Author: sos4nt (Stefan Schüßler)
* 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/