From: eregontp@... Date: 2019-09-07T12:18:50+00:00 Subject: [ruby-core:94829] [Ruby master Misc#15723] Reconsider numbered parameters Issue #15723 has been updated by Eregon (Benoit Daloze). @matz Thank you for the decision, I agree _1 is more readable than @1. I'm a bit sad to hear that @marcandre's point about "it's only really useful for 1 unnamed argument" isn't used in this decision. What will be the semantics of _0 and _1? (relates to #15708) I am unsure from your comment and current trunk does not seem to implement _n yet. I'd guess from your comment that `_0` is `|a|` and `_1` is `|a,|` and `_2` is `|a,b|`? ```ruby ruby -e '[1,2,[3,4]].each { p _0 }' ruby -e '[1,2,[3,4]].each { p _1 }' ``` I believe both of them should always print `[3, 4]` for the 3rd element. And therefore I think only _1 would be needed (with the semantics of `|a|`), and there is no need for `_0`. Is there any use-case that would make sense for printing `3` and therefore losing data that way? I think there is no good enough reason to break that. I think >99% of Ruby users expect `map { _1 * 2 }` to be the same as `map { |e| e * 2 }`, and not have different semantics based on the Array's elements. IMHO, using `|a,|` is very rare in practice and it should always be explicit that elements are dropped (the trailing `,` indicates that). Having those semantics for `_0` or `_1` loses that aspect, and I think it hurts the feature by making it more complicated and dangerous to use. ---------------------------------------- Misc #15723: Reconsider numbered parameters https://bugs.ruby-lang.org/issues/15723#change-81450 * Author: sos4nt (Stefan Sch����ler) * Status: Feedback * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- 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. ---Files-------------------------------- implicit-param.diff (20 KB) -- https://bugs.ruby-lang.org/ Unsubscribe: