Strange error message when trying to initialise field of type SVector


I was hoping someone could talk me through why this throws:

using StaticArrays

type Polly{N,T}

p = Polly{2,Float64}((1.0, 0.0))

and adds insult to injury with this curious error message:

LoadError: No precise constructor found. Length of input was 2 while length of StaticArrays.SVector{2,Float64} is 2.


You need

julia> Polly{2,Float64}(SVector(1.0, 0.0))

but actually

julia> Polly(SVector(1.0, 0.0))

works out the type (“infers the type”) automatically.

You probably want an outer constructor like

julia> Polly(t::Tuple) = Polly(SVector(t))

to be able to just do

julia> Polly((2,3))

and then you can do

julia> Polly(t...) = Polly(t)

to have

julia> Polly(2, 3)


The problem is a missing convert method in StaticArrays, apparently:

julia> using StaticArrays

julia> convert(SVector{2,Float64}, (1.0, 2.0))
ERROR: No precise constructor found. Length of input was 2 while length of StaticArrays.SVector{2,Float64} is 2.
 in convert(::Type{StaticArrays.SVector{2,Float64}}, ::Tuple{Float64,Float64}) at /home/ferris/.julia/v0.5/StaticArrays/src/core.jl:39

The (abstract type) constructors in StaticArrays are a mess (but I honestly thought this one worked… oh well). I was hoping to clear this up in Julia v0.6 because my previous attempts at getting a sensible set of constructors ran into the subtyping inconsistencies that Jeff Bezanson has recently fixed.

@krcools - so I can track this, could I get you to file an issue at please? I also recommend the suggestions of @dpsanders to make your life easy. Nice constructors can make working with your types a breeze, but you often need several definitions to achieve a good/well rounded API.


Thank you both. @andyferris, I opened an issue in the project repo as requested.

I actually had a lot of the infrastructure @dpsanders refers to in place. The errors described here resulted upon migrating from FixedSizeArrays to StaticArrays. To be honest, I’m not a big fan of

Polly(t...) = Polly(t)

This creates an annoying corner case when you try to store a single SVector inside of another SVector (which I seem to do a lot given how many times I had to struggle with this case…)


Yes, the one-element constructor is definitely rather tricky.

A single SVector inside a SVector could be even worse because of the ways constructors interact with convert.