[#97652] [Ruby master Feature#16746] Endless method definition — mame@...

Issue #16746 has been reported by mame (Yusuke Endoh).

24 messages 2020/04/01

[#97655] [Ruby master Misc#16747] Repository reorganization request — shyouhei@...

Issue #16747 has been reported by shyouhei (Shyouhei Urabe).

12 messages 2020/04/01

[#97745] [Ruby master Bug#16769] Struct.new(..., immutable: true) — takashikkbn@...

Issue #16769 has been reported by k0kubun (Takashi Kokubun).

10 messages 2020/04/08

[#97803] [Ruby master Misc#16775] DevelopersMeeting20200514Japan — mame@...

Issue #16775 has been reported by mame (Yusuke Endoh).

20 messages 2020/04/10

[#97810] [Ruby master Bug#16776] Regression in coverage library — deivid.rodriguez@...

Issue #16776 has been reported by deivid (David Rodr刕uez).

11 messages 2020/04/10

[#97828] [Ruby master Misc#16778] Should we stop vendoring default gems code? — deivid.rodriguez@...

Issue #16778 has been reported by deivid (David Rodr刕uez).

37 messages 2020/04/11

[#97878] [Ruby master Feature#16786] Light-weight scheduler for improved concurrency. — samuel@...

Issue #16786 has been reported by ioquatix (Samuel Williams).

72 messages 2020/04/14

[#97893] [Ruby master Bug#16787] [patch] allow Dir.home to work for non-login procs when $HOME not set — salewski@...

Issue #16787 has been reported by salewski (Alan Salewski).

18 messages 2020/04/15

[#97905] [Ruby master Feature#16791] Shortcuts for attributes of Process::Status — 0xfffffff0@...

Issue #16791 has been reported by 0x81000000 (/ /).

10 messages 2020/04/16

[#97907] [Ruby master Bug#16792] Make Mutex held per Fiber instead of per Thread — eregontp@...

Issue #16792 has been reported by Eregon (Benoit Daloze).

9 messages 2020/04/16

[#97989] [Ruby master Misc#16802] Prefer use of RHS assigment in documentation — samuel@...

Issue #16802 has been reported by ioquatix (Samuel Williams).

10 messages 2020/04/21

[#97992] [Ruby master Misc#16803] Discussion: those internal macros reside in public API headers — shyouhei@...

Issue #16803 has been reported by shyouhei (Shyouhei Urabe).

14 messages 2020/04/21

[#98026] [Ruby master Bug#16809] ruby testsuite fails on s390x alpine (musl) with --with-coroutine=copy — ncopa@...

Issue #16809 has been reported by ncopa (Natanael Copa).

11 messages 2020/04/23

[#98034] [Ruby master Feature#16812] Allow slicing arrays with ArithmeticSequence — zverok.offline@...

Issue #16812 has been reported by zverok (Victor Shepelev).

12 messages 2020/04/23

[#98044] [Ruby master Bug#16814] Segmentation fault in GC while running test/ruby/test_fiber.rb on s390x — Rei.Odaira@...

Issue #16814 has been reported by ReiOdaira (Rei Odaira).

14 messages 2020/04/24

[#98059] [Ruby master Bug#16816] Prematurely terminated Enumerator should stay terminated — headius@...

Issue #16816 has been reported by headius (Charles Nutter).

9 messages 2020/04/24

[#98066] [Ruby master Feature#16818] Rename `Range#%` to `Range#/` — sawadatsuyoshi@...

Issue #16818 has been reported by sawa (Tsuyoshi Sawada).

11 messages 2020/04/26

[ruby-core:97863] [Ruby master Feature#15897] `it` as a default block parameter

From: jonathan@...
Date: 2020-04-13 03:31:34 UTC
List: ruby-core #97863
Issue #15897 has been updated by joallard (Jonathan Allard).


jeremyevans0 (Jeremy Evans) wrote in #note-39:

> I'm going to close this feature since numbered block parameters were introduced to address it.

Noted. But I think there might have been some confusion.

In my opinion, the spirit of this ticket was to adopt `it` as a syntax rather than solve the underlying function with any combination of non-word symbols (eg. _1, @1, or $_0, _[0], ...) It seems to me like there's a fair amount of agreement about it.

Having slept on it for a few months now (pun intended) and as a daily user of Ruby for soon 10 years –  and seeing it's in usage in other language –, I can say that adopting the keyword `it` is still relevant and a good idea to me.

If I may argue on the substance just a bit more, I see the very essence of Ruby in `it`. Not in `_1`, unfortunately. Just like I see Ruby in `array.first` rather than `array[0]`. I am reminded of Ruby's readability-before-purity philsophy and "Write the code you wish you could".

Moreover, the one-arg block (`obj.method{ |one| one... }`) pattern is, in my experience, used quite frequently. `it` could make that both shorter and more expressive. That is why I find importance in this proposal.

When I asked whether there was anything needed to move forward, that's what it was about. The `_1` syntax does not address the needs for a natural, expressive, terse block param syntax.

Of course, seeing the current resolution, I'm not having unrealistic expectations, but I just wanted to be clear with what the proposal was for and make the case.

If the right way is to open another ticket or there's another way forward, I'm happy to walk the walk or help.


----------------------------------------
Feature #15897: `it` as a default block parameter
https://bugs.ruby-lang.org/issues/15897#change-85088

* Author: mame (Yusuke Endoh)
* Status: Closed
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
----------------------------------------
How about considering "it" as a keyword for the block parameter only if it is the form of a local varaible reference and if there is no variable named "it"?

```
[1, 2, 3].map { it.to_s } #=> ["1", "2", "3"]
```

If you are familiar with Ruby's parser, this explanation is more useful: NODE_VCALL to "it" is considered as a keyword.

Examples:

```
public def it(x = "X")
  x
end

[1, 2, 3].map { it.to_s }    #=> ["1", "2", "3"]
[1, 2, 3].map { self.it }    #=> ["X", "X", "X"] # a method call because of a receiver
[1, 2, 3].map { it() }       #=> ["X", "X", "X"] # a method call because of parentheses
[1, 2, 3].map { it "Y" }     #=> ["Y", "Y", "Y"] # a method call because of an argument
[1, 2, 3].map { it="Y"; it } #=> ["Y", "Y", "Y"] # there is a variable named "it" in this scope

it = "Z"
[1, 2, 3].map { it.to_s }    #=> ["Z", "Z", "Z"] # there is a variable named "it" in this scope
```

Pros:
* it is the best word for the feature (according to @matsuda)
* it is reasonably compatible; RSpec won't break because their "it" requires an argument

Cons:
* it actually brings incompatibility in some cases
* it is somewhat fragile; "it" may refer a wrong variable
* it makes the language semantics dirty

Fortunately, it is easy to fix the incompatible programs: just replace `it` with `it()`.  (Off topic: it is similar to `super()`.)
Just inserting an assignment to a variable "it" may affect another code.  This is a bad news, but, IMO, a variable named "it" is not so often used.  If this proposal is accepted, I guess people will gradually avoid the variable name "it" (like "p").
The dirtiness is the most serious problem for me.  Thus, I don't like my own proposal so much, honestly.  But it would be much better than Perlish `@1`.  (Note: I don't propose the removal of `@1` in this ticket.  It is another topic.)  In any way, I'd like to hear your opinions.


An experimental patch is attached.  The idea is inspired by @jeremyevans0's [proposal of `@`](https://bugs.ruby-lang.org/issues/15723#note-98).


P.S. It would be easy to use `_` instead of `it`.  I'm unsure which is preferable.

---Files--------------------------------
its.patch (4.92 KB)
mame_its_proposal.patch (5.26 KB)


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

In This Thread

Prev Next