[ruby-core:95060] [Ruby master Bug#16178] Numbered parameters: _1 should be the same as |x| and _0 should not exist

[zverok.offline@gmail.com]

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


Some counter-points (that being said, I dislike the "unnamed parameters" idea as a whole, because I am afraid this feature -- being just "shorter" while staying imperative -- will stay in the way of adoption of more promising features like `&obj.:method`, experiments towards proper currying etc.):

**First**
> `|x,|` is almost never used in Ruby, and for good reasons

Honestly, we use it pretty frequently in our codebase and find it appealing. It is the shortest and pretty clear (YMMV, of course) way of processing only first elemente of "tuple-alike" arrays, like zips of data or data with indexes. Like, "find indexes of paragraphs matching some criteria":

```ruby
paragraphs.each_with_index.select { |para,| para.match?(....) ].map(&:last)
```

Of course, here we can dive into bike-shedding about "real Jedi will write `{ |para, _idx|`, because it is easier to ....", but I believe "some people use it" is enough counter-argument to "nobody uses it" :)

**Second**, we have "0 is whole, 1 is first match, etc." conditions in other places of Ruby—string matching:
```ruby
m = "Serhii Zhadan".match(/^(.+?) (.+?)$/)
# => #<MatchData "Serhii Zhadan" 1:"Serhii" 2:"Zhadan">
m[0]
# => "Serhii Zhadan"
m[1]
# => "Serhii" 
```

**Third**, I believe that in most of real, non-artificial situations, processing of sequence of heterogenous (some unpackable, some not) values with "shortcut blocks args" is a situation to either avoid, or being aware of your data nature. And with homogenous data, the problem is non-existent, while benefits are pretty obvious:

```ruby
<<-GRADES
John:4
Mary:5
Paul:3
Vasily:2
GRADES
  .lines(chomp: true)
  .map { _0.split(':') }
  .to_h { [_1, _2.to_i] }
```
In your proposal, the last line should be, like
```ruby
to_h { [_1[0], _1[1].to_i] } 
# or, OK, give up with them
to_h { |n, g| [n, g.to_i] }
```
I believe examples like mine, like "quick-and-somewhat dirty" experiments is exactly the target code to be simplified by the numbered parameters,

**UPD:** OK, the last point is answered while I've writing this :)

----------------------------------------
Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not exist
https://bugs.ruby-lang.org/issues/16178#change-81693

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: 
* ruby -v: ruby 2.7.0dev (2019-09-24T12:57:54Z master 0e84eecc17) [x86_64-linux]
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN
----------------------------------------
Currently on trunk:
```ruby
array = ["string", 42, [1, 2]]

array.map { |x| x * 2 }
# => ["stringstring", 84, [1, 2, 1, 2]]

array.map { _1 * 2 }
# => ["stringstring", 84, 2]
```

Oops, this trivial code just lost data and completely ignored the element class!
This is clearly contrary to intuition and is very dangerous.

Using `_0` instead has the correct behavior but it's clear we use 1-based indexing for numbered parameters,
and it doesn't solve that `_1` has dangerous behavior.

Basically the current behavior is that `_0` is the same as `|x|` and `_1` is the same as `|x,|`.
`|x,|` is almost never used in Ruby, and for good reasons, it just throws away data/information/the class of the object.
Such a dangerous operation should only be done when it's explicit, and the trailing comma in `|x,|` shows that, but `_1` does not.

So let's make `_1` be `|x|` and remove `_0`.

I am going to be harsh, but this discussion has gone too long without any serious written argument for the current behavior:
I believe it's irrational and irresponsible to have `_1` be `|x,|`, it's just going to lead to nasty bugs.

Try to convince me otherwise.
If not, in one week I want to apply this change.

From the discussion in https://bugs.ruby-lang.org/issues/15723#note-127
and in https://bugs.ruby-lang.org/issues/15708

Some reactions to this behavior in https://twitter.com/eregontp/status/1115318993299083265



-- 
https://bugs.ruby-lang.org/