# Revisiting type stability
**URL:** https://discourse.julialang.org/t/revisiting-type-stability/13955
**Category:** General Usage
**Tags:** type-stability
**Created:** [August 23, 2018, 4:50pm UTC](https://discourse.julialang.org/t/revisiting-type-stability/13955 "2018-08-23T16:50:00Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@Wenjie](https://discourse.julialang.org/u/Wenjie)
#### Post date: [August 23, 2018, 4:50pm UTC](https://discourse.julialang.org/t/revisiting-type-stability/13955/1 "2018-08-23T16:50:00Z")
**Type Stability** is one of the most important concept in Julia but never _properly_ defined. Instead, it is described with examples; most examples are similar to the following:
```julia
function t1(n)
s = 0
t = 1
for i in 1:n
s += s/i
t = div(t, i)
end
return t
end
function t2(n)
s = 0.0
t = 1
for i in 1:n
s += s/i
t = div(t, i)
end
return t
end
```
where `t1` is unstable and `t2` is stable. The reason given is that `s` changes type. ~~However, I managed to produce a type stable code but still changing `s`’s type within. See the following~~
```julia
function t3(n)
s = 0
t = 1
for i in 1:n
s/i; s = 0.0
t = div(t, i)
end
return t
end
```
Here `s` changes from Integer to Floating-point in the loop.
So how should we understand the type stability without relying on `@code_native`?
---
### Author:  [@yuyichao](https://discourse.julialang.org/u/yuyichao)
#### Post date: [August 23, 2018, 4:59pm UTC](https://discourse.julialang.org/t/revisiting-type-stability/13955/2 "2018-08-23T16:59:19Z")
> [@Wenjie](#):
>
> The reason given is that `s` changes type
No that’s not the reason. The reason is the use of `s` in the loop could be of different types.
> [@Wenjie](#):
>
> So how should we understand the type stability without relying on `@code_native` ?
`@code_native` is **never** what you should use, especially not for type stability. Use `@code_warntype` instead.
---
### Author:  [@yuyichao](https://discourse.julialang.org/u/yuyichao)
#### Post date: [August 23, 2018, 5:06pm UTC](https://discourse.julialang.org/t/revisiting-type-stability/13955/3 "2018-08-23T17:06:24Z")
> [@Wenjie](#):
>
> never _properly_ defined
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.
---
### Author:  [@Wenjie](https://discourse.julialang.org/u/Wenjie)
#### Post date: [August 23, 2018, 6:34pm UTC](https://discourse.julialang.org/t/revisiting-type-stability/13955/4 "2018-08-23T18:34:57Z")
Hi @yuyichao, thanks for the reply. Could you also comment on my function `t3` and explain why it is type stable (or not)?
---
### Author:  [@jw3126](https://discourse.julialang.org/u/jw3126)
#### Post date: [August 23, 2018, 6:51pm UTC](https://discourse.julialang.org/t/revisiting-type-stability/13955/5 "2018-08-23T18:51:16Z")
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).
---
### Author:  [@yuyichao](https://discourse.julialang.org/u/yuyichao)
#### Post date: [August 23, 2018, 7:35pm UTC](https://discourse.julialang.org/t/revisiting-type-stability/13955/6 "2018-08-23T19:35:21Z")
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.