Ruby

Isn't it significantly slower than doing it manually due to all these extra block and method calls etc in between?

Looping class method is an unusual pattern in Enumerable. So I first hesitated, but actually it's the only way to go if we want to introduce `product'.
And the method seems to be convenient. Thus, I accept.
@Eregon (Benoit Daloze) If the performance matters, we can re-implement it in C.

Matz.

Thanks. Performance monsters can also special-case arrays and ranges and omit calls to each_entry to boost performance. 😂

My performance concern was not about Ruby vs C, writing in C would have the same issues.

What I'm saying is this:

(1..3).each do |i| ["A", "B"].each do |c| puts "#{i}-#{c}" end end 

will always be faster than:

Enumerator.product(1..3, ["A", "B"]).each do |i, c| puts "#{i}-#{c}" end 

because the second has a generic/cannot-do-sensible-inline-cache loop and lots of array allocation and splatting.

So Enumerator.product makes sense when one doesn't know how many enums to combine, or a large number of them, but for 2-3 it's better performance-wise (and maybe also for clarity) to just use nested each.

And between writing Enumerator.product in Ruby or C I'd prefer a lot in Ruby because it's a million times more readable, and it can be reused by other Ruby implementations :)

It might also be nice to require at least one enum argument, since Enumerator.product #=> [nil] seems a bit odd. Here's a stab at lazy size:

def Enumerator.product(*enums, **nil, &block) raise ArgumentError, 'wrong number of arguments (given 0, expected 1..)' if enums.empty? unless block_given? return to_enum(__method__, *enums) do enums.reduce(1) do |acc, enum| enum_size = enum.size break unless enum_size acc * enum_size end end end enums.reverse.reduce(block) do |inner, enum| lambda do |*values| enum.each_entry do |value| inner.call(*values, value) end end end.call end 

That's actually not a mathematical idea. The 0-ary Cartesian product of sets should be defined as a singleton set for theoretical and practical reasons. It's just like 2^0 equals to 1.

Python's itertools.product aligns with this theory.

import itertools for i in itertools.product(range(3), range(3)): print("2-ary: " + repr(i)) for i in itertools.product(range(3)): print("1-ary: " + repr(i)) for i in itertools.product(): print("0-ary: " + repr(i)) 

Output:

2-ary: (0, 0) 2-ary: (0, 1) 2-ary: (0, 2) 2-ary: (1, 0) 2-ary: (1, 1) 2-ary: (1, 2) 2-ary: (2, 0) 2-ary: (2, 1) 2-ary: (2, 2) 1-ary: (0,) 1-ary: (1,) 1-ary: (2,) 0-ary: () 

Related to #6499 #7444 #8970

https://github.com/ruby/ruby/pull/6197