println!, eprintln! and writeln! accept other literals not just format strings

[ollie27]

The following all compile and run for example:

println!(0);
writeln!(b, true);
println!('a');

I would expect them to produce "error: format argument must be a string literal." like print!(0); does.

This is because they use things like concat!($fmt, "\n") but concat! accepts other literals not just str.

I assume this isn't intentional.

[jFransham]

One way to fix this is to replace print!'s definition with

macro_rules! print {
    ($fmt:tt $($arg:tt)*) => ($crate::io::_print(format_args!(concat!($fmt) $($arg)*)));
}

I would prefer to force println! and friends to take strings but at least this keeps it consistent.

EDIT: I honestly don't like how concat! automatically stringifies, it seems kinda ugly and I feel like there should be a separate macro that does compile-time stringification. This would almost certainly be super backwards-incompatible though.

[nagisa]

I feel like there should be a separate macro that does compile-time stringification

stringify!

[jFransham]

@nagisa awesome! Why do the places that need concat!'s stringifying functionality not use concat!(stringify!()) so concat! doesn't duplicate functionality? That would solve this issue.

EDIT: Turns out stringify! is different to concat!, the latter only accepts literals whereas the former will verbatim stringify token trees, such as assert_eq!(stringify!(a + b), "a + b").

[durka]

Seems like it'd be a breaking change to "fix" this.

[bluss]

For unreachable!() it is explicit and by design, so that part is no problem.

($msg:expr) => ({
        unreachable!("{}", $msg)
    });

[ollie27]

@bluss good point, unreachable! actually has it's own unintuitive behaviour similar but different to panic! #22932.

[raindev]

Why do we consider that the code like println!('a') works to be a bug? I understand that forbidding it will make println! more consistent and explicit but we're trading in some convenience here. The other option could be to make print! behave in same way.

[ollie27]

@raindev it's not documented so technically something needs to fixed, even if it's just the documentation.

If we make print! behave the same then surely we'd have to change format! and format_args! as well to keep things consistent and I don't think that's a good idea as this isn't even useful.

I think this should either be fixed as a breaking change, I doubt it will break much if any real world code, or just depreciated.

[raindev]

@ollie27 thanks for the clarifications, thats makes sense now.

I'm not sure format! and format_args! should behave exactly as print! and println! as the two groups of macros serve different purposes. Maybe one more special case doesn't worth it however.

[aturon]

Libs team consensus: while it may be desirable to clean this up, this is not breakage we're willing to take on during the Rust 1.x series. I've added a new tag, closed-as-desirable-breakage, to help us track issues like this that we might want to revisit if we ever produce a 2.0 release.

[oli-obk]

related issue: assert! accepts non-bools

[ollie27]

Sadly, eprintln has been implemented with this bug, so is also affected: #41192.

[Vurich]

This would be improved by #35625