On Thu, Apr 27, 2017 at 5:50 AM, John Holdsworth <[email protected]> wrote:
> > On 26 Apr 2017, at 23:40, Xiaodi Wu via swift-evolution < > [email protected]> wrote: > > 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. > > > Ouch, fair enough, I apologise for waisting the communities time. The > logic behind the new proposal was that newline escapes were removed from > SE-0168 as they would have been inconsistent with regular strings. So, the > next step seemed like testing the water with a new proposal with newline > escapes for all strings while we are looking at string literals in general. > I’m sorry if that and the tone of my last email was irritating. > > Multi-line strings have already been merged as agreed so perhaps there is > little point discussing this further. I've also come to realise that in > practice, stripping the last newline off multiline strings for consistency > is not an issue. > I'd imagine that this was part of the idea of "later": let the current design percolate by giving people real-world experience with it. If, as proponents have argued, trailing spaces are a key issue, you'll find people who haven't even followed the discussion chiming in to say, gee, let's get an additive solution to the problem. If, as I surmise, it's not an issue, then we won't need to add anything further. -John > > > 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 > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
