Oh, yes, I see the miscommunication now. Phantom types can be leveraged in a similar way, where a type (the phantom type that you are generic over) represents t

Oh, yes, I see the miscommunication now. Phantom types can be leveraged in a similar way, where a type (the phantom type that you are generic over) represents that state. To answer your question - the end result of both approaches is a session type with the same guarantees. I've seen that approach used but I can't really comment too much on the differences as I've never used it myself. I find my approach simple in practice (I've shipped Python code that takes the same approach, sans affine types) because it separates the types out. So, essentially, I write my non-sesssiony struct with all of its methods, and then I wrap that in the session types. This lets me easily drop into the non-session type if necessary, and the sessions types act as thin wrappers. My imap client worked the same way, if I recall. The downside is likely boilerplate.