[Pitch] Improve String Literals

hartbit · May 12, 2017, 8:44pm

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:

github.com

hartbit/swift-evolution/blob/literal-string-improvements/proposals/XXXX-improve-string-literals.md

# Improve String Literals

* Proposal: [SE-XXXX](XXXX-improve-string-literals.md)
* Authors: [David Hart](https://github.com/hartbit), [Adrian Zubarev](https://github.com/devandartist)
* Review Manager: TBD
* Status: TBD

## Introduction

This proposal builds on top the new features of [SE-0168 Multi-Line String Literals](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.

## Motivation

In Swift 3, String literals have three pain points:

* Strings containing double-quotes
* Multi-line strings
* Long single-line strings

Proposal [SE-0168](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:

This file has been truncated. show original

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
<swift-evolution/XXXX-improve-string-literals.md at literal-string-improvements · hartbit/swift-evolution · GitHub

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.

<swift-evolution/XXXX-improve-string-literals.md at literal-string-improvements · hartbit/swift-evolution · GitHub

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" }
    """)
<swift-evolution/XXXX-improve-string-literals.md at literal-string-improvements · hartbit/swift-evolution · GitHub 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:

<swift-evolution/XXXX-improve-string-literals.md at literal-string-improvements · hartbit/swift-evolution · GitHub 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
    ")
<swift-evolution/XXXX-improve-string-literals.md at literal-string-improvements · hartbit/swift-evolution · GitHub 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.
    """
<swift-evolution/XXXX-improve-string-literals.md at literal-string-improvements · hartbit/swift-evolution · GitHub 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""")
<swift-evolution/XXXX-improve-string-literals.md at literal-string-improvements · hartbit/swift-evolution · GitHub compatibility

This feature is purely additive; it has no effect on source compatibility.

<swift-evolution/XXXX-improve-string-literals.md at literal-string-improvements · hartbit/swift-evolution · GitHub on ABI stability

This feature is purely additive; it has no effect on ABI stability.

<swift-evolution/XXXX-improve-string-literals.md at literal-string-improvements · hartbit/swift-evolution · GitHub on API resilience

This feature is purely additive; it has no effect on API resilience.

<swift-evolution/XXXX-improve-string-literals.md at literal-string-improvements · hartbit/swift-evolution · GitHub 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

xwu · May 12, 2017, 9:14pm

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.

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.

···

On Fri, May 12, 2017 at 15:51 David Hart via swift-evolution < swift-evolution@swift.org> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

hartbit · May 13, 2017, 6:42am

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.

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.

David.

···

On 12 May 2017, at 23:14, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Fri, May 12, 2017 at 15:51 David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

benrimmington · May 17, 2017, 2:26am

Re: <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 `\`

Markdown can already be "hard-wrapped" in a multi-line string:
<Daring Fireball: Markdown Syntax Documentation;
Are there any better examples, to show the need for this feature?

### Adopt the C/Objective-C syntax that concatenates single-line strings

Concatenation of adjacent string literals in Swift
(which I think is handled by the *preprocessor* in C)
has a potential hazard [H2] identified by Peter Dillinger:
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/034897.html>

-- Ben

xwu · May 14, 2017, 1:55am

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 Sat, May 13, 2017 at 1:42 AM, David Hart <david@hartbit.com> wrote:

On 12 May 2017, at 23:14, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Fri, May 12, 2017 at 15:51 David Hart via swift-evolution < > swift-evolution@swift.org> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Jon_Shier · May 15, 2017, 2:59pm

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 <swift-evolution@swift.org> wrote:

On Sat, May 13, 2017 at 1:42 AM, David Hart <david@hartbit.com <mailto:david@hartbit.com>> wrote:

On 12 May 2017, at 23:14, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> 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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

hartbit · May 15, 2017, 9:28pm

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.

Thanks for the references! Indeed, those specific points were discussed but I’m not sure what they mean by "can be considered later as an additive feature”. I’m not so certain it necessarily pushes it back to a future version of Swift. Nonetheless, the other points in the proposal don’t seem to have been discussed.

···

On 14 May 2017, at 03:55, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Sat, May 13, 2017 at 1:42 AM, David Hart <david@hartbit.com <mailto:david@hartbit.com>> wrote:

On 12 May 2017, at 23:14, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:

On Fri, May 12, 2017 at 15:51 David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

xwu · May 15, 2017, 9:21pm

Again, the point I'm making is totally independent of the merits of the
proposal. The point is that most of these ideas _have_ been considered, and
they have not been accepted for Swift 4.

You and I may not agree with that decision, but it is simply not OK to ask
over and over again that the community consider your favored idea after
it's been explicitly considered, formally proposed, and rejected or
modified.

···

On Mon, May 15, 2017 at 09:59 Jon Shier <jon@jonshier.com> wrote:

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 < > swift-evolution@swift.org> wrote:

On Sat, May 13, 2017 at 1:42 AM, David Hart <david@hartbit.com> wrote:

On 12 May 2017, at 23:14, Xiaodi Wu <xiaodi.wu@gmail.com> 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 < >> swift-evolution@swift.org> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

xwu · May 15, 2017, 9:52pm

I'm quite sure it means this: As with all parts of Swift, a decision can be
re-considered if implementation difficulties are found, or if new insights
arise from extended use. Because these features are additive, rejecting
them now does not mean that source compatibility requirements would make
such re-consideration impossible--if they are to be re-considered in the
future. Until such time as a fit justification is found to bring the
current decision into question, the decision of the core team is that these
proposed features are rejected from inclusion in Swift.

···

On Mon, May 15, 2017 at 16:28 David Hart <david@hartbit.com> wrote:

On 14 May 2017, at 03:55, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Sat, May 13, 2017 at 1:42 AM, David Hart <david@hartbit.com> wrote:

On 12 May 2017, at 23:14, Xiaodi Wu <xiaodi.wu@gmail.com> 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.

Thanks for the references! Indeed, those specific points were discussed
but I’m not sure what they mean by "can be considered later as an
additive feature”. I’m not so certain it necessarily pushes it back to a
future version of Swift. Nonetheless, the other points in the proposal
don’t seem to have been discussed.

On Fri, May 12, 2017 at 15:51 David Hart via swift-evolution < >> swift-evolution@swift.org> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

gwendal.roue · May 16, 2017, 1:01pm

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).

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.

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?

Last, the proposal contains literals without leading and trailing newlines. I thought those were not supported by SE-0168. If this is the case, we need more detail here, so that the proposal is rock solid, and the core team confident it deserves consideration. A little more work, please :-)

Thanks,
Gwendal Roué

···

Le 15 mai 2017 à 23:52, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> a écrit :

I'm quite sure it means this: As with all parts of Swift, a decision can be re-considered if implementation difficulties are found, or if new insights arise from extended use. Because these features are additive, rejecting them now does not mean that source compatibility requirements would make such re-consideration impossible--if they are to be re-considered in the future. Until such time as a fit justification is found to bring the current decision into question, the decision of the core team is that these proposed features are rejected from inclusion in Swift.
On Mon, May 15, 2017 at 16:28 David Hart <david@hartbit.com> wrote:

On 14 May 2017, at 03:55, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Sat, May 13, 2017 at 1:42 AM, David Hart <david@hartbit.com> wrote:

On 12 May 2017, at 23:14, Xiaodi Wu <xiaodi.wu@gmail.com> 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.

Thanks for the references! Indeed, those specific points were discussed but I’m not sure what they mean by "can be considered later as an additive feature”. I’m not so certain it necessarily pushes it back to a future version of Swift. Nonetheless, the other points in the proposal don’t seem to have been discussed.

On Fri, May 12, 2017 at 15:51 David Hart via swift-evolution <swift-evolution@swift.org> 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
  • Authors: David Hart, Adrian Zubarev
  • Review Manager: TBD
  • Status: TBD
Introduction

This proposal builds on top the new features of SE-0168 Multi-Line String Literals by widening the use-cases for unescaped double-quotes and resolving certain issues around long lines in single and multi-line string literals.

Motivation

In Swift 3, String literals have three pain points:

  • Strings containing double-quotes
  • Multi-line strings
  • Long single-line strings
Proposal SE-0168 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" }
    """)
Proposed solution

By implementing multi-line string literals and support for unescaped double-quotes with the same syntax, SE-0168 has made those features unusable on their own. By dissociating them and supporting two extra syntax features, we can solve all the above problems:

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

")
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.
    """
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""")
Source compatibility

This feature is purely additive; it has no effect on source compatibility.

Effect on ABI stability

This feature is purely additive; it has no effect on ABI stability.

Effect on API resilience

This feature is purely additive; it has no effect on API resilience.

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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

xwu · May 16, 2017, 3:31pm

Xiaodi Wu, your opposition has been recorded. You don't buy the Motivation
section. Other people here do, definitely.

I think you make some insightful comments below. But again, to clarify, I
am not voicing support or opposition to the ideas themselves.

I am objecting that this pitch contains mostly ideas discussed previously
and amply, and which have been formally considered and rejected. _Whether
or not you buy the motivation for doing so_, it is--as a matter of
etiquette if nothing else--not appropriate to make repeated pitches every
few weeks. As I wrote earlier, few (if any) people would volunteer their
time and effort to bring up thoughtful points about an upcoming decision if
the same discussion is simply going to repeat itself two weeks after the
decision has been made.

Therefore, I am claiming that even if some believe that this is the best
idea ever conceived, and even if minor changes to the rationale or design
are made, it should as a matter of principle not be the subject of further
discussion on this list _because it has already been rejected_. To do so
would undermine accepted norms which are important to encourage thoughtful
and timely participation.

···

On Tue, May 16, 2017 at 8:01 AM, Gwendal Roué <gwendal.roue@gmail.com> wrote:

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).

