[ruby-core:112426] [Ruby master Feature#18980] Re-reconsider numbered parameters: `it` as a default block parameter

Issue #18980 has been updated by rubyFeedback (robert heiler).


If I recall correctly I suggested @1 @2 and so forth.

At a later time _1 _2 and so forth was added, which is not entirely the same. I
then realised that the suggestion was actually much older than my suggestion,
and the ruby core team often said they may build upon suggestions and modify
it.

What surprised me was that one of my use case was not implemented, at the least
back then.

Which was:

    @large_collection_as_an_array.each {|cats_with_a_fluffy_tail, dogs_with_cute_ears, ships_with_red_painting, cars_without_a_door|
    }

For such a situation, in particular in IRB as well as in quick debugging, I wanted to
be able to refer to the element at hand quickly, without having to remember the name
as such.

So I could then do:

    pp @1
    pp @3

And so on.

Unfortunately it seems as if that was not considered, and it was (back then at
the least) made forbidden to assign proper (long) names to the block variables.
The syntax was also changed; I find _1 _2 a bit hard to read.

I should note that I remember the other proposal about "it". I don't have a strong
opinion against it. But I also don't feel particularly committed towards wanting
to use it. The whole point of @1 @2 was actually to help in prototyping, e. g. to
be faster when you write code initially. It's not a huge saving of time, admittedly
so, but it does help, and I think in particular for IRB it can really be helpful
(I'd wish we could still use _1 _2 and so forth together with real names of the
variables; my use case was that I am fine with the initial block names, and I
would keep them, but in the middle of writing more code, I just want to refer
to the variable without necessarily always needing to remember the name. I have
to scroll back with my crappy editor.)

maedi wrote:

> I see that $. is already a pre-defined variable which would
> make $.method_name difficult to parse.

All $-variables are quite hard to remember. With @1 or _1 this is 
a bit different because, like in a regex, you just refer to some
specific group by number rather than a name. (Or just syntax, as is
the case with the various $: $< and what not.)

maedi wrote:

> Though I still like _@.

That one trips my brain up. I think we should be conservative about
syntax. Perlisms can be useful due to begin succinct, but readability
is also a useful metric to have.

What surprised me the most is that people began to include _1 _2 and
so forth in real production code. To me it is purely a method of 
testing and debugging aid; but I guess the moment you add functionality
someone is going to use it, and a few of these change their style
to include these.

maedi wrote:

> Another thing you could do which is very Ruby is provide a
> special block param that acts as an object and interact
> with that:

I have no real problem with "it", even though I most likely won't
use it. But we could use "it" also as reference object via 
[] method e. g. it[0], it[1] in addition to "normal" use of "it".

adiel wrote:

Over time I decided to always use a variable named x for such purposes: map.keys.select{|x| x =~ /foo/}.



----------------------------------------
Feature #18980: Re-reconsider numbered parameters: `it` as a default block parameter
https://bugs.ruby-lang.org/issues/18980#change-101874

* Author: k0kubun (Takashi Kokubun)
* Status: Open
* Priority: Normal
----------------------------------------
## Problem
Numbered parameters (`_1`, `_2`, ...) look like unused local variables and I don't feel motivated to use them, even though I need this feature very often and always come up with `_1`.

```rb
[1, 2, 3].each { puts _1 }
```

I have barely used it in the last 2~3 years because it looks like a compromised syntax. I even hesitate to use it on IRB.

### Why I don't use `_1`

I'm not clever enough to remember the order of parameters. Therefore, when a block has multiple parameters, I'd always want to name those parameters because which is `_1` or `_2` is not immediately obvious. Thus I would use this feature only when a block takes a single argument, which is actually pretty common. 

If I use `_1`, it feels like there might be a second argument, and you might waste time to think about `_2`, even if `_2` doesn't exist, which is a cognitive overhead. If you use `it`, it kinda implies there's only a single argument, so you don't need to spend time remembering whether `_2` exists or not. It is important for me that there's no number in `it`.

## Proposal
Hoping to introduce `it` as an alternative to `_1` later, experiment with warning `#it` method calls without any arguments or blocks.

If nobody sees serious problems after some warning period, we'll implement `it` as follows:

### Specification

```rb
[1, 2, 3].each { puts it }
```

`it`s behavior should be as close to `_1` as possible. `it` should treat array arguments in the same way as `_1`. `it` doesn't work in a block when an ordinary parameter is defined. `it` is implemented as a special case of `getlocal` insn, not a method. `it` without an argument is considered `_1` or a normal local variable if defined. `it` is considered a method call only when it has any positional/keyword/block arguments.

## Past discussions
* [Feature #4475] default variable name for parameter: Proposed `it`, and merged as `@1`.
  * 2019/03/13: [DevelopersMeeting20190311Japan](https://docs.google.com/document/d/e/2PACX-1vTUCmj7aUdnMAdunG0AZo0AdWK-9jvfXcB7DWYmzGtmPc0IuIPGn7eLARoR5tBd6XUUB08W-hH74k-T/pub)
  * 2019/04/17: [DevelopersMeeting20190417Japan](https://docs.google.com/document/d/1hw6Xca8arG6b0V63zvWnNEtxIjEjEVzS10KXGhzZpI8/pub)
  * 2019/04/20: [Ruby Committers vs the World](https://youtu.be/5eAXAUTtNYU?t=3118)
* [Feature #15723] Reconsider numbered parameters: Renamed `@1` to `_1`.
  * 2019/08/29: [DevelopersMeeting20190829Japan](https://docs.google.com/document/d/1XypDO1crRV9uNg1_ajxkljVdN8Vdyl5hnz462bDQw34/edit?usp=sharing)
* [Feature #15897] `it` as a default block parameter: Proposed `it`, and got closed because `_1` was merged.

### Compatibility

`it` has not necessarily been rejected by Matz; he just said [it's difficult to keep compatibility](https://bugs.ruby-lang.org/issues/4475#note-6) and [`it` or `this` _could_ break existing code](https://bugs.ruby-lang.org/issues/15723#note-2). It feels like everybody thinks `it` is the most beautiful option but is not sure if `it` breaks compatibility. But, in reality, does `it`?

The following cases have been discussed:

* `it` method, most famously in RSpec: You almost always pass a positional and/or block argument to RSpec's `it`, so the conflict is avoided with my proposal. You virtually never use a completely naked `it` ([comment](https://bugs.ruby-lang.org/issues/15897#note-29)).
* `it` local variable: With the specification in my proposal, the existing code can continue to work if we consider `it` as a local variable when defined.

With the specification in my proposal, existing code seems to break if and only if you call a method `#it` without an argument. But it seems pretty rare (reminder: a block given to an RSpec test case is also an argument). It almost feels like people are too afraid of compatibility problems that barely exist or have not really thought about options to address them.

Also, you could always experiment with just showing warnings, which doesn't break any compatibility. Even if it takes 2~3 years of a warning period, I'd be happy to use that in 3 years.

### Confusion
We should separately discuss incompatible cases and "works but confusing" cases. Potential confusion points:

* RSpec's `it "tests something" do ... end` vs `it` inside the `do ... end`
* `it` could be a local variable or `_1`, depending on the situation

My two cents: You'd rarely need to write `it` directly under RSpec's `it` block, and you would just name a block argument for that case. In a nested block under a test case, I don't think you'd feel `it` is RSpec's. When you use a local variable `it = 1`, you'd use the local variable in a very small scope or few lines because otherwise, it'd be very hard to figure out what the local variable has anyway. So you'd likely see the assignment `it = 1` near the use of the local variable and you could easily notice `it` is not `_1`. If not, such code would be confusing and fragile even without this feature. The same applies when `it` is a method/block argument.

I believe it wouldn't be as confusing as some people think, and you can always choose to not use `it` in places where `it` is confusing.



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- [e-mail]
 To unsubscribe send an email to [e-mail]
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/