Is `Type` required?

[bnjbvr]

It seems to me that the use-case for Type is:

• call get_type() on a TypeDescriptor, that returns a Type
• then lower the Type into a more precise kind of type: EnumType with as_enum(), StructType with as_struct(), etc.

It seems that Type also normalizes some information exposed via methods that can be useful on their own, e.g. default_value, type_name, etc.

So as to lower the API surface, I was wondering if Type could be removed, and replaced directly by the more precise type kinds?

As far as I can tell, reimplementing the "normalizing" methods would vary in difficulty:

• type_name should be straightforward: unless it's a scalar, use the type_name on the underlying type
• into_type_descriptor goes the other direction, and it seems to be unused both in the lib and in our main use case
• into_type_info_at_path and default_value might need some not-so-pretty matches

If we went down that road, I'd also suggest suffixing all the more-precise-type-kinds with Descriptor, for symmetry with TypeDescriptor, as it seems this is what they are (?). (Maybe all of this could be shortened to the Desc suffix, in general, to not make for really long names like TupleStructTypeDescriptor.)

What do you think about this?

[davidpdrsn]

So as to lower the API surface, I was wondering if Type could be removed, and replaced directly by the more precise type kinds?

I'm not sure. I think having an enum to match on is very convenient. Would the alternative be

if let Some(struct_type) = type_descriptor.as_struct() {
    // its a struct!
}

if let Some(tuple_struct_type) = type_descriptor.as_tuple_struct() {
    // its a tuple struct
}

// repeat for tuple, enum, list, etc

If we went down that road, I'd also suggest suffixing all the more-precise-type-kinds with Descriptor, for symmetry with TypeDescriptor, as it seems this is what they are (?)

I think that would make the API too verbose. To me StructTypeDescriptor isn't really better than StructType, just longer.

This is a very personal opinion but in general I'd rather put related types in the same module, rather than use suffixes. Suffixes feel very "java" to me 🤷

[davidpdrsn]

I also think keeping into_type_descriptor is worth it. Being able to drill down into some deeply nested type and convert your destination type into an owned+serializable type seems useful to me. Even if we don't happen to use it ourselves yet.

[bnjbvr]

Alright, these are good arguments. Wonder if we could fuse into the other direction? TypeDescriptor would be an enum, and it would use a Cow<Graph> for the type graph, since it can either be owned (for the root element) or borrowed (for children type desc).

[davidpdrsn]

Yes that sounds like a good direction to try! I agree that getting rid of Type would make things cleaner overall.

[davidpdrsn]

I think we should just keep Type for now. Having used mirror-mirror a lot internally I don't think its too bad.