constraints on non-type as type parameters

[yuyichao]

When a type parameter is specified to be T <: Top, it actually accept non-type as parameters as well.

julia> type A{T<:Top}
       end

julia> A{1}
A{1}

julia> A{1.2}
A{1.2}

Although 1 and 1.2 are clearly not subtypes of Top

julia> 1 <: Top
ERROR: type: subtype: expected Type{T<:Top}, got Int64

julia> 1.2 <: Top
ERROR: type: subtype: expected Type{T<:Top}, got Float64

This is also the case for the builtin Type (some other types like Array doesn't even have this constraint specified)

julia> Type
Type{T<:Top}

julia> Type{1}
Type{1}

julia> Type{1.2}
Type{1.2}

No error is raised even if this parameter is used as a type of a field

julia> type A{T<:Top}
       a::T
       end

julia> A{1}
A{1}

julia> A{1}.names
(:a,)

julia> A{1}.types
(1,)

The same thing happens for T <: Any although this time it correctly reject Core.Unref

julia> type A{T <: Any}
       end

julia> A{1}
A{1}

julia> A{1.2}
A{1.2}

julia> A{Core.Undef}
ERROR: type: A: in T, expected T, got Type{Undef}

julia> Core.Undef <: Any
false

Specifying other types seems fine

julia> type C{T <: Integer}
       end

julia> C{1}
ERROR: type: C: in T, expected T<:Integer, got Int64

julia> C{Int}
C{Int64}

Another related issue is that Vararg doesn't specify any constraint on the parameter and therefore the following syntax is allowed.

julia> (1...)[1]
1...

julia> typeof((1...)[1])
DataType

[JeffBezanson]

This is not a high priority, since it doesn't prevent anybody from getting work done.

[yuyichao]

I agree, I couldn't really think of a situation that this can affect the correctness of valid code either. It's only a little bit confusing when I did sth wrong and the error pops up in unrelated place etc...

[vtjnash]

the Top and Undef types are gone now. its unclear to me if type A{T<:Any} end is supposed to mean something different from type A{T} end, which was the remaining odd case observed here.

[toivoh]

Well it would definitely seem reasonable that T would be constrained to be a type in the former case, but I don't know enough about the internals to day whether it would be reasonable to change it to work like that.

[yuyichao]

Yeah, I relized that Top and Undef are gone. However, this issue is about T <: Any (and also T <: Top before) accepting non-type as type parameters.

Conceptually type A{T<:Any} end means A{1} is not allowed.

[yuyichao]

I guess it requires a field in TypeVar to define whether non-type is allowed? Although I guess there's a number of other places that needs to be changes as well.

[yuyichao]

At some point I was also thinking that it might be nice to be able to write sth like

type A{T<:Top, N::Int}
...
end

So that the first parameter has to be a type and the second has to be a Int.

The (only) benefit would be less confusion and less manual checking if one want to be safe but I'm not sure how big a change it requires in the underlying system...

Edit: I am aware that T <: Top is a boolean expression while N::Int is an assertion so it's not that consistent but I guess the meaning should be pretty clear....

[toivoh]

This idea has come up before (a long time ago I believe), I also think that it would be a good addition (and don't know how hard it would be).

[mgkuhn]

As far as I can tell, the Julia documentation does at the moment not explicitly state, what values are permitted as type parameters. All the examples I found show only other types as type parameters. Are e.g. integer values also allowed as type parameters? Any immutable value that can be created at compiler time (e.g. a text string)?

A good practical application example of an integer parameter would be a parametric modular-arithmetic type, where the modulus is compiled into the code, rather than being encoded as a run-time parameter along with each value. Imagine an application that does a lot of modular arithmetic, but only ever with the three fixed modulus values 5, 7 and 17. It would be great to be able to implement that via a single parametric "type Mod{modulus::Int} v::Int; end", which the programmer can then instantiate as types Mod{5}, Mod{7} and Mod{17} and add with "+(x::Mod{N}, y::Mod{N}) = Mod{N}(mod(x.v+y.v, N))"?

At the moment, the latter results in "ERROR: UndefVarError: N not defined".

[mbauman]

Please ask questions about usage on our discourse message board.

For documentation, see the first section of the page you linked, the last bullet point. Integers as type parameters are fully supported and frequently used. That's how we encode the dimensionality in our arrays. In fact, your exact example is in the examples/ folder.

The thing you're running into is that Julia does not support isa (::) restrictions within type parameter lists. Only subtype (<:) expressions are currently supported. But this is unrelated to this issue. If you have further questions, please continue the discussion on the message board.