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

[merch-redmine@jeremyevans.net]

Issue #15723 has been updated by jeremyevans0 (Jeremy Evans).


pascalbetz (Pascal Betz) wrote:
> Aren't there any other symbols we can use? paragraph, backtick, caret, (double-)dagger, ...?

We should not add any sigils that are non-ASCII.  That removes paragraph, dagger, double-dagger.

`^` (caret) would not be backwards compatible as it is already a binary operator:

```ruby
proc{a.foo ^1} # already means `a.foo.^(1)`
```

backtick is also not backwards compatible:

```ruby
foo = Object.new
def foo.`(x) x end
proc{foo. `1}
```

bozhidar (Bozhidar Batsov) wrote:
> Btw, isn't it possible to just add `$it` and make it a hash if there's more than one param to a block? E.g. `$it[1] * $it[2]`. (or something along those lines)

`$it` can already be defined, so this is not backwards compatible.

In terms of using a hash/array instead of separate arguments, we should try to avoid introducing shortcuts that make code slower by forcing object allocations.

maedi (Maedi Prichard) wrote:
> Why not a single dot? (`.`) It mirrors the UNIX concept of "current directory":
> ```
> [1, 2, 3].each { puts . }
> ```
> With a method/property:
> ```
> posts.each { ..author = 'Santa Clause' }
> ```

Thing about parsing the following code:

```ruby
posts.each { foo.to_i ..num }
```

Currently, this is a range, and if `.` was used as a reference to the current object, it would become ambigious as then it could mean `foo.to_i(..num)`. 

As stated earlier, we need to have a syntax that can handle multiple block arguments, and `.1` causes problems with ranges (e.g. is `foo...1` the same as `(foo)..(.1)` or `(foo)...(1)`?) and would not be backwards compatible.





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

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