Issue #15723 has been updated by zverok (Victor Shepelev).


(my small branch in this burning fire)

For me the biggest problem with the new feature is not the particular syntax, but the simple fact that the feature (as far as I can understand) is "orphan", just kinda "nice (or not-that-nice, depends on personal preference) thing to have, why not".

I'd argue that intuitive inclining to "don't repeat variable name in simple blocks" is a good and Rubyish thing, but the solution with "hack" (just throwing some syntax on top) leads us nowhere. `@1`/`@2` doesn't provide new concepts that can be reused in different contexts; it doesn't give a push to rethink how to structure code; it doesn't like any other feature and absolutely unrelated to them (or rather confusingly similar to instance variables -- without trying to conceptualize it, like, for example, saying "OK, let's say `Proc` instance has internal instance variables named `@<num>`, and ...").

Counter-example of "good feature" in 2.7 (even if some dislike the syntax) is `&obj.:method` thing. It targets the same audience ("I want my blocks DRYer"), and probably even will lose the competition if both will be released in 2.7 (because `map { File.read(@1) }` is kinda "easier to explain" than `map(&File.:read)`). But "method reference" feature leads to:
* more functional and well-thought code -- designing library and application methods that are easier to use in such chains, without "5 optional arguments";
* movement towards first-class method objects, that are acceptable and usual to people to see stored in variables and collections, passed to other methods and so on;
* keep people thinking on good design for real powerful currying (not the one we have now, which is too verbose and obscure to use), to, maybe, make their peace with something like 

  ```ruby
  HTTP.get(url).body.then(&JSON.:parse.(symbolyze_names: true))
  ```

So, it is about overall shifting of idiomatics towards "functional" way, which could be argued about (whether it is good or bad thing), but at least it is **conscious shift of idiomatics**. 

Numbered parameters is "just semantic hack", it doesn't change anything conceptually, just challenges the parsers and makes syntax incompatible with previous versions in a hard way (which, again, is not necessary a bad thing, but definitely a bad thing for _just convenience_ feature).

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

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