So, independent of whether one thinks this is a good idea or not, the core team wrote the following:
> Discussion on the list raised the idea of allowing a line to end with \ to "escape" the newline and elide it from the value of the literal; the core team had concerns about only allowing that inside multi-line literals and felt that that could also be considered later as an additive feature. It seems to me that, when the core team considers a feature and then removes it from an accepted proposal, saying that it should be considered _later_, that word doesn't mean immediately asking the community to consider it again. On Wed, Apr 26, 2017 at 2:14 PM, Adrian Zubarev via swift-evolution < [email protected]> wrote: > Hello folks, > > To keep things focused I opened up a new thread for this talk. Previously > the discussion took place at the thread named [Accepted] SE-0168: > Multi-Line String Literals. > > John Holdsworth has provided a first draft in his PR: > https://github.com/apple/swift-evolution/pull/695 > > I think we need to fine tune the proposal before it gets into the review > process. > ------------------------------ > > To quickly sum up, the previous proposal added support for multi-line > string literals into Swift, where its model was squeezed to the minimum. > > 1. > > No text directly after/before the starting/closing tripled """ > delimiters. > 2. > > The string content line before the closing delimiter does not inject a > new line to the final string, only lines before the last content line does. > 3. > > Trailing spaces in each string content lines will produce a warning > and hopefully provide a Fix-it to remove these, therefore there is no > trailing precision added with the minimum model of the multi-line string > literal. (This approach is editor/linter independent whatsoever.) > > ------------------------------ > > This follow up proposal will fix the last missing peace for multi-line > string literals and additionally add new possibilities to the single quoted > string literal as well. > > This proposal should also not change the fact number two from above! > > let s1 = """ > myStringExample > """ > > let s2 = "myStringExample" > > s1 == s2 // => true > > ------------------------------ > > Currently both string literals suffers from the following issue where long > strings will produce a very hard to read literal. Notice, we don’t want to > discuss here if we should or should not ever hardcode long string literals > at all. > > let myLongStringWithParagraphs = """ > Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod > tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, > quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo > consequat. > > Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod > tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, > quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo > consequat. > """ > > let myLongLineString = "Lorem ipsum dolor sit amet, consectetur adipiscing > elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut > enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut > aliquip ex ea commodo consequat." > > The current proposal solves that problem while also adding trailing > precision for the tripled multi-line string literal and providing > flexibility for code formatting for us developers in a editor independent > fashion. > > The example from above could be rewritten, while preserving the indent and > producing the exact equivalent result strings as above. > > let myLongStringWithParagraphs = """ > Lorem ipsum dolor sit amet, consectetur adipiscing elit, \ > sed do eiusmod tempor incididunt ut labore et dolore magna \ > aliqua. Ut enim ad minim veniam, quis nostrud exercitation \ > ullamco laboris nisi ut aliquip ex ea commodo consequat. > > Lorem ipsum dolor sit amet, consectetur adipiscing elit, \ > sed do eiusmod tempor incididunt ut labore et dolore magna \ > aliqua. Ut enim ad minim veniam, quis nostrud exercitation \ > ullamco laboris nisi ut aliquip ex ea commodo consequat. > """ > > let myLongLineString = "Lorem ipsum dolor sit amet, \ > "consectetur adipiscing elit, sed do eiusmod tempor \ > "incididunt ut labore et dolore magna aliqua. Ut enim \ > "ad minim veniam, quis nostrud exercitation ullamco \ > "laboris nisi ut aliquip ex ea commodo consequat." > > If this proposal will be accepted the trailing whitespaces inside a string > literal will produce two different warnings with similar Fix-its. > > // In the examples v1 and v2 the Fix-it will either ask you to delete the > // trailing space(s) or to a add a `\` after the last whitespace character. > > let v1 = """ > 123<space> > """ > > let v2 = """ > abc > 123<space> > """ > > // In the example v3 the Fix-it will either ask you to delete the > // trailing space(s) or to a add a `\n\` after the last whitespace > // character. > > let v4 = """ > abc<space> > 123 > """ > > > > -- > Adrian Zubarev > Sent with Airmail > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