> 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.

> 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?

Last, the proposal contains literals without leading and trailing
newlines. I thought those were not supported by SE-0168. If this is the
case, we need more detail here, so that the proposal is rock solid, and the
core team confident it deserves consideration. A little more work, please
:-)

Thanks,
Gwendal Roué

> Le 15 mai 2017 à 23:52, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> a écrit :
>
> I'm quite sure it means this: As with all parts of Swift, a decision can
be re-considered if implementation difficulties are found, or if new
insights arise from extended use. Because these features are additive,
rejecting them now does not mean that source compatibility requirements
would make such re-consideration impossible--if they are to be
re-considered in the future. Until such time as a fit justification is
found to bring the current decision into question, the decision of the core
team is that these proposed features are rejected from inclusion in Swift.
> On Mon, May 15, 2017 at 16:28 David Hart <david@hartbit.com> wrote:
>> On 14 May 2017, at 03:55, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
>>
>> On Sat, May 13, 2017 at 1:42 AM, David Hart <david@hartbit.com> wrote:
>>
>>> On 12 May 2017, at 23:14, Xiaodi Wu <xiaodi.wu@gmail.com> 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.
>
> Thanks for the references! Indeed, those specific points were discussed
but I’m not sure what they mean by "can be considered later as an additive
feature”. I’m not so certain it necessarily pushes it back to a future
version of Swift. Nonetheless, the other points in the proposal don’t seem
to have been discussed.
>
>>> On Fri, May 12, 2017 at 15:51 David Hart via swift-evolution < > swift-evolution@swift.org> 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
>>> • Authors: David Hart, Adrian Zubarev
>>> • Review Manager: TBD
>>> • Status: TBD
>>> Introduction
>>>
>>> This proposal builds on top the new features of SE-0168 Multi-Line
String Literals by widening the use-cases for unescaped double-quotes and
resolving certain issues around long lines in single and multi-line string
literals.
>>>
>>> Motivation
>>>
>>> In Swift 3, String literals have three pain points:
>>>
>>> • Strings containing double-quotes
>>> • Multi-line strings
>>> • Long single-line strings
>>> Proposal SE-0168 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" }
>>> """)
>>> Proposed solution
>>>
>>> By implementing multi-line string literals and support for unescaped
double-quotes with the same syntax, SE-0168 has made those features
unusable on their own. By dissociating them and supporting two extra syntax
features, we can solve all the above problems:
>>>
>>> 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
>>>
>>>
>>> ")
>>> 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.
>>> """
>>> 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""")
>>> Source compatibility
>>>
>>> This feature is purely additive; it has no effect on source
compatibility.
>>>
>>> Effect on ABI stability
>>>
>>> This feature is purely additive; it has no effect on ABI stability.
>>>
>>> Effect on API resilience
>>>
>>> This feature is purely additive; it has no effect on API resilience.
>>>
>>> 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
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

DevAndArtist · May 16, 2017, 1:39pm

Well the main complain I had during the discussion with David was, that I previously had such a model in mind which will break up long double-quoted string literals. Please look up this design in the alternative section of our proposal. By adding slightly redundant multi-line string literal syntax for consistency renders that complain to zero. By allowing:

"
SELECT 'name'
FROM 'people'
WHERE age > 20
"
it becomes clear that the trailing backslash should only be used for escaping new line injection in multi-line string literals, but not for breaking up long strings (similar to other languages like JavaScript):

"SELECT 'name' \
FROM 'people' \
WHERE age > 20"
This also lets us adopt the C/Objective-C syntax instead.

"SELECT 'name' "
"FROM 'people' "
"WHERE age > 20"

···

--
Adrian Zubarev
Sent with Airmail

Am 16. Mai 2017 um 15:02:06, Gwendal Roué via swift-evolution (swift-evolution@swift.org) schrieb:

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).

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.

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?

hartbit · May 16, 2017, 2:39pm

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?

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:

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.

[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.

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.
  “”"

···

On 16 May 2017, at 15:01, Gwendal Roué <gwendal.roue@gmail.com> wrote:

Last, the proposal contains literals without leading and trailing newlines. I thought those were not supported by SE-0168. If this is the case, we need more detail here, so that the proposal is rock solid, and the core team confident it deserves consideration. A little more work, please :-)

Thanks,
Gwendal Roué

Le 15 mai 2017 à 23:52, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> a écrit :

I'm quite sure it means this: As with all parts of Swift, a decision can be re-considered if implementation difficulties are found, or if new insights arise from extended use. Because these features are additive, rejecting them now does not mean that source compatibility requirements would make such re-consideration impossible--if they are to be re-considered in the future. Until such time as a fit justification is found to bring the current decision into question, the decision of the core team is that these proposed features are rejected from inclusion in Swift.
On Mon, May 15, 2017 at 16:28 David Hart <david@hartbit.com> wrote:

On 14 May 2017, at 03:55, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Sat, May 13, 2017 at 1:42 AM, David Hart <david@hartbit.com> wrote:

On 12 May 2017, at 23:14, Xiaodi Wu <xiaodi.wu@gmail.com> 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.

Thanks for the references! Indeed, those specific points were discussed but I’m not sure what they mean by "can be considered later as an additive feature”. I’m not so certain it necessarily pushes it back to a future version of Swift. Nonetheless, the other points in the proposal don’t seem to have been discussed.

On Fri, May 12, 2017 at 15:51 David Hart via swift-evolution <swift-evolution@swift.org> 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
  • Authors: David Hart, Adrian Zubarev
  • Review Manager: TBD
  • Status: TBD
Introduction

This proposal builds on top the new features of SE-0168 Multi-Line String Literals by widening the use-cases for unescaped double-quotes and resolving certain issues around long lines in single and multi-line string literals.

Motivation

In Swift 3, String literals have three pain points:

  • Strings containing double-quotes
  • Multi-line strings
  • Long single-line strings
Proposal SE-0168 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" }
   """)
