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.

▲

vatsachak a day ago | parent [-]

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 ())

	▲	throwaway17_17 a day ago \| parent [-]
		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.