Feature #21455: Add a block argument to Array#join

• Status: Rejected
• Assignee: -
• Target version: -

[leoarnold (Leo Arnold)]

I sometimes come across code like this where
the Array#join at the end can easily
be overlooked or stands out like a sore thumb:

hex_string = string.bytes.map do |byte|
  format('%02X', byte)
end.join(' ')

It seems idiomatic and more succinct
to pass the block to Array#join directly:

hex_string = string.bytes.join(' ') do |byte|
  format('%02X', byte)
end

Pull Request: https://github.com/ruby/ruby/pull/13731

[leoarnold (Leo Arnold)]

• Description updated (diff)

[leoarnold (Leo Arnold)]

• Description updated (diff)

[mame (Yusuke Endoh)]

• Related to Feature #21386: Introduce `Enumerable#join_map` added

[mame (Yusuke Endoh)]

I have a different view on this proposal.

If Array#join were to accept a block, I would expect its behavior to relate directly to the "join" action itself, not the transformation of each element (which is the responsibility of map).

Specifically, it seems most appropriate for the block's return value to be used as the separator between elements. This would allow for dynamic separators based on context, such as the position of the join.

For example, this approach provides an elegant way to handle the Oxford comma:

items = ["Apple", "Banana", "Cherry"]

i = 0
str = items.join do
  i += 1
  if i == items.size - 2
    ", and "
  else
    ", "
  end
end

p str #=> "Apple, Banana, and Cherry"

I believe this approach is more intuitive and consistent.

To be clear, I am not making a counter-proposal here. My main point is that it feels illogical for Array#join to accept a block that performs a map-like operation, as that behavior is unrelated to the behavior of "join" itself.

[matz (Yukihiro Matsumoto)]

• Status changed from Open to Rejected

It's fundamentally join_map we have rejected. Array#join should join, not mapping.
We are not going to add every enumerable method combined with map. filter_map is an exception.

Matz.