Provide better constructors for type with tag-parameter

[mauro3]

The constructor is missing:

julia> type A{T,S}
       a::S
       end

julia> A{Int}(5)
ERROR: MethodError: Cannot `convert` an object of type Int64 to an object of type A{Int64,S}
This may have arisen from a call to the constructor A{Int64,S}(...),
since type constructors fall back to convert methods.
 in A{Int64,S}(::Int64) at ./sysimg.jl:63
 in eval(::Module, ::Any) at ./boot.jl:234
 in macro expansion at ./REPL.jl:92 [inlined]
 in (::Base.REPL.##1#2{Base.REPL.REPLBackend})() at ./event.jl:46

When the tag-parameter is in the first position (or also multiple), I think it is unambiguous that I mean to call this constructor:

julia> (::Type{A{T}}){T,S}(a::S) = A{T,S}(a)

julia> A{Int16}(5)
A{Int16,Int64}(5)

Would it be possible to automatically provide it?

[JeffBezanson]

Yes, it should be possible to add this. Seems like a good feature.

[JeffreySarnoff]

➕ 3️⃣ (keep the pattern walking, too; to feature more of this good feature)

julia> type A{T,S}
       a::T
       end

julia> A{Int}(5)
# unambiguously understood to be as
julia> (::Type{A{T}}){T,S}(a::T) = A{T,S}(a) 
julia> A{Int16}(5)
A{Int64,Int16}(5)

Whether my free parameter is to be as leader or as follower in a given type's param parade should remain my decision and guided by descriptive design rather than determined by broken symmetry.
I have used both positions and like that expressive freedom -- it regards source is communication.

[yuyichao]

That can be too confusing for

type A{T<:Integer,S<:AbstractFloat}
    a::T
end

[JeffreySarnoff]

@yuyichao why? T is T and S is not T.

[yuyichao]

A{Float64}(1) won't work. Even without the type constraint, A{Float64}(1) will still be confusing since A{Float64}(1) would be A{Int,Float64}(1) which is not an instance of A{Float64}.

[JeffreySarnoff]

Maebee. That's not how I use 'external' parameters, so I have no opinion about that.

[cstjean]

@shashi pointed out a related example:

type A{T}
   a::T
   b::Float64
end

A(2, 3)  
> ERROR: MethodError: no method matching A(::Int64, ::Int64)

[StefanKarpinski]

That seems correct to me, no?

[yuyichao]

It is correct in that it's currently the expected behavior. We could define A{T}(a::T, b) automatically for it though. It should be possible to determine the arguments/fields that isn't involved in inferring the type parameter syntactically and define the method with relaxed argument types.