Should `AbstractUnitRange` be Array-like?

[jakobnissen]

I mean, of course AbstractUnitRange is an array. But unit ranges are not best serialized as arrays: They are usually much more compactly represented as structs. This is especially notable if the range is large.

Example:

julia> JSON3.write(1:20)
"[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20]"

I don't know enough about JSON or this package to really understand what the implications of making unit ranges struct-like are, but it sure seems like more efficient serialization to me if only the endpoints could be serialized.

[quinnj]

The StructTypes.jl package doesn't have a primary goal of "serialization" per-se, but of just providing programmatic tools for working with "data" structs and "interface" structs. Consumers of StructTypes.jl (like JSON3.jl, Strapping.jl, Avro.jl, etc.), are more in the business of serialization things and may be concerned with the efficiency as you've noted. But as StructTypes.jl deals, as we'll call it, at the "conceptual level", I think having AbstractUnitRange be StructTypes.ArrayType() makes sense. Individual serialization packages can "intercept" the struct type of individual types if desired and "invoke" them as another struct type; JSON3.jl does this with NamedTuples, for example, here. So it's fairly easy for a package to customize, for example, serialization of AbstractUnitRange without needing to change the struct type in StructTypes.jl.

[jakobnissen]

That makes sense. Closing the issue, but it may be worth thinking about for JSON3!