On Tue, May 16, 2017 at 4:01 PM, David Hart <[email protected]> wrote:
> > On 16 May 2017, at 17:36, Gwendal Roué <[email protected]> wrote: > > > Le 16 mai 2017 à 16:39, David Hart <[email protected]> a écrit : > > > On 16 May 2017, at 15:01, Gwendal Roué <[email protected]> wrote: > > Xiaodi Wu, your opposition has been recorded. You don't buy the Motivation > section. Other people here do, definitely. > > Divorce the """ delimiter from the multi-line syntax and have them only > support unescaped double-quotes > > > This means support for: > > let x = " > foo > bar > " > > This one is unexpected, and not requested by many users. Does it bring > much? > > I wonder whether this addition was introduced in order to make the > proposal as consistent as possible, and prevent some criticisms. It has > proven pointless. I suggest forgetting about pleasing people who don't want > to be pleased, and to reconsider this "divorce" section. Consistency is not > the main point. The main point is UX. This means easing the daily life of > code writers, and easing the daily life of code readers (this involves > being careful which text editors and code prettyfiers are unable to handle > the proposal). > > > Well, one of the issues I have with the status-quo is that ""” has two > meanings (support for “ without escaping and multi-line support), which > causes consistency issues when you want to support “"” one-liners. I prefer > a model where features can be orthogonally composed: hence “”” for > escaping, and newlines around delimiters to signify multi-lines. Support > for multi-lines with “ delimiters is a natural consequence of that model: > so why disallow it? > > > Because this pollutes your proposal. Instead of making it simpler, it > makes it more complex. You force the reader to think about the consequences > of the composition of orthogonal topics, and sort between useful ones that > improve life, and useless ones that pollute the mind, the time of stack > overflow reviewers, and the future Swift String tutorials. Do you want to > give more work to the linters and style fashionistas who love those kind of > holes in language? > > > If my proposal was accepted as-is except “ multi-line delimiters were > disallowed, I would find that rather inelegant. That’s why I’m mentioning > it. I prefer the proposal to be a bit more “polluted” but be more detailed. > > If the two following literals are equivalent, I suggest your forget about > the first, since it brings nothing on top of SE-0168: > > " > foo > bar > " > > """ > foo > bar > “"" > > > I don’t understand the argument. As per my proposal, the following two > strings are also equivalent: > > “foo bar” > “””foo bar””” > > The second simply allows the use of double-quote heavy strings with not > escaping at the expense of longer delimiters. Why couldn’t that argument > also be made for the examples you gave above? > > Anyway, it’s probably not worth spending too much time discussing details > like this. Let’s agree on the important stuff first :) > > The proposal argument for it is weak: > > 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: > > > "never" is a smelly word: real programs evolve, and good diffs are local > diffs: > > // bad diff > - " > + """ > ... > ... > ... > - “Yes”, he said. > + "Yes", he said > ... > ... > ... > -" > +""" > > Support escaping newlines in multi-line strings with a trailing \ > > > Great. That's the main request, unless I'm misled: split long literals > accross multiple lines. > > Now that Xiaodi Wu has found them, the core team questions about the > trailing backslash should be addressed in more details. > > > Sure: > > > Cool. Hard-wrapping is the meat. > > 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. > > I’m not sure what subtleties they are referring to, so I don’t know how to > address those fears. And I’m not convinced raw strings are the right > solution because I’d like to retain escaping and string interpolation even > in those one-liners. Raw strings are interesting, I just don’t see them as > a solution for triple-quoted one-liners. > > > This is about "single-line triple quoted strings", not trailing backslash > and hard-wrapping. Still, more about that below, in the section about C > inspiration. > > > [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. > > This last one confused me. In what else than multi-line literals could we > escape newlines? Be definition, if you don’t escape it, it’s a newline and > your are by definition in a multi-line literal. > > > This means that SE-0168 was about triple-quoted literals, and that the > core team felt uneasy supporting trailing backslash for triple-quoted > literals only. > > If you intend to provide hard-wrapping with the trailing backslash, your > proposal must support it in single-quoted literals also. > > > At, let’s start with that. If support for trailing backslash in > single-quoted literals is mandatory, I see three ways of handling it: > > *1. No special indentation stripping* > > print(“This is a \ > single-line \ > sentence”) > > *2. Strip indentation based on the last line (similar to “””)* > > print(“This is a \ > single-line \ > sentence”) > > *3. Line continuation style* > > print(“This is a \ > "single-line \ > "sentence”) > > *Opinion* > > The problem is that all of the above have their own issues IMHO (1 is not > very useful, 2 is too similar to multi-lines so confusing, 3 is Adrian’s > favorite but not an improvement over C-style concatenation). In fact, all > of the above improves very little on C’s string literal concatenation: > > print(“This is a " > "single-line " > "sentence”) > > So by bother? Trailing backslash in single-quotes strings looks like > “pollution” to me. > Bingo. You've just rephrased the core team's rationale for rejecting the `\` feature the first time round, and you've also just demonstrated what Gwendal said earlier about focusing your proposal. Your stated motivation is to improve hard-wrapping. The core team rejected `\` because it's a syntax for hard-wrapping that simply doesn't make sense for `"` string literals. Their challenge for any would-be authors of future proposals on hard-wrapping is to create a single design that makes sense for both `"""` string literals and `"` string literals. Instead, you are re-proposing `\` and also proposing a _different_ syntax, declaring that both features should be legal for both types of string literals; however, each syntax is still seriously lacking in ergonomics for one or the other type of string literal. This goes again to my original point: your proposal is re-stating a rejected feature. But if we need to have it, I’d go for the simplest possible solution (1). > > Adopt the C/Objective-C syntax that concatenates single-line strings > > > A battle-tested solution. Doesn't it look redundant with both the > "divorce" and the trailing backslash? > > > It may look redundant but I see them supporting two different purposes: > > • Multi-line strings allow editing and copy/pasting of long strings, > containing newlines, without having to prefix each line with a delimiter > (because it does it’s nice leading whitespace stripping): it’s great for > DSLs like SQL where newlines help readability but has no effect on parsing. > But it comes at the expense of vertical space. > • The string concatenation syntax is great for shorter pieces of text > where newlines should not be inserted by default and where vertical space > is more conservative: greater for text messages. > > If we did not have that feature, long text messages which need manual > wrapping would look like: > > assert(condition, “”” > This is my message but after some point I need to go to the \ > next line and I need to escape newlines on every line. > “”" > > > C string concatenation is quite good for strings that are not wrapped > (think markdown), while SE-0168 literals shine for strings that are already > wrapped (think commits written by Linus): > > > Agreed. But trailing backslash in SE-0168 literals is even better for > strings that are not wrapped (IMHO): > > “”" > Lorem ipsum dolor sit amet, consectetur adipiscing elit. Praesent sed \ > facilisis erat. Maecenas placerat nisi id lectus lacinia, a vehicula \ > mauris consequat. > > Donec quam arcu, venenatis a varius non, placerat a ligula. Proin eget \ > libero quis lacus sodales convallis lacinia in eros. Nulla mollis dictum \ > ligula, ut facilisis sapien sollicitudin in. > “”” > > Don’t you think? (Notice the lack of \n when newlines are wanted, and the > lack of the line continuation) > > // Non-wrapped strings: > > "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Praesent sed " > "facilisis erat. Maecenas placerat nisi id lectus lacinia, a vehicula " > "mauris consequat.\n" > "\n" > "Donec quam arcu, venenatis a varius non, placerat a ligula. Proin eget " > "libero quis lacus sodales convallis lacinia in eros. Nulla mollis dictum > " > "ligula, ut facilisis sapien sollicitudin in." > > > """ > Lorem ipsum dolor sit amet, consectetur adipiscing elit. Praesent sed > facilisis erat. Maecenas placerat nisi id lectus lacinia, a vehicula mauris > consequat. > > Donec quam arcu, venenatis a varius non, placerat a ligula. Proin eget > libero quis lacus sodales convallis lacinia in eros. Nulla mollis dictum > ligula, ut facilisis sapien sollicitudin in. > """ > > // Wrapped strings: > > "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Praesent sed\n" > "facilisis erat. Maecenas placerat nisi id lectus lacinia, a vehicula\n" > "mauris consequat.\n" > "\n" > "Donec quam arcu, venenatis a varius non, placerat a ligula. Proin eget\n" > "libero quis lacus sodales convallis lacinia in eros. Nulla mollis dictum > \n" > "ligula, ut facilisis sapien sollicitudin in." > > > """ > Lorem ipsum dolor sit amet, consectetur adipiscing elit. Praesent sed > facilisis erat. Maecenas placerat nisi id lectus lacinia, a vehicula > mauris consequat. > > Donec quam arcu, venenatis a varius non, placerat a ligula. Proin eget > libero quis lacus sodales convallis lacinia in eros. Nulla mollis dictum > ligula, ut facilisis sapien sollicitudin in. > """ > > NB: C string concatenation has nothing to do with C's trailing backslash: > > char *s = "Long strings can be bro\ > ken into two or more pieces."; > > The C's trailing backslash only means "dear parser, please pretend the > following newline does not exist." C has thus no support for indentation, > unlike Swift and SE-0168. Since the core team has rejected triple-quoted > strings that do not start with a newline because of subtleties with > indentation, the proposal needs *great care* on this topic :-) > > Le 16 mai 2017 à 16:58, Tony Allevato <[email protected]> a écrit : > > Regarding the C/Objective-C syntax, what would be the advantages over > concatenating the strings with `+`? > > > The support for ExpressibleByStringLiteral and > ExpressibleByStringInterpolation protocols. > > Gwendal > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
