f{T<:Real}(x::T) and f(x::Real) have the exact same applicability. One
definition should overwrite the other, so currently this is a bug that
should be fixed as part of #8974. The way to read the first type is

Union over all T<:Real . T

Of course the biggest difference is that there will be a `T` inside
the first function set to the type of the argument. If you don't need
that, the second version is preferred since it's simpler.

In *some* cases the need to bind `T` inside the function will force
the compiler to specialize a function for more different types than it
otherwise would. This typically happens with tuple types, since there
are "too many" of them (O(n^m)).


On Mon, Dec 8, 2014 at 3:36 AM,  <[email protected]> wrote:
>
>
> On Monday, December 8, 2014 6:16:25 PM UTC+10, David van Leeuwen wrote:
>>
>> Good question, I would be interested in the answer myself.  If the tips
>> indicate the explicit type dependency is preferred, then I guess that for
>> the first form the compiler compiles a new instance of the function
>> specifically for the concrete type `T`, while in the second, it presumably
>> compiles to deal with a (partly) type-instable `x` within the function body.
>>
>> f1{R<:Real}(x::R) = -x
>>
>> f1(x::Real) = x
>>
>> f1 (generic function with 2 methods)
>>
>> So the methods are kept separate, but I think the first form hides access
>> to the second form.
>
> IIUC it doesn't really "hide" it, but for a call like f1(1.0) the generic
> can be used to generate f1(x::Float64) which is more specific than
> f1(x::Real) so it is used instead.
>
>
>>
>>
>> On Monday, December 8, 2014 7:12:39 AM UTC+1, Igor Demura wrote:
>>>
>>> What exactly the difference between:
>>> function foo{T<:AbstractType}(x::T) = ...
>>> and
>>> function foo(x::AbstractType) = ... ?
>>> Is any difference at all? The "tips" section of the docs says the second
>>> is preferred. If they are the same, why first syntax?
>
>
> See above.
>
>>>
>>> I can imagine that I can benefit if I have several parameters:
>>> function bar{T<:AbstractType}(x::Concrete{T}, y::AnotherOf{T}, z::T) =
>>> ...
>>>
>

Reply via email to