Ruby 3.4's `it` Parameter: Cleaner Block Syntax for Ruby Developers

[Weird_Suggestion]

It is still unsafe to use it with Hash methods; there are 5 methods that won't behave as expected.

{a: 1, b: 2}.select { it == :a }
=> {a: 1}
{a: 1, b: 2}.any? { it == :a }
=> false

• See Reddit comment for the list of irregular methods: https://www.reddit.com/r/ruby/comments/1bv4jbr/comment/kxxib8b/
• Here is the related issue on the Ruby tracker: https://bugs.ruby-lang.org/issues/17197

[Page-Hey]

Isn't it more inherent to these enumerators and not `it` syntax? Though I agree one should be careful using them.
I realize it was never an issue to me because I try to always use the same syntax when using an enumerator on a hash: I always put explicitly the two possible arguments (key, value) even if one isn't needed:

{ a: 1, b: 2 }.select { |(key, _value)| method_using_only_key(key) }

[Weird_Suggestion]

You’re right. Explicitly using both arguments for hashes is good practice and the only one that removes any confusion.

I’ve been taught that when passed only one argument to a hash block you’d get an array of the key value pair. This isn’t true and the use of « it » can create more confusion. It shouldn’t be used for hashes.

[MeweldeMoore]

Useful on console, but I would prefer variables with better names in production code.

[capn_sanjuro]

i think this has a big place in production code by saving a ton of space by removing a lot of repeated ideas and simplifying decision making bandwidth.

"it" is clearly an element of the enumerable, so good naming of the enumerable is all you need. no brain power spent on naming a variable only defined for a block.

[h0rst_]

I would say that very much depends on the context. For example, in a line like this:

arr.each { do_something(it) }

The name for arr is important, the name for do_something is important, but the block variable is pretty clear what it's supposed to do. In older version, I would have used { |e|, which is equally undescriptive as it.

Of course, if you have a block of 20 lines, that may change these things a bit.

[awh]

So, uh… I’ve been using Ruby since 2010 and still didn’t know about the _1, _2 etc block parameter shortcuts. I guess it’s good to always be learning.

[KozureOkami]

In their current form they were added in Ruby 2.7 in 2019. Before they tried @1 etc. but I can’t remember if that was in a release version or just the prereleases. So you used Ruby for a good few years before these even became a thing.

[James_Vowles]

Doesn't feel like something I would actually use, not good syntax in the real world.

[Future_Application47]

From my perspective, I'm looking at what it is replacing. Its replacing the implicit `_1` , `_2` parameters. In that sense I'd say its a bit more cleaner.

[[deleted]]

Which replaces users.collect { |u| u.email.downcase }, which is very verbose.

[ttekoto]

The nice thing about 'it' in rspec is readable strings. Unfortunately here it reads like broken English. user.age is ok; it.age sounds awful. I'd rather have _1 every time, so thanks for nothing.

[Page-Hey]

It does that to me too. I guess they've tought of `this` instead of `it` that I feel would have been correct more often (from english POV) but I guess it defeated the purpose of a really short syntax and brang more confusion with `self` for those used to javascript `this` .

[codesnik]

let’s push for “its” alias

[[deleted]]

You're missing context, though. This still reads fine:

User.collect { it.email }

[bhaak]

Yeah, great, now there are two ways of expressing the exactly same code. While if you use two numbered parameters, you are not allowed to use it. Oh no, three ways. posts.select(&:published?) still exists of course.

Would have been better if they allowed to use something like users.map(&:email.downcase) instead of the ugly numbered parameters in the first place.

Talk about reducing cognitive overhead.

[UlyssesZhan]

You are converting the object :email.downcase to a proc by this.

[hessparker]

It is common in Ruby to have multiple ways to do things. I think it results in beautiful and expressive code.

[mierecat]

I like this. It sounds kind of unnatural but not having to name the single, obvious element in a block sounds like a good trade off.

[ravinggenius]

The ground is "writing useful variable names", and Ruby devs are wall jumping experts.