First, I think this proposal is somewhat incomplete (in a way that the original “fat objects” was not). Thinness is not just a property of trait objects – when we allocate the underlying data, we also need to specify the vtable there. That is, in Rust, you don’t (in Rust) allocate trait objects directly. First you allocate a value of a known type (e.g. &Struct) and then this is coerced to a trait object (e.g., &Trait). We couldn’t permit you to coerce an &Struct to some &thin Trait, even if Struct: Trait, because the &Struct doesn’t have the vtable for Trait. So you need two forms, one that is like &thin<Trait> Struct (a Struct preceded by the vtable for a Trait) and &thin<Trait> (underlying type is unknown). The original “fat object” proposal called these &Fat<Trait,Struct> and &Fat<Trait>.
Personally, I still feel a lack of motivation. If the concern is just that the presence of a vtable in a struct is not explicit enough, I think there are other ways to address that (we can e.g. require some form of reciprocal annotation on Struct that indicates it is tied to Trait, or adopt something lke inherent traits). I’d like to see some classic OO pitfall that you think this will sidestep, for example, or some important pattern that will become much easier.
I also don’t think that fat objects are more expressive than thin traits: I think you can use coding patterns to achieve all the flexibility that fat objects offer, if it should be required (put another way, fat objects and thin traits are duals of one another). For example, I described earlier how to “repackage” some foreign trait into a thin trait, so that you can (locally) create a dense graph of objects or something. Another thing one can do with fat objects is to take a common struct and make thin objects of different traits. But you can also do this (via composition) under the thin trait proposal.
Given that the two are duals, it seems like the question boils down to ergonomics. The thin trait proposal optimizes for an OO-like point-of-view, in which structs and traits are tied together. It works quite well for that. I also think this makes it somewhat easier to teach and explain, since the pair of a “struct+thin-trait” is pretty close to an OO class. Moreover, the fact that, if you DON’T care about object layout, you can basically ignore thin-ness altogether is very appealing. That is, you don’t really have to know that #[repr(thin)] means if you are reading code, you still know what it does.
In contrast, the fat object makes it easier to mix-and-match structs and traits willy nilly (though, as I discuss above, that is also possible with thin traits). But I think, in practice, that flexibility will not be particularly useful. And it comes at a great toll in everyday ergonomics. You need type aliases for just about any use, and you can’t really read code without encountering these &thin Trait types. I guess I find that Fat<> is a nice factoring of thin objects from a theoretical point-of-view, but lacking from a practical POV.
I am reminded (for some reason) of the concept of a resource: in olden days, we didn’t have the Drop trait, but instead had resources, which were just a nominal type that introduced a destructor. Eventually we moved towards the Drop trait. I think overall this was a good move, since it makes the language feel smaller (though when you drill into the details, it is in some ways more complex). Now you only have to think about structs (and, yes, some structs have destructors). Similarly, with thin traits, you really just have structs and traits, but some traits are thin. Obviously it’s an illusion, in some sense, but I do think it’s important to keep the number of core concepts small, and to structure things so that you can easily layer the new concepts with relative ease.
Anyway, sorry if this post comes off as harsh. I really do like the fat objects idea intellectually, and I find it to be an interesting refactoring. I’m just concerned about how it will feel in practice, and I’m interested in more practical motivations and use cases.