Don't erase Box types

[ascjones]

For rust type generators we need to know if a type is a Box in order to generate e.g. valid non self-referential types. This can be done either by defining a custom composite type as I have done here, or maybe as a special case TypeDef enum variant.

[dvdplm]

Do you think we should do the same for other smart pointer types, Rc<T>, Arc<T>, Ref<T>, RefMut<T> etc? Or wait until we know we need them?

[Robbepop]

Do you think we should do the same for other smart pointer types, Rc<T>, Arc<T>, Ref<T>, RefMut<T> etc? Or wait until we know we need them?

We definitely do need them to be properly serialized. This is where there might be different use cases though since it won't make a lot of sense to do this in other contexts such as Javascript UIs.

[ascjones]

Maybe we could use the WrapperTypeEncode concept from codec to encapsulate these kind of types, capturing the name of the wrapper type along with the wrapped type. https://github.com/paritytech/parity-scale-codec/blob/ab18de2477cc2a3421cd647092ebfe76b362cbd7/src/codec.rs#L344

[dvdplm]

I think we should wait until we need them so we have a clear use case in front of us.

[ascjones]

Updated and marked ready for review. I'm happy with this solution for Box on its own for now, can consider other smart pointers if and when we need them.

[Robbepop]

I think we want a clearly defined enum variant for this kind of type.
This type should be called Indirection since that is what it actually is if we abstract from Rust.
The type is not stored inline but indirectly or out-of-line to the object which it owns.
This also simplifies the interaction with UIs with this new Indirection variant because most UIs only care about the serialization and deserialization information anyways.

[Robbepop]

What do you think about a middle ground solution where we introduce this Indirection type definition on the one hand side but still keep proper custom types for all of Box, Rc, Arc etc.? This way we could quickly identify indirectional types and would not have the problem of having to be too precise about them, e.g. introducing a RefCountedIndirection for Rc.