# Type-annotate vs convert
**URL:** https://discourse.julialang.org/t/type-annotate-vs-convert/4404
**Category:** General Usage
**Created:** [June 22, 2017, 2:46am UTC](https://discourse.julialang.org/t/type-annotate-vs-convert/4404 "2017-06-22T02:46:14Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@Stephen\_Vavasis](https://discourse.julialang.org/u/Stephen_Vavasis)
#### Post date: [June 22, 2017, 2:46am UTC](https://discourse.julialang.org/t/type-annotate-vs-convert/4404/1 "2017-06-22T02:46:14Z")
Consider the issue of annotating types of objects taken from unknown sources. The following are two solutions to this problem:
```julia
function test1(a::Vector{Any})
x = a[1]::Int
2*x
end
```
and
```julia
function test2(a::Vector{Any})
x = convert(Int, a[1])
2*x
end
```
The manual recommends the first solution in the Performance-Tips section. It seems to me that the second solution might be preferable in many instances because the resulting code has greater genericity. But `@code_warntype` on `test2` gave me many more warnings than on `test1`– it reported that `x` and `2*x` in `test2` were both of type `Any`. (Julia 0.5.2).
Why does the compiler not know the types in `test2`?
---
### Author:  [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [June 22, 2017, 4:06am UTC](https://discourse.julialang.org/t/type-annotate-vs-convert/4404/2 "2017-06-22T04:06:45Z")
`convert` is just a normal function — it doesn’t have any special sauce besides a very strong convention that `convert(T, x)` returns something of type `T`. Just like calling all other functions with an unknown argument, Julia doesn’t know exactly which method of `convert` will be called, and so it can’t make any assumptions about the return type.
The type assertion `a[1]::T`, on the other hand, will _error_ if `a[1]` is anything but `T`, meaning that Julia can conclusively determine that every time control flow successfully passes the assertion `a[1]` is a `T`.
---
### Author:  [@greg\_plowman](https://discourse.julialang.org/u/greg_plowman)
#### Post date: [June 22, 2017, 5:15am UTC](https://discourse.julialang.org/t/type-annotate-vs-convert/4404/3 "2017-06-22T05:15:33Z")
Maybe both:
```julia
x = convert(Int, a[1])::Int
```
---
### Author:  [@nalimilan](https://discourse.julialang.org/u/nalimilan)
#### Post date: [June 22, 2017, 10:29am UTC](https://discourse.julialang.org/t/type-annotate-vs-convert/4404/4 "2017-06-22T10:29:04Z")
There have been discussions about enforcing that `convert(T, x)::T`, but for now you can use both `convert` and an assertion.
---
### Author:  [@Stephen\_Vavasis](https://discourse.julialang.org/u/Stephen_Vavasis)
#### Post date: [June 22, 2017, 5:47pm UTC](https://discourse.julialang.org/t/type-annotate-vs-convert/4404/5 "2017-06-22T17:47:09Z")
Thanks for the explanation. In retrospect, this makes perfect sense.
As a general matter, I worry that Julia’s great flexibility (such as the flexibility to define a `convert(T,x::X)` that returns a non-`T`) opens up many pitfalls for the user. But this particular piece of flexibility seems potentially useful. So I have just submitted a PR for the manual to explain the point.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [June 23, 2017, 5:37am UTC](https://discourse.julialang.org/t/type-annotate-vs-convert/4404/6 "2017-06-23T05:37:59Z")
> [@Stephen\_Vavasis](#):
>
> But this particular piece of flexibility seems potentially useful.
Can you given an example for when `convert(T, ...)` returning a non-`T` would be useful?
---
### Author:  [@Stephen\_Vavasis](https://discourse.julialang.org/u/Stephen_Vavasis)
#### Post date: [June 23, 2017, 12:14pm UTC](https://discourse.julialang.org/t/type-annotate-vs-convert/4404/7 "2017-06-23T12:14:47Z")
This is a bit of a stretch…
In the following old thread:
> [@Recovering parameter type from parameter list](https://discourse.julialang.org/t/recovering-parameter-type-from-parameter-list/1343):
>
> Suppose I want to be generic as follows: # concepts abstract AbstractFoo{N,T} abstract AbstractContainer{F} # partial specialization where we fix T = Float64 immutable Foo{N} \<: AbstractFoo{N,Float64} end # a container of AbstractFoo{N,T} where we save state in a vector of T immutable Container{F\<:AbstractFoo{N,T}} \<: AbstractContainer{F} state::Vector{T} end The code above doesn’t compile because of the malformed parameter list. What is the best way to recover the type T from the type Abs…
I proposed a solution (untested!) to the original poster’s problem. The solution involved a constructor for a type `S` that returned a non-`S`. I believe that this is permitted by the language. Meanwhile, there is a close relationship between constructors and `convert`. So I can imagine that there are situations for constructing complex types in which defining `convert(T,x)` to return a non-`T` might be useful.