Seems to be related to `typeintersect` and the error also disappears
when the order of defining those functions are reversed
Minimum working example:
```julia
type A
end
type B
end
f{T}(::Type{T}, ::T) = nothing
f{T<:B}(::Type{A}, ::T) = nothing
g{T<:B}(::Type{A}, ::T) = nothing
g{T}(::Type{T}, ::T) = nothing
t1 = f.env.defs.sig
t2 = f.env.defs.next.sig
println("Signatures: $t1, $t2")
println("Intersect: $(typeintersect(t1, t2))")
println("Intersect: $(typeintersect(t2, t1))")
```
Output (on my branch that fixes the output formatting....)
```
Warning: New definition
f(Type{A}, T<:B) at /home/yuyichao/tmp/julia/type_intersect.jl:10
is ambiguous with:
f(Type{T}, T) at /home/yuyichao/tmp/julia/type_intersect.jl:9.
To fix, define
f(Type{A}, A)
before the new definition.
Signatures: Tuple{Type{T},T}, Tuple{Type{A},T<:B}
Intersect: Union()
Intersect: Tuple{Type{A},A}
```
Should probably be reported as bug?
On Tue, May 5, 2015 at 7:09 AM, Avik Sengupta <[email protected]> wrote:
> Thanks Tovio
>
>> unless JString <: String (but I guess it isn't?).
>
> No, indeed, JString is not a subtype of a Julia string. It is simply a
> wrapper around a pointer. It has no string-like behaviour in Julia, other
> than being able to be converted back and forth from a Julia string.
>
>> it seems to me that your method can never be an identity conversion
>
> I could write a method definition such as
>
> convert(::Type{JString}, str::JString) = str
>
> I suppose that should be safe, but I don't understand why that should be
> necessary, or what benefit it will have.
>
> On Tuesday, 5 May 2015 11:38:38 UTC+1, Toivo Henningsson wrote:
>>
>> This looks like a julia bug, unless JString <: String (but I guess it
>> isn't?).
>>
>> The method from Base is the generic identity conversion, but it seems to
>> me that your method can never be an identity conversion?
