Hit-and-miss method ambiguity detection?

[timholy]

In Images, check out commit ddb4259fb2ac39464ed451c5f627d2cd729090ad (I'm about to fix a bunch of ambiguity warnings, but this is a commit that still has them). The list of ambiguity warnings starts with

Warning: New definition 
    -(AbstractImageDirect{T,N},AbstractArray{T,N}) at /home/tim/.julia/v0.3/Images/src/algorithms.jl:17
is ambiguous with: 
    -(AbstractArray{TA,2},UniformScaling{TJ<:Number}) at linalg/uniformscaling.jl:35.
To fix, define 
    -(AbstractImageDirect{TA,2},UniformScaling{TJ<:Number})
before the new definition.

Why is - judged as ambiguous, when the corresponding + (which is also defined in linalg/uniformscaling) is not even mentioned?

[mauro3]

Can this be closed now that an error is thrown or is there a deeper issue?

[JeffBezanson]

The question is whether we are consistently judging similar + and - methods as ambiguous. To close this we have to check that the + and - methods in question are either both ambiguous or both non-ambiguous.

[StefanKarpinski]

If this applies to ambiguity errors now, rather than warnings, how about changing the title?

[Keno]

I cannot reproduce this on latest Julia 0.3 with the specified version of Images (all ambiguity warnings that do appear are symmetric between + and -). Regardless, I looked at the signatures from back then and note that one of them has an extra <:Number restriction that may have easily thrown off ambiguity detection. Given that this predates the type system rewrite, I'm gonna call this non-actionable and close it.