-
Notifications
You must be signed in to change notification settings - Fork 4
Add execution::invoke() algorithm #303
Copy link
Copy link
Open
Labels
P1enhancementNew feature or requestNew feature or requestgood-first-issueSomething to try if you're new to the projectSomething to try if you're new to the projectneeds-paperNeeds a paper to be writtenNeeds a paper to be written
Description
Activity
Metadata
Metadata
Assignees
Labels
P1enhancementNew feature or requestNew feature or requestgood-first-issueSomething to try if you're new to the projectSomething to try if you're new to the projectneeds-paperNeeds a paper to be writtenNeeds a paper to be written
It seems reasonably common to want to invoke a function with some arguments on some execution context as an asynchronous operation, representing this operation as a sender.
Several examples currently build this sort of operation out of a combination of
just()andthen(), possibly combined withstarts_on()to do the scheduling.The pattern of writing
then(just(), [] { do_something(); })just to wrap up a call to some lambda in a sender seems like an overly complicated (and also compile-time-expensive) way of writing this.It would be more concise and also should be much simpler in terms of implementation (e.g. computing completion-signatures) to just have an algorithm that takes an invocable and that returns a sender that completes with the result of invoking that function/lambda when the sender is started.
e.g.
execution::invoke([] { do_something(); })instead of the just+then expression above.This could then be composed with
starts_on()to executedo_somethingon a particular scheduler's context.