I’m running into trouble having parametric types that I would sometimes like to refer to by their deparametrised UnionAll versions, while only having instances of the types available. Here’s a heavily simplified mock-up of what I’m trying to do: abstract type AbstractContainer end struct ContainerType1{T} <: AbstractContainer where T <: Any loot::T end struct ContainerType2{T1, T2} <: AbstractContainer where T <: Any loot1::T1 loot2::T2 end unpack(c::ContainerType1) = (c.loot,) unpack(c::ContainerType2) = (c.loot1, c.loot2) Please don’t take this too literally: There should be more than 2 subtypes of AbstractContainer, and they aren’t all specified by simply how many objects they hold. The point here is the type hierarchy. There are two, related things I would like to do with these types, that I haven’t figured out a good way to do. First there’s this: symbolize_contents(x::T) where {T <: AbstractContainer} = T(map(Symbol, unpack(x))...) symbolize_contents(ContainerType1("1")) This fails, because there is no constructor ContainerType1{String}(loot::Symbol), whereas what I “mean” is to call ContainerType1(loot::Symbol). The best solution I’ve come up with is to define something like this for each container type, deparametrize(::Type{<:ContainerType1}) = ContainerType1 after which I can do symbolize_contents(x::T) where {T <: AbstractContainer} = deparametrize(T)(Symbol(x.loot)) This seems a little silly to me, and more importantly, it doesn’t solve the second thing I’m trying to do, which is to generalise the following to all subtypes of AbstractContainer: merge_containers(x::ContainerType1, y::ContainerType1) = blahblah merge_containers(x::ContainerType2, y::ContainerType2) = blahblah What I’m trying to say here is that I don’t ever want to merge an instance of ContainerType1 with an instance of ContainerType2, but I am fine merging say a ContainerType1{String} with a ContainerType2{Int}. So I would like something like merge_containers(x::T, y::T) where {T <: AbstractContainer} = blahblah but with the diagonality happening on the level of deparametrised UnionAll types, rather than the fully specified concrete types. In other words, ideally, I would want to write merge_containers(x::T1, y::T2) where {deparametrize(T1) == deparametrize(T2) <: AbstractContainer} = blahblah or maybe unionall_containers = (ContainerType1, ContainerType2) merge_containers(x::T, y::T) where {T in unionall_containers} = blahblah but neither of these is valid Julia. I’m interested in both Learning about any relevant features or design patterns that could help in situations like these. Understanding why Julia doesn’t allow something like that last bit of code above. Is there a deep reason why what I’m asking for is impossible? In researching this, I learned about the existence of TypeNames, but I don’t really know if I should try to use them here, considering for instance performance concerns. The manual says very little about them. Stripping parameter from parametric types is relevant, but doesn’t really solve my case. The second section of this bit of the manual also seems relevant, but I simply don’t understand it.

Adapting this one: [image] Get new type with different parameter New to Julia Have a read through: https://docs.julialang.org/en/v1/manual/methods/#Extracting-the-type-parameter-from-a-super-type-1 The thing is, that parameters might change place, or don’t exist (see the BitVector example). Thus, it is generally not a good idea to do this. If you still want to do it, you probably want a generated function: julia> @generated function newT(::Type{T}, ::Type{TT}) where {T,TT} getfield(parentmodule(T), nameof(T)){TT} end newT (generic function with 2 me… ?

Thanks, that’s indeed useful. That would give me a more generic way of implementing the deparametrize function, something like deparametrized_typeof(::T) where T = T.name.wrapper or deparametrized_typeof(::T) where T = getfield(parentmodule(T), nameof(T)) Two follow-up questions: Would something like this come with performance/type stability gotchas? This doesn’t allow me to do the second thing I wanted to do, the diagonal dispatch type thing that I psedo-coded as merge_containers(x::T1, y::T2) where {deparametrize(T1) == deparametrize(T2) <: AbstractContainer}. If this is impossible to achieve, I would be happy if someone could help me understand why. It seems to me like an entirely natural thing to request from the type system.

[image] mhauru: Would something like this come with performance/type stability gotchas? Here’s the version of this I have, which also handles arbitraryily deep UnionAlls like e.g. basetype(Array{Complex{T},N} where {T,N}): basetype(t::DataType) = t.name.wrapper basetype(t::UnionAll) = basetype(t.body) The DataType version is inferred and completely optimized away at compile time, you can see e.g. the output is the same for both: julia> @code_llvm (() -> basetype(Array{Float64,2})([1,2,3]))() julia> @code_llvm (() -> Array([1,2,3]))() The UnionAll one also is inferred for some simple cases like basetype(Array{Float32}), but not for anything more complex. I’d be curious if anyone has a way to fix that though. [image] mhauru: the diagonal dispatch type thing that I psedo-coded as merge_containers(x::T1, y::T2) where {deparametrize(T1) == deparametrize(T2) <: AbstractContainer} My intuition would be that the most Julian solution is to drop the requirement that x and y be the same concrete type and instead write your code generically, such that the constraint could just directly be: merge_containers(x::AbstractContainer, y::AbstractContainer) If that doesn’t work, then I think you can do this with some of the trait packages.

Thanks for the @code_llvm stuff, that helps. For merge_containers(x::AbstractContainer, y::AbstractContainer), this is in fact what I’m doing at the moment. The reason I’m not happy with this is that one could accidentally call merge_containers for two different container types, and while this is a nonsense operation, any sort of duck typing might take a while to catch it, or it might even go through but just lead to nonsense behavior. So I would rather catch it early and in an informative way. I should look into if I can get what I want with traits, it’s time for me to get familiar with them anyway.

Deparametrising types

General Usage

mauro3 June 23, 2020, 3:00pm 2

Adapting this one:

Topic		Replies	Views
Dynamic union of parametric types General Usage parametric-types , types	21	499	May 27, 2025
UnionAll as a Type Parameter General Usage parametric-types	3	1740	February 1, 2022
Tricky parametric type dispatch General Usage parametric-types	4	1151	April 12, 2019
Modify Parameters of Type General Usage	6	1260	August 18, 2017
Type system limitations General Usage question , parametric-types	5	825	February 21, 2020

Deparametrising types

Related topics