Best practices to add more than one bound to type parameters

[frankwswang]

@frankwswang

N is not explicitly presented, which is what I really wanted. Because in practice, I want something like:

struct myT{T, N, V<:NTuple{N, T}}
    a::V # V should also be constrained to subtypes of TwoOrThreeTuple{T}
    b::Array{T, N}
    c::Tuple{Int, Vararg{V, N}}
    # more fields...
end

Please refer to the above demo. My end goal is to add more type fields with concrete type constraints while introducing as few new type parameters as possible.

This includes adding more constraints to a single field, which is what my original simplified MWE was trying to show:

@frankwswang

MWE:

julia> const TwoOrThreeTuple{T} = Union{NTuple{2, T}, NTuple{3, T}}
Union{Tuple{T, T}, Tuple{T, T, T}} where T

julia> struct myT{T, N, NTuple{N, T}<:V<:TwoOrThreeTuple{T}}
       a::V
       end

julia> myT((1,2))
ERROR: UndefVarError: `N` not defined

In this way, I can (re-)use N and T to constrain more fields like .b::Array{T, N} and .c::Tuple{Int, Vararg{V, N}} without introducing new dedicated type parameters for them.

Additionally, by reusing the same type parameters, I hope to provide more information to the compiler for type inference when certain functions can only access part of the composite types. Although, this is not necessarily achievable given the current state of Julia’s compiler. That’s why I didn’t mention it before.

[frankwswang]

Ehm… I’ll think about it… Thanks!

[DNF]

This is definitely a more interesting example. Of course, you could even here reduce the number of type parameters to two, ditching the V, while fully expressing the type coupling, if you constrained N in the constructor instead.

It’s still not entirely clear to me why that simplification isn’t an option, but I understood that it’s not.

[frankwswang]

Yeah… I wish there were more ways for us to manipulate/control TypeVars…