\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.
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?
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).