Skip to content

Unusable constructorof for a type with a type-parameter that is unused #58

Description

@oxinabox

Consider a type like:

struct Foo{D}
       x::Int
end

Which could be used as Foo{:KeyFacts}(25).
constructorof returns just Foo

Then the following issue occurs:

julia> constructorof(Foo{:ABC})
Foo

julia> constructorof(Foo{:ABC})(22)
ERROR: MethodError: no method matching Foo(::Int64)

Which is a problem.
That informatiuon is lost and i can't construct it anymore.
If the type param had been used it could be deduced from the type by the default constructor, but where it isn't it can not

I assume the reason for this is that uses like Setfield.jl might change the type of one of the fields and so for type-parameters that are used it wants them to removed to hit the default constructor.


I am not sure on the solution to this.

My own use case is same type in, same type out.
So one option is to expose a duplicate of setproperties and of constructorof that always has the same type.
It is a bit ugly though.

For the special case where all the type parameters are unused, we could detect that by them never occuring in fieldtypes.
And then we know that it is safe to generate the constructor that has the type parameter set.
But that doens't work for cases where some are used and some are not.
Though for many of these case that i have seen in the wild they have just one unused type parameter and the rest used, and expose a constructor FooBar{C}(a::A, b::B) where {A,B,C}

Activity

  1. jw3126 commented on May 31, 2022

    @jw3126
    Member

    Thanks, yes that is an issue that pops up every now and then.

    I assume the reason for this is that uses like Setfield.jl might change the type of one of the fields and so for type-parameters that are used it wants them to removed to hit the default constructor.

    yes

    For the special case where all the type parameters are unused, we could detect that by them never occuring in fieldtypes.

    That is certainly possible. However we decided against using any heuristics like this and instead recommend to either
    design types differently or overload constructorof(::Type{<:Foo}). See also #27.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions