I don't understand why this sort of solution does not satisfy me like a sound design would do. Maybe I just don't understand all of the ramifications of the various design options, but my main concern is the verbosity of composition. Of course, explicitness is always a good first guess, you can't go terribly wrong with being explicit, but I feel like it hinders abstraction here. When traits are required to be explicitly implemented, there are no good options to build an abstract library on top of libraries which are not abstract/general (i.e. use traits). You are dependent on imported libraries to expose the right traits for you to implement, so that you can exploit their library as optimally as possible, with little boilerplate. If they don't offer traits and generic functions, you are forced to take the long way around and wrap their type in one of your types and use something like the Into<TheirType> trait, so that you have to call .into() to use their functions or methods.
I know it is a small disadvantage and there are still the advantages of being explicit about it, but I think this pretty much describes my dissatisfaction and what I meant in this discussion. I feel like there is potential to better exploit genericism, and to be able to do more with less code. Not allowing for genericity should be a conscious decision, just like allowing for genericity should be, and they should be equally expensive to implement. Currently I feel like implementing a generic API has more programming cost than implementing an (unnecessarily) specific API.
I don't think this should be discussed strictly on the grounds of "inheritance" as I don't think this is what this is actually about. Inheritance is one design to achieve abstraction, traits are another, better one. That does not mean that we should stop there. What I am diffusely imagining here is a kind of meta language, a type system for types. Types define a range of values, a set, if you will, of concrete bit sequences. They map a string of bytes with a specific size to a meta-structure which is essentially just an interface for humans. So types allow us to talk about data in a meaningful way, by being able to structure and emphasize according to our human intent.
Now we got traits and generic types, which map types to meta-structures which allow us humans to talk about types. Generic types describe ranges of types, just like types describe ranges of values, and traits are to generic types what properties are to structs. So a new trait actually defines a new type of types, and can be combined with other traits to form a hierarchy of traits.
I yet have to think of concrete ways this could be improved in Rust, as Rusts design is already ahead of its time. But maybe it is now a little bit more clear where I was going with this. Mainly what I am missing is syntactic sugar for these kinds of meta-types. For example something to build a trait definition from a type, so that you can just have a trait which is for "everything that is like this: <Type>". This would also make it easier to generalize an API once you have written a specialized version of it. Of course you could just copy the method signatures into the new trait yourself and implement it yourself, but lets be honest here, the work is to write the code, and any way to simplify that should be an improvement. There are more important issues, but maybe we can find some interesting ideas down this road.