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

[dunrix29a@gmail.com]

Issue #15723 has been updated by dunrix (Damon Unrix).


Hi.

I'm aware this issue is just a tip of an iceberg and Matz has the final say,however I'm worried the project is slipping from its original path. I mean, how easily it gives green-light to half-assed proposals, how there is considered only one side of the coin.

Is there still actually valued simplicity, readability and consistency of the language ? Approach the problem in a generic way, without creating superfluous yet-another exceptions to the basic rules ? Are these systemic virtues just relics of the past ?

Getting back to the topic, I'd give a few reasons why the accepted idea of implicit block arguments is intrinsically bad:
* cost of introduced loss in readibility and obviousness overweights benefits of no need for explicit arguments
* creates another gap at unifying blocks/procs/lambdas with methods
* creates inconsistency in system of identifiers - symbol `@` referencing instance/class variables of the class loses its reliability
* IDEs, code editors and validity parsers, would need add another condition - special case for `@` followed by digits only
* has limited use, only for very simple cases of one or two arguments passed, and only for a subset of obvious unambiguous calls. Imagine indirect calls/yields to a stored Proc and resulting need of detective work figure out what is actually passed, when explicit and proper named arguments would help greatly.

I'd expect development of Ruby language will bring more clean with stabilized API, make MRI faster while holding to sane memory footprint. Instead one have to contend with increased complexity without any visible benefits. Just sharing similar sentiment with my co-workers..


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

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