Falling back to Base.convert during construction does not work for custom types with a single field

[helgee]

When I run the following code

type A
    v::Float64
end

type B
    v::Float64
end

Base.convert(::Type{A}, b::B) = A(b.v/2)
b = B(2)
A(b)

it fails with this error message because the implicit constructor is called.

ERROR: MethodError: `convert` has no method matching convert(::Type{Float64}, ::A)
This may have arisen from a call to the constructor Float64(...),
since type constructors fall back to convert methods.
Closest candidates are:
  call{T}(::Type{T}, ::Any)
  convert(::Type{Float64}, ::Int8)
  convert(::Type{Float64}, ::Int16)
  ...
 in call at none:2

I expected this to work since the manual states:

defining Base.convert(::Type{T}, args...) = ... automatically defines a constructor T(args...) = ...."

The following code on the other hand works:

type A
    v::Float64
end

Base.convert(::Type{Float64}, a::A) = a.v/12
a = A(2)
Float64(a)

It seems that the new constructor is only generated for built-in types and not for custom types.

EDIT: Typo.

[yuyichao]

Maybe related #15044 ?

[cstjean]

It fails on Julia 0.4.3.

[JeffBezanson]

The wording in the manual is not ideal. Defining convert does not create a constructor; it only adds a method to convert. Then there is a fallback that invokes convert if a type doesn't have a matching constructor. If for a given type convert and "construct" mean the same thing, you can define convert inside the type block to suppress generation of default constructors.

[helgee]

Why does the type constructor not fall back to the convert method that I have defined, then?

[JeffBezanson]

Because of the default constructors:

julia> type A
           v::Float64
       end

julia> methods(A)
3-element Array{Any,1}:
 A(v::Float64) at none:2          
 A(v) at none:2                   
 (::Type{T}){T}(arg) at int.jl:419

[helgee]

I apologize if I am being dense. But if this is the intended behavior I do not understand the reasoning behind it. Especially since the following example works.

type C
    v::Float64
    w::Float64
end

type D
    v::Float64
    w::Float64
end

Base.convert(::Type{C}, d::D) = C(d.v/2, d.w/2)
d = D(2, 2)
C(d)

[swt30]

This was surprising to me too. I would have assumed that the default constructor for A in the first example was A(v::Float64) and that it would coexist with A(b::B) from convert. But @JeffBezanson has indicated that convert will only be called as a fallback. Looking at the output from methods, it seems that the more general case A(v) is also defined for us. This appears to do a conversion or promotion on v, which enables us to write A(x) where x is not a Float64. Because a general single-argument method is already defined, the fallback isn't used.

In contrast, the second case with types C and D works because there is no general case for the single-argument C(x), only for C(v,w). Therefore the fallback method gets called as expected.

[swt30]

Just to clarify on that second case, the following will give the same error:

type C
    v::Float64
    w::Float64
end

type D
    v::Float64
    w::Float64
end

Base.convert(::Type{D}, c1::C, c2::C) = D(c1.v, c2.w)

c1 = C(2, 2)
c2 = C(3, 3)
D(c1, c2)

[helgee]

@swt30 Thanks for the explanation. I finally got it.

I have opened a PR for clarifying the documentation. This corner case seems very unfortunate to me, though. "You can also extend Base.convert unless the number of arguments matches the number of fields" might be hard to sell to a newcomer.

[cstjean]

@helgee I agree that it's not pretty, but maybe it's better to frame it the way Jeff did? "If you want to use convert as your only constructor, put it in the type definition so that Julia does not automatically create a constructor."

type B
    v::Float64
end

type A
    v::Float64
    Base.convert(::Type{A}, b::B) = new(b.v/2)
end

b = B(2)
A(b)

[helgee]

@cstjean In my real-world code the whole thing is not an issue because the number of arguments and the number of fields are not the same. I was just stumped by it during testing. In cases were conversion and construction are not the same it is also easy to circumvent the problem by doing this:

type A
    v::Float64
end

type B
    v::Float64
end

Base.convert(::Type{A}, b::B) = A(b.v/2)
# Explicit constructor
A(b::B) = convert(A, b)

b = B(2)
A(b)

I am just bothered by it because it seems like a serious WAT?! to me and the manual was actively misleading.

[nalimilan]

I agree this is terribly confusing. Would it be possible to stop defining the default A(x) = ... constructor, and define convert(::Type{A}, x) = ... instead?