I haven't dug that deep into the internals, but I tend to use the
`f1(T1::Type)` where T1 is completely unconstrained, and can be any type in
the system. On the other hand, I use the second version when I want to
constrain the types that can be possible arguments:
`f2{T2<:Number}(::Type{T2})`
On Thursday, 27 February 2014 23:59:52 UTC, Kevin Squire wrote:
>
>
> That's actually a rather deep question. A definitive answer can probably
> only come from the core developers, but playing with some examples can give
> some hints. Try these at the REPL:
>
> f1(T1::Type) = T1
> f2{T2}(::Type{T2}) = T2
> code_native(f1, (Type{Int},))
> code_native(f2, (Type{Int},))
> code_native(f1, (Type{FloatingPoint},))
> code_native(f2, (Type{FloatingPoint},))
>
> f1(T1::Type) = super(T1)
> f2{T2}(::Type{T2}) = super(T2)
> code_native(f1, (Type{Int},))
> code_native(f2, (Type{Int},))
> code_native(f1, (Type{FloatingPoint},))
> code_native(f2, (Type{FloatingPoint},))
>
> Some things to note:
>
> - For f1, T1 is popped from the call stack, and for f2, T2 is a
> constant.
> - Different versions of the f1 and f2 are compiled for different types
> (at least for the second set of functions). Because of this, the two
> functions end up having very similar behavior.
>
>
> Cheers!
> Kevin
>
>
> On Thursday, February 27, 2014 2:53:21 PM UTC-8, Sam L wrote:
>>
>> If I want to write a function that takes a type as an argument, is there
>> a difference between how T1 behaves in f1 and how T2 behaves in f2 if the
>> functions have signatures f1(T1::Type) and f2{T2}(::Type{T2})?
>>
>> Thanks,
>> Sam
>>
>
