What does Go's io.ReadWriteCloser gain by embedding io.Reader, io.Writer and io.Closer?

## What an interface declaration may contain A Go interface type lists what a value must be able to do. Its body can hold two kinds of line: a **method signature**, and the **name of another interface**, which is called *embedding*. When you embed an interface, every method it requires becomes a requirement of the new interface too. The resulting method set is the union of the embedded sets plus any methods you spelled out directly. The `io` package is the canonical demonstration: - `io.Reader` requires `Read(p []byte) (n int, err error)` - `io.Writer` requires `Write(p []byte) (n int, err error)` - `io.Closer` requires `Close() error` - `io.ReadWriteCloser` embeds all three and declares nothing else So `io.ReadWriteCloser` is not a bigger idea than its parts; it is a *name* for the conjunction of them. `io.ReadWriter`, `io.ReadCloser` and `io.WriteCloser` exist in the same family for the other combinations. ## Satisfaction stays implicit Go has no `implements` keyword. A type satisfies an interface when its method set contains every required method with an identical signature -- the compiler checks that at the point of assignment or call, not at the point of declaration. `*os.File` has `Read`, `Write` and `Close` (among many others), so it satisfies `io.ReadWriteCloser` without the `os` package having heard of the interface. Your own type does exactly the same: write the three methods and you are done. A common beginner mistake is thinking the implementing struct must itself embed `io.Reader` -- it must not; embedding an interface into a *struct* is a different mechanism with different consequences. ## Embedding is not inheritance An interface contains no code at all -- only requirements. So embedding cannot hand an implementer a default `Read`, cannot provide a base implementation, and has no notion of overriding or of calling "up". Everything embedding does is arithmetic on method sets at compile time. This is why the compound interfaces cost nothing at run time: an interface value is still a pair of (dynamic type, value), and calling `Close` through `io.ReadWriteCloser` costs the same as calling it through `io.Closer`. ## Assignability runs from wide to narrow Because satisfaction is by method set, a value typed as `io.ReadWriteCloser` may be assigned to a variable of type `io.Reader`, or passed to `func Count(r io.Reader)`. The wider interface's method set is a superset of the narrower one's, so the requirement is met. The reverse does not work: an `io.Reader` cannot be assigned to an `io.ReadWriteCloser`, because the compiler has no evidence that `Write` and `Close` exist. Getting from narrow back to wide requires a run-time type assertion, which is a different topic. ## Duplicate methods across embedded interfaces Embedding two interfaces that both require a method with the same name is fine in current Go as long as the signatures are identical -- the union simply contains it once. If the signatures differ, the declaration is a compile-time error, because no single type could satisfy both. ## Why this shape matters for design The payoff is that the small interfaces are reusable and the compound ones are free. If `io` had started with one large `File` interface, every function would have demanded far more than it used, and every fake in a test would have had to implement the lot. Instead each function asks for the narrowest thing it actually calls: `io.Copy` takes an `io.Writer` and an `io.Reader`, so it works over files, network connections, `bytes.Buffer`, HTTP bodies and pipes alike, none of which were designed with `io.Copy` in mind. When you design your own interfaces, follow the same order: write the one- and two-method interfaces that describe single capabilities, and compose them by embedding only where a caller genuinely needs the combination. A three-line interface that embeds two others reads better than a six-method one, and each half stays independently usable. ## What to remember Embedding an interface inside an interface unions method sets, adds no implementation, is resolved entirely at compile time, and keeps the standard library's small interfaces composable.