Issue #15723 has been updated by ted (Ted Johansson).


What strikes me is that this feature attempts to solve a problem that is very limited in scope:

- Blocks where the arguments can't be given a meaningful name arguably become more noisy than they may need to.

with a very big hammer:

- Every single block now has access to unnamed variables, which also increase the footprint of the Ruby syntax.

The magnitude of the change doesn't seem to yield proportional value.

Off the top of my head, I can imagine a solution that instead gives the flexibility to yield with injected, block-scope variables. This could:

1. Be implemented as a new method (e.g. `yield_with`, for backwards compatibility.
2. Be overridden by using the normal block parameter syntax, for backwards compatibility.
3. Work like regular local variables, letting them be overridden, for backwards compatibility.

**Example:**

``` ruby
# Definition

def foo
  yield_with a: 1, b: 2
end

# Usage

foo { a + b }
#=> 3

foo { |c, d| c + d }
#=> 3

foo do
  a = 3
  a + b
end
#=> 5
```

This would allow people to introduce magical, semantic variables at their own discretion.

It doesn't require any new syntax, and the standard library could choose to adopt this partially or fully, at any rate, perhaps even reinforcing existing idioms:

```ruby
[1, 2, 3].map { itself * 2 }
#=> [2, 4, 6]
```

Now. I just came up with this as I was reading through the thread, so I haven't had time to contemplate any of the potential pitfalls, but the point was to highlight that there might be solutions that are more proportional to the problem being solved.

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

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