Solving function coloring by adding implicit Task.Run() calls, when awaiting synchrononous functions

[gre-42]

When awaiting a synchronous function, implicitly adding a Task.Run() should resolve the need for providing both, synchronous, and asynchronous functions.

[CyrusNajmabadi]

Not really understanding what you're asking for. Why would you need to await a synchronous function?

[gre-42]

The calling function should yield the thread upon await, run the callee on the background thread pool, and continue execution on the caller's thread when the background task is finished.

[CyrusNajmabadi]

The calling function should yield the thread upon await, run the callee on the background thread pool, and continue execution on the caller's thread when the background task is finished.

You said it was a synchronous function. So what is there to await?

[gre-42]

The rationale behind the proposal is to let the caller, not the callee, decide if an operation is slow in the given context, but thinking it through I guess async/await is good as it is.

[gre-42]

Maybe uninterruptible functions accepting a CancellationToken should always have a task interface, because this is necessary in single-threaded environments.

[CyrusNajmabadi]

Maybe uninterruptible functions accepting a CancellationToken

Why would it take a cancellation token if its uninterruptible? The point of cancellation it to allow the operation to be interrupted.

[gre-42]

The rationale behind the proposal is to let the caller, not the callee, decide if an operation is slow in the given context, but thinking it through I guess async/await is good as it is.

[CyrusNajmabadi]

The rationale behind the proposal is to let the caller, not the callee, decide if an operation is slow in the given context,

That's already how it works. The caller passes in the cancellation token, and if 'an operation is slow' (or needs cancellation for any reason whatsoever), it cancels it.