Well, the commit message says “remove a couple uses of ntuple to help the compiler” so I just copied the phrase. My guess is that it makes it impossible to infer the type so that compiler gives up early which in turn makes JIT completion time shorter.
That make sense. By the way how did you spot this issue? (By your amazing InteracticeCodeSearch.jl I guess?) Do you think it is possible to automatically scan up a call chain to detect where type instability happens?
I just guessed xs[1:end-1] was the problematic part and then ran xs = (1, 2, 3); @edit xs[1:2]. It led me to the code using Vector which didn’t seem very nice for the type system so I ran git blame to find the commit.
(@search from InteractiveCodeSearch.jl actually does not work this case since it evaluates xs[1:2]. It would be nice to support this but @edit works perfectly fine so I’m not super motivated to fix this at the moment…)
I just read ?@code_typed and it turned out you can pass optimize=false to do:
which tells you that the type instability happens at getindex. It only takes care of the “first level” of the call chain but I guess it can be handy.
I think it would be very useful if slicing is type stable. I don’t know what’s the best way to get attention from core devs, though. Maybe move to “internals” category?