type-metadata
Design: Differentiate between Box<T> and T (etc)
After https://github.com/type-metadata/type-metadata/pull/5 has been merged the current semantics is that types like Box<T> and T or String and str are treated as different types in the type registry and thus receive their own unique identifiers.
It should be simple to fix this behaviour if we want to.
The pros are that the current behaviour is more general the cons are that it might produce bigger compacted type registries and provide information that is unnecessary for our current purposes (third party UI).
This issue is meant as discussion for the underlying design decision.
Ideally the user can supply a transform/normalize/filter function to process the type information at some stage (serialization or generation?) and this function can merge equivalent types and dedupe them. But I feel this approach while is very generic and could be useful, is overkill for the initial purpose of this library and introduce too much complexity to the code.
I will say just merge those equivalent types during generation phase to keep thing simple.
Rational against differentiating between Box<T> and T etc.:
I'm really not sure what value that adds externally - in my view the data is purely there for encoding/decoding purposes. So if String and str have equivalent encodings, why differentiate at all?
It basically means that all parsers now to write aliassing logic to treat them the same - Python (polkascan), Java (W3F), oo7 (Parity) and polkadot-js.
Actually TypeDef seems to have a misleading name since it represents more of a simplified encoding rather than the underlying type structure.
Subsumed by https://github.com/type-metadata/type-metadata/issues/31. However, we shall keep this issue open for keeping the discussion in here visible.
I want to note that having different types (e.g. Box<T> and T) that share the same type_metadata::TypeId while being different types with different core::any::TypeId is a current unsoundness in the current implementation of the Registry and leads to duplicates in the resulting serialized type table.
We should either add diagnostics to the Registry to warn about this case if approached, implement a better compactification algorithm that doesn't require this invariant or implement distinct type_metadata::TypeId for all known distinct types.