ill-formed output produced by broadcast operations on empty arrays

[thautwarm]

The following behaviour can be reproduced in Julia v1.8-v1.10.0-DEV.

julia> Int[] .+ String[]
Union{}[]

julia> Int[] .* String[]
Union{}[]

It can be also observed at map operations:

 julia> map(+, Int[], String[])
Union{}[]

This is caused by missing some necessary checks when using type inference tricks to pre-decide the element type. If the type level computation gets us a bottom type, raising an exception looks more appropriate:

R = Base.return_type(f, Tuple{A, B})
R == Base.Bottom && error("invalid operation ...")
# do stuff

[StefanKarpinski]

This seems correct, no?

[StefanKarpinski]

I guess the argument for throwing an error is that if these arrays were non-empty there would be an error. A little weird though because Julia generally doesn't throw errors for potentially invalid things that you didn't actually do. There are, of course, tools like JET to opt into getting that kind of warning in advance, but in this case no Int + String operation was actually attempted and the element type of the resulting array is correct: there are no values of it, so it's Union{}.

[thautwarm]

but in this case no Int + String operation was actually attempted and the element type of the resulting array is correct: there are no values of it, so it's Union{}.

This is interesting and does feel consistent to me.

My concern is that broadcast may cause errors reported later than expected, as the computation result may get involved in multiple dispatch and report strange errors. For example, my application (where this issue raises) looks like:

work2(x) = someintegerarray .+ x

x2 = work1(x1)  # work 1 processes the input
x3 = work2(x2) # work 2 performs broadcasting
x4 = work3(x2) # work 3 uses multiple-dispatch to do stuff

I found that some nested calls in "work3" were reporting strange errors to me, but they actually came from my lack of consideration for "work2" because I didn't realize that the broadcast had such behavior.

JET can be usually very useful for such scenarios, but my work1 is too dynamic to get inferred in advance. Any thoughts?

[thautwarm]

I'm not sure if this is an issue of the language. If you don't think so just close this, then I'd move the thread to discourse.