Make Array#transpose, Enumerable#reject, Enumerable#to_h work with tuples

[HertzDevil]

As noted in #3718 (comment), methods cannot depend on typeof(exp.first) if exp is an Enumerable or Indexable, because it breaks when exp is also a Tuple:

{1, 'a'}.reject(Int32)        # Error: no overload matches 'Array(NoReturn)#<<' with type Char
{ {1, 'a'}, {"", true} }.to_h # Error: no overload matches 'Hash(Int32, Char)#[]=' with types (Int32 | String), Char
[{1, 'a'}].transpose          # Error: expected block to return T, not (Char | Int32)

This PR fixes them:

{1, 'a'}.reject(Int32)        # => ['a']
{ {1, 'a'}, {"", true} }.to_h # => {1 => 'a', "" => true}
[{1, 'a'}].transpose          # => [[1], ['a']]

typeof({1, 'a'}.reject(Int32))        # => Array(Char)
typeof({ {1, 'a'}, {"", true} }.to_h) # => Hash(Int32 | String, Bool | Char)
typeof([{1, 'a'}].transpose)          # => Array(Array(Char | Int32))

Some methods like Enumerable#flat_map call typeof(yield first), which is okay as long as the method also yields each element from the collection itself, but for clarity these first calls inside typeofs are also replaced with first_internal Enumerable.element_type(self).

[asterite]

I wonder if, instead of adding a nodoc methods to every type here, we can introduce an internal type inside Enumerable, with a method that computes this. For every object except tuple it calls first, but for tuple it would be different. What do you think?

[HertzDevil]

#10429 does that:

module Enumerable(T)
  def self.element_type(x)
    x.each { |elem| return elem }
    ::raise ""
  end
end

class Foo # not an Enumerable
  def each
    yield 1
    yield 'a'
  end
end

typeof(Enumerable.element_type([1, 'a'])) # => (Char | Int32)
typeof(Enumerable.element_type({1, 'a'})) # => (Char | Int32)
typeof(Enumerable.element_type(Foo.new))  # => (Char | Int32)

Like String.interpolation, it also has public docs there.

[asterite]

Cool! Can we bring that method from that PR into this one? I'll try to review the other one this week. Sorry, we can't catch up with so many great PRs! 😅

[HertzDevil]

I didn't replace the internal methods in NamedTuple because Enumerable.element_type doesn't work on them (it requires the value to satisfy Enumerable's interface even if the value's type doesn't include the module, and that requires single-element yields whereas NamedTuple#each yields the key and value separately).

[straight-shoota]

This method is intended for being used in typeof and not supposed to be actually called. But still, it can be. And then it should raise a proper exception, instead of an empty message.

Unfortunately it's not possible to move the typeof into the method because of nesting calls and yielded values. That would probably be the best solution.

[straight-shoota]

Do we want element_type as a public method like this?

I realize it's already merged from #10429, thus not necessarily subject to this PR.

[HertzDevil]

It cannot be even protected because splat expansions must be able to access the method in any scope, for the same reason as ::String.interpolation being public.

[asterite]

I think it's actually good to have this public because it enables shards to use it if they need it.

[straight-shoota]

But what about the empty raise? It's public API and can be called outside of typeof.

[HertzDevil]

Either EmptyError or a generic BUG: exception, I guess.

[oprypin]

Note: #10429 is merged, and now the diff from src/enumerable.cr entirely disappears, as it exactly matches what's in master.