ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: "matheusrich (Matheus Richard)" <noreply@ruby-lang.org>
To: ruby-core@ruby-lang.org
Subject: [ruby-core:110131] [Ruby master Feature#18980] Re-reconsider numbered parameters: `it` as a default block parameter
Date: Wed, 28 Sep 2022 15:58:51 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-99389.20220928155851.10073@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-18980.20220826103125.10073@ruby-lang.org

Issue #18980 has been updated by matheusrich (Matheus Richard).


> Now I'm almost giving it up because there are more people who dislike it than I expected.

I'm not sure how good the people here represent the whole community. My bet is most people don't even notice these feature requests unless they appear on something like RubyWeekly.

The fact that many here are maintainers of Ruby implementations also has a biased effect on new features, as they might represent a burden on them. I'm not saying this is a bad thing, I love the diversity of points of view that this brings! OTOH, it's fair that people that do take time to discuss things here have a bigger influence on the direction that Ruby follows.

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

* 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/

  parent reply	other threads:[~2022-09-28 15:58 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-26 10:31 [ruby-core:109707] [Ruby master Feature#18980] Re-reconsider numbered parameters: `it` as a default block parameter k0kubun (Takashi Kokubun)
2022-08-26 12:43 ` [ruby-core:109708] " Eregon (Benoit Daloze)
2022-08-26 14:41 ` [ruby-core:109710] " k0kubun (Takashi Kokubun)
2022-08-26 15:45 ` [ruby-core:109713] " Eregon (Benoit Daloze)
2022-08-26 15:48 ` [ruby-core:109714] " Eregon (Benoit Daloze)
2022-08-26 22:46 ` [ruby-core:109721] " k0kubun (Takashi Kokubun)
2022-08-26 23:32 ` [ruby-core:109722] " jeremyevans0 (Jeremy Evans)
2022-08-27  9:04 ` [ruby-core:109729] " hanazuki (Kasumi Hanazuki)
2022-08-28 16:42 ` [ruby-core:109747] " graywolf (Gray Wolf)
2022-08-28 20:42 ` [ruby-core:109748] " k0kubun (Takashi Kokubun)
2022-08-28 21:21 ` [ruby-core:109749] " baweaver (Brandon Weaver)
2022-08-28 21:35 ` [ruby-core:109750] " k0kubun (Takashi Kokubun)
2022-08-28 21:37 ` [ruby-core:109751] " jeremyevans0 (Jeremy Evans)
2022-08-29  8:05 ` [ruby-core:109753] " zverok (Victor Shepelev)
2022-08-29 11:03 ` [ruby-core:109760] " Eregon (Benoit Daloze)
2022-08-29 11:53 ` [ruby-core:109764] " zverok (Victor Shepelev)
2022-08-29 23:37 ` [ruby-core:109777] " k0kubun (Takashi Kokubun)
2022-08-30  7:07 ` [ruby-core:109782] " zverok (Victor Shepelev)
2022-08-30  8:25 ` [ruby-core:109785] " k0kubun (Takashi Kokubun)
2022-08-30 11:27 ` [ruby-core:109788] " zverok (Victor Shepelev)
2022-08-30 13:38 ` [ruby-core:109790] " ufuk (Ufuk Kayserilioglu)
2022-08-30 14:16 ` [ruby-core:109791] " zverok (Victor Shepelev)
2022-08-31 19:36 ` [ruby-core:109800] " Dan0042 (Daniel DeLorme)
2022-08-31 20:53 ` [ruby-core:109802] " austin (Austin Ziegler)
2022-08-31 22:04 ` [ruby-core:109804] " zverok (Victor Shepelev)
2022-08-31 22:38 ` [ruby-core:109805] " k0kubun (Takashi Kokubun)
2022-09-01  0:16 ` [ruby-core:109806] " byroot (Jean Boussier)
2022-09-01 12:23 ` [ruby-core:109810] " Dan0042 (Daniel DeLorme)
2022-09-01 13:13 ` [ruby-core:109811] " zverok (Victor Shepelev)
2022-09-01 13:57 ` [ruby-core:109812] " Dan0042 (Daniel DeLorme)
2022-09-28 15:47 ` [ruby-core:110130] " matheusrich (Matheus Richard)
2022-09-28 15:58 ` matheusrich (Matheus Richard) [this message]
2022-10-07 11:05 ` [ruby-core:110226] " adiel (Adiel Mittmann)
2022-12-01  6:41 ` [ruby-core:111109] " maedi (Maedi Prichard)
2022-12-02 22:43 ` [ruby-core:111166] " maedi (Maedi Prichard)
2022-12-03  0:21 ` [ruby-core:111168] " ufuk (Ufuk Kayserilioglu)
2022-12-03  7:33 ` [ruby-core:111171] " funny_falcon (Yura Sokolov)
2022-12-06  5:18 ` [ruby-core:111216] " maedi (Maedi Prichard)
2023-02-14 19:32 ` [ruby-core:112426] " rubyFeedback (robert heiler) via ruby-core
2023-12-07  7:08 ` [ruby-core:115629] " k0kubun (Takashi Kokubun) via ruby-core

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-99389.20220928155851.10073@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).