Indirect Members

The problem with the "wrap the property type in a box" approach is that it forces a separate heap allocation for each indirect property, which is going to increase memory fragmentation. This is fine if you just have a single property, but if you start adding more indirect properties, you're going to want them to be contained in the same "box".

Someone could probably develop a macro-based solution here that would extract the relevant properties into a storage class, but this is something that the language should really support directly because there are subtle inefficiencies/feetguns if you do it wrong (or even do it right): you have to implement copy-on-write yourself if your type is mutable, you have to write forwarding accessors and make sure they don't become a performance bottleneck, the box class adds useless metadata to the binary that you don't actually need/want, etc.

5 Likes