← Back to context

Comment by llleeeoooh

5 hours ago

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

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.