It's the typestate pattern. The compiler enforces valid state transitions and so you can't just pass to the same function. It's useful to ensure that only some transitions are allowed. To be honest, the connection state presented by GP is a bad example. But you shouldn't say "it defeats the point".

A better example is an HTTP writer. One state is `Headers` with the methods `add_header()` and `body()` which returns the response in state `Body`. This enforces that one can't add headers after `body()` has been called. But you can finish the response in the `Body` state. If you do something not in this order, you get a compile error.

Yes, it'd probably be compiled into very machine code. However defining an enum for it puts the intention into the source code more explicitly, so that's considered the more idiomatic way. You'd probably have a `fn peer_id(&self) -> Option<Inet4Addr>` accessor that you'd use in the case where you'd want the Option.

Personally I don’t like using nil to represent specific states in my domain. I try to only judiciously use it to represent the lack of knowledge about some state, like if I need to reach out to some external service I don’t control, that may or may not give me an answer for my query (and conversely, I don’t like putting “unknown” cases into my enums).

it's just a minimal example, in reality you would typically have various other data that exists exclusively in connected/unconnected states

This opens you to the possible mistake of accidentally passing something of value None that then is mistakenly interpreted as a valid disconnect.

In some cases using None that way is totally fine, but it is a trade off and the cleaner way is to use a separate type

Yes, the type I wrote down is isomorphic to Option<int32>, so the compiler will ultimately generate the same machine code and do the same optimizations.

But defining a new type allows you to give the two cases more descriptive names. That saves you from having to remember and comment what the two cases represent. In a small but significant way, the code documents itself.

Also, doing it this way gives the Connection type its own name and identity separate from Option<int32>. So if you have a function that takes a Connection and some other Option<int32>, you can’t accidentally switch them: even though the two types are equivalent for optimizations and codegen, they’re NOT equivalent for the type checker.

It also makes function signatures more self-documenting: you can tell just from the type that the function takes or returns a Connection, and that helps in a small but real way to understand what it does.

I like programming like this a lot! So much so that the reason I personally like Rust a lot is simply that it’s a mainstream language with great tooling that has sum types and reasonable generics. It’s like if OCaml or Haskell had the community or tooling, or if Go or Python had the type features.