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

[chocolate@cpan.org]

Issue #15723 has been updated by chocolateboy (Chocolate Boy).


sawa (Tsuyoshi Sawada) wrote:

> This looks to me like splitting Ruby into two dialects and letting the programmer declare when using the non-default one. I think it would be a start of a nightmare in which Ruby has many dialects.

`it` doesn't require new syntax, so I don't see how it can be considered a dialect any more than "use strict" in JavaScript (which similarly changes the semantics of an existing keyword (`this`), amongst other things). Even if it did, it's had no such effect in Perl in the 13 years since it was [introduced](https://perldoc.perl.org/perl593delta.html#The-feature-pragma).

> `using` is already used for refinements, and here were are dealing with block arguments, which are unrelated. It would be confusing to use the same keyword with different meanings.

The behavior/feature is different but the mechanism is the same i.e. it instructs the parser/compiler/interpreter to make a scoped change in semantics that can't otherwise be implemented in userspace.

> Pragma is ugly and we want to get rid of it. I think that adding even another form of pragma would make the situation even worse.

I agree that magic strings are hacky and ugly and would be happy to see them phased out. But I don't see an issue with implementing compiler directives in a non-hacky way. While a keyword like `use` (Perl, JavaScript, Groovy) or `using` might be cleaner or more familiar, a dedicated syntax is customary and arguably clearer (as well as safer/more compatible), and the suggested syntax (which is used by [Crystal](https://crystal-lang.org/reference/syntax_and_semantics/attributes.html)) is consistent with annotations and directives in other languages such as [C#](https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/attributes/), [Java](https://docs.oracle.com/javase/tutorial/java/annotations/basics.html), [JavaScript](https://github.com/tc39/proposal-decorators), [Kotlin](https://kotlinlang.org/docs/reference/annotations.html), and [Rust](https://doc.rust-lang.org/rust-by-example/attribute.html).

As things currently stand, the only other alternatives to opting in (via a pragma) to Groovy/Kotlin's simple/standard `it` are a) introducing `it` globally, which could break some existing code or b) adding more controversial/compromised syntax which no-one is entirely happy with.

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

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

---Files--------------------------------
implicit-param.diff (20 KB)


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