[Trasmatta]

The default block parameter name seems small, but I feel like I'm gonna use it all the time, especially when I'm in the Rails console just trying to debug data

[lucasoshiro]

Kotlin also has it, I can tell you that it's really useful

[cempaka]

Ruby has had this in the same form as "_1" for a while (and the obvious other indexes in the case of multiple params), but I agree Kotlin's "it" reads much better.

[onedognight]

Groovy has had “it” for a while. I suspect it predates Kotlin’s usage.

[pledg]

Also matches Groovy

[sergiotapia]

Similar ish but equally cool is Nim's `result` keyword for functions. https://nim-by-example.github.io/variables/result/

Also damn Nim needs to do a much better job with their docs and site. `nim result` returns this very outdated third-party link first and nothing else official.

[jarjoura]

I constantly run into situations where I need to nest an iterator computation, and things like "it" get confusing.

I'm all for adding language features to avoid boilerplate, and it's clearly useful. I just want to call out that anonymous typing can be polarizing in large codebases and maybe only use it sparingly.

[Trasmatta]

I doubt I'll use it in committed code very often at all, this feels more like something that's very useful when hacking at something in the REPL

[elif]

nested_example = [1, 2, 3, 4, 5].map do

  [it, (1..it).map { it * it }]

end

Has an ambiguity, so you just add |x| to one of them..

nested_example = [1, 2, 3, 4, 5].map do |x|

  [x, (1..x).map { x * it }]

end

Seems like a mental over complication of a non-issue to me.

[snuxoll]

Implicit `it` shadows in other languages like Kotlin just like any other variable scope, and I really can’t say I’ve ever had it be a problem (implicit receivers, on the other hand, can be a right pain in the ass in poorly designed libraries and can I just say Gradle can go right to hell for it).

[jarjoura]

It’s a nonissue in small projects, but I’m not sure I agree that `{ x * it }` is easy to reason about when coming back to this block in 6 months. It’s mostly something that I’ve seen bite engineers during refactoring.

[tyre]

Being ruby you can monkey patch block to add an additional t to every nested block’s `it`

(This is terrible please don’t)

[regularfry]

I've not been tracking ruby core discussions for ages now, but I could have sworn that exactly this was discussed and rejected a decade or so ago.

[faitswulff]

I think I remember that as well. If you read the changelog, it goes through a good deal of edge cases behaviors that they probably ironed out in the intervening time, like captured variables with the same name and nested blocks with it parameters.

[Spivak]

I was disappointed that "block parameter name" wasn't the ability to give a block an actual name that will show up in a stack trace. It's been an endless source of frustration when your stack trace is just a bunch of anonymous blocks and procs. I assume JS devs feel a similar pain with anonymous functions.

[allknowingfrog]

We already had "_1", "_2", etc., for inline block arguments. Adding "it" increases the surface area of the language without adding any new functionality. I think the underscored names are actually better for readability. They jump out at me, while "it" looks like every other variable name.

  items.map { foo(_1) }
  items.map { foo(it) }

[block_dagger]

I like “it” but it’s a shame it works only in single line blocks.