3 ms·

If something bad happened, that seems much more important to ensure it printed than printing output saying that everything is working just fine. This trade-off

If something bad happened, that seems much more important to ensure it printed than printing output saying that everything is working just fine. 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.

int_19h 8y ago
There's no way to ensure that it is printed, because the environment can prevent you from doing so - stdout/err can be a pipe and it can be closed, for example. So, suppose warn() fails. What can you do about it - try to print a warning that you can't print warnings?
- coder543 8y ago
  That's kinda my point. If stdout or stderr fails, what are you going to do about it? The normally correct solution is to panic/terminate the program. Having a simple "print" function that does that is an obvious nicety. 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.
  - AndyKelley 8y ago
    If stdout fails and your program's purpose is to print to stdout, for example, if you are `cat`, `less`, `diff`, `ps`, `ls`, etc... then you should print an error message to stderr and exit with an error code. The super common use case is std.debug.warn, not printing to stdout.
    - int_19h 8y ago
      I think it might be helpful if the name of warn() did not imply that the message is actually a warning, i.e. that "something bad happened". There are many legitimate cases for printing purely informational messages to stderr - operation progress, that sort of thing. When someone sees a hello world app in Zig, and there's warn() in it, the first knee-jerk reaction is, "so what are we warning about?". 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.
      - v_lisivka 8y ago
        Standard output for errors is for errors only, or for debugging information if enabled manually. Please, don't abuse stderr, because admins are very dependent on it to be clean. Use stderr for errors and stdout for anything else. If you need your own output stream with your own output rules, just print to file.
  - int_19h 8y ago
    stdout is the one that is likely to be redirected somewhere that might fail (e.g. a file, or another program that might crash). So it's the one that you do not want to ignore failures on, not anymore so than you'd ignore an error for stdin. 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.

int_19h 8y ago

There's no way to ensure that it is printed, because the environment can prevent you from doing so - stdout/err can be a pipe and it can be closed, for example. So, suppose warn() fails. What can you do about it - try to print a warning that you can't print warnings?

coder543 8y ago
That's kinda my point. If stdout or stderr fails, what are you going to do about it? The normally correct solution is to panic/terminate the program. Having a simple "print" function that does that is an obvious nicety. 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.
- AndyKelley 8y ago
  If stdout fails and your program's purpose is to print to stdout, for example, if you are `cat`, `less`, `diff`, `ps`, `ls`, etc... then you should print an error message to stderr and exit with an error code. The super common use case is std.debug.warn, not printing to stdout.
  - int_19h 8y ago
    I think it might be helpful if the name of warn() did not imply that the message is actually a warning, i.e. that "something bad happened". There are many legitimate cases for printing purely informational messages to stderr - operation progress, that sort of thing. When someone sees a hello world app in Zig, and there's warn() in it, the first knee-jerk reaction is, "so what are we warning about?". 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.
    - v_lisivka 8y ago
      Standard output for errors is for errors only, or for debugging information if enabled manually. Please, don't abuse stderr, because admins are very dependent on it to be clean. Use stderr for errors and stdout for anything else. If you need your own output stream with your own output rules, just print to file.
- int_19h 8y ago
  stdout is the one that is likely to be redirected somewhere that might fail (e.g. a file, or another program that might crash). So it's the one that you do not want to ignore failures on, not anymore so than you'd ignore an error for stdin. 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.