[weberc2]

Both types implement the `Client` interface. So either type can be passed into a function that accepts the `Client` interface, but a `CachedHTTPClient` cannot be passed into a function that accepts an `HTTPClient` (you would have to pass the `CachedHTTPClient.HTTPClient`) and of course not vice versa either. You can do the same thing in Java (forgive my syntax):

    public interface Client {
        ArrayList<String> getUsers();
        void createUser(String name);
    }

    public class HTTPClient implements Client {
        public ArrayList<String> getUsers() { /* ... */ }
        public void createUser(String name) { /* ... */ }
    }

    public class CachedHTTPClient implements Client {
        private HTTPClient httpClient;

        public ArrayList<String> getUsers() { /* ... */ }

        // In Go via "struct embedding", this method would be generated
        // automatically; in Java, we have to write it out. NBD.
        public void createUser(String name) { this.httpClient.createUser(name); }
    }

[jayd16]

Makes sense. I guess I just don't see how exported types save you from any of the pitfalls of inheritance. In my mind composition is the use of existing types without being forced into a type contract.

[weberc2]

Mind you, I don’t advocate for struct embedding, but it doesn’t force you into a type contract. The outer struct retains its type—it is not a subtype of the nested type so it can’t be used in places that take the inner type.

Literally all it does is automatically create methods on the outer struct that delegate to the anonymous member.

Unlike inheritance, there is no fragile base class problem and methods on the inner anonymous member can’t dispatch to methods on the outer struct. Also, the “parent” member is just another field in your struct. You can modify it or replace it at runtime, unlike the parent in OOP languages.