Proposal: Async Console I/O APIs

[hez2010]

Proposal

Async Console I/O APIs

Since now we can write async Task Main, I think it's necessary to add APIs to support cancellable async console I/O operations without needs of operating Console.In, Console.Out directly for converience.

Proposed APIs

public static class Console 
{
+    public static Task WriteAsync(string content, CancellationToken cancellationToken);
+    // ... other overloads for char, int and etc
+    public static Task WriteLineAsync(T content, CancellationToken cancellationToken);
+    // ... other overloads for char, int and etc
+    public static Task<int> ReadKeyAsync(CancellationToken cancellationToken);
+    public static Task<string> ReadLineAsync(CancellationToken cancellationToken);
}

[huoyaoyuan]

There are so many overloads on textwriter. Accessing In or Out is just literally 3 or 4 characters without any code flow changes, and can be much shorter if saved as variable.

Only ReadKeyAsync is really benificial.

[fbrosseau]

Also, at least under Windows, but I would assume other implementations are similar, the in/out streams are implemented as synchronous-only streams, so the proposal to have first-class async methods on Console would be a misleading hidden threadpool block.

[adamsitnik]

Console is not opened for async IO on Windows, but with #87103 and #72503 we should be able to get cancellation support on Windows. I wonder whether it would be possible to implement it on Unix.

cc @stephentoub @tmds

[tmds]

+    public static Task WriteAsync(string content, CancellationToken cancellationToken);
+    // ... other overloads for char, int and etc
+    public static Task WriteLineAsync(T content, CancellationToken cancellationToken);

These don't seem particularly useful: usually you want to block until the output was written.

+    public static Task<int> ReadKeyAsync(CancellationToken cancellationToken);
+    public static Task<string> ReadLineAsync(CancellationToken cancellationToken);

These have a UX race between cancellation and the user providing input: was the input for the previous or the next caller?

If ReadKeyAsync incercepts (like ReadKey(incercept: true)) on cancellation the key could go back in the queue.

I wonder whether it would be possible to implement it on Unix.

I think we may perform the read on a separate thread where it blocks until there is input.