Proposed solution

By implementing multi-line string literals and support for unescaped double-quotes with the same syntax, SE-0168 has made those features unusable on their own. By dissociating them and supporting two extra syntax features, we can solve all the above problems:

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

")
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.
   """
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""")
Source compatibility

This feature is purely additive; it has no effect on source compatibility.

Effect on ABI stability

This feature is purely additive; it has no effect on ABI stability.

Effect on API resilience

This feature is purely additive; it has no effect on API resilience.

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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

gwendal.roue · May 16, 2017, 3:51pm

Xiaodi Wu, your opposition has been recorded. You don't buy the Motivation section. Other people here do, definitely.

I think you make some insightful comments below. But again, to clarify, I am not voicing support or opposition to the ideas themselves.

I am objecting that this pitch contains mostly ideas discussed previously and amply, and which have been formally considered and rejected. _Whether or not you buy the motivation for doing so_, it is--as a matter of etiquette if nothing else--not appropriate to make repeated pitches every few weeks. As I wrote earlier, few (if any) people would volunteer their time and effort to bring up thoughtful points about an upcoming decision if the same discussion is simply going to repeat itself two weeks after the decision has been made.

You did very kindly quote the rejection reasons. This is a work effort that the proposal authors should take seriously. Everybody knows how difficult it is to find a past message in swift-evolution :-)

