Return HasEltype only for homogenous non-empty tuples

[timholy]

Inspired by #35803, https://github.com/JuliaLang/Statistics.jl/pull/36, but seems like it might be worth trying on its own now that we're in the 1.6 cycle. Surprisingly little broke even without the @default_eltype change, let's see what that fixes/messes up!

If this does OK we might want a PkgEval run just to figure out what consequences a change like this might have.

[timholy]

That's pretty good, just a change in error type for mean(()), and the new error is more informative:

julia> mean(())
ERROR: ArgumentError: reducing over an empty collection is not allowed
Stacktrace:
 [1] _empty_reduce_error() at ./reduce.jl:299
 [2] reduce_empty_iter(::Base.MappingRF{typeof(identity),typeof(+)}, ::Tuple{}, ::Base.EltypeUnknown) at ./reduce.jl:352
 [3] mapreduce_empty_iter(::Function, ::Function, ::Tuple{}, ::Base.EltypeUnknown) at ./reduce.jl:347
 [4] mean(::typeof(identity), ::Tuple{}) at /home/tim/src/julia-master/usr/share/julia/stdlib/v1.6/Statistics/src/Statistics.jl:64
 [5] mean(::Tuple{}) at /home/tim/src/julia-master/usr/share/julia/stdlib/v1.6/Statistics/src/Statistics.jl:44
 [6] top-level scope at REPL[8]:1

Let's also check the impact on packages:

@nanosoldier runtests(ALL, vs=":master")

[JeffBezanson]

I think there's a subtle shade of meaning here: EltypeUnknown implies that since we know nothing about the types of the elements, it's worth checking as you go to see if the types are actually homogeneous. But with a heterogeneous tuple we already know that there is no useful element type --- might as well use Any.

[timholy]

I guess the approach I took here was motivated by

julia> map(identity, Any[1, 1.0])
2-element Array{Real,1}:
 1
 1.0

julia> collect((1, 1.0))
2-element Array{Real,1}:
 1
 1.0

But I'd be fine with using Any. I will sit tight with this until the PkgEval run reports back, because there's a small chance that will nix this entirely.

I'm going to mark this as breaking, even though it's hopefully pretty mild.

[timholy]

Ah, we also have this. Of course, like this PR there is more than a little element of "checking as you go" there, so I don't think the EltypeUnknown() is entirely wrong.

But we could leave it as HasEltype(), and fix the reduction dispatch hierarchy so that it never tries to iterate over an empty tuple. I will play around a bit.

[nanosoldier]

Your package evaluation job has completed - possible new issues were detected. A full report can be found here. cc @maleadt

[timholy]

Haven't dug yet, but the more plausible failures are:

• DiskDataProviders 0.1.0
• ImageCore 0.8.14: a change in the output of a show test (this is likely real)
• LikelihoodProfiler 0.2.0: (a leak of Core.Compiler.UseRef up to user level)
• SimpleMock 1.1.4 (Cassette-releated)

and possibly others (conversely, some of these may be spurious).

Let's just leave this open for a while and see where further investigations take us.

[JeffBezanson]

Ah, good point that inferring first on a tuple does not give a very accurate element type! :) Fortunately I think this is dead code for tuples, since tuples have known lengths, and empty tuples have a known element type.

[timholy]

This doesn't seem urgent, and we can revisit later if need be.