Two things: Shall we rename the thread for to focus onto the new topic?
The toolchain is great, the multi-line string literal how I imagined it to be the whole time, except for two smaller issues. The the fix-it is wrong for the following two examples: """ 123<space> """ """ abc 123<space> """ It will ask you to add \n\ for for the line behind the closing delimiter it only should be \. But a warning in such a case is the perfect direction for the whole debate we’re having in this thread. The second issue is only out of my curiosity. """ Foo\<space><new_line_character> """ This results in an error right now. Is it possible to teach the compiler to swallow whitespace characters after the backslash until a new line character is found, simply said to ignore them, because in that case they are irrelevant and not harmful. -- Adrian Zubarev Sent with Airmail Am 23. April 2017 um 13:30:34, John Holdsworth via swift-evolution (swift-evolution@swift.org) schrieb: Following this thread it reads to me that SE-0168 being accepted without newline escapes was regrettable as it gave us more flexibility in formatting “long strings”. As the core team rejected it on the basis that it was inconsistent with conventional string literals the obvious thing to do is raise a short micro-proposal that newline escape be introduced into both. This would also bring them into line with C literals. I’ve drafted a new proposal we could discuss and which I hope to submit tomorrow as the implementation is trivial if it’s not too late: https://github.com/johnno1962c/swift-evolution/blob/master/proposals/0173-newline-escape-in-strings.md For me personally, this would also have the happy side effect of making it possible to reopen the debate about "should the final newline be stripped by default" as it could now so easily be escaped for those who like their multiline literals missing a newline on the last line :) I’ve updated the prototype toolchain to bring it into line with the Core team's decision available here: http://johnholdsworth.com/swift-LOCAL-2017-04-22-a-osx.tar.gz (This includes newline escaping on all strings but dutifully strips the last line) As it looks like this patch might form the basis of the implementation in Swift 4, all testing appreciated. https://github.com/apple/swift/pull/8813 -John On 23 Apr 2017, at 10:41, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote: Sure, I can give an example. I'm not going to suggest that it'd win any awards, but: By restricting multiline literals to begin and end on distinct lines, the core team has established an interesting property. Namely, "literals" are delimited horizontally while """literals""" are delimited vertically. To enable hard wrapping, permit continuation of literals by apposition of consecutive literals. That is, "Hello, " "world!" would be equivalent to "Hello, world!". This single rule can be applied to either kind of string literal. That is: let a = "Hello, " "world!" let b = """ Hello, """ """ world! """ a == b // true It certainly permits elided newlines. It is the exact same rule applied to both types of literals. It preserves code indentation and does not require single-line string literals to support code stripping. I leave it to your judgement whether it works "equally well" and/or is "horrible." On Sun, Apr 23, 2017 at 04:13 Brent Royal-Gordon <br...@architechies.com> wrote: On Apr 22, 2017, at 8:12 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote: On Sat, Apr 22, 2017 at 3:38 AM, Brent Royal-Gordon <br...@architechies.com> wrote: On Apr 21, 2017, at 11:48 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote: This goes to my question to David Hart. Isn't this an argument for a feature to allow breaking a single-line string literal across multiple lines? What makes this a use case for some feature for _multiline_ string literals in particular? Well, if you're breaking a string across several lines, you will want indentation stripping too. Are you suggesting we should also bring that feature to single-line string literals with escaped newlines? No, I am suggesting that whatever design is used for escaped newlines, if at all possible it should be equally apt for "strings" and """strings""" such that it will not require indentation stripping. Could you share an example of such a design? It doesn't have to be something you'd be happy to have in the language; it just needs to fit the following criteria: * Permits non-significant hard-wrapping in a string literal. * Works equally well with single and triple string literals. * Preserves code indentation, but does not require single string literals to do indentation stripping. * Is not horribly inconvenient. -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
