Pre-RFC: A format spec for newline

\n works on all unices, but not on Windows. As println!() already emits the correct newline for the underlying OS, it should be easy enough to add a format spec that emits a newline, to use in multiline messages instead of \n.

I’d just like to add that we shouldn’t use \n because this is a specific character and not all Windows software needs strings with "\r\n", so that’d be too much magic.

Bikeshedding time:

  • {n}
  • {/}
  • {.}
  • other ideas?

Does this need a full-blown RFC or would a PR with the additional code be acceptable?

\g. It’s half-way between \n and \r. … I mean, on American keyboards, anyway.

That said, I agree with the answer in this this suspiciously apropos Stack Overflow question; I’m not sure there’s a huge need for this. I stopped caring about the distinction years ago, and never really noticed a problem outside of Notepad.

Well, that and code dealing with raw HTTP or Gopher and the like.

Edit: to clarify, I stopped caring about which I output. I still care about correctly processing both as valid newlines.

Are you sure println! outputs \r\n on windows? The docs and code say otherwise:

For C, Windows lets you control the translation in each file handle with "t" or "b" mode in fopen, _O_TEXT or _O_BINARY in _open. The default is text, but you can even change that with _set_fmode. This is for both input and output, affecting both newlines and EOF markers.

(Glibc accepts "b" as a no-op, as there's no translation in any case.)

For those, don't you want "\r\n" regardless of target_os?

FYI, .NET has only the Environment.Newline character constant. Java does not only have newline character constants but also a format specifier.

I’m more interested in whether Rust BufRead::read_line() should recognize CRLF as a single new line (on Windows ?). Java readLine() recognizes “any one of a line feed ('\n'), a carriage return ('\r'), or a carriage return followed immediately by a linefeed” as a newline. .NET ReadLine() does the same.

Thanks for the heads-up. AFAIK, Rust readLine accepts \r?\n as line delimiter (which means \r will be silently discarded at EOL). \r by itself does not constitute a newline (and the systems that use it as a line delimiter are becoming increasingly rare).

So, I’ve been assured that the Windows side of things is taken care of, which I was a bit worried about (but do not have sufficient first-hand experience, since I haven’t used Windows in the last two years).

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