# Type Inference
**URL:** https://discourse.julialang.org/t/type-inference/89761
**Category:** General Usage
**Tags:** multidispatch
**Created:** [November 4, 2022, 8:23am UTC](https://discourse.julialang.org/t/type-inference/89761 "2022-11-04T08:23:45Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@tchebycheff](https://discourse.julialang.org/u/tchebycheff)
#### Post date: [November 4, 2022, 8:23am UTC](https://discourse.julialang.org/t/type-inference/89761/1 "2022-11-04T08:23:45Z")
I always held automatic type inference as one of Julia’s distinguishing features. Why are packages full of type qualifications? Is it the performance improvement, error handling or just the coolness factor?
P.S.
I hope Julia programs do not start looking like C++ in terms of readability.
---
### Author:  [@lmiq](https://discourse.julialang.org/u/lmiq)
#### Post date: [November 4, 2022, 10:59am UTC](https://discourse.julialang.org/t/type-inference/89761/2 "2022-11-04T10:59:14Z")
> [@tchebycheff](#):
>
> Is it the performance improvement
mostly not (there are only specific situations where type annotations - in functions - may improve performance). Types in declarations of structs are important, though.
> [@tchebycheff](#):
>
> error handling
This is probably the most common use. Sometimes the code gets clearer to use and debug with type annotations. Also for dispatch, when the type annotations define to which type of variable each method works (actually this is the most important use).
But to actually understand your question, maybe you would like to post some example, so a more precise answer of why annotations were used in some specific case.
---
### Author:  [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)
#### Post date: [November 4, 2022, 11:21am UTC](https://discourse.julialang.org/t/type-inference/89761/3 "2022-11-04T11:21:31Z")
> [@tchebycheff](#):
>
> Why are packages full of type qualifications? Is it the performance improvement, error handling or just the coolness factor?
I would say neither of these.
Types in method arguments are used to say what set of arguments should dispatch to that method:
```julia
struct Cat end
struct Dog end
noise(::Cat) = "mjau"
noise(::Dog) = "woof"
```
So if we have a `noise(Cat())` it dispatches to one method while a `noise(Dog())` dispatches to another. T
[https://www.youtube.com/watch?v=kc9HwsxE1OY](https://www.youtube.com/watch?v=kc9HwsxE1OY) might be interesting to watch for you.
---
### Author:  [@tchebycheff](https://discourse.julialang.org/u/tchebycheff)
#### Post date: [November 25, 2022, 2:16am UTC](https://discourse.julialang.org/t/type-inference/89761/4 "2022-11-25T02:16:53Z")
For example, this is from StatsBase.jl
```julia
function _momentk(v::RealArray, k::Int, m::Real)
n = length(v)
s = 0.0
for i = 1:n
@inbounds z = v[i] - m
s += (z ^ k)
end
s / n
end
```
RealArray is an abstract type defined by the package. Is there a reason other than error handling to not write the function as:
```julia
function momentk(v, k, m)
n = length(v)
s = 0.0
for i = 1:n
@inbounds z = v[i] - m
s += (z ^ k)
end
s / n
end
```
Of course, if i pass a vector of Complex numbers the second function happily returns a value, while the first throws up a “generic” error:
```julia
_momentk(ans,2,0)
ERROR: MethodError: no method matching _momentk(::Vector{Complex{Int64}}, ::Int64, ::Int64)
Closest candidates are:
_momentk(::AbstractArray{T} where T<:Real, ::Int64, ::Real) at ~/play/jl/type.jl:3
Stacktrace:
[1] top-level scope
@ REPL[22]:1
```
Perhaps type annotation here precludes a more graceful handling of error (or any handling of error other than “method does not exist”?).
---
### Author:  [@tchebycheff](https://discourse.julialang.org/u/tchebycheff)
#### Post date: [November 25, 2022, 2:26am UTC](https://discourse.julialang.org/t/type-inference/89761/5 "2022-11-25T02:26:06Z")
Thanks for the reference to the excellent talk.
I had in mind examples as such as the StatsBase one i posted above.
---
### Author:  [@aplavin](https://discourse.julialang.org/u/aplavin)
#### Post date: [November 25, 2022, 8:09am UTC](https://discourse.julialang.org/t/type-inference/89761/6 "2022-11-25T08:09:05Z")
> [@tchebycheff](#):
>
> ```julia
> function _momentk(v::RealArray, k::Int, m::Real)
>
> ```
>
> Is there a reason other than error handling to not write the function as:
Just guessing, but I think it constrains to Real and Int because other types (complex and non-integer correspondingly) may technically work, but are unlikely to yield correct results.
A simpler example would be `abs(x) = sqrt(x^2)`: this function “works” when passed complex numbers, but the result is nonsensical.
---
### Author:  [@tchebycheff](https://discourse.julialang.org/u/tchebycheff)
#### Post date: [November 25, 2022, 8:23am UTC](https://discourse.julialang.org/t/type-inference/89761/7 "2022-11-25T08:23:12Z")
Yes, it seems to be a form of error handling. The error for complex input (above) does not say complex values are nonsensical; it says that the method signature does not match. There is a difference here i think.