Repository navigation
widening of type parameters (wishlist to use ConstructionBase in StructArrays) #68
Description
This continues some of the discussion in #53, esp. #53 (comment). See also JuliaArrays/StructArrays.jl#241 for a PR to use this package in StructArrays.
In StructArrays one generally needs to figure out a type not from fieldvalues (which ConstructionBase can deal with) but from arrays of field values. For example, starting from the type Pair and the columns [1, 2, 3], ["a", "b", 2], I would like to figure out that the eltype for the resulting StructArray (which should be Pair{Int, Any}). Could ConstructionBase be extended to support something like this?
There is a second issue in this example. In this Pair{Int, Any} scenario, the default constructorof would "lie" about the element type. In other words:
julia> constructorof(Pair{Int, Any})(1, "a") isa Pair{Int, Any}
falseWould it be feasible to add a version of constructorof that respects the type parameters? Ideally, that would also address #58 as well as other problematic types (such as types with inner constructors).
Activity
aplavin commentedon Sep 2, 2022
How is this related to ConstructionBase or JuliaArrays/StructArrays.jl#241? I don't see any type computations in ConstructionBase now, only construction/modification of instances. That PR also doesn't touch StructArrays eltype computations at all.
That's basically just the type itself, unless it defines an inner constructor that doesn't just take its fields. A major point of
constructorofis that it can construct an object with different field types, depending on the values.piever commentedon Sep 5, 2022
At the moment it isn't, but I was wondering whether one could have a deeper integration than the one in JuliaArrays/StructArrays.jl#241, where the
bypass_constructorhack (as well as the complex promotion mechanisms) in StructArrays were no longer needed.Naturally, I understand that it could be outside the scope of ConstructionBase.