Incorrect "Method definition overwritten" error

[nalimilan]

The error message below (with a recent git master) seems incorrect:

julia> type T
           x::Tuple{Int, Int}
       end
       T(x) = IConvError((x, x))
WARNING: Method definition call(Type{Main.T}, Any) in module Main at none:2 overwritten at none:4.

Indeed, the method isn't overwritten at all:

julia> methods(T)
4-element Array{Any,1}:
 call(::Type{T}, x::Tuple{Int64,Int64}) at none:2
 call(::Type{T}, x) at none:4                    
 call{T}(::Type{T}, arg) at essentials.jl:62     
 call{T}(::Type{T}, args...) at essentials.jl:63 

julia> T((1,1))
T((1,1))

[yuyichao]

It is overwriting the methods.

julia> type T
           x::Tuple{Int,Int}
       end

julia> methods(T)
3-element Array{Any,1}:
 T(x::Tuple{Int64,Int64}) at none:2     
 T(x) at none:2                         
 (::Type{T}){T}(arg) at essentials.jl:25

julia> T(x) = error(x)
WARNING: Method definition (::Type{Main.T})(Any) in module Main at none:2 overwritten at none:1.
T

julia> methods(T)
3-element Array{Any,1}:
 T(x::Tuple{Int64,Int64}) at none:2     
 T(x) at none:1                         
 (::Type{T}){T}(arg) at essentials.jl:25

It might not be very useful though...

[JeffBezanson]

Ah yes, it's overwriting a default constructor. That is indeed kind of unfortunate.

[nalimilan]

Good catch, I forgot there's also a constructor with a broad signature.

Maybe we'd need the concept of low-priority methods which can be overwritten without a warning. That could also be useful for example to allow delegating most methods for a type to one of its fields (#2248): you would be able to overwrite some methods after the @delegate macro would have defined them with a low priority. This was mentioned this at #3292 (comment) and following comments. Though defining the specific methods first, and calling the macro afterwards so that it only defines the missing ones might also work, not sure.

[jiahao]

I'd like to propose that this issue be categorised as a bug and put on the 0.5.x milestone. I've hit this issue in my own code

[JeffBezanson]

With #11310, it will be easy to put "outer" constructors (i.e. constructors where type parameters have not been specified) inside type blocks, so there won't really need to be "outer" constructors any more.

[JeffBezanson]

@jiahao Could you clarify? The only "complete fix" I have in mind is to make it syntactically easier to write all constructors inside the type block. I would not want to do something like changing which default constructors we generate or which warnings we give. What fix are you thinking of?

[nalimilan]

No warning is printed on current master.