I forgot, what's Rust's opinion on OO? I would hope it's non-traditional. We need to get away from tradition OO and concentrate on what really matters - dispatch!.
Trait specialization is Rust's answer to several of the abstractions provided in most OOP languages and the initial implementation (with conservative type resolution) has been in nightly for a while. I believe there is still a bit of work to do before stabilization but the feature is under active development. One of the primary challenges is the soundness and predictability of the algorithm that selects the right implementation for each type.
With specialization, instead of inheriting classes, traits can provide blanket and default implementations for types that depend on the traits implemented by that type. So, for example, you can provide several different "impl<T> ExTrait for T" with different trait bounds like "T: Clone", "T: Clone + Send", and "T: Clone + Send + Future<...>". Once the conservative inference algorithm is improved, this will be a much more powerful way to compose functionality than OOP but it will require a different approach to abstraction.
I think the plan is to eventually add trait objects that implement multiple traits which will cover more complex cases of dynamic dispatch like those in virtual inheritance.
Rust has flat level class: Struct and its implementation methods. No inheritance here. Struct method can be called as struct_obj.func1().
Rust also has Trait, which is like interface, with a set of method function signatures. A Trait is implemented for a Struct to have concrete method implementation. Trait supports inheritance.
Rust doesn't have classes or inheritance. Instead of classes you just have data, and you can give those data types methods via traits, which gives you composition.
Because they are traits [1], not interfaces, and they also have some features from type classes [2].
When you create a class in an OOP language, you have do declare all interfaces it supports, and provide implementations for them (or mark the class as abstract). In Rust's case, you declare the data separately as a struct declaration, and then implement the traits you want in impl declarations. You can also implement traits for other traits, or for types from other modules, including the standard library.
Finally, compared to traditional OOP interfaces Rust's traits can require static functions in addition to instance methods and they can also implement methods with an overridable default implementation.
Ah, I read the Wiki article and my impression of traits was "interfaces with implementation" and as far as I could tell, Rust traits have no implementation, they 'need' impl(emendations) so they seemed more like interferences to me :)
I've noticed this and while I don't use it much it has caught me off guard once or twice. And while it wasn't the end of the world, I wasn't too fond of the solutions I came up with. Is there a reason why they can't have fields? Why wouldn't they just be an "extension" to a struct/enum, modifying their memory representation?
If they had fields, what would you do when you implemented two of them on a struct? It also muddles up the ability to tack on traits in later crates.
Traits aren't supposed to be used the way you do single inheritance. Rust prefers composition over inheritance, so you combine structs and enums to get what you want there.
Note that this is different from what's being asked, what's being asked is why they can't have fields like abstract classes that get appended to the original struct. That would make traits more like mixins.
That RFC lets you declare fields that the trait implementor is supposed to provide; implementing a trait will not automatically add a field, instead, you will be forced to add such a field yourself (unless one already exists) and link it to the trait field.
It's a more rusty way of addressing many of the same use cases, but it's not the same thing. It's basically sugar for declaring a getter and setter as trait/interface methods.
While it's not what I asked, I actually like the answer as long as I can provide overrideable default methods in the that use the lvalues. I can't think of any of my own use cases that couldn't adequately be covered by it.
