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


TL; DR: a keyword (e.g. `it`) could be used without breaking backwards-compatibility via a **pragma** e.g.:

```ruby
using 'it'

def test(url)
  http.get(url).then { JSON.parse(it) }
end
```

---

I don't mind `@1, @2` etc., given the constraints, and wouldn't mind Clojure's `%1, %2` etc. either if that were possible, but I have always preferred Groovy's (and now Kotlin's) `it`. Although it's not as flexible, it feels like "if you need more arguments, name them" is a reasonable tradeoff/affordance.

`it` has been proposed and ruled out on the grounds that it could break or conflict with existing code. This then leads to the search for other (syntactical) solutions, since backwards compatibility is required in this case, which inevitably leads to aesthetic concerns and compromises.

However, it *is* possible to introduce `it`  without breaking any existing code  by using a [pragma](https://en.wikipedia.org/wiki/Directive_(programming)) i.e. by signalling to the parser/compiler that a new syntax/semantic is in effect in the current scope. Perl has safely [introduced features](https://perldoc.perl.org/feature.html) in this way for years, and JavaScript has the same facility, although, for [historical reasons](http://2ality.com/2014/12/one-javascript.html), it doesn't use it as much.

Of course, Ruby already supports pragmas by overloading comments e.g.:

```ruby
# frozen_string_literal: true
```

That could be used here as well e.g.:

```ruby
# use_default_topic: true

def test(url)
  http.get(url).then { JSON.parse(it) }
end
```

\- but I personally find magic comments [hacky/ugly](https://news.ycombinator.com/item?id=9522973) and would prefer pragmas to be available in a cleaner, more explicit, and possibly (down the line) more extensible way. One option could be to overload `using` e.g.:

```ruby
using 'it'

def test(url)
  http.get(url).then { JSON.parse(it) }
end
```

By restricting this usage to the top-level and requiring a string literal (or a fixed set of bareword feature names), this could be detected at parse/compile time in the same way as a magic comment. Calling `using` with a string currently raises a runtime error, so it wouldn't conflict with any working code, though it might (in theory) require a few tests that are expected to fail to be updated (i.e. an impact similar to changing the wording of an internal error message).

Either way, pragmas are already supported by Ruby and IMO this is a natural use case for them which delivers the best of both worlds: a clean and familiar syntax which maintains backwards compatibility.

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

* Author: sos4nt (Stefan Schler)
* 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/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>