Meta: I appreciate that you took the time to wrote out a significant amount of text about how this would work, how it compares to other possibilities, and its advantages and drawbacks.
Though, personally I would be more interested in a way to inline struct fields, despite the disadvantages you pointed out. In my opinion they just solve more problems, including:
-
"Struct full of
Options"-like use cases, where a struct has multiple enum-typed fields and their tags could be combined into a bitfield. - Enabling arbitrary bitfields.
- Simulating alignment requirements with offsets, like "multiple of four plus two", for structs like:
struct Foo { a: u16, b: (u16, u32), // would be nice if this didn't need padding c: u32, }
I don't see why types which are inlined would have to be fully public or why visibility would be involved at all. I also don't believe this would require monomorphizing any code more than it already is. References would be an issue, but they can be made to work to at least some extent. It's true that there may be a bit of overhead when calling non-inlined methods taking references, so binned would be better for use cases that do that frequently, but on the other hand, inlining allows for significantly more space optimizations. And the design I have in mind doesn't require adding a new default trait bound; as backwards compatibility risks go, at most it might cause issues with applying derive macros to structs that opt into their fields being inlined.