The core team has left some room for improvement. They talk about non-explicit "subtleties", and future "additive features". I don't see any etiquette violation here.

Therefore, I am claiming that even if some believe that this is the best idea ever conceived, and even if minor changes to the rationale or design are made, it should as a matter of principle not be the subject of further discussion on this list _because it has already been rejected_. To do so would undermine accepted norms which are important to encourage thoughtful and timely participation.

Like you, I want any further work to build on top of SE-0168, which has been accepted. There is no matter for a fileprivate drama here. The new proposal needs some focus: we should give some time to the authors.

Gwendal

···

Le 16 mai 2017 à 17:31, Xiaodi Wu <xiaodi.wu@gmail.com> a écrit :
On Tue, May 16, 2017 at 8:01 AM, Gwendal Roué <gwendal.roue@gmail.com <mailto:gwendal.roue@gmail.com>> wrote:

> Le 15 mai 2017 à 23:52, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :
>
> I'm quite sure it means this: As with all parts of Swift, a decision can be re-considered if implementation difficulties are found, or if new insights arise from extended use. Because these features are additive, rejecting them now does not mean that source compatibility requirements would make such re-consideration impossible--if they are to be re-considered in the future. Until such time as a fit justification is found to bring the current decision into question, the decision of the core team is that these proposed features are rejected from inclusion in Swift.
> On Mon, May 15, 2017 at 16:28 David Hart <david@hartbit.com <mailto:david@hartbit.com>> wrote:
>> On 14 May 2017, at 03:55, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:
>>
>> On Sat, May 13, 2017 at 1:42 AM, David Hart <david@hartbit.com <mailto:david@hartbit.com>> wrote:
>>
>>> On 12 May 2017, at 23:14, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> 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.
>
> Thanks for the references! Indeed, those specific points were discussed but I’m not sure what they mean by "can be considered later as an additive feature”. I’m not so certain it necessarily pushes it back to a future version of Swift. Nonetheless, the other points in the proposal don’t seem to have been discussed.
>
>>> On Fri, May 12, 2017 at 15:51 David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
>>> • Authors: David Hart, Adrian Zubarev
>>> • Review Manager: TBD
>>> • Status: TBD
>>> Introduction
>>>
>>> This proposal builds on top the new features of SE-0168 Multi-Line String Literals by widening the use-cases for unescaped double-quotes and resolving certain issues around long lines in single and multi-line string literals.
>>>
>>> Motivation
>>>
>>> In Swift 3, String literals have three pain points:
>>>
>>> • Strings containing double-quotes
>>> • Multi-line strings
>>> • Long single-line strings
>>> Proposal SE-0168 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" }
>>> """)
>>> Proposed solution
>>>
>>> By implementing multi-line string literals and support for unescaped double-quotes with the same syntax, SE-0168 has made those features unusable on their own. By dissociating them and supporting two extra syntax features, we can solve all the above problems:
>>>
>>> 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
>>>
>>>
>>> ")
>>> 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.
>>> """
>>> 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""")
>>> Source compatibility
>>>
>>> This feature is purely additive; it has no effect on source compatibility.
>>>
>>> Effect on ABI stability
>>>
>>> This feature is purely additive; it has no effect on ABI stability.
>>>
>>> Effect on API resilience
>>>
>>> This feature is purely additive; it has no effect on API resilience.
>>>
>>> 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
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution

allevato · May 16, 2017, 2:58pm

Well the main complain I had during the discussion with David was, that I
previously had such a model in mind which will break up long double-quoted
string literals. Please look up this design in the alternative section of
our proposal. By adding slightly redundant multi-line string literal syntax
for consistency renders that complain to zero. By allowing:

"
SELECT 'name'
FROM 'people'
WHERE age > 20
"

it becomes clear that the trailing backslash should only be used for
escaping new line injection in multi-line string literals, but not for
breaking up long strings (similar to other languages like JavaScript):

"SELECT 'name' \
FROM 'people' \
WHERE age > 20"

This also lets us adopt the C/Objective-C syntax instead.

"SELECT 'name' "
"FROM 'people' "
"WHERE age > 20"

Regarding the C/Objective-C syntax, what would be the advantages over

concatenating the strings with `+`? All I can see is that it saves two
characters per line—is that sufficient to warrant adding another way of
doing the same thing? They're available in C/Obj-C because `+` for string
literals *wasn't* available, but since Swift does support `+` for string
literals, I think it's hard to rationalize adding this.

···

On Tue, May 16, 2017 at 6:47 AM Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote:

--
Adrian Zubarev
Sent with Airmail

Am 16. Mai 2017 um 15:02:06, Gwendal Roué via swift-evolution (
swift-evolution@swift.org) schrieb:

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).

> 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.

> 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?

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

gwendal.roue · May 16, 2017, 2:20pm

I

···

Le 16 mai 2017 à 15:39, Adrian Zubarev <adrian.zubarev@devandartist.com> a écrit :

Well the main complain I had during the discussion with David was, that I previously had such a model in mind which will break up long double-quoted string literals. Please look up this design in the alternative section of our proposal. By adding slightly redundant multi-line string literal syntax for consistency renders that complain to zero. By allowing:

"
SELECT 'name'
FROM 'people'
WHERE age > 20
"
it becomes clear that the trailing backslash should only be used for escaping new line injection in multi-line string literals, but not for breaking up long strings (similar to other languages like JavaScript):

"SELECT 'name' \
FROM 'people' \
WHERE age > 20"
This also lets us adopt the C/Objective-C syntax instead.

"SELECT 'name' "
"FROM 'people' "
"WHERE age > 20"

SE-0168 had one focus: long literals that contain newline characters. And it does a great job addressing it.

SE-0168 does not talk about hard wrapping. Make this the only focus of your proposal. Simplify your motivation section. Strip away redundant solutions. Become expert in hard wrapping, and please give us one correct solution. Don't forget to talk about trailing/leading newlines and text editor grammars, because those were two important discussion topics for SE-0168.

Gwendal

gwendal.roue · May 16, 2017, 3:36pm

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 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
"""

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.

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):

// 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:39, David Hart <david@hartbit.com> a écrit :

On 16 May 2017, at 15:01, Gwendal Roué <gwendal.roue@gmail.com> wrote:

Le 16 mai 2017 à 16:58, Tony Allevato <tony.allevato@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

hartbit · May 16, 2017, 2:45pm

I

Well the main complain I had during the discussion with David was, that I previously had such a model in mind which will break up long double-quoted string literals. Please look up this design in the alternative section of our proposal. By adding slightly redundant multi-line string literal syntax for consistency renders that complain to zero. By allowing:

"
SELECT 'name'
FROM 'people'
WHERE age > 20
"
it becomes clear that the trailing backslash should only be used for escaping new line injection in multi-line string literals, but not for breaking up long strings (similar to other languages like JavaScript):

"SELECT 'name' \
FROM 'people' \
WHERE age > 20"
This also lets us adopt the C/Objective-C syntax instead.

"SELECT 'name' "
"FROM 'people' "
"WHERE age > 20"

SE-0168 had one focus: long literals that contain newline characters. And it does a great job addressing it.

SE-0168 does not talk about hard wrapping. Make this the only focus of your proposal. Simplify your motivation section. Strip away redundant solutions. Become expert in hard wrapping, and please give us one correct solution. Don't forget to talk about trailing/leading newlines and text editor grammars, because those were two important discussion topics for SE-0168.

I’m okay with that goal. But I’m not convinced that trailing backslash in multi-line strings alone can solve hard-wrapping. Again, compare the two examples (already mentioned in previous email):

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.
    “””)

VS

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.")

···

On 16 May 2017, at 16:20, Gwendal Roué via swift-evolution <swift-evolution@swift.org> wrote:

Le 16 mai 2017 à 15:39, Adrian Zubarev <adrian.zubarev@devandartist.com <mailto:adrian.zubarev@devandartist.com>> a écrit :

Gwendal

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

benrimmington · May 16, 2017, 7:28pm

Would it be possible to have compile-time concatenation of *all* string literals using the `+` operator?

  // Written as:
  @available(*, unavailable, message: "Long strings can be bro" +
                                      "ken into two or more pieces.")
  // Compiled as:
  @available(*, unavailable, message: "Long strings can be broken into two or more pieces.")

This could also be used with types such as StaticString, which don't have their own `+` operator.

  // Written as:
  let s: StaticString = "Long strings can be bro" +
                        "ken into two or more pieces."
  // Compiled as:
  let s: StaticString = "Long strings can be broken into two or more pieces."

-- Ben

···

On 16 May 2017, at 16:36, Gwendal Roué wrote:

Le 16 mai 2017 à 16:58, Tony Allevato <tony.allevato@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.

DevAndArtist · May 16, 2017, 6:32pm

Would you prefer concatenation syntax using a trailing backslash over a trailing double quote?

let s = "Long strings can be bro\
        "ken into two or more pieces."

let s = "Long strings can be bro"
        "ken into two or more pieces."
At least it seems reasonable and consistent to me, because this is no more a feature for escaping new lines only, but a feature for hard wrapping string literals.

Thank you for your feedback.

···

--
Adrian Zubarev
Sent with Airmail

Am 16. Mai 2017 um 17:37:06, Gwendal Roué via swift-evolution (swift-evolution@swift.org) schrieb:

Le 16 mai 2017 à 16:39, David Hart <david@hartbit.com> a écrit :

On 16 May 2017, at 15:01, Gwendal Roué <gwendal.roue@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 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
"""

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.

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):

// 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@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