Hacker News Reader

Comment by kibwen | Hacker News Reader

> Even though DebugAny inherits from Any

I'm going to push back against this terminology for the sake of people who don't know Rust and are coming from traditional OO languages.

Rust traits don't "inherit" from other traits, they "require" other traits.

So if I have two traits, where one requires the other:

    trait Foo {}

    trait Bar: Foo {}

That doesn't add Foo's methods to Bar's list of methods, like you might expect from the term "inheritance".

Instead, it just means that it's not possible to implement Bar for a type unless Foo is also separately implemented for that type.

Despite this it's still accurate to say that this enables a supertype/subtype relationship in certain contexts, but be careful because Rust isn't a traditionally OO language, so that may not always be the most useful framing.

View on HN

> That doesn't add Foo's methods to Bar's list of methods, like you might expect from the term "inheritance".

This is not completly correct. It's true you won't e.g. be able to implement `Foo` and specify `Bar`'s method in it, however it does mean that e.g. `dyn Foo` will support `Bar`'s methods.

> Despite this it's still accurate to say that this enables a supertype/subtype relationship in certain contexts

It does enable something that looks like subtyping because you're allowed to use something that implements `Foo` when something that implements `Bar` is expected. However this is not called subtyping in Rust terms; subtyping in Rust exists but is unrelated to traits (it's only affected by lifetimes)

It’s not clear from that description how it differs from interface inheritance in OOP.

In an interface/class hierarchy A < B < C, C can be an abstract class that only implements B’s methods and not A’s.

In Rust, an implementation of a trait never implements methods that weren't defined on that trait explicitly. In your example, an implementation of C inherits from B and A, but only implements B's methods. In Rust, an implementation of C cannot itself implement B's or A's methods; it is merely allowed to assume that they have been implemented elsewhere. This also means that subtraits cannot override the behavior of methods defined on supertraits.

Okay, but doesn't Bar nevertheless inherit Foo's methods in the sense of interface inheritance? Or does code that gets passed a Bar not get access to Foo's methods?

> does code that gets passed a Bar not get access to Foo's methods

Prior to the current version of Rust it was impossible to access methods on `Foo` when a `&dyn Bar` was passed. With the current beta version you can upcast.

> Prior to the current version of Rust it was impossible to access methods on `Foo` when a `&dyn Bar` was passed.

This has been working since Rust 1.0, I think:

    trait Foo {
        fn foo(&self);
    }
    trait Bar : Foo {}

    impl Foo for () {
        fn foo(&self) { println!("Hello") }
    }
    impl Bar for () {}

    fn xxx(x: &dyn Bar) {
       x.foo();
    }

    pub fn main() {
        xxx(&());
    }

> With the current beta version you can upcast

Right. Now you can convert from `&dyn Bar` to `&dyn Foo` which wasn't possible before.

Inherent method implementations were unavailable. (Eg: impl dyn Foo) and then call this via Bar.

It might be better to think of it this way: types in Rust do not implement traits, traits are implemented for types. It might seem subtle, but its not: a trait can be implemented for a type without that type's knowledge (obviously taking care for the orphan rule). Traits are also implemented via pattern matching (Into being implemented for all Froms is the most trivial example). Go's interfaces come closer to Rust traits than those from OOP languages.

I've experienced a lot of fear in other people, especially when interviewing, about Rust not being OOP. Very smart people seem to be coming up with carve-outs to keep that religion alive. Try letting go of OOP for a month or two, and you'll find that you're better off letting OOP be someone else's problem.

I think we have different notions of OOP. OOP without implementation inheritance and with extension interfaces/methods is still very much OOP to me.

> It’s not clear from that description how it differs from interface inheritance in OOP.

Remember, when people talk about "OOP" what they're actually talking about is Java EE 6.

The terminology that Rust uses is that "Foo" is a supertrait of "Bar". I understand that the docs so not call it inheritance, but from my experience at least people call this "trait inheritance" quite commonly.

What's the practical distinction here? I agree with you that rust isn't OOP, but for the sake of communication and understanding--what's the practical difference between requiring a trait and inheriting from it?

It means you can't just write `impl Bar for MyType` and get Foo pulled in automatically. You have to write both `impl`s yourself.

The inheritance-like syntax is shorthand for `trait Bar where Self: Foo`, and bounds like this can show up in lots of other places, where they follow the same rules: `MyType` has to impl all of them, and the traits and bounds can have fairly arbitrary (or at least un-tree-like) relationships.

The upcasting thing is a rare exception to the idea that this `Self: Foo` bound is just like any other bound.

If Bar inherited from Foo, Bar would have Foo's methods. So if you implemented Bar for Gum, Gum would get Bar and Foo.

But Bar requiring Foo means that if you want to use Gum in a place that expects Bar, Gum must have both Bar's methods and Foo's methods.

In some cases, you might be able to derive some of those.

Rust isn't classical Java OOP, that many keep conflating with OOP, there are many ways of OOP type systems in computer science.

I have easily translanted the raytracing in one weekend from its OOP design in C++, into a similar OOP design in Rust.

For one, each trait has a separate namespace for its items, so in particular Foo::quux and Bar::quux are distinct even when one trait "inherits" from the other.

> people who don't know Rust and are coming from traditional OO languages.

Should those people be learning Any in the first place initially as an introduction to the language? How similar to `unsafe` is `Any` in terms of "try to avoid it"?

If you're new to Rust, you have effectively no reason to take time out to learn about the std::any::Any type. I wouldn't say it's something to "avoid"; this is unlike unsafe, where I would advise a new programmer to actively avoid it (unless they have a C background, maybe). It's just something you don't really need, and dyn traits in Rust are still relatively verbose and restrictive enough that it naturally steers you toward more idiomatic, non-dynamic code (which isn't to say that dyn traits are useless, they have their place, but it's a niche IMO).

Reply on news.ycombinator.com