And warn cannot fail?
pub fn warn(comptime fmt: []const u8, args: ...) void {
const held = stderr_mutex.acquire();
defer held.release();
const stderr = getStderrStream() catch return;
stderr.print(fmt, args) catch return;
}
This tradeoff is not appropriate for stdout.
Also the decision to use the mutex is not appropriate for stdout. The application may be single-threaded, or have its own synchronization strategy that makes the mutex redundant.
Zig is optimal.
This trade-off is not self-evidently correct... it's easily boiled down to personal preference. Consistency would be nicer. Zig is not "optimal" just because someone says it.
So, suppose warn() fails. What can you do about it - try to print a warning that you can't print warnings?
If you want something different, use a library or some other parts of the stdlib. Making that super common use case painful is not obviously a good decision.
The super common use case is std.debug.warn, not printing to stdout.
I would actually even argue that the meaning of "print" as printing to stdout by default is an unfortunate historical artifact. For the kind of stuff print is usually used by most of the code, it really should go to stderr, and "print" kinda implies some kind of logging IMO.
From that perspective, my suggestion would be to add a no-failure @import("std").debug.print that is an alias for warn. I don't think it's likely that breaking the established convention of print-defaults-to-stdout would cause issues in practice - in programs where this matter (like cat), the developer will quickly discover the issue the moment they try using it in a pipeline. And for programs where it doesn't, defaulting to stderr is actually the right thing.
But if you'd rather not break the convention, how about adding debug.log that is an alias for debug.warn? Or debug.say, or something like it.
stderr is the one that is not likely to be redirected somewhere that might fail - that's the whole point of keeping it distinct from stdout! And if it does get redirected, than the person that is requesting redirection is responsible for ensuring lack of failures in that channel.
I think you're approaching this from the perspective of stdout as a place for diagnostic output. It's not - it's a place for actual output (i.e. a function of program's input - the useful result of its operation). Yes, in practice, people routinely use it for diagnostics, but that's exactly the problem that Zig is trying to fix here by being opinionated about it, so far as I can tell.