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

[shevegen@gmail.com]

Issue #15723 has been updated by shevegen (Robert A. Heiler).


> I vote for 3 (and hashrockets ;))

I'd add a fourth variant - that is to use both explicit names and
@1 @2 @3. :)

But to keep my comment somewhat short - since hashrockets was mentioned, even with a
twinkling smiley, I initially did not like hashrockets, and I think => is also visually
nicer, I slightly changed my mind over time and am fine with the foo: :bar variant. I
use it a lot, too.

THe primry reason as to why I like foo: :bar is indeed that you can write less code.
Which is quite nice if you really have a lengthy Hash.

For similar reasons I like:

    %w( foo bar bla )

I find it much easier to write than:

    ['foo','bar','bla']

Even if the latter variant may be less confusing to a newcomer. But the first variant
is so much nicer to type - I can omit all these various ','. Similar for @1 @2 at the
least for debugging. I don't think I would use @1 @2 in production code per se, but 
am I the only one who sometimes forgets what is stored in a hash or a similar object
that uses .each?

There has been another suggestion where we would be allowed to  omit ',' in ... Hash
definitions, I think, like:

    x = {
      'foo' => 'bar'
      'bla' => 'ble'
    }

Or something like this. I forgot whether this can be done or not and matz' opinion
on it, but if we ignore this, then I think it's not bad if we were able to omit ','
in code constructs such as that.

Similar reasoning can be applied to @1 @2 too, by the way. It's not as if people
are suddenly forced to have to use it. But it would be an additional option, similar
to the addition of the safe navigation operator. Before the addition of the safe
navigation, it was not easily possible, in a succinct way, to query/check for
operations that may fail.

I used to bring this example before:

https://github.com/ruby/ruby/commit/91fc0a91037c08d56a43e852318982c9035e1c99

Old code:

    f.close if f && !f.closed?

New code:

    f&.close

The first variant, in my opinion, is simpler to understand (to me at the least); but
the second variant is significantly shorter, I think we all have to concede this.
And the second aspect to not forget is, syntax preferences aside, is that it added
something that was not doable/possible in the same way before.

I completely understand that syntax matters and that syntax is very, very important,
but it should not be the sole reason for evaluation, in particular if other changes
have had a similar pattern before - be it hashrockets or any other changes. There
will be always some folks who will dislike any change; I do so too. :) But it really
should not be the sole focus as such, since we can say the same about ANY change in
regards to syntax. Of course there should be reasons for changes, but folks who 
dislike syntax may often dislike any reason given in favour of a syntax change
too, so ... ;)

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

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