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


Don't you think it may be just the high time stop throwing yet-another of *half-baked hacks* and cease work on implementation & release of the #4475 feature, until other and more mature solution is found ?

It seems the whole concept of implicit block arguments need to be rethought carefully, if sustainability and relevance of the language is still taken seriously. I'd suggest start from anew under a new feature request, while requisite rules of good language design are taken into a consideration.

Existing solution for example breaks rule of the general approach, as it only works with (anonymous)blocks and procs, not with lambdas and methods which are strict in arguments. It only adds to fragmentation of the language.
Existing solution also breaks rule of the semantic consistency with introduction of contextually-dependent exception, when existence of implicit block variables is dependent on absence of explicitly stated arguments.

Implicit arguments should work universally, ie. also for lambdas and methods. It follows that they have to be independent on presence of explicitly stated arguments. In addition, it requires transparency for all kind of arguments - both positional and keyword, with or without default values.
Should not clash with existing syntax or scope/identifier naming or even break backwards compatibility.

I'd suggest start some deeper discussion in some other place, then fill a new feature request after main objectives will be already addressed.


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

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