Making functions that must be called in a specific, pre-defined order is the problem.

Forcing it to be done correctly through the type system is a neat trick, but better is to design it so the trick wasn’t needed in the first place.

This entirely depends on the underlying problem.

All I’m saying is that having a set of functions that must be called in a specific order is often a code smell. Forcing them to be called in the right order improves the ergonomics, but doesn’t eliminate the smell.

If there is no shared information in the ticket other than the fact that the earlier method was called, then you’re almost certainly modifying global hidden state. If you can avoid that, all the better.

If you do need to package data along with the ticket, you can just use regular structs. Which is usually better from a naming perspective anyway.

    let gpu : GPU     = GPU::initialize(…);
    let ctx : Context = gpu.create_context(…);

    let t1 : Ticket<GPU>     = GPU::initialize();
    let t2 : Ticket<Context> = GPU::create_context(t1);

The article also mentions that typestates can be cumbersome:

> Typestate improves code faultlessness and testability, but comes at the cost of more boilerplate code and can degrade readability.

I have noticed this in my own code. `Ticket` with an internal variable tracking the state makes using it simpler. I just have to store one object in my struct `struct MyData { ticket: Ticket }` and call `ticket` methods in the correct order.

Typestate `Ticket<T>` is not as simple. I have to wrap it in my own enum: `enum TicketState { Ticket1(Ticket<Func1Done>), Ticket2(Ticket<Func2Done>), }` to store in my struct: `struct MyData { ticket: TicketState }`. Then every time I call `ticket` methods, I must extract the correct variant value first. That degrades readability and creates extra run-time cost.

I’m probably doing it wrong, but when there’s a state with multiple transitions out, I can either model it as distinct methods per transition in which case the caller needs to know how to transition between states or I can have the caller pass an enum in which moves the branch into the state machine at the expense of an enum and a match statement. It’s also like 10x the code. Again, I’m very open to the possibility that I’m doing something wrong. Curious how you would model a state machine for (1) reserving the right to do the inventory (2) querying the next page of results (based on a cursor) and (3) recording the page information and the next cursor.

That sounds like a Wrapper<Func1Payload>, not a Ticket<Func1Call> that will become an extra parameter of Func2 whose only purpose is to prove to Func2 that you called Func1.

Maybe I misunderstood something.

Why should this be such a bad anti pattern? Sure, a function might not need to work on the entire data model, but with pass by reference, does it matter that much? I dont see big negatives by using struct args, possibly wrapped in some typestate.

On the other hand, doesnt seprating args and typestate defeat the purpose? Since they can now be constructed separately.

There is no cost imposed by wrapping a type in a struct to enforce a dependency.