Fix eltype of flatten of tuple with non-2 length

[jakobnissen]

In 4c076c8, eltype of flatten of tuple was improved by computing a refined eltype at compile time. However, this implementation only worked for length-2 tuples, and errored for all others.
Generalize this to all tuples.

Closes #56783

[jakobnissen]

Turns out we need to think about bootstrapping - iterators.jl is defined before a lot of Base (and the compiler), so several functions like mapreduce and tuple_type_tail are not defined at the time the module is defined (and used to compile the compiler).
I'm giving it a go now with the recursive - somewhat less elegant - implementation. If that still doesn't work, or is too complex for this small accuracy increase, we can just revert to before #55946

[nsajko]

Turns out we need to think about bootstrapping

I second @martinholters suggestion for using afoldl above. The afoldl function is defined in operators.jl, which is included before iterators.jl.

[jakobnissen]

That requires splatting the tuple, which might not be a good idea.

[nsajko]

Splatting is only an issue for large tuples, in any case pretty sure splatting directly is preferable to calling tuple_type_tail, which seems like a monstrosity, and starts with a warning for incorrectness:

julia/base/tuple.jl

Lines 430 to 445 in ece1c70

	function tuple_type_tail(T::Type)
	@_foldable_meta # TODO: this method is wrong (and not :foldable)
	if isa(T, UnionAll)
	return UnionAll(T.var, tuple_type_tail(T.body))
	elseif isa(T, Union)
	return Union{tuple_type_tail(T.a), tuple_type_tail(T.b)}
	else
	T.name === Tuple.name || throw(MethodError(tuple_type_tail, (T,)))
	if isvatuple(T) && length(T.parameters) == 1
	va = unwrap_unionall(T.parameters[1])::Core.TypeofVararg
	(isdefined(va, :N) && isa(va.N, Int)) || return T
	return Tuple{Vararg{va.T, va.N-1}}
	end
	return Tuple{argtail(T.parameters...)...}
	end
	end

[nsajko]

EDIT: this entire comment is incorrect. I misinterpreted/misused infer_effects - the inferred effects are always foldable simply because the given type signatures throw unconditionally.

Splatting is only an issue for large tuples

Actually, it doesn't seem to be an issue at all. Here are two variants on @martinholters' suggestion:

function f(::Type{Iterators.Flatten{I}}) where {I<:Union{Tuple,NamedTuple}}
    Base.afoldl((T, i) -> Base.promote_typejoin(T, eltype(i)), Union{}, fieldtypes(I)...)
end

function g(::Type{Iterators.Flatten{I}}) where {I<:Union{Tuple,NamedTuple}}
    function reducer(t::Type, i::Int)
        Base.promote_typejoin(t, eltype(fieldtype(I, i)))
    end
    Base.afoldl(reducer, Union{}, 1:fieldcount(I)...)
end

Both are foldable independently of tuple length:

julia> Base.infer_effects(f, Tuple{Type{Iterators.Flatten{<:Tuple}}})
(+c,+e,!n,+t,+s,+m,+u,+o,+r)

julia> Base.infer_effects(g, Tuple{Type{Iterators.Flatten{<:Tuple}}})
(+c,+e,!n,+t,+s,+m,+u,+o,+r)

julia> Base.infer_effects(f, Tuple{Type{Iterators.Flatten{<:NamedTuple}}})
(+c,+e,!n,+t,+s,+m,+u,+o,+r)

julia> Base.infer_effects(g, Tuple{Type{Iterators.Flatten{<:NamedTuple}}})
(+c,+e,!n,+t,+s,+m,+u,+o,+r)

Also note that the new variant works without splatting a tuple.

[DilumAluthge]

Ah, I did not mean to merge this PR without getting @martinholters's approval first.

@martinholters Could you do a post-merge review of this PR? If there are any changes you suggest, we can either make those changes in a follow-up PR, or revert this PR if there are major changes needed.

[nsajko]

FWIW the implementation that was merged is what @martinholters suggested: #56802 (comment)

[nsajko]

Just made a PR to test foldability inference of eltype and other basic iteration interface functions for various iterator types: #56838

[martinholters]

Right, I'm ok with the implementation, given it's my suggestion. Some @inferreds in the tests might have been worth considering.

[DilumAluthge]

Thanks Martin!

[DilumAluthge]

Some @inferreds in the tests might have been worth considering.

@jakobnissen or @nsajko Would you be able to make a follow-up PR that addresses this?

[nsajko]

Would you be able to make a follow-up PR that addresses this?

See #56838 and #56885