Skip to content

Comment on Functional State Machines in Rust: Typestate and Newtype Patternsparent

Comments

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.

Okay let's say you had three functions

func1(foo_0) -> bar0

func2(foo_1, foo_2) -> bar1

func3(foo_3, foo_3) -> bar2

And you wanted to make sure that func2 and func3 can only be called after func1 has been called.

A wrapper on the output of func1 here would be awkward because then you return Wrapper<Func1Done>(bar0). But func2 does not even need a bar0 and neither does func3.

So the solution is to return (bar0, Wrapper<Func1Done>) from func1 where

struct Wrapper<T>(//cheating ())

I think this is a good argument for the Ticket, however, for the case where these three functions are generically useful, not just used in this specified order, I would write a specific function, just copy-paste of the bodies capturing the required ordering as an implementation detail.

Obviously if you are operating in a wide, concurrent async system then the Ticket and separate function calls is the better mechanism for the ordering.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.