[esailija]

The problem is of course that there is no useful default behavior you can define when the trait is so isolated and generic.

[josephg]

It doesn't have to be "so isolated". The trait can still have required methods that don't have a default implementation. Eg:

    trait Robot {
        fn send_command(&mut self, command: Command);

        fn stop(&mut self) {
            self.send_command(Command.STOP);
        }
    }

    struct BenderRobot;
    
    impl Robot for BenderRobot {
        // Required.
        fn send_command(&mut self, command: Command) { todo!(); } 
    }

This is starting to look a lot like C++ class inheritance. Especially because traits can also inherit from one another. However, there are two important differences: First, traits don't define any fields. And second, BenderRobot is free to implement lots of other traits if it wants, too.

If you want a real world example of this, take a look at std::io::Write[1]. The write trait requires implementors to define 2 methods (write(data) and flush()). It then has default implementations of a bunch more methods, using write and flush. For example, write_all(). Implementers can use the default implementations, or override them as needed.

Docs: https://doc.rust-lang.org/std/io/trait.Write.html

Source: https://doc.rust-lang.org/src/std/io/mod.rs.html#1596-1935

[RHSeeger]

> First, traits don't define any fields.

How does one handle cases where fields are useful? For example, imagine you have a functionality to go fetch a value and then cache it so that future calls to get that functionality are not required (resource heavy, etc).

    // in Java because it's easier for me
    public interface hasMetadata {
        Metadata getMetadata() {
            // this doesn't work because interfaces don't have fields
            if (this.cachedMetadata == null) {
                this.cachedMetadata = generateMetadata();
            }
            return this.cachedMetadata;
        }
        // relies on implementing class to provide
        Metadata fetchMetadata(); 

    }

[Klonoar]

Getters and setters that get specified by the implementing type.

[RHSeeger]

But then you have the getters, setters, and field on every class that implements the functionality. It works, sure, it just feels off to me. This is code that will be the same everywhere, and you're pulling it out of the common class and implementing it everywhere.

[josephg]

Yep. Or ... don't put that in the interface at all. It looks like an implementation concern to me.

[RHSeeger]

But if there's a lot of classes that implement the same thing, then not duplicating code makes sense. And saying "it's an implementation detail" leads to having the same code in a bunch of different classes. It feels very similar to the idea of default implementations to me; when the implementation will be the same everywhere, it makes sense to have it in one place.

[josephg]

So to be clear about your example: You have a whole lot of different - totally distinct - types of things, which all need to have the same logic to cache HTTP requests? Can you give some examples of these different types you're creating? Why do you have lots of distinct types that need exactly the same caching logic?

It sounds like you could solve that problem in a lot of different ways. For example, you could make an HTTP client wrapper which internally cached responses. Or make a LazyResource struct which does the caching - and use that in all those different types you're making. Or make a generic struct which has the caching logic. The type parameter names the special individual behaviour. Or something else - I don't have enough information to know how I'd approach your problem.

Can you describe a more detailed example of the problem you're imagining? As it is, your requirements sound random and kind of arbitrary.

[jjmarr]

Don't mix implementation and interface inheritance.