From: headius@... Date: 2019-04-12T19:11:37+00:00 Subject: [ruby-core:92259] [Ruby trunk Misc#15723] Reconsider numbered parameters Issue #15723 has been updated by headius (Charles Nutter). What about using `_1`, `_2`? These are value variable names that could be reserved for argument offsets. This would mimic some golfed block code like `{|_| ...}` (though I know there's some debate about whether `@1` should map to `|x|` or `|x,|`). There are pros: * It still looks like a local variable. * Things with leading underscores are often hidden or internal; in this case, these names would be hidden references to the passed-in arguments. * It will parse on older Ruby impls. And some cons: * Though it parses on older impls, it will parse as a method call. This is probably fine, though, since it will error using NameError as being a missing local *or* method. * It may conflict in some cases with Ruby code using `_###` variable names. However this new meaning is only valid within a block, and only within a block that has no arguments, plus since these are treated as normal local variables, doing `{_1 = 'foo'}` will not conflict in any way (user does not expect to receive vars, so arg list is irrelevant; _1 is a valid local var name, so it will still work correctly). ---------------------------------------- Misc #15723: Reconsider numbered parameters https://bugs.ruby-lang.org/issues/15723#change-77592 * 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. -- https://bugs.ruby-lang.org/ Unsubscribe: