Relax the constraint of parameter order for parameter type constructor

[frankwswang]

julia> struct myT{A<:Real, B}
           a::A
           myT{B}(a::A) where {A, B} = new{A, B}(a)
       end

julia> myT{Vector{Int}}(1, [1])
ERROR: TypeError: in myT, in A, expected A<:Real, got Type{Vector{Int64}}
Stacktrace:
 [1] top-level scope
   @ REPL[2]:1

Currently, when a constructor of a parameter type has explicit parameters in the {} part of its definition, even if not all of the parameters are included, they are still constrained by the type's struct definition. I wonder if this constraint could be loosened in the future release. This will make cases like the above prompt error exception. The reason I would need such a use case is to use the parameters in {} for multiple dispatch. Thanks!

[frankwswang]

I know that for now I can always do something like myT(::Val{B}, a::A) where {A, B} = new{A, B}(a). So maybe this proposal is not really worthy, although it does give a cleaner syntax.

[simeonschaub]

That sounds unnecessarily confusing. myT{Vector{Int}} is equivalent to myT{Vector{Int}, B} where B and as such this constructor also wouldn't fulfill the general assumption that myT{Vector{Int}}(1, [1]) isa myT{Vector{Int}}

[frankwswang]

That sounds unnecessarily confusing. myT{Vector{Int}} is equivalent to myT{Vector{Int}, B} where B and as such this constructor also wouldn't fulfill the general assumption that myT{Vector{Int}}(1, [1]) isa myT{Vector{Int}}

Thanks for the reply! Your reason is exactly what I wanted to question. Why should myT{A}(args...) necessarily correspond to myT{A, B}? It's a constructor, hence just a Function method that creates the actual struct of type myT with certain type parameters. You can even define a method (as an outer constructor) like

myT{T}() where {T} = T

which doesn't actually construct a new instance of myT. So I would argue myT{A}(args...) is closer to a generic function than an extension of the parametric type. Also, if each item in (args...) doesn't have to strictly correspond to each field of the created type instance, why should the parameters in {T...} of the constructor do? What's more, we already have an inner construction that meets what you ask for: new{T...}(fields...) that is directly tied to the type information of constructed myT. Unless there's some performance concern for keeping this constraint, I don't think it's necessary nor creates confusion.

[JeffBezanson]

The syntax myT{A}(args...) = ... doesn't define some separate function from myT; it specifies what to do when the object myT{A} is called. The function and the type are one and the same. Whether it constructs an instance or not is not relevant; what matters is that the type itself is the called object. So I believe this is not really possible to implement.

To elaborate further, myT{A}(x) does the same thing as

f = myT{A}
f(x)

so the myT{A} syntax indeed must mean the same thing in both cases.

[vtjnash]

you can define myS{B, A<:Real} = myT{A, B}, then use myS where ever you need this

[frankwswang]

The syntax myT{A}(args...) = ... doesn't define some separate function from myT; it specifies what to do when the object myT{A} is called. The function and the type are one and the same. Whether it constructs an instance or not is not relevant; what matters is that the type itself is the called object. So I believe this is not really possible to implement.

To elaborate further, myT{A}(x) does the same thing as

f = myT{A}
f(x)

so the myT{A} syntax indeed must mean the same thing in both cases.

I guess this really unveiled the different perspectives of treating f here. Is it a function that looks like type myT or a type instance that can be treated like a function? In the current state of Julia it seems that the priority of parametric types is over function methods.

[JeffBezanson]

It's not really meaningful in julia to ask whether f is or is not a function. In general, all you can say is whether a method exists that matches a given call. In f(x), we have an ordered pair f x, and we try to find a method that matches those objects. A "constructor" like Pair(1, 2) is just a method that matches the objects Pair, 1, and 2, and Pair happens to be a type as well.

[frankwswang]

It's not really meaningful in julia to ask whether f is or is not a function. In general, all you can say is whether a method exists that matches a given call. In f(x), we have an ordered pair f x, and we try to find a method that matches those objects. A "constructor" like Pair(1, 2) is just a method that matches the objects Pair, 1, and 2, and Pair happens to be a type as well.

Thanks! That helps to clarify a lot. I thought methods are only connected to functions because when I called methods I got:

julia> methods(myT)
# 0 methods for type constructor:

despite I have defined 2 methods myT{B}(a::A) where {A, B} and myT{T}() where {T}.

[StefanKarpinski]

You're asking for methods of myT which tells you which methods can be called as myT(...) without any type parameters. You haven't defined any such methods, so there aren't any. If you ask for methods of a specific myT you'll see them:

julia> methods(myT{Int})
# 1 method for type constructor:
[1] (myT{B})(a::A) where {A, B} in Main at REPL[2]:3

I don't know if there's a way to ask for methods with a type parameter without picking an actual type parameter value but you can always do methods(myT{Union{}}) (although there might be lower bounds on the type parameter, so you do need to find a type that actually inhabits the parameter space).

[JeffBezanson]

Unfortunately we only have an easy methods(f) call for the case where you have the specific callable object f. We could potentially add something similar for when you only know the type of the callable, then you could ask for e.g. methodsT(Type{<:myT}), which would give all constructors for any sort of myT type, which would be pretty useful.