3 ms·

Because you may want to share certain behaviors between the two wrapper types via generic impl

• binary132 1mo ago
  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 1mo ago
    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 1mo ago
      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.