Hi! I've been writing a CLI app. So far, I used async style mostly.
However, as I've written the core logic, I began to write the output of the program to stdout. I thought, well I use async, so why not use asynchronous variants of stdout and stdin?
But I stumbled upon a problem that my structs that implement Display won't be able to use asynchronous variants, as fmt synchronous. Are there any asynchronous variants of Display?
But I think not, as this idea is obscure (then I might have to write 2 implementations: one sync, other async).
Should I better use synchronous stdout and stdin? I think this is probably the answer, but I wonder if anyone has other thoughts.
I remember trying using some bridge between async and sync code, but I couldn't make it to work
The Display trait and friends don't perform any I/O, so asychronous versions of them make no sense. Just use format!() or .to_string() to display your structs as Strings, and then output those strings using async I/O.
Also, you may want to give this thread an actual title, unless you want your e-mail address broadcast to the internet?
I edited the title myself (because I apparently have permissions to do that). @pot_45 : Feel free to change it again if you'd prefer something different.
This does not follow. The important part is not whether Display or its implementations include some particular IO operations (indeed, they do not), but the fact that IO operations are performed while in the stack frame of a Display::fmt() call.
In order to actually make use of whatever text a Display implementation displays, the destination (as wrapped by fmt::Formatter) must accept and either store or send on the text. Thus, if the true destination (say, some network socket, for example) cannot accept the text rapidly enough, then either unbounded buffering or blocking must occur, both of which are undesirable. An ‘async version of Display’ would enable the whole formatting and writing process to be suspended, which is a capability that is impossible with the current definition of Display.
(I don’t mean that an async version of Display is necessarily worth writing; only that it is definitely not nonsensical or superfluous.)