syntactic sugar Foo{<:Bar} for Foo{T} where T<:Bar

[stevengj]

This closes #6984 by adding the syntactic sugar Foo{<:Bar} for Foo{T} where T<:Bar. Update: similarly for Foo{>:Bar}.

It combines fine with the where syntax, e.g. TwoParams{S,<:Number} where S<:Real works.

If you nest types, then the where goes with the innermost type where the <: appeared, e.g. Vector{Foo{<:Bar}} is Vector{Foo{T} where T<:Bar}. You can nest these, e.g. Vector{<:Foo{<:Bar}} works.

[ararslan]

Worth linking to https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science), do you think?

[stevengj]

I added a link above.

[JeffBezanson]

I have to admit, this is really nice.

As it happens, it's also gentler on the type/dispatch system, since it moves where clauses inside types relative to the current idiomatic way to write this, f{T<:Real}(x::Array{T}). You generally want T to cover as little of the signature as possible.

[stevengj]

Since this syntax parses in Julia 0.5, it should be possible to make @compat function f(x::Array{<:Real}) method definitions transform to function f{T<:Real}(x::Array{T}), at least for the common non-nested case.

The nested case, e.g. f(x::AbstractArray{<:AbstractArray{<:Real}}), seems impossible to express in 0.5 since it requires triangular dispatch?

[JeffBezanson]

Yes, the nested case can't be expressed in 0.5. The closest thing might be to have Compat convert <:Real to TypeVar(:T, Real, false), just dropping a free typevar in there. But this doesn't seem likely to work in all cases.

[stevengj]

Oh, cool, I didn't know about TypeVar in 0.5. That will make the @compat macro much easier to write. In Julia 0.5:

julia> @eval f(::Array{$(TypeVar(:T, Real, false))}) = 1
f (generic function with 1 method)

julia> f([2,3,4])
1

[stevengj]

Should be good to merge?

[KristofferC]

Can you do ex Point{T<:Real} and use T in the body?

[stevengj]

@KristofferC, no, if you want to do that I think you need to declare a type parameter explicitly. Otherwise, what is the scope for T? If you can figure out a good way to define it and we decide we want that, I think that would be a separate PR anyway.

Note that if you do f(x::Complex{T} where T<:Real) = T, this will throw an error on f(3+4im) because T is only defined inside the where statement, not in the body of the function.

[KristofferC]

Ah, thanks for explaining.

[JeffBezanson]

At some point we should take a pass through Base and use this where possible; that will help eliminate uses of to-be-deprecated static parameter syntax.

[stevengj]

Unfortunately, it looks like the TypeVar trick won't work in the @compat macro because the second argument to TypeVar needs to be a type, but at the time of macro evaluation we only have a symbolic expression for the type.

[stevengj]

(Of course, I could just eval the type expression in the current module and hope for the best. This will cover the common case of function definitions, I guess)

[yuyichao]

For most (all?) cases, simply leave a TypeVar(....) as expression in the code should work too.

[stevengj]

@yuyichao, great, I thought the TypeVar had to be spliced in. I've submitted a Compat PR, it seemed remarkably easy.