Create a flushing version of print!

language design
1

A flushing print macro without a newline is a very basic feature almost all languages provide out of the box, I feel like it might confuse and or discourage newcomers with its absence, furthermore it is rather odd for such a basic thing to not be part of std

I have seen the above issue and realize why print! itself does not flush stdout and so I think it might be best to implement a new macro that does maybe called printf or fprint

I am posting this here as research for an RFC as recommended by the README

1 Like
2

Does this need a macro? It’s stdout().lock().flush(), right?

3

That implies locking stdout twice, though.

4

So does calling print! multiple times, though, right? I thought the answer for locking, if you’re worried about it, is to lock it manually and use write! instead of print!.

5

don’t macros exist exactly to get rid of this sort of busywork ? it just seems unnecessarily verbose to call two functions just to print and flush the screen not to mention confusing for beginners

1 Like
6

For now, you can define the macro yourself:

macro_rules! print_flush {
    ( $($t:tt)* ) => {
        {
            let mut h = stdout();
            write!(h, $($t)* ).unwrap();
            h.flush().unwrap();
        }
    }
}
2 Likes
7

What is this functionality usually named in other languages?

8

printf, System.out.print etc most languages flush their normal printing function and since rust does not for its own reasons I think a function should be added that does

9

That’s slightly incorrect. [Java System.out.print does no extra flushing.] Rather, when it thinks it’s in a try, Java flushes System.out on every write call.

I think a print-and-flush can be useful, but I disagree that it’s the default everywhere else; rather, stdout tends to be flushed “smartly” on a stdin read halt and/or a tty is detected.

10

Thank you I wasn’t aware of that, haven’t programmed a lot with Java either way since rust cannot smart-flush like for instance Java I would still think a new macro would be beneficial

11

No. Macros exist to do things like force the first argument to be a string literal, take a variadic number of parameters, etc.

Now, it might be worth it to have a function. But I'm not convinced it's worth it to simplify stdout().lock().flush() to flush_stdout(). Edit: oh, thanks cuviper! Not needing the .lock() means things are definitely fine.

cout << "Hello world!"; doesn't flush in C++; if you want flushing it's cout << "Hello world!" << flush;. (And it's not a macro.)

12

FWIW, you can stdout().flush() too, which will lock() internally.

1 Like
13

I personally disagree with that statement but I understand your argument

True but in C/C++ stdout is flushed when attempting to read from stdin which is one of the most common reason to want to write to screen without a trailing newline especially for beginners

1 Like
14

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.