Proposal doesn't mention that, but it seems \n is used as line terminator for multi-line string literals on any platform. On Windows it can cause some problems. For instance, if some package has a test which reads some text file, then compares result to a multi-line string literal it will fail. This occurs because git by default converts all new lines in all text files in the working copy to platform-specific ones.
During the review, there was a pull request which included these details, but it wasn't merged by the Core Team. Normalization of line breaks was also mentioned in the decision notes, and in the language reference book.
The quoted string should normalize newlines to \n in the value of the literal, regardless of whether the source file uses \n (Unix), \r\n (Windows), or \r (classic Mac) line endings. Likewise, when the compiler strips the initial and final newline from the literal value, it will strip one of any of the \n, \r\n, or \r line-ending sequences from both ends of the literal.
Line breaks in a multiline string literal are normalized to use the line feed character. Even if your source file has a mix of carriage returns and line feeds, all of the line breaks in the string will be the same.
Multiline string literals currently require a line break immediately after the opening quotation marks. We could support line break options in this position, e.g. """LF by default, """CRLF when required by a data format or platform.
That sort of thing the correct solution. If Swift were to interpret source differently on different platforms, crossâcompilation would end up irreparably broken.