You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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);
}
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.
Reacted by Miha Zupan, antiufo, pinkfloydx33 and strangeman375
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.
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.
+ 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.
+publicstatic Task<int> ReadKeyAsync(CancellationTokencancellationToken);+ public staticTask<string>ReadLineAsync(CancellationTokencancellationToken);
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.
Activity
huoyaoyuan commentedon Nov 26, 2019
There are so many overloads on textwriter. Accessing
InorOutis just literally 3 or 4 characters without any code flow changes, and can be much shorter if saved as variable.Only
ReadKeyAsyncis really benificial.fbrosseau commentedon Nov 30, 2019
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.
Allow serving of unknown files (dotnet#299)
adamsitnik commentedon Nov 14, 2023
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 commentedon Nov 16, 2023
These don't seem particularly useful: usually you want to block until the output was written.
These have a UX race between cancellation and the user providing input: was the input for the previous or the next caller?
If
ReadKeyAsyncincercepts (likeReadKey(incercept: true)) on cancellation the key could go back in the queue.I think we may perform the read on a separate thread where it blocks until there is input.