Issues with incomplete parameterized types

General Usage
2

Probably not. Type information benefits the compiler when it is concrete, or a small Union of such types. Anything else is fine with Any unless you use it for dispatch.

In order of your questions:

  1. nope, the constructor can have a different name (even though in practice it is not very common). Your error comes from an incorrect f{T}(...) function syntax which is now obsolete, use f(...) where {T}. See the manual chapter on functions.

  2. Think of the constructor as a function or a callable. Your interface design should determine how much type information the user should/would want to provide, and how much can be inferred from arguments. Parametric constructors are special cases because you can include type parameters in the callable, but with IntermediateSimpleResult this is not possible, as there is no such type, it’s just a plain function (with access to new).

  3. No, it does not, eg

    struct Foo{T}
    Foo(::Type{Z}) where Z = new{Z}()
    Foo{S}() where S = new{S}()
end

    will work fine. But it is better style to be consistent.

  4. Yes, that could be tricky. Type calculations always are. If possible, redesign your interface not to preallocate, if not, write a small auxiliary function to do it for you. Concrete type parameters are not required, but then you lose some compiler optimizations.

Keep in mind that Julia’s parametric type system is extremely rich and it is easy to get carried away with when encountering it for the first time. Avoiding abstract type parameters helps with performance, the rest should be kept simple when possible.

2 Likes