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


As the person who suggested the `@1` syntax, I guess I should give my opinion.  

First, any approach that did not use a sigil (e.g. `this` or `it`) would probably break backwards compatibility, and that is not considered acceptable.  So the only acceptable approach would be something that uses a sigil.  In order to support more than 1 argument, the sigil would need to be numbered.  As this is being added to reduce verbosity, you probably want the sigil followed by the number representing the argument.

There are a limited number of sigils that are possible options:

`@`: Chosen syntax for block argument access, and `@` already associated with scoped (instance) variable access
`$`: Also associated with variable access, but unscoped (global), and `$1` and such already used for regular expression captures (`$#1` and such would be possible, but longer)
`\`: Associated with escaping in strings, not variable access
`%`: Associated with string/array creation (e.g. `%[a]`, `%w[a b]`) and modulus/formatting, not variable access
`:`: Associated with symbol creation, ternary operator, and method creation operator (`.:`), not variable access

I think most other sigils would not be backwards compatible as the syntax would be already valid (`~`) or would probably cause parsing issues if introduced (`/`). Any sigil that could be a unary or binary operator could break backwards compatibility if used.

As I said when proposing the syntax, I'm not convinced an implicit block argument syntax is a good idea.  However, if we are going to have an implicit block argument syntax, I think `@1`, `@2`, etc. is probably the best choice.

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

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