Add special case for Void in typejoin() to return Union{T, Void}

[nalimilan]

This allows for a more efficient code and array layout than using Any.
Other types like Null will be able to opt into this mechanism.

This is an alternative to #23940, though it doesn't address all issues since e.g. collect return types are not always inferred here even though they are correct thanks to the progressive broadening of the container type (compare tests with the other PR).

That's also the minimal change among multiple options:

• use a special case for Void and Null (this PR)
• apply this to all pairs of a concrete type with a singleton type (quite arbitary)
• apply this to all pairs of concrete types

The last solution is less arbitrary, but things like [1, "a"] would return a Vector{Union{String, Int}}, and the fact that this applies only to Unions of two types is still somewhat arbitrary.

Finally, the name isspecial should really be improved but I couldn't find a good solution.

[omus]

Maybe call this typejoin_rule? It could work similarly to promote_rule.

[nalimilan]

Except that it's not as general as a rule: it's very limited since it only allows returning Union rather than Any. You can't give a custom type to return. So it's actually closer to a binary trait like IndexStyle. Also it's not supposed to be a public API, only Nulls.jl should use it at this point, waiting for its possible inclusion in stdlib.

[vtjnash]

There's nothing wrong with changing this function in Base, but we're currently using the same code in Core.Inference, and we don't want that usage to change. (it would be perfectly acceptable however to copy this function and have different versions in use, or do something like create a promote_join that is overloadable and calls typejoin as a fallback, and use it instead everywhere except inference)

[vtjnash]

If you're intending for people to override this, typejoin won't be pure anymore (currently marked as such)

[nalimilan]

Even if people are only supposed to override this with isspecial(::Type{Null}) = true? @pure is still a mystery to me (is the problem due to the addition of methods after the fact?).

[JeffBezanson]

is the problem due to the addition of methods after the fact?

Yes.

[nalimilan]

There's nothing wrong with changing this function in Base, but we're currently using the same code in Core.Inference, and we don't want that usage to change. (it would be perfectly acceptable however to copy this function and have different versions in use, or do something like create a promote_join that is overloadable and calls typejoin as a fallback, and use it instead everywhere except inference)

Thanks for the suggestions. I really don't have strong opinions about what's the best approach. At this point I'm not sure there's a use case for a complex promote-like mechanism, so I'd say we should rather go with the most limited changes which work for the Union{T, Void} case.

[nalimilan]

@JeffBezanson Any suggestions regarding the best approach?

[JeffBezanson]

I prefer doing the most conservative thing and only adding this for nothing and missing.

[nalimilan]

Fine with me, will have a look once missing is in Base.

[nalimilan]

I've updated the PR. I now leave typejoin as-is, and introduce promote_join (unexported) instead, which falls back to typejoin but has special methods for Void and Missing. I'm not sure about the name, though, since promote evokes the promotion mechanism which may imply a conversion. Not a big deal since it's internal, but if somebody has better ideas...

[nalimilan]

@JeffBezanson @vtjnash Is the new approach OK?

[quinnj]

Looks like this needs a rebase; @JeffBezanson, mind taking a look?

[nalimilan]

Closing in favor of the alternative promote_type_strict approach at #25423.

[nalimilan]

GitHub won't let me reopen this, so I've filed #25553 instead.