# Pre-RFC: A format spec for newline **URL:** \ **Category:** Uncategorized\ **Created:** [November 23, 2015, 10:07am UTC](https://internals.rust-lang.org/t/pre-rfc-a-format-spec-for-newline/2934 "2015-11-23T10:07:48Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![llogiq](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/llogiq/32/13692_2.png) [@llogiq](https://internals.rust-lang.org/u/llogiq)\ **Post date:** [November 23, 2015, 10:07am UTC](https://internals.rust-lang.org/t/pre-rfc-a-format-spec-for-newline/2934/1 "2015-11-23T10:07:49Z")
`\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? ---
**Author:** ![DanielKeep](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/danielkeep/32/1332_2.png) [@DanielKeep](https://internals.rust-lang.org/u/DanielKeep)\ **Post date:** [November 23, 2015, 10:45am UTC](https://internals.rust-lang.org/t/pre-rfc-a-format-spec-for-newline/2934/2 "2015-11-23T10:45:46Z")
`\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](http://stackoverflow.com/questions/33867076/is-there-a-format-spec-that-will-output-a-os-specific-newline/33867420#33867420); 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. ---
**Author:** ![oli-obk](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/oli-obk/32/3168_2.png) [@oli-obk](https://internals.rust-lang.org/u/oli-obk)\ **Post date:** [November 23, 2015, 12:02pm UTC](https://internals.rust-lang.org/t/pre-rfc-a-format-spec-for-newline/2934/3 "2015-11-23T12:02:45Z")
Are you sure `println!` outputs `\r\n` on windows? The docs and code say otherwise: [https://doc.rust-lang.org/stable/src/std/macros.rs.html#110-113](https://doc.rust-lang.org/stable/src/std/macros.rs.html#110-113) ---
**Author:** ![cuviper](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cuviper/32/1897_2.png) [@cuviper](https://internals.rust-lang.org/u/cuviper)\ **Post date:** [November 23, 2015, 6:06pm UTC](https://internals.rust-lang.org/t/pre-rfc-a-format-spec-for-newline/2934/4 "2015-11-23T18:06:11Z")
For C, Windows lets you control the translation in each file handle with "t" or "b" mode in [`fopen`](https://msdn.microsoft.com/en-us/library/yeby3zcb.aspx), `_O_TEXT` or `_O_BINARY` in [`_open`](https://msdn.microsoft.com/en-us/library/z0kc8e3z.aspx). The default is text, but you can even change that with [`_set_fmode`](https://msdn.microsoft.com/en-us/library/61dstksf.aspx). 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.) > [@DanielKeep](#): > > Well, that and code dealing with raw HTTP or Gopher and the like. For those, don't you want "`\r\n`" regardless of `target_os`? ---
**Author:** ![nodakai](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nodakai/32/6161_2.png) [@nodakai](https://internals.rust-lang.org/u/nodakai)\ **Post date:** [December 3, 2015, 4:20pm UTC](https://internals.rust-lang.org/t/pre-rfc-a-format-spec-for-newline/2934/5 "2015-12-03T16:20:54Z")
FYI, .NET has only the [`Environment.Newline`](https://msdn.microsoft.com/en-us/library/system.environment.newline.aspx) character constant. Java does not only have [newline character constants](http://stackoverflow.com/questions/247059/is-there-a-newline-constant-defined-in-java-like-environment-newline-in-c) but also [a format specifier](https://docs.oracle.com/javase/8/docs/api/java/util/Formatter.html). I’m more interested in whether [Rust `BufRead::read_line()`](https://doc.rust-lang.org/std/io/trait.BufRead.html#method.read_line) should recognize CRLF as a single new line (on Windows ?). [Java `readLine()`](https://docs.oracle.com/javase/8/docs/api/java/io/BufferedReader.html#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()`](https://msdn.microsoft.com/en-us/library/system.io.streamreader.readline%28v=vs.110%29.aspx) does the same. ---
**Author:** ![llogiq](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/llogiq/32/13692_2.png) [@llogiq](https://internals.rust-lang.org/u/llogiq)\ **Post date:** [December 3, 2015, 8:44pm UTC](https://internals.rust-lang.org/t/pre-rfc-a-format-spec-for-newline/2934/6 "2015-12-03T20:44:29Z")
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). ---
**Author:** ![llogiq](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/llogiq/32/13692_2.png) [@llogiq](https://internals.rust-lang.org/u/llogiq)\ **Post date:** [March 25, 2019, 8:25am UTC](https://internals.rust-lang.org/t/pre-rfc-a-format-spec-for-newline/2934/7 "2019-03-25T08:25:30Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.