`promote_op` doesn't play well with `Union{Missing, T}`

[andyferris]

Sometimes I use promote_op to predict the element type of containers for non-trivial operations where the element type might change.

However, while working out how my packages might work with missing in v0.7 I came across this stumbling block:

julia> Base.promote_op(+, Int, Union{Float64, Missing})
Any

(I do realize there is a momentum to rely less on inference and more on "the type of actual elements at run-time" (at least in Base)... but sometimes the promote_op pattern is the quickest path to victory and I don't see why it shouldn't work as well as possible).

[KristofferC]

From some small poking. The return type of applying + to Int and the union is computed as Union{Missing, Float64} but that is only returned if the two types and the return type are isdispatchtuple. Otherwise typejoin is called and we have:

julia> isdispatchtuple(Union{Missing, Float64})
false

julia>  typejoin(Int64, Union{Missing, Float64}, Union{Missing, Float64})
Any

[andyferris]

Right! As you note, inference itself is precise.

julia> Core.Compiler.return_type(+, Tuple{Int, Union{Float64, Missing}})
Union{Missing, Float64}

While not quite dispatchable, I wonder if we could nonetheless add some extra logic around Union types here (or in typejoin itself)?

[vtjnash]

I think the literal definition of this function should probably be:

Base.promote_op(op, AT::Type...) = Base.promote_type(AT..., Base._return_type(op, Tuple{AT...}))

But it's never been implemented as anything meaningfully similar to that.

Nor have any of the users of the code likely intended for it to do that.

Nor is it currently documented to do anything like that.

We've removed most users of this function, so it would seem that we're well on our way to eliminating it entirely. I'll put up a PR shortly to fix it.