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

[dunrix29a@gmail.com]

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


jeremyevans0 (Jeremy Evans) wrote:
> I'm not sure what led you to this statement, as the feature does work with lambdas and methods:
> …

Hmm, not obvious from description in the accepted feature request. By recent 2.7.0-dev implementation I can confirm numbered params are also present in those constructs, however that makes things even more inconsistent and confusing.
It now makes lambdas arguments exclusively derived from occurrences of numbered params in their bodies, while it may be ok for procs with their non-strict arguments.

``` ruby
# lambda with(out?) how many arguments ?
lambda { "some multi-line string with #{@1} "\
         "argument and eventually, "\
         "some #{@22} another one."}.call(1)
# ArgumentError (wrong number of arguments (given 1, expected 22))

```

``` ruby

# not possible combine with safeguard explicit arguments
lambda {|x,y| "some multi-line string with #{@1} "\
              "some #{@22} another one."}
# SyntaxError ((irb):57: ordinary parameter is defined)
# ...ome multi line string with #{@1}" }
```

> define_method(:a){@1+@2}

Only this special way of method definition, when body is replaced with passed block/proc.
Not unified with normal method definition:

``` ruby
def a();@1+@2;end
# SyntaxError ((irb):63: numbered parameter outside block)
```

> I disagree.  This syntax can make simple blocks even simpler, and simple blocks are much more common than complex blocks.  Implicit block arguments do not have to support all complex cases to be useful.

I disagree. As already demonstrated, it makes code less obvious while saved typing is minuscule - only *single* character for one argument, *none* for two or more. Where numbered arguments can be scattered anywhere in block with jumbled order. Not mentioning less flexibility, like compound object deconstruction or splat-consuming.

> The syntax was explicitly chosen to be invalid in earlier versions of Ruby, to avoid backwards compatibility issues.  "Clashes with existing syntax" is either false if taken literally (as the syntax is invalid in previous versions of Ruby), or subjective if not taken literally (such as "it doesn't feel right because I am used to @ being only used for instance variables").

Huh, I've been speaking about brand new, completely reworked proposal ..


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

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