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


bozhidar (Bozhidar Batsov) wrote:
> > I definitely prefer @1 over %1 for Ruby, because for me it 'rhymes' with @instance_var and @@class_var, as jeremyevans0 has explained.
> 
> That's why I dislike it so much. Block vars would ideally not look like class/instance vars. Apart from my preferences this will also impact some editors, which might have had custom font locking for something starting with `@` and now they have to update it to differentiate the two categories.

Is there a particular reason why block argument access shouldn't look like variable access (`@`), but instead should look like string/array creation or modulus (`%`)?  Other than looking like Clojure?  As I haven't done much programming in Clojure, using `%1` for block argument access and such looks quite weird to me.

In any case, as decuplet pointed out, I was wrong and `%` is not possible as a sigil due to backwards compatibility, as it is used for the modulus operator:

```ruby
proc{foo %1}
```

This currently means call the `foo` method, and call the `%` method on the result with the argument `1`.  If `%1` where added, it would become ambigious. 

> It's obviously up to Matz to decide how he wants to do things, but I think that controversial features might be rollbacked until they are researched better and ideally solved better.

I disagree.  To only accept uncontroversial features is the death knell for progress.  Design by committee is the last thing Ruby needs.

Now, if introducing syntax causes regressions, sure, back it out until the regressions are fixed.  However, that is not the case here.

> With the strong focus on backwards compatibility every time something gets accepted into the language we're basically stuck with it forever, so I think it makes sense to think long and hard about any language change.

I agree.  However, to imply that matz has not already done this before accepting the feature is a tad insulting (I think). matz took over a month from when the `@1` syntax was proposed before accepting it.

> I also feel there's a communication problem - as people outside the core team generally have no way to know what's being worked on it's hard for them to provide any feedback on shortlisted issues until they see some announcement that a few feature was added.

The proposal was posted as a note to an existing issue.  Provided you are notified about all notes posted to issues (and if you are interested in ruby-core development, you probably should be), you should have had over a month to provide feedback for matz to consider before he accepted the feature.

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

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