3 ms·
It MIGHT or might NOT be valid, it depends. In a lot of cases, I might just want to print, but not yield "right here," but later (if at all in the current metho
by withinboredom 3y ago
It MIGHT or might NOT be valid, it depends. In a lot of cases, I might just want to print, but not yield "right here," but later (if at all in the current method). Further, writing to i/o is usually non-blocking (assuming the buffers are big enough for whatever you are writing), so in this case, the await literally makes no sense.
- couchand 3y agoThe canonical reason a language adds a utility like print over just offering the services of the underlying console is to make the Hello, World example as terse as possible. IO is inherently extremely complicated, but we always want people to be able to do their simplified form without thinking about it.
- nine_k 3y agoA smart print() implementation may check if there's enough output buffer, and, if so, quickly return a Future which has already completed. A smart scheduler can notice that and not switch to another green thread.
- withinboredom 3y agoOne can argue that in the VAST majority of instances, you'll never ever be printing so much that you'll fill the buffer. If you need that kind of control, just get a direct stream to stdout, otherwise make print() block if it needs to.
- avianlyric 3y agoYou might not fill the buffer. But your program might crash before the buffer is flushed. In that case having prints explicitly block until the IO is completed is very valuable, especially when debugging. Nobody wants to waste time debugging their debug code.
- withinboredom 3y agoThen just write to stderr, which is unbuffered (usually).