I don't agree with this change. The block is clearly only on one line, no?

I would expect this to be ok:

foo
  .baz { transform(it) }
  .bat { change(it) }

What is the point of single-line if this is rejected?

I think those cases make it less readable, so they are not suitable to allow. I think single-line refers strictly to one line on the same line.

The offense message is specifically "Avoid using it block parameter for multi-line blocks". Especially when chaining method calls like that, naming the block argument does not add anything. I don't understand why one of these would less readable:

bar { do_something(it) }

foo
  .bar { do_something(it) }

It's only a little more indented and has a dot before it. I would consider method chaining like that one of the best use-cases for it.

AKAIK, it was introduced as a shorthand. As stated in the main point, code that should be maintained ought to be explicitly named. What it refers to cannot be known without tracing back to the receiver's name, and line-broken method calls are visually inconvenient as well.

I kind of agree with @Earlopain on this point, as I also think the setting targets a single-line block, not the whole expression the block is part of. In my mind there's little difference between several chained blocks on the same line or multiple lines, so I think this will likely confuse some people.

Guess I should have thought more about the PR before merging it. My bad!

Hmm, I'm questioning whether it makes sense to evaluate this based on the blocks themselves. For example, in a case like:

articles.
  foo { ... }.
  bar { ... }

what matters for understanding what the object represents is not the method names like foo or bar, but the receiver name articles.
I’m not yet convinced that having no meaningful naming in cases like this, where the code drifts away from the receiver, contributes to single-line readability.

Hey. 👋 In case it helps, I'm a big fan of the more functional aspects of Ruby and was taken aback by this change. For example, the following is no longer valid (where, previously, it was):

firmware.where { attachment_data.has_key "id" }
        .select { attachment_data.get_text("id").as(:attachment_id) }
        .map(:attachment_id)
        .each { shrine_store.delete it }

I understand the arguments made here but would be in favor of what I've posted above as being valid. Each line is a step which has it's own operation (so-to-speak). The readability isn't degraded because there are four steps here which read, nicely, from top to bottom. Each is self contained. The fact that I use it in the fourth step is a matter of convenience. I don't think it detracts from readability. It's no different, in terms of readability, than if you had removed steps 1 through 3. Example:

# This would not work, functionally, but only showing for illustration purposes.
firmware.each { shrine_store.delete it }

It's the same computation, in my mind, when reading this code (yes, the receiver is different, but you have to make that computation in your mind each time you use it anyway).

At the very least, could there be an option to allow for a functional pipeline flow like this?

I'm also surprised by this very opinionated change.

Wasn't the numbered parameters syntax introduced specifically to make multi-line block chains like the examples here be more convenient / more similar to pipe operators in other languages?

I am glad that I am not the only one that is against this change. I openend #14565 to revert, let's hope for the best.

@Earlopain Merged. As noted above - I acknowledge I misread the intention of this PR and we'll need to discuss further if any changes to the existing behavior are needed.