Where both Tuple and NamedTuple are subtypes of AbstractTuple.
Now (v"1.7") that indexing over NamedTuples exists and indexes over its values, there are more methods that share functionality (first and last have worked alike on both types … for example).
Tuple and NamedTuple are function-driven types (rather than struct driven); does this make sharing an Abstract type more difficult?
Somewhat related, I have encountered scenarios where being able to group distinct NamedTuple types together and dispatch therewith would be of use.
Tuple is very much special in the type system, because it can have concrete subtypes with a varying number of parameters, is covariant in its parameters and obeys the diagonal rule. This is something that can not be implemented for any other types, therefore I don’t really see the reason for such an abstract type.
If you just want to write code where it’s useful to work with both Tuples and NamedTuples, you can of course use Union{Tuple, NamedTuple} or perhaps something like TupleLike{T <: Tuple} = Union{T, NamedTuple{<:Any, T} without the need for introducing an abstract type.
4 Likes
Tuple and NamedTuple don’t share a lot of methods. AFAICT what they have in common is mostly the basic indexing interface, right? I think we need a trait to identify types that implement it, including also AbstractArray and Broadcasted.
BTW, in DataFrames.jl we define DataFrameRow and GroupKey which are views that replicate the behavior of NamedTuple. So it could make sense to have an abstract type for named tuple-like types.
4 Likes