In general, I”Ēm OK with this change, but I think that there”Ēs a possible
scoping issue with these automatic variables that I”Ēm not sure thathas
been considered:

outer.each {
  puts @1
  @1.each {
    puts @1
  }
}

Elixir doesn”Ēt have this issue because you *can”Ēt* declare nested
declarations this way. But in Ruby, you would no longer have access to the
outer `@1`.

I”Ēm not sure what other languages similar to Ruby do.

-a

On Sun, Mar 31, 2019 at 5:35 AM <zverok.offline / gmail.com> wrote:

> Issue #15723 has been updated by zverok (Victor Shepelev).
>
>
> (my small branch in this burning fire)
>
> For me the biggest problem with the new feature is not the particular
> syntax, but the simple fact that the feature (as far as I can understand)
> is "orphan", just kinda "nice (or not-that-nice, depends on personal
> preference) thing to have, why not".
>
> I'd argue that intuitive inclining to "don't repeat variable name in
> simple blocks" is a good and Rubyish thing, but the solution with "hack"
> (just throwing some syntax on top) leads us nowhere. `@1`/`@2` doesn't
> provide new concepts that can be reused in different contexts; it doesn't
> give a push to rethink how to structure code; it doesn't like any other
> feature and absolutely unrelated to them (or rather confusingly similar to
> instance variables -- without trying to conceptualize it, like, for
> example, saying "OK, let's say `Proc` instance has internal instance
> variables named `@<num>`, and ...").
>
> Counter-example of "good feature" in 2.7 (even if some dislike the syntax)
> is `&obj.:method` thing. It targets the same audience ("I want my blocks
> DRYer"), and probably even will lose the competition if both will be
> released in 2.7 (because `map { File.read(@1) }` is kinda "easier to
> explain" than `map(&File.:read)`). But "method reference" feature leads to:
> * more functional and well-thought code -- designing library and
> application methods that are easier to use in such chains, without "5
> optional arguments";
> * movement towards first-class method objects, that are acceptable and
> usual to people to see stored in variables and collections, passed to other
> methods and so on;
> * keep people thinking on good design for real powerful currying (not the
> one we have now, which is too verbose and obscure to use), to, maybe, make
> their peace with something like
>
>   ```ruby
>   HTTP.get(url).body.then(&JSON.:parse.(symbolyze_names: true))
>   ```
>
> So, it is about overall shifting of idiomatics towards "functional" way,
> which could be argued about (whether it is good or bad thing), but at least
> it is **conscious shift of idiomatics**.
>
> Numbered parameters is "just semantic hack", it doesn't change anything
> conceptually, just challenges the parsers and makes syntax incompatible
> with previous versions in a hard way (which, again, is not necessary a bad
> thing, but definitely a bad thing for _just convenience_ feature).
>
> ----------------------------------------
> Misc #15723: Reconsider numbered parameters
> https://bugs.ruby-lang.org/issues/15723#change-77387
>
> * 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  Ican
> *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>
>


-- 
Austin Ziegler  halostatue / gmail.com  austin / halostatue.ca
http://www.halostatue.ca/  http://twitter.com/halostatue
(supressed text/html)
Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>