From: psychoslave@... Date: 2019-04-04T09:35:31+00:00 Subject: [ruby-core:92147] [Ruby trunk Misc#15723] Reconsider numbered parameters Issue #15723 has been updated by psychoslave (mathieu lovato stumpf guntz). Thank you Jeremy for your detailed feedback. > Not backwards compatible as `by` could already be a local variable or method. One could just assume precedence of locally defined identifiers over keywords, but that is a whole other point. Personally I would be fine with a facility that would not make keywords locked reserved words, but won't argue for that here, and don't expect it to be a retained solution in this scope. One easy way to do that in a backward compatible way though is to disable it by default. If the goal is to provide a syntax convenient for quick and dirty read���eval���print loops while discourage its use in code bases, that would also seem a saner approach. > You cannot calculate arity with a syntax that uses a single variable for all arguments. If you mean that an array would not be the right structure to use, what about using a hash indexed with integer? (goodbye `by.first` of course) > Requires 5 characters minimum to access an implicit variable. Well, sure, but as far as I'm concerned readability largely outweighs the benefit of a few keystrokes > We should avoid adding syntax that requires allocating an array or any other object, as that is bad for performance. I agree that performance matter, but syntax definition is not implementation enforcement. On this regard, I personally feel that Ruby is not pushing its "everything is an object" far enough: `if.class` is not expected to work. Of course there are (understandable) conceptual simplicity and performance issues underlying this choice. But here too, this would not require the implementation to treat such a construct as it indeed treats user defined classes, just to provide an homogeneous behavior to the language user. > Any approach that used a single variable that was not a true object would be problematic. Well that achieves to convince me the suggestion is not that great, thank you. I'm not convinced with the current proposal either, that said. If there is one thought that I would think worth considering in my text above, it's to turn the feature off by default and let user enable it at their own discretion. ---------------------------------------- Misc #15723: Reconsider numbered parameters https://bugs.ruby-lang.org/issues/15723#change-77472 * 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: