# Dynamic type declarations
**URL:** https://discourse.julialang.org/t/dynamic-type-declarations/3239
**Category:** General Usage
**Created:** [April 16, 2017, 3:31am UTC](https://discourse.julialang.org/t/dynamic-type-declarations/3239 "2017-04-16T03:31:05Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@poke1024](https://discourse.julialang.org/u/poke1024)
#### Post date: [April 16, 2017, 3:31am UTC](https://discourse.julialang.org/t/dynamic-type-declarations/3239/1 "2017-04-16T03:31:05Z")
Hello, I just stumbled across
> local f = function(T::Type)
> return function(x::T)
> x + 1
> end
> end
which gives “UndefVarError: T not defined” due to the inner x::T.
This is a bit surprising to me, as using dynamic types is allowed for local, i.e. the following is ok:
> local f = function(T::Type)
> local x::T = 3
> x + 1
> end
Now, I’m aware that I could rewrite the first example with something like `eval(Expr(:function, Expr(:tuple, Expr(:(::), :x, T) ...`, but unfortunately, in my specific use case I actually need a capture (thus breaking the eval approach due to eval’s global scope), i.e. what I actually want to achieve is this:
> local y
> local f = function(T::Type)
> return function(x::T)
> x + y
> end
> end
Is there any sensible to achieve this?
---
### Author:  [@rdeits](https://discourse.julialang.org/u/rdeits)
#### Post date: [April 16, 2017, 4:04am UTC](https://discourse.julialang.org/t/dynamic-type-declarations/3239/2 "2017-04-16T04:04:36Z")
One option would be to replace `function(x::T)` with
```julia
function(x)
typeassert(x, T)
x + y
end
```
---
### Author:  [@poke1024](https://discourse.julialang.org/u/poke1024)
#### Post date: [April 16, 2017, 5:45am UTC](https://discourse.julialang.org/t/dynamic-type-declarations/3239/3 "2017-04-16T05:45:10Z")
I know, I used `x::T + y` temporarily, which is similar, I guess.
But I wonder if needing to have the parameter types of lambdas fixed in this way is expected behaviour in Julia or if it can be considered a bug.
Yet using `typeassert` seems to be a very good solution, as it produces efficient code:
```julia
function f(x)
typeassert(x, Int)
x + 1
end
@code_llvm f(10)
```
```julia
define i64 @julia_f_71777(i64) #0 {
top:
%1 = add i64 %0, 1
ret i64 %1
}
```
---
### Author:  [@yuyichao](https://discourse.julialang.org/u/yuyichao)
#### Post date: [April 16, 2017, 12:56pm UTC](https://discourse.julialang.org/t/dynamic-type-declarations/3239/4 "2017-04-16T12:56:40Z")
It is expected. The closure you create on multiple invocations of the parent function are of the same type and the method definition including the dispatch specification is statically computed at compile time. The sementic is defined this way since doing it otherwise would be very expensive, either you have to create new type or adding new method to a type at runtime.
That said, it is not impossible to transform the code to do an assertion in this case automatically. However, since it will **NOT** have the same semantic as specifying the dispatch it’s a little bit confusing (not much) if we do so.
---
### Author:  [@rdeits](https://discourse.julialang.org/u/rdeits)
#### Post date: [April 18, 2017, 3:32am UTC](https://discourse.julialang.org/t/dynamic-type-declarations/3239/5 "2017-04-18T03:32:27Z")
Note that the typeassert isn’t necessary if you’re just trying to produce efficient code:
```julia
julia> function f(x)
x + 1
end
f (generic function with 1 method)
julia> @code_llvm f(10)
define i64 @julia_f_70822(i64) #0 {
top:
%1 = add i64 %0, 1
ret i64 %1
}
```