On Sat, May 13, 2017 at 1:42 AM, David Hart <[email protected]> wrote:
> > On 12 May 2017, at 23:14, Xiaodi Wu <[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]> 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 >> >> 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] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
