> On 16 May 2017, at 17:36, Gwendal Roué <gwendal.r...@gmail.com> wrote:
>
>
>> Le 16 mai 2017 à 16:39, David Hart <da...@hartbit.com
>> <mailto:da...@hartbit.com>> a écrit :
>>
>>>
>>> On 16 May 2017, at 15:01, Gwendal Roué <gwendal.r...@gmail.com
>>> <mailto:gwendal.r...@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. 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.allev...@gmail.com
>> <mailto:tony.allev...@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
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
