And there’s basically no way to properly define it in an implementation independent way while still being useful. The proper definition should probably be that if in the program, the use of a variable in a specialization of the function could be of different types at runtime, then there’s type instability. However, this definition is basically undecidable so in practice, the useful definition is that if the compiler cannot figure out the leaf type of a use then there’s type instability. This is what @code_warntype shows you. Since it depend on what the compiler can do, I would not call it a “proper” definition, even though it is nonetheless the only useful one.
Well if the definition is, what @code_warntype shows you, then it is not type stable. This is not a good definition if you e.g. want to build a mathematical paper on top of it. But as @yuyichao said its very practical. E.g. I only write @code_warntype-stable code in performance critical spots (at least in julia 0.6).
In this case it’s not type stable. However, since the operation that this insability is on is so trivial, together with the type inference union splitting and LLVM DCE there will end up not being any performance issue. This is a very unusual case though since most code won’t really write expressions that are not used.