+1, this seems useful.
I think you’re onto a good tack with the idea of using interfaces for this – even if the default way of defining attributes is as a composition of others, we don’t want to rule out users defining their own highly-efficient internal representations if needed.
Btw, I don’t think it is merely “some common cases”. There is very rarely any special representation involved. I think if we moved to a model where the “default” way of defining the structure of these attributes is via a TableGen DSL (already under discussion in Ease of defining new types - #19 by River707 for types) that expresses them as basic compositions, then we could generate all this easily in the very common case. I think a simple struct/list/“oneof” type of composition system would work really well (would probably want to do a more thorough survey of use cases than I just did in the last 5 minutes 
).
So basically the design could be:
- have an attribute/type interface “buildable as a composition of other attributes/types”.
- (eventually) TableGen’eration of almost all attributes/types; TableGen automatically implements the above interface, and can be used to generate binding wrappers.
- we could also have introspection to avoid the need to statically generate the binding wrappers for most cases