All awaitables are implicitly typed senders

[ericniebler]

I think this demonstrates that we should update P2300 to make execution::connect and execution::sender_traits hip to awaitables.

[ericniebler]

@lewissbaker For the record, I don't believe this prevents us from coming to LEWG with a std::task<> proposal that does something smarter with context from the receiver.

[LeeHowes]

We can specialise for std::task, I can see that. I am wondering though if the right default here should be to repost on get_scheduler(r) or to call inline? If we can transitioning from an arbitrary awaitable to an arbitrary sender, should we switch scheduler for safety, or call inline for efficiency?

[ericniebler]

I feel that if folks want to start the awaitable on a particular execution context, they can use the on algorithm. I wouldn't presume the user's intent based the presence or absence of a scheduler associated with the receiver.

Edit: oh, you're probably talking about on resumption. If the awaitable resumes on a different context, what should happen? I'm less certain about that.

Edit 2: If we wanted to reschedule on resume, I think we'd need to standardize something like co_viaIfAsync. @lewissbaker what do you think?

[LeeHowes]

Correct, I'm thinking about resumption.

We can standardise an algorithm to do that, and it need not be a coroutine one, it could just be the equivalent of on(void) or a named algorithm like reschedule_on_current_scheduler() (as the folly coroutine version) (assuming that on resumes on the downstream, I forget if we specced it that way). Or we can require it as part of resumption of a coroutine.

Fundamentally though the question is what the right default here is. It's possible that coroutines are no different from a situation like:

sender foo(sender s) { return s | do something big and complicated that might be resumed inline; }

in which case the algorithm solution works whether s is an awaitable or not:

Sender foo(Sender s) { return s | reschedule_on_current_scheduler() | do something big and complicated that might be resumed inline; }

or it's possible that coroutines are a bigger concern because the way people write code makes them more prone to accidental deadlock from inline resumption of children.