And I think Rust's is anything but piecemeal and hacky. I like it quite a bit more than what Python, C++, or Java has provided. Now what?
In particular, the ability to implement an interface for a type without having to name it on the type itself is a huge benefit. It means that I can keep the declaration for the type to just what matters: its data members. The API for the type beyond that can be implemented in any order elsewhere in the module (or, in the larger scope, crate) instead of needing to be right beside the declaration.
Inheritance is a bad default to provide over composition. Types are covariant or contravariant depending on the mutability of the API. For example, the canonical:
struct Ellipse {
public:
void set_major(int x);
void set_minor(int x);
};
struct Circle : public Ellipse {
// So what does `circle->set_major` do here?
};
means that an Ellipse& is actually dangerous because if it is actually a circle, set_major and set_minor actually twiddle the same thing. This feels quite dirty to me when trying to apply the Liskov Substitution Principle and expecting get_major to not care about set_minor calls.
Rust's trait system instead pushes you to think about interfaces that actually matter (here, probably Shape with area and perimeter methods. But mutability is insane to have in such a mechanism because shapes can have all kinds of free parameters that it would never be possible to enumerate everything.
Digging into some library I've never heard of to look for…something that isn't on anyone here's schedule either.
If you just want to showcase something, then be clear that that is what you are doing. Don't put something on the table and say "something should be done" and refuse to explain when folks ask you what to do with your proposal.
AFAICT, "full and clean" has never been done before, so claiming its benefits would seem to be quite premature IMO.