"A Tragedy of Julia’s Type System"

[Mason]

@foobar_lv2

So, at least @Benny is of the opinion that it has to be that way, i.e. that inference of non-SSA captures will always and unavoidable suck.

But additionally, it sucks extra hard, because the lowering is dumb. E.g.

function f()
x = 0
if false x = 1 end
g()=x
g()
end

gleefully infers as Any. This is because lowering is dumb and only sees the AST, and neither CFG nor const-prop nor escape analysis nor anything!

I tend to agree with @Benny, the problem is hard, and it will always suck. But it doesn’t need to suck that badly.

For what it’s worth, there’s a currently open PR specifically trying to fix cases like this right now under active development: perform inference using optimizer-derived type information by aviatesk · Pull Request #56687 · JuliaLang/julia · GitHub

The idea is that after things like type inference and dead code elimination, the compiler can go back to a very early point in the pipeline and use knowledge it learned later to say

ah, xs type never changes and can’t be lexically modified anywhere in the program, so it’s okay to just let g return 0 instead of forcing it to go through a Box

I’m pretty optimistic this can work. Specifically check out the tests the PR adds showing it can correctly infer return types in very similar functions: julia/Compiler/test/inference.jl at b775f2008d944c376f4f3f9f48ff2a096eb66a74 · JuliaLang/julia · GitHub

These tests are already passing.