[swift-evolution] [Pitch] Improve String Literals

Tue May 16 16:32:50 CDT 2017

On Tue, May 16, 2017 at 4:01 PM, David Hart <david at hartbit.com> wrote:

>
> On 16 May 2017, at 17:36, Gwendal Roué <gwendal.roue at gmail.com> wrote:
>
>
> Le 16 mai 2017 à 16:39, David Hart <david at hartbit.com> a écrit :
>
>
> On 16 May 2017, at 15:01, Gwendal Roué <gwendal.roue at gmail.com> 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 <tony.allevato at gmail.com> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170516/98ea7491/attachment.html>