Personally, when a proposal is such an obvious improvement (I think this pitch makes a pretty convincing case that the accepted proposal was deficient) for a feature that hasn’t been implemented yet, I would hope there’s room to at least consider it. As someone who uses all of these string literal cases, I want this feature. At the very least, a solution for long single-line string would be appreciated.
Jon > On May 13, 2017, at 9:55 PM, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > > On Sat, May 13, 2017 at 1:42 AM, David Hart <[email protected] > <mailto:[email protected]>> wrote: > >> On 12 May 2017, at 23:14, Xiaodi Wu <[email protected] >> <mailto:[email protected]>> wrote: >> >> I feel like a broken record: Of the three proposed components of the >> proposed solution, two were amply considered by the community and the core >> team in SE-0168. The decision has already been made _not_ to implement these >> ideas at this time. > > Can you provide me with quote from the Core Team that it should not be > implemented at this time? I have troubles finding it. > >> Significant defects discovered after the fact during implementation or new >> insights after extensive usage can prompt revisiting the decision, but that >> is not the case here: implementation did not require further clarification >> and the feature has only just landed on master. We simply cannot revisit >> topics willy-nilly. The process simply cannot work that way: few have the >> time and energy to offer their fullest consideration the first time round, >> and no one would be willing to do that if it means that the same topic will >> be revisited one month later. > > The concerns summarised in this proposal were only heavily discussed after > the acceptance of multi-line strings. Therefore, there is a great chance that > they were not discussed by the Core Team. We feel obliged to put this > proposal forward to formalise those issues. > > > [1] > > Your draft proposes to '[d]ivorce the `"""` delimiter from [...] multi-line > syntax' in order to allow `"""long strings"""` to be valid syntax. > > SE-0168 proposed 'a single simple syntax for inclusion: """long strings"""`, > explicitly permitting that syntax. > > The core team, after considering SE-0168, deliberately rejected that feature > for Swift 4. They wrote that they 'acknowledge[] that single-line triple > quoted strings have other uses in other languages, [...] but supporting that > alongside the indentation-stripping behavior leads to a lot of subtlety, and > there could be other solutions to the escaping problem down the line, such as > raw strings.' They concluded that: 'If nothing else, single-line triple > quoted strings can be considered later as an additive feature.' > > [2] > > Your draft proposes to 'support escaping newlines in multi-line strings with > a trailing `\`'. > > The core team, after considering SE-0168, acknowledged that '[d]iscussion 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.' They deliberately > rejected that feature for Swift 4, reasoning that '[they] had concerns about > only allowing that inside multi-line literals and felt that that could also > be considered later as an additive feature.' > > > If someone from the Core Team lets us know this is definitely out of scope > for Swift 4, we’ll be happy to bring it back once discussion for Swift 5 > starts. > > > Not being on the core team, I can't tell you what's definitely out of scope, > but I'm pretty sure discussing something "down the line" and "later" don't > mean revisiting a topic 22 days after the original proposal is modified and > 16 days after it's implemented, but rather in a future version of Swift, > after users have been able to try and gain experience with the approved > design. > > >> On Fri, May 12, 2017 at 15:51 David Hart via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> Hi swift-evolution, >> >> Adrian Zubarev and I have discussed several issues with string literals >> still unresolved after the multi-line string literals proposals and we >> believe that they are important enough to address for Swift 4. Here is the >> pitch for our proposal. >> >> Please let us know what you think: >> >> https://github.com/hartbit/swift-evolution/blob/literal-string-improvements/proposals/XXXX-improve-string-literals.md >> >> <https://github.com/hartbit/swift-evolution/blob/literal-string-improvements/proposals/XXXX-improve-string-literals.md> >> >> Improve String Literals >> >> Proposal: SE-XXXX >> <https://github.com/hartbit/swift-evolution/blob/literal-string-improvements/proposals/XXXX-improve-string-literals.md> >> Authors: David Hart <https://github.com/hartbit>, Adrian Zubarev >> <https://github.com/devandartist> >> Review Manager: TBD >> Status: TBD >> >> <https://github.com/hartbit/swift-evolution/blob/literal-string-improvements/proposals/XXXX-improve-string-literals.md#introduction>Introduction >> >> This proposal builds on top the new features of SE-0168 Multi-Line String >> Literals >> <https://github.com/hartbit/swift-evolution/blob/literal-string-improvements/proposals/0168-multi-line-string-literals.md> >> by widening the use-cases for unescaped double-quotes and resolving certain >> issues around long lines in single and multi-line string literals. >> >> >> <https://github.com/hartbit/swift-evolution/blob/literal-string-improvements/proposals/XXXX-improve-string-literals.md#motivation>Motivation >> >> In Swift 3, String literals have three pain points: >> >> Strings containing double-quotes >> Multi-line strings >> Long single-line strings >> Proposal SE-0168 >> <https://github.com/hartbit/swift-evolution/blob/literal-string-improvements/proposals/0168-multi-line-string-literals.md> >> fixed the two first problems with the same syntax. Unfortunately, while an >> improvement on Swift 3, several problems remain: >> >> Long single-line strings still require the less than ideal concatenation >> syntax: >> Some project styles (like the Standard Library) mandate a maximum line >> length, requiring long single-line strings to be hard-wrapped. This still >> requires odd solutions: >> >> assert(condition, "This is a long assertion message that requires " + >> "string concatenation when the project style enforces maximum line " + >> "lengths") >> Long lines in a multi-line strings can't be manually wrapped: >> let markdown = """ >> # Title >> >> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer >> elementum commodo sem, a congue orci porta sit amet. Duis facilisis, est et >> vehicula congue, turpis dui ultricies nunc, ut elementum quam elit nec >> felis. Integer aliquam id risus nec laoreet. Vivamus vitae odio sit amet >> quam iaculis fermentum nec sed neque. >> >> ## Subtitle >> >> Cras et nibh velit. Praesent eleifend sagittis quam, pellentesque >> lobortis lectus commodo vel. Vivamus suscipit, nulla quis blandit >> ullamcorper, velit neque euismod nibh, nec blandit mi diam molestie ex. Cras >> porttitor, est sed pharetra interdum, ipsum mauris viverra quam, sit amet >> eleifend purus elit sit amet odio. >> """ >> Short strings containing double-quotes have to use the multi-line syntax to >> benefit from unescaped double-quotes: >> print(""" >> { "success": false, "error": "Wrong parameter" } >> """) >> >> <https://github.com/hartbit/swift-evolution/blob/literal-string-improvements/proposals/XXXX-improve-string-literals.md#proposed-solution>Proposed >> solution >> >> By implementing multi-line string literals and support for unescaped >> double-quotes with the same syntax, SE-0168 >> <https://github.com/hartbit/swift-evolution/blob/literal-string-improvements/proposals/0168-multi-line-string-literals.md> >> has made those features unusable on their own. By dissociating them and >> supporting two extra syntax features, we can solve all the above problems: >> >> >> <https://github.com/hartbit/swift-evolution/blob/literal-string-improvements/proposals/XXXX-improve-string-literals.md#divorce-the--delimiter-from-the-multi-line-syntax-and-have-them-only-support-unescaped-double-quotes>Divorce >> the """ delimiter from the multi-line syntax and have them only support >> unescaped double-quotes >> >> The change allows us to express short strings containing double-quotes >> without resorting to the multi-line syntax: >> >> print("""{ "success": false, "error": "Wrong parameter" }""") >> As a consequence, multi-line strings are now only defined by a newline >> following the leading delimiter and the whitespace preceeding the trailing >> delimiter. They gain support for " delimiters, which has the nice advantage >> of saving a few characters in multi-line strings which are known to never >> contain double-quotes: >> >> print(""" >> Triple " are still valid delimiters >> """) >> >> query(" >> SELECT 'name' >> FROM 'people' >> WHERE age > 20 >> ") >> >> <https://github.com/hartbit/swift-evolution/blob/literal-string-improvements/proposals/XXXX-improve-string-literals.md#support-escaping-newlines-in-multi-line-strings-with-a-trailing->Support >> escaping newlines in multi-line strings with a trailing \ >> >> This change allows hard-wrapping long lines in multi-line strings. They also >> have the added benefit of making trailing white-space at the end of >> source-code lines explicit. >> >> let markdown = """ >> # Title >> >> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer \ >> elementum commodo sem, a congue orci porta sit amet. Duis facilisis, est >> \ >> et vehicula congue, turpis dui ultricies nunc, ut elementum quam elit >> nec \ >> felis. Integer aliquam id risus nec laoreet. Vivamus vitae odio sit amet >> \ >> quam iaculis fermentum nec sed neque. >> >> ## Subtitle >> >> Cras et nibh velit. Praesent eleifend sagittis quam, pellentesque \ >> lobortis lectus commodo vel. Vivamus suscipit, nulla quis blandit \ >> ullamcorper, velit neque euismod nibh, nec blandit mi diam molestie \ >> ex. Cras porttitor, est sed pharetra interdum, ipsum mauris viverra \ >> quam, sit amet eleifend purus elit sit amet odio. >> """ >> >> <https://github.com/hartbit/swift-evolution/blob/literal-string-improvements/proposals/XXXX-improve-string-literals.md#adopt-the-cobjective-c-syntax-that-concatenates-single-line-strings>Adopt >> the C/Objective-C syntax that concatenates single-line strings >> >> This change will be familiar to C developers and provides a cleaner and more >> performant solution for long single-line strings: >> >> assert(condition, "This is a long assertion message that flows " >> "from one line to the next without requiring the concatenation " >> "operator") >> >> assert(condition, """This is another "single-line" message that """ >> """supports up to two double-quotes (" and "") without any """ >> """escaping""") >> >> <https://github.com/hartbit/swift-evolution/blob/literal-string-improvements/proposals/XXXX-improve-string-literals.md#source-compatibility>Source >> compatibility >> >> This feature is purely additive; it has no effect on source compatibility. >> >> >> <https://github.com/hartbit/swift-evolution/blob/literal-string-improvements/proposals/XXXX-improve-string-literals.md#effect-on-abi-stability>Effect >> on ABI stability >> >> This feature is purely additive; it has no effect on ABI stability. >> >> >> <https://github.com/hartbit/swift-evolution/blob/literal-string-improvements/proposals/XXXX-improve-string-literals.md#effect-on-api-resilience>Effect >> on API resilience >> >> This feature is purely additive; it has no effect on API resilience. >> >> >> <https://github.com/hartbit/swift-evolution/blob/literal-string-improvements/proposals/XXXX-improve-string-literals.md#alternatives-considered>Alternatives >> considered >> >> A different syntax for supporting long single-line strings was discussed >> where ending delimiters were replaced with the \escaping character, >> mirroring their use in multi-line strings: >> >> assert(condition, "This is a long assertion message that flows \ >> "from one line to the next without requiring the concatenation \ >> "operator") >> >> assert(condition, """This is another "single-line" message that \ >> """supports up to two double-quotes (" and "") without any \ >> """escaping""") >> That syntax saved two characters per line in strings with """ delimiters but >> had several disadvantages: >> >> It loses the familiarity with C syntax >> It introduces an asymmetry between the last line and those above >> It does not do any actual escaping, introducing developer ambiguity with >> their use in multi-line literals >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <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
