forward propagate type parameter constraints of super class

[vtjnash]

type parameters of subtypes should probably inherit the type intersection of their usage(s) in the subclass:

abstract Country
abstract AbstractAsset{Listed<:Country,Origin<:Country}
type Stock{Listed,Origin} <: AbstractAsset{Listed,Origin}; end

julia> Stock <: AbstractAsset # oops, this doesn't make complete sense
false

julia> Stock <: super(Stock)
true

julia> super(Stock) <: AbstractAsset
false

julia> super(Stock)
AbstractAsset{Listed,Origin}

julia> Stock
Stock{Listed,Origin}

julia> AbstractAsset
AbstractAsset{Listed<:Country,Origin<:Country}

julia> Stock <: AbstractAsset{TypeVar(:_), TypeVar(:_)}
true

julia> AA=AbstractAsset{TypeVar(:_), TypeVar(:_)} # similarly, this should probably have updated the type bound of the typevar to reflect the constraint that will exist upon creation
AbstractAsset{_,_}

consider also the following cases for implementation:

type SingleStock{Listed} <: AbstractAsset{Listed,Listed}; end
type InvalidStock{N<:Integer} <: AbstractAsset{N,N}; end

from the mailing list: https://groups.google.com/d/msg/julia-users/5GtBjAfLRbQ/idIR6IHhsdkJ

[davidagold]

@vtjnash Which of the following behaviors (of Stock and Stockk) do you think ought to be included in a resolution of this issue?

abstract Country
abstract AbstractAsset{Listed<:Country,Origin<:Country}
type US <: Country; end

type Stock{Listed<:Country, Origin<:Country} <: AbstractAsset{Listed, Origin}; end
type Stockk{Listed, Origin} <: AbstractAsset; end

julia> Stock <: AbstractAsset
true

julia> super(Stock{US, US})
AbstractAsset{US,US}

julia> Stockk <: AbstractAsset
true

julia> super(Stockk{US, US})
AbstractAsset{Listed<:Country,Origin<:Country}

EDIT: Upon reflection it seems that only the behavior of Stock would be relevant here; the behavior of Stockk is orthogonal to the current issue since the type parameters don't appear in both the sides of the declaration(?).

[vtjnash]

EDIT: Upon reflection it seems that only the behavior of Stock would be relevant here; the behavior of Stockk is orthogonal to the current issue since the type parameters don't appear in both the sides of the declaration(?).

yes, it is a bit confusing and misleading to be giving the parameters the same name, since they are bound by position and not name

[yuyichao]

I believe this may be related to the segfault of the following script

abstract C{T<:Union(Void, Int)}
type D{T} <: C{T} d::T end

for i = 1:1000
    println(D(Float64(i)))
end

[yuyichao]

So one thought when working on #11606 is that should these also apply to members as well?

It would be wierd if the type constraints is different for the following two cases

abstract A{T<:Integer}

type B{T}
a::A{T}
end

type C{T} <: A{T}
end

[yuyichao]

The method version of this is causing an ambiguity issue on master.

julia> type A{T<:Unsigned,N} <: Real
       end

julia> f{T<:Unsigned,T2,N}(::Type{A{T,N}}, x::A{T2}) = 1
f (generic function with 1 method)

julia> f{U<:A}(::Type{U}, x::Real) = 2
f (generic function with 2 methods)

julia> f(A{UInt8,8}, A{UInt16,8}())
1

julia> g{T,T2,N}(::Type{A{T,N}}, x::A{T2}) = 1
g (generic function with 1 method)

julia> g{U<:A}(::Type{U}, x::Real) = 2
g (generic function with 2 methods)

julia> g(A{UInt8,8}, A{UInt16,8}())
ERROR: MethodError: g(::Type{A{UInt8,8}}, ::A{UInt16,8}) is ambiguous. Candidates:
  g{U<:A}(::Type{U}, x::Real) in Main at REPL[6]:1
  g{T,T2,N}(::Type{A{T,N}}, x::A{T2,N} where N) in Main at REPL[5]:1

This needs to be worked around in https://github.com/JuliaMath/FixedPointNumbers.jl/pull/66/files#diff-3e207ee23e45a99d2de56bc3e3182065R40

[JeffBezanson]

Dup of #9441 I think?

[KristofferC]

Closing as dup