I believe there is a macro to check, I forget which, but could a macro “conform” the type of both code paths, i.e. here to Float64 (as it’s an (almost) superset)? I think a macro could do it, I’m not sure, as I’m not good with writing macros yet. That would be a step in the right direction, and even better if the compiler could do it automatically for you.
A first step might be to just give you a Union of both types, whatever they are.
That’s just an example, I just used one with a Float64, as more likely do happen in practice (and I know of div, another solution). I’m just thinking this could be a bit problematic for my solution here (there only involving integers):
Note, there I think I resolved all the issues, at least outlined the loop problem in the end. There are no showstoppers there, including this type-instability problem (while annoying and potentially slowing down, not a safety problem).
You mean Numba does this automatically (without a macro since Python doesn’t have macros), not that a macro in Julia couldn’t be implemented, only that you don’t want it?
But note it would make the intention explicit (I know there are other ways for that, I’m thinking of better ways), and as is, it’s not at all clear what the user wanted, regarding types, can’t be read from the code as it is (or the programmer actually intended for type-stable AND type-unstable). It could be:
julia> @code_warntype f(1.0)
[..]
Body::Float64
what the programmer had in mind, i.e. always called with Float64 and that IS type-stable. But while the code IS general, it’s not type-stable in general. It is type-unstable as I stated, and shown earlier, or in a different way, if the programmer thinks he’s fixing it this way:
julia> function f(x)
if x % 2 == 0
x/2
else
2.0x
end
end
then instead type-unstable for e.g. Float32 input (also Float16, while not for Float64 and all integers):