# How to correctly define and call templated/parametric methods using the new 'where' syntax
**URL:** https://discourse.julialang.org/t/how-to-correctly-define-and-call-templated-parametric-methods-using-the-new-where-syntax/24129
**Category:** General Usage
**Created:** [May 12, 2019, 1:10am UTC](https://discourse.julialang.org/t/how-to-correctly-define-and-call-templated-parametric-methods-using-the-new-where-syntax/24129 "2019-05-12T01:10:26Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)
#### Post date: [May 12, 2019, 1:10am UTC](https://discourse.julialang.org/t/how-to-correctly-define-and-call-templated-parametric-methods-using-the-new-where-syntax/24129/1 "2019-05-12T01:10:26Z")
I have already read [the manual](https://docs.julialang.org/en/v1/manual/methods/index.html), [the relevant issue](https://discourse.julialang.org/t/anybody-else-find-the-new-where-syntax-less-than-satisfactory/4897/5), and have done some fair share of googling, so I am getting a little frustrated that I cannot find the missing information.
I come from a C++ background, I wanted to follow a pattern that I follow in my C++ code for performance and flexibility reasons (the c++ templates) and I know that Julia supported something like this at some point:
`f{T}(parameters that do not have type T) = computation using type T inside`
This is, a method that receives a explicit type clearly known in compilation time, and that is not the type of any of its arguments, and use this information to define which object will be used to perform some computation inside the method and/or help to define the return type of the method.
Using the new where syntax I was able to to the following:
`f() where {T} = some code`
However, I do not know how to call this method, as I do not know how to inform T to the method. Obviously, just calling the method, as in:
`f()`
gives
`ERROR: UndefVarError: T not defined`
what I consider expected, but the old syntax:
`f{Int64}()`
gives
`ERROR: TypeError: in Type{...} expression, expected UnionAll, got typeof(f)`
What I suppose means that it expected a type constructor? Not sure, but as this is the old syntax I also understand it should not work. I did not however find any reference to how do this. The comment of [StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski) (that I cited above) is almost what I want, as it seems to mention my problem:
> The only really odd case, as you mention, is `f(...) where T = body` without any type bound, but I’ve found that even this case fairly quickly loses its unfamiliarity.
but he just says that and do not explain how to call. He also says
> The syntax used to define a method always matches the syntax used to call it.
but:
`f() where {Int64}`
gives
`ERROR: UndefVarError: T not defined`
So I am not sure by what he did mean by “always matches”.
Sorry if it is a stupid question, this clearly has a simple answer, but I cannot see it.
---
### Author:  [@dpsanders](https://discourse.julialang.org/u/dpsanders)
#### Post date: [May 12, 2019, 3:05am UTC](https://discourse.julialang.org/t/how-to-correctly-define-and-call-templated-parametric-methods-using-the-new-where-syntax/24129/2 "2019-05-12T03:05:50Z")
If I understand correctly what you’re asking, I don’t think you can do that (define a function that has a type parameter but does not have any arguments that depend on that parameter).
You can, however, define a function that receives a type explicitly and dispatch on that:
```julia
julia> f(::Type{T}) where {T} = T
f (generic function with 1 method)
julia> f(Float64)
Float64
julia> f(::Type{T}) where {T <: Integer} = Int
f (generic function with 2 methods)
julia> f(BigInt)
Int64
```
---
### Author:  [@rdeits](https://discourse.julialang.org/u/rdeits)
#### Post date: [May 12, 2019, 3:54am UTC](https://discourse.julialang.org/t/how-to-correctly-define-and-call-templated-parametric-methods-using-the-new-where-syntax/24129/3 "2019-05-12T03:54:39Z")
If you really really want the `f{T}()` syntax, you could create a parameterized struct and define methods on its type:
```julia
julia> struct Foo{T} end
julia> function Foo{T}() where {T}
println("T = $T")
return zero(T)
end
julia> Foo{Int}()
T = Int64
0
julia> Foo{Float64}()
T = Float64
0.0
```
However, I would 100% recommend doing what @dpsanders suggested instead. While my suggestion looks more like the syntax you’re asking for, his suggestion is cleaner, more Julian, and will be easier to understand and maintain.
---
### Author:  [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)
#### Post date: [May 12, 2019, 5:18pm UTC](https://discourse.julialang.org/t/how-to-correctly-define-and-call-templated-parametric-methods-using-the-new-where-syntax/24129/4 "2019-05-12T17:18:34Z")
Is a ‘class’ method what you want? Then the advice you have gotten from @dpsanders is the way to go. Or, is what you wish to accomplish unrelated to classes? I fail to see how to dispatch properly without passing arguments that could inform the compiler of the type…
---
### Author:  [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)
#### Post date: [May 12, 2019, 5:34pm UTC](https://discourse.julialang.org/t/how-to-correctly-define-and-call-templated-parametric-methods-using-the-new-where-syntax/24129/5 "2019-05-12T17:34:17Z")
Hmm, so I was not finding the answer because it didn’t exactly exist. I thought that there was a difference between passing the type directly as parameter and passing it on a guaranteed-to-be-known-on-compilation-time way. I imagine that in non-dinamic languages (that do not even have a canonical type to represent types) the difference is needed, but in dynamic languages like Julia maybe the difference is not relevant.
This sprouts two immediate doubts in my mind:
1. Why exactly the `::Type{T}` syntax is needed and what it means? (even just a link to a reference to it is welcome)
2. How smart the compiler can be about this? If I have multiple functions that take such type parameter, and I call one of them with a “type literal” (maybe not the right term, but something like Int32, ou Float64, a defined concrete type, I mean), and this function pass down this parameter to the other functions, will the compiler generate a specific native code for all functions using the specific value I passed by parameter? If I remember right, the compiler tries to obtain good performance by specializing for the type of the parameters, if the parameter is a type parameter, it will specialize for its value?
3. If the @dpsanders way is the more “Julian” way, I will use it, except if the @rdeits way (using a struct) has better performance for some reason. I will probably do a benchmark on this.
Thanks @dpsanders and @rdeits for the complete answers.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [May 12, 2019, 5:56pm UTC](https://discourse.julialang.org/t/how-to-correctly-define-and-call-templated-parametric-methods-using-the-new-where-syntax/24129/6 "2019-05-12T17:56:10Z")
1. see the manual, in particular [Types · The Julia Language](https://docs.julialang.org/en/v1/manual/types/#man-singleton-types-1) and [Methods · The Julia Language](https://docs.julialang.org/en/v1/manual/methods/#Design-Patterns-with-Parametric-Methods-1)
2. extremely smart, for concrete types it’s as if they were literally baked into the code or better
3. both are fine strategies and have their place, see the design patterns I linked. When everything is inferred, performance should be equivalent.
---
### Author:  [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)
#### Post date: [May 12, 2019, 7:18pm UTC](https://discourse.julialang.org/t/how-to-correctly-define-and-call-templated-parametric-methods-using-the-new-where-syntax/24129/7 "2019-05-12T19:18:06Z")
Thank you very much. I will adapt my code patterns to the Julian way then.
---
### Author:  [@c42f](https://discourse.julialang.org/u/c42f)
#### Post date: [May 13, 2019, 3:15am UTC](https://discourse.julialang.org/t/how-to-correctly-define-and-call-templated-parametric-methods-using-the-new-where-syntax/24129/8 "2019-05-13T03:15:48Z")
> [@Henrique\_Becker](#):
>
> thought that there was a difference between passing the type directly as parameter and passing it on a guaranteed-to-be-known-on-compilation-time way. I imagine that in non-dinamic languages (that do not even have a canonical type to represent types) the difference is needed, but in dynamic languages like Julia maybe the difference is not relevant.
This is exactly correct.
As @dpsanders pointed out, the “Julian” way is to just pass the type as a value. If you’re coming from C++ (as I did) you’ll find that Julia really removes the design conundrum of “should I do this at compile or runtime” which is always present when designing C++ libraries. Instead, everything has runtime semantics so you can just pass your types around as normal parameters to functions. On the other hand the compiler is really excellent at specializing such code, so you get a lot of convenience and rarely pay a price for it.
To give a concrete example of how such interfaces look in julia, consider the standard `convert(T,x)` function which takes the type `T` as the first argument.
The generated code is efficient when the type is inferred to be a constant, for example:
```julia
julia> foo(x) = convert(Float64, x)
foo (generic function with 1 method)
julia> @code_native foo(1) # convert from Int64
.text
vcvtsi2sdq %rdi, %xmm0, %xmm0
retq
nopw %cs:(%rax,%rax)
julia> @code_native foo(1.0) # Float64->Float64 ... nothing to do
.text
retq
nopw %cs:(%rax,%rax)
julia> @code_native foo(1.0f0) # convert from Float32 to Float64
.text
vcvtss2sd %xmm0, %xmm0, %xmm0
retq
nopw %cs:(%rax,%rax)
```
---
### Author:  [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)
#### Post date: [May 13, 2019, 1:48pm UTC](https://discourse.julialang.org/t/how-to-correctly-define-and-call-templated-parametric-methods-using-the-new-where-syntax/24129/9 "2019-05-13T13:48:17Z")
Thank you Chris for putting my mind at rest. I will make an habit of
using `@code_native` for checking such things, I did not use it before
because I am not very familiar with assembler, but seems a great tool
if you can break the functions in small ones.
---
### Author:  [@c42f](https://discourse.julialang.org/u/c42f)
#### Post date: [May 14, 2019, 12:52am UTC](https://discourse.julialang.org/t/how-to-correctly-define-and-call-templated-parametric-methods-using-the-new-where-syntax/24129/10 "2019-05-14T00:52:48Z")
Personally I just know enough assembly to be dangerous 😉 Having said that, I do find that it’s quite useful to look at `@code_native` to maintain a mental model of what causes the compiler to generate “obviously bad” code.
For something higher level, check out `@code_warntype` to see how inference is doing on a given function call. If you want a more powerful version of `@code_warntype` which lets you statically step into an inferred tree of function calls, check out [Cthulhu.jl](https://github.com/JuliaDebug/Cthulhu.jl).
---
### Author:  [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)
#### Post date: [May 14, 2019, 2:44am UTC](https://discourse.julialang.org/t/how-to-correctly-define-and-call-templated-parametric-methods-using-the-new-where-syntax/24129/11 "2019-05-14T02:44:12Z")
Thank you again. This topic keeps on giving, XD. I tried to use @trace
(from Traceur) but: 1) even things that were instantaneous before
becomes unbearably slow; 2) its default behavior is to output a
warning with just the line where the problem happened, so the problem
can happen in a method of a distant Module that I do not even know
which line of my code ends up using. I will experiment with
@code\_warntype and Cthulhu.jl for the checking the types in the
future.