[Accepted] SE-0168: Multi-Line String Literals

Proposal Link: swift-evolution/0168-multi-line-string-literals.md at master · apple/swift-evolution · GitHub

Hello Swift Community,

The review of SE-0168: "Multi-Line String Literals" ran from April 6...12, 2017. The proposal is accepted with revisions. Community feedback was largely positive on the idea, though the discussion highlighted several under-specified aspects.

- Questions arose about whether text could appear on the same line as the opening and closing delimiter, and how that would interact with the de-indentation algorithm. The core team feels that it is important to keep this feature focused on its purpose of allowing the easy embedding of pasted blocks of text, so text inside the literal on the same line as either delimiter should be disallowed.

// Allowed, equal to "foo\nbar"
"""
  foo
  bar
  """

// Not allowed
"""foo
  bar
  """

// Not allowed
"""
  foo
  bar"""

This keeps the model straightforward to describe: a single newline is always stripped after the opening delimiter and before the closing one, and the closing delimiter's position always determines the indentation level of the entire literal. The core team acknowledges that single-line triple quoted strings have other uses in other languages, such as to avoid excessive escaping in a string that contains lots of literal quotes, 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. If nothing else, single-line triple quoted strings can be considered later as an additive feature.

- The core team also believes that underindentation or inconsistent tab/space usage within the indentation should be an error. Every line inside the literal must begin with the exact sequence of spaces and tabs that precedes the closing delimiter.

  """
  <tab><space>this is OK
  <space><space>this is an error
  <space><tab>this is also an error
  <tab>under-indenting is an error too
  <tab><space><space>but you can go nuts after the indentation all you want
  <tab><space><tab>you do you
  <tab><space>"""

- The quoted string should normalize newlines to \n in the value of the literal, regardless of whether the source file uses \n (Unix), \r\n (Windows), or \r (classic Mac) line endings. Likewise, when the compiler strips the initial and final newline from the literal value, it will strip one of any of the \n, \r\n, or \r line-ending sequences from both ends of the literal.

  // equal to "foo\nfoo\nfoo\nfoo"
  """^J
    foo^M^J
    foo^J
    foo^M
    foo^M
    """

- It should be clarified that multiline strings support the same escapes and interpolations as single-line strings. This allows a literal """ to be written \""". Discussion 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; the core team had concerns about only allowing that inside multi-line literals and felt that that could also be considered later as an additive feature.

Thanks John, Brent, and Tyler for the original proposal, and thanks to everyone who participated in the discussion!

-Joe
Review Manager

First of all, thank you for accepting the proposal. However I still have one single concern left about the trailing whitespaces. Will the final implemented version raise a warning or produce an error when there are trailing whitespaces?

The whole idea of a trailing \ was in first place to prevent new line injection but also for trailing whitespace character precision.

The following example could have 1000 characters, but a different developer who reads the code wouldn’t even notice.

"""
Foo<space><space>…<space>
Bar
"""
That’s what the trailing backslash was meant for. To prevent unwanted whitespaces, or if you really need them, to force you to be precise about them.

"""
Foo<space><space><space>\n\
Bar
"""

···

--
Adrian Zubarev
Sent with Airmail

Am 19. April 2017 um 22:03:31, Joe Groff via swift-evolution (swift-evolution@swift.org) schrieb:

- It should be clarified that multiline strings support the same escapes and interpolations as single-line strings. This allows a literal """ to be written \""". Discussion 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; the core team had concerns about only allowing that inside multi-line literals and felt that that could also be considered later as an additive feature.

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md

Hello Swift Community,

The review of SE-0168: "Multi-Line String Literals" ran from April 6...12, 2017. The proposal is *accepted with revisions. *Community feedback was largely positive on the idea, though the discussion highlighted several under-specified aspects.

- Questions arose about whether text could appear on the same line as the opening and closing delimiter, and how that would interact with the de-indentation algorithm. The core team feels that it is important to keep this feature focused on its purpose of allowing the easy embedding of pasted blocks of text, so *text inside the literal on the same line as either delimiter should be disallowed.*

    // Allowed, equal to "foo\nbar"
    """
       foo
       bar
       """

Could you clarify, shouldn't this be equal to "foo\nbar\n" ? I.e. with trailing \n for "bar" line?
I didn't find any clarification about the injecting of line-end for last text line(not for the """ delimiter).

···

On 19.04.2017 23:03, Joe Groff via swift-evolution wrote:

    // Not allowed
    """foo
       bar
       """

    // Not allowed
    """
       foo
       bar"""

This keeps the model straightforward to describe: a *single newline *is always stripped after the opening delimiter and before the closing one, and the closing delimiter's position always determines the indentation level of the entire literal. The core team acknowledges that single-line triple quoted strings have other uses in other languages, such as to avoid excessive escaping in a string that contains lots of literal quotes, 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. If nothing else, single-line triple quoted strings can be considered later as an additive feature.

- The core team also believes that *underindentation or inconsistent tab/space usage within the indentation should be an error.* Every line inside the literal must begin with the exact sequence of spaces and tabs that precedes the closing delimiter.

"""
<tab><space>this is OK
<space><space>this is an error
<space><tab>this is also an error
<tab>under-indenting is an error too
<tab><space><space>but you can go nuts after the indentation all you want
<tab><space><tab>you do you
<tab><space>"""

- The quoted string should *normalize newlines* to \n in the value of the literal, regardless of whether the source file uses \n (Unix), \r\n (Windows), or \r (classic Mac) line endings. Likewise, when the compiler strips the initial and final newline from the literal value, it will strip one of any of the \n, \r\n, or \r line-ending sequences from both ends of the literal.

// equal to "foo\nfoo\nfoo\nfoo"
"""^J
   foo^M^J
   foo^J
   foo^M
   """

- It should be clarified that *multiline strings support the same escapes and interpolations* as single-line strings. This allows a literal """ to be written \""". Discussion 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; the core team had concerns about only allowing that inside multi-line literals and felt that that could also be considered later as an additive feature.

Thanks John, Brent, and Tyler for the original proposal, and thanks to everyone who participated in the discussion!

-Joe
Review Manager

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

That seems like a reasonable thing to warn about. That also reminds me, blank lines should be accepted within a literal even if they aren't "indented" with invisible whitespace.

-Joe

···

On Apr 19, 2017, at 2:43 PM, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:

First of all, thank you for accepting the proposal. However I still have one single concern left about the trailing whitespaces. Will the final implemented version raise a warning or produce an error when there are trailing whitespaces?

The whole idea of a trailing \ was in first place to prevent new line injection but also for trailing whitespace character precision.

The following example could have 1000 characters, but a different developer who reads the code wouldn’t even notice.

"""
Foo<space><space>…<space>
Bar
"""
That’s what the trailing backslash was meant for. To prevent unwanted whitespaces, or if you really need them, to force you to be precise about them.

"""
Foo<space><space><space>\n\
Bar
"""

Hmm, I don't know that I agree. What's the harm of trailing spaces, and if a warning, how would I silence it given that \ is rejected as a way to suppress a literal newline?

\("") comes to mind, if nothing else. Other common tools like Git already flag trailing whitespace by default, so even if Swift doesn't warn about it, you might still need to satisfy other tools in your pipeline.

-Joe

···

On Apr 19, 2017, at 3:07 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Wed, Apr 19, 2017 at 17:02 Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Apr 19, 2017, at 2:43 PM, Adrian Zubarev <adrian.zubarev@devandartist.com <mailto:adrian.zubarev@devandartist.com>> wrote:

First of all, thank you for accepting the proposal. However I still have one single concern left about the trailing whitespaces. Will the final implemented version raise a warning or produce an error when there are trailing whitespaces?

The whole idea of a trailing \ was in first place to prevent new line injection but also for trailing whitespace character precision.

The following example could have 1000 characters, but a different developer who reads the code wouldn’t even notice.

"""
Foo<space><space>…<space>
Bar
"""
That’s what the trailing backslash was meant for. To prevent unwanted whitespaces, or if you really need them, to force you to be precise about them.

"""
Foo<space><space><space>\n\
Bar
"""

That seems like a reasonable thing to warn about. That also reminds me, blank lines should be accepted within a literal even if they aren't "indented" with invisible whitespace.

-Joe

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

Not to mention that many IDEs (at least have options to) trim trailing whitespace automatically, so it has a fair to high likelihood of breaking unexpectedly and invisibly.

···

On Apr 19, 2017, at 3:09 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On Apr 19, 2017, at 3:07 PM, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:

Hmm, I don't know that I agree. What's the harm of trailing spaces, and if a warning, how would I silence it given that \ is rejected as a way to suppress a literal newline?

\("") comes to mind, if nothing else. Other common tools like Git already flag trailing whitespace by default, so even if Swift doesn't warn about it, you might still need to satisfy other tools in your pipeline.

-Joe

On Wed, Apr 19, 2017 at 17:02 Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Apr 19, 2017, at 2:43 PM, Adrian Zubarev <adrian.zubarev@devandartist.com <mailto:adrian.zubarev@devandartist.com>> wrote:

First of all, thank you for accepting the proposal. However I still have one single concern left about the trailing whitespaces. Will the final implemented version raise a warning or produce an error when there are trailing whitespaces?

The whole idea of a trailing \ was in first place to prevent new line injection but also for trailing whitespace character precision.

The following example could have 1000 characters, but a different developer who reads the code wouldn’t even notice.

"""
Foo<space><space>…<space>
Bar
"""
That’s what the trailing backslash was meant for. To prevent unwanted whitespaces, or if you really need them, to force you to be precise about them.

"""
Foo<space><space><space>\n\
Bar
"""

That seems like a reasonable thing to warn about. That also reminds me, blank lines should be accepted within a literal even if they aren't "indented" with invisible whitespace.

-Joe

_______________________________________________
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

Cosigned. We already have an Xcode setting to strip trailing whitespace, a Git setting to flag it, and linter settings to remove it. (For instance, SwiftFormat has a --trimwhitespace flag.) Not every tool needs to handle every case of questionable style.

···

On Apr 19, 2017, at 3:18 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

Other common tools like Git already flag trailing whitespace by default, so even if Swift doesn't warn about it, you might still need to satisfy other tools in your pipeline.

Isn't that an equally good argument for Swift *not* warning you about it? If it's harmful, you'll have other tools in the pipeline to flag it for you.

--
Brent Royal-Gordon
Architechies

If I understood Joe correctly he said it gets stripped:

"a single newline is always stripped after the opening delimiter and before the closing one, and the closing delimiter's position always determines the indentation level of the entire literal."

So I think it would be "foo\nbar".

···

On Apr 19, 2017, at 4:52 PM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

On 19.04.2017 23:03, Joe Groff via swift-evolution wrote:
Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md
Hello Swift Community,
The review of SE-0168: "Multi-Line String Literals" ran from April 6...12, 2017. The proposal is *accepted with revisions. *Community feedback was largely positive on the idea, though the discussion highlighted several under-specified aspects.
- Questions arose about whether text could appear on the same line as the opening and closing delimiter, and how that would interact with the de-indentation algorithm. The core team feels that it is important to keep this feature focused on its purpose of allowing the easy embedding of pasted blocks of text, so *text inside the literal on the same line as either delimiter should be disallowed.*
   // Allowed, equal to "foo\nbar"
   """
      foo
      bar
      """

Could you clarify, shouldn't this be equal to "foo\nbar\n" ? I.e. with trailing \n for "bar" line?
I didn't find any clarification about the injecting of line-end for last text line(not for the """ delimiter).

   // Not allowed
   """foo
      bar
      """
   // Not allowed
   """
      foo
      bar"""
This keeps the model straightforward to describe: a *single newline *is always stripped after the opening delimiter and before the closing one, and the closing delimiter's position always determines the indentation level of the entire literal. The core team acknowledges that single-line triple quoted strings have other uses in other languages, such as to avoid excessive escaping in a string that contains lots of literal quotes, 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. If nothing else, single-line triple quoted strings can be considered later as an additive feature.
- The core team also believes that *underindentation or inconsistent tab/space usage within the indentation should be an error.* Every line inside the literal must begin with the exact sequence of spaces and tabs that precedes the closing delimiter.
"""
<tab><space>this is OK
<space><space>this is an error
<space><tab>this is also an error
<tab>under-indenting is an error too
<tab><space><space>but you can go nuts after the indentation all you want
<tab><space><tab>you do you
<tab><space>"""
- The quoted string should *normalize newlines* to \n in the value of the literal, regardless of whether the source file uses \n (Unix), \r\n (Windows), or \r (classic Mac) line endings. Likewise, when the compiler strips the initial and final newline from the literal value, it will strip one of any of the \n, \r\n, or \r line-ending sequences from both ends of the literal.
// equal to "foo\nfoo\nfoo\nfoo"
"""^J
  foo^M^J
  foo^J
  foo^M
  foo^M
  """
- It should be clarified that *multiline strings support the same escapes and interpolations* as single-line strings. This allows a literal """ to be written \""". Discussion 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; the core team had concerns about only allowing that inside multi-line literals and felt that that could also be considered later as an additive feature.
Thanks John, Brent, and Tyler for the original proposal, and thanks to everyone who participated in the discussion!
-Joe
Review Manager
_______________________________________________
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

Hmm, I don't know that I agree. What's the harm of trailing spaces, and if
a warning, how would I silence it given that \ is rejected as a way to
suppress a literal newline?

\("") comes to mind, if nothing else.

Good point.

Other common tools like Git already flag trailing whitespace by default, so

even if Swift doesn't warn about it, you might still need to satisfy other
tools in your pipeline.

Isn't that an equally good argument for Swift *not* warning you about it?
If it's harmful, you'll have other tools in the pipeline to flag it for you.

···

On Wed, Apr 19, 2017 at 5:09 PM, Joe Groff <jgroff@apple.com> wrote:

On Apr 19, 2017, at 3:07 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

-Joe

On Wed, Apr 19, 2017 at 17:02 Joe Groff via swift-evolution < > swift-evolution@swift.org> wrote:

On Apr 19, 2017, at 2:43 PM, Adrian Zubarev <adrian.zubarev@devandartist. >> > wrote:

First of all, thank you for accepting the proposal. However I still have
one single concern left about the trailing whitespaces. Will the final
implemented version raise a warning or produce an error when there are
trailing whitespaces?

The whole idea of a trailing \ was in first place to prevent new line
injection but also for trailing whitespace character precision.

The following example could have 1000 characters, but a different
developer who reads the code wouldn’t even notice.

"""
Foo<space><space>…<space>
Bar
"""

That’s what the trailing backslash was meant for. To prevent unwanted
whitespaces, or if you really need them, to force you to be precise about
them.

"""
Foo<space><space><space>\n\
Bar
"""

That seems like a reasonable thing to warn about. That also reminds me,
blank lines should be accepted within a literal even if they aren't
"indented" with invisible whitespace.

-Joe

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

Not dealing with trailing whitespaces is indeed the right decision, I
think. The idea has always been that one key advantage for this syntax is
that one can copy and paste the greatest possible amount of multi-line text
without having to edit each line.

Many source documents can have such trailing spaces at the end of lines.
For example, I'm sure that some of the HTML documents I've written, unless
linted, have such spaces. They are both invisible and harmless in the
original source document.

They would also do no harm in a multi-line literal. There is no need to
warn or error in that scenario, and the proposed workaround requires a
rather ugly escape pattern to cure this non-harm.

···

On Wed, Apr 19, 2017 at 16:43 Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote:

First of all, thank you for accepting the proposal. However I still have
one single concern left about the trailing whitespaces. Will the final
implemented version raise a warning or produce an error when there are
trailing whitespaces?

The whole idea of a trailing \ was in first place to prevent new line
injection but also for trailing whitespace character precision.

The following example could have 1000 characters, but a different
developer who reads the code wouldn’t even notice.

"""
Foo<space><space>…<space>
Bar
"""

That’s what the trailing backslash was meant for. To prevent unwanted
whitespaces, or if you really need them, to force you to be precise about
them.

"""
Foo<space><space><space>\n\
Bar
"""

--
Adrian Zubarev
Sent with Airmail

Am 19. April 2017 um 22:03:31, Joe Groff via swift-evolution (
swift-evolution@swift.org) schrieb:

- It should be clarified that *multiline strings support the same escapes
and interpolations* as single-line strings. This allows a literal """ to
be written \""". Discussion 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; the core team had concerns about only allowing that inside
multi-line literals and felt that that could also be considered later as an
additive feature.

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

Hmm, I don't know that I agree. What's the harm of trailing spaces, and if
a warning, how would I silence it given that \ is rejected as a way to
suppress a literal newline?

···

On Wed, Apr 19, 2017 at 17:02 Joe Groff via swift-evolution < swift-evolution@swift.org> wrote:

On Apr 19, 2017, at 2:43 PM, Adrian Zubarev < > adrian.zubarev@devandartist.com> wrote:

First of all, thank you for accepting the proposal. However I still have
one single concern left about the trailing whitespaces. Will the final
implemented version raise a warning or produce an error when there are
trailing whitespaces?

The whole idea of a trailing \ was in first place to prevent new line
injection but also for trailing whitespace character precision.

The following example could have 1000 characters, but a different
developer who reads the code wouldn’t even notice.

"""
Foo<space><space>…<space>
Bar
"""

That’s what the trailing backslash was meant for. To prevent unwanted
whitespaces, or if you really need them, to force you to be precise about
them.

"""
Foo<space><space><space>\n\
Bar
"""

That seems like a reasonable thing to warn about. That also reminds me,
blank lines should be accepted within a literal even if they aren't
"indented" with invisible whitespace.

-Joe

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

This is the natural way of text blocks. If you really need a blank line you can add one at the start/end or alternatively use \n.

"""

Foo

"""

// Equals "\nFoo\n"

···

--
Adrian Zubarev
Sent with Airmail

Am 19. April 2017 um 22:53:07, Vladimir.S via swift-evolution (swift-evolution@swift.org) schrieb:

On 19.04.2017 23:03, Joe Groff via swift-evolution wrote:

Proposal Link:
https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md

Hello Swift Community,

The review of SE-0168: "Multi-Line String Literals" ran from April 6...12, 2017. The
proposal is *accepted with revisions. *Community feedback was largely positive on the
idea, though the discussion highlighted several under-specified aspects.

- Questions arose about whether text could appear on the same line as the opening and
closing delimiter, and how that would interact with the de-indentation algorithm. The
core team feels that it is important to keep this feature focused on its purpose of
allowing the easy embedding of pasted blocks of text, so *text inside the literal on
the same line as either delimiter should be disallowed.*

// Allowed, equal to "foo\nbar"
"""
foo
bar
"""

Could you clarify, shouldn't this be equal to "foo\nbar\n" ? I.e. with trailing \n
for "bar" line?
I didn't find any clarification about the injecting of line-end for last text
line(not for the """ delimiter).

// Not allowed
"""foo
bar
"""

// Not allowed
"""
foo
bar"""

This keeps the model straightforward to describe: a *single newline *is always
stripped after the opening delimiter and before the closing one, and the closing
delimiter's position always determines the indentation level of the entire literal.
The core team acknowledges that single-line triple quoted strings have other uses in
other languages, such as to avoid excessive escaping in a string that contains lots
of literal quotes, 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. If nothing else, single-line triple
quoted strings can be considered later as an additive feature.

- The core team also believes that *underindentation or inconsistent tab/space usage
within the indentation should be an error.* Every line inside the literal must begin
with the exact sequence of spaces and tabs that precedes the closing delimiter.

"""
<tab><space>this is OK
<space><space>this is an error
<space><tab>this is also an error
<tab>under-indenting is an error too
<tab><space><space>but you can go nuts after the indentation all you want
<tab><space><tab>you do you
<tab><space>"""

- The quoted string should *normalize newlines* to \n in the value of the literal,
regardless of whether the source file uses \n (Unix), \r\n (Windows), or \r (classic
Mac) line endings. Likewise, when the compiler strips the initial and final newline
from the literal value, it will strip one of any of the \n, \r\n, or \r line-ending
sequences from both ends of the literal.

// equal to "foo\nfoo\nfoo\nfoo"
"""^J
foo^M^J
foo^J
foo^M
foo^M
"""

- It should be clarified that *multiline strings support the same escapes and
interpolations* as single-line strings. This allows a literal """ to be written \""".
Discussion 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; the core team had concerns
about only allowing that inside multi-line literals and felt that that could also be
considered later as an additive feature.

Thanks John, Brent, and Tyler for the original proposal, and thanks to everyone who
participated in the discussion!

-Joe
Review Manager

_______________________________________________
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

Hi,

I think, it would be more natural to include the last newline.
Multi-line String literals are for multiple lines.
And each line ends in a \n. Otherwise it wouldn’t be a line.

Having
    """
    line 1
    """

···

+
    """
    line 2
    """
    ==
    """
    line 1
    line 2
    """

makes a lot of sense to me.

Or do we want to magically add a trailing newline everywhere as we do in print()?
Better change print to only add the newline when necessary! (e.g. by adding a new parameter which defaults to „auto“)


Martin

Am 19.04.2017 um 23:51 schrieb Adrian Zubarev via swift-evolution <swift-evolution@swift.org>:

This is the natural way of text blocks. If you really need a blank line you can add one at the start/end or alternatively use \n.

"""

Foo

"""

// Equals "\nFoo\n"

--
Adrian Zubarev
Sent with Airmail

Am 19. April 2017 um 22:53:07, Vladimir.S via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

On 19.04.2017 23:03, Joe Groff via swift-evolution wrote:
> Proposal Link:
> https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md
>
> Hello Swift Community,
>
> The review of SE-0168: "Multi-Line String Literals" ran from April 6...12, 2017. The
> proposal is *accepted with revisions. *Community feedback was largely positive on the
> idea, though the discussion highlighted several under-specified aspects.
>
> - Questions arose about whether text could appear on the same line as the opening and
> closing delimiter, and how that would interact with the de-indentation algorithm. The
> core team feels that it is important to keep this feature focused on its purpose of
> allowing the easy embedding of pasted blocks of text, so *text inside the literal on
> the same line as either delimiter should be disallowed.*
>
> // Allowed, equal to "foo\nbar"
> """
> foo
> bar
> """

Could you clarify, shouldn't this be equal to "foo\nbar\n" ? I.e. with trailing \n
for "bar" line?
I didn't find any clarification about the injecting of line-end for last text
line(not for the """ delimiter).

>
> // Not allowed
> """foo
> bar
> """
>
> // Not allowed
> """
> foo
> bar"""
>
> This keeps the model straightforward to describe: a *single newline *is always
> stripped after the opening delimiter and before the closing one, and the closing
> delimiter's position always determines the indentation level of the entire literal.
> The core team acknowledges that single-line triple quoted strings have other uses in
> other languages, such as to avoid excessive escaping in a string that contains lots
> of literal quotes, 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. If nothing else, single-line triple
> quoted strings can be considered later as an additive feature.
>
> - The core team also believes that *underindentation or inconsistent tab/space usage
> within the indentation should be an error.* Every line inside the literal must begin
> with the exact sequence of spaces and tabs that precedes the closing delimiter.
>
> """
> <tab><space>this is OK
> <space><space>this is an error
> <space><tab>this is also an error
> <tab>under-indenting is an error too
> <tab><space><space>but you can go nuts after the indentation all you want
> <tab><space><tab>you do you
> <tab><space>"""
>
> - The quoted string should *normalize newlines* to \n in the value of the literal,
> regardless of whether the source file uses \n (Unix), \r\n (Windows), or \r (classic
> Mac) line endings. Likewise, when the compiler strips the initial and final newline
> from the literal value, it will strip one of any of the \n, \r\n, or \r line-ending
> sequences from both ends of the literal.
>
> // equal to "foo\nfoo\nfoo\nfoo"
> """^J
> foo^M^J
> foo^J
> foo^M
> foo^M
> """
>
> - It should be clarified that *multiline strings support the same escapes and
> interpolations* as single-line strings. This allows a literal """ to be written \""".
> Discussion 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; the core team had concerns
> about only allowing that inside multi-line literals and felt that that could also be
> considered later as an additive feature.
>
> Thanks John, Brent, and Tyler for the original proposal, and thanks to everyone who
> participated in the discussion!
>
> -Joe
> Review Manager
>
>
> _______________________________________________
> 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

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

[...] a single newline is always stripped after the opening delimiter and before the closing one. [...]

Regards
Anders

···

On 20 Apr 2017, at 04:52, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

On 19.04.2017 23:03, Joe Groff via swift-evolution wrote:
Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md
Hello Swift Community,
The review of SE-0168: "Multi-Line String Literals" ran from April 6...12, 2017. The proposal is *accepted with revisions. *Community feedback was largely positive on the idea, though the discussion highlighted several under-specified aspects.
- Questions arose about whether text could appear on the same line as the opening and closing delimiter, and how that would interact with the de-indentation algorithm. The core team feels that it is important to keep this feature focused on its purpose of allowing the easy embedding of pasted blocks of text, so *text inside the literal on the same line as either delimiter should be disallowed.*
   // Allowed, equal to "foo\nbar"
   """
      foo
      bar
      """

Could you clarify, shouldn't this be equal to "foo\nbar\n" ? I.e. with trailing \n for "bar" line?
I didn't find any clarification about the injecting of line-end for last text line(not for the """ delimiter).

   // Not allowed
   """foo
      bar
      """
   // Not allowed
   """
      foo
      bar"""
This keeps the model straightforward to describe: a *single newline *is always stripped after the opening delimiter and before the closing one, and the closing delimiter's position always determines the indentation level of the entire literal. The core team acknowledges that single-line triple quoted strings have other uses in other languages, such as to avoid excessive escaping in a string that contains lots of literal quotes, 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. If nothing else, single-line triple quoted strings can be considered later as an additive feature.
- The core team also believes that *underindentation or inconsistent tab/space usage within the indentation should be an error.* Every line inside the literal must begin with the exact sequence of spaces and tabs that precedes the closing delimiter.
"""
<tab><space>this is OK
<space><space>this is an error
<space><tab>this is also an error
<tab>under-indenting is an error too
<tab><space><space>but you can go nuts after the indentation all you want
<tab><space><tab>you do you
<tab><space>"""
- The quoted string should *normalize newlines* to \n in the value of the literal, regardless of whether the source file uses \n (Unix), \r\n (Windows), or \r (classic Mac) line endings. Likewise, when the compiler strips the initial and final newline from the literal value, it will strip one of any of the \n, \r\n, or \r line-ending sequences from both ends of the literal.
// equal to "foo\nfoo\nfoo\nfoo"
"""^J
  foo^M^J
  foo^J
  foo^M
  foo^M
  """
- It should be clarified that *multiline strings support the same escapes and interpolations* as single-line strings. This allows a literal """ to be written \""". Discussion 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; the core team had concerns about only allowing that inside multi-line literals and felt that that could also be considered later as an additive feature.
Thanks John, Brent, and Tyler for the original proposal, and thanks to everyone who participated in the discussion!
-Joe
Review Manager
_______________________________________________
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

True, but this is not about IDEs or editors. The feature itself doesn’t know what an editor is and what it capable of, nor should be ever rely on that. Not everyone uses the same settings and you cannot be 100% sure to expect the same string from looking at it, which was written in a different editor if we don’t warn about trailing whitespaces now.

The trailing whitespaces might not do any harm for the currently accepted version, but we’ll have to warn about them if we decide to add the trailing backspace. As currently accepted we still have a hole to fill for coding styles, we do not support multi-lined string literals for code formatting only, nor do we have trailing precision for the same matter. (That’s what the backslash was meant for.) That said, I cannot break up a really long hardcoded string, which in my IDE is softly wrapped, into a multi-line string literal so that it looks in every editor the same and still expect the same result and be precise about the trailing whitespace characters.

···

--
Adrian Zubarev
Sent with Airmail

Am 20. April 2017 um 00:27:48, Brent Royal-Gordon via swift-evolution (swift-evolution@swift.org) schrieb:

On Apr 19, 2017, at 3:18 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

Other common tools like Git already flag trailing whitespace by default, so even if Swift doesn't warn about it, you might still need to satisfy other tools in your pipeline.

Isn't that an equally good argument for Swift *not* warning you about it? If it's harmful, you'll have other tools in the pipeline to flag it for you.

Cosigned. We already have an Xcode setting to strip trailing whitespace, a Git setting to flag it, and linter settings to remove it. (For instance, SwiftFormat has a --trimwhitespace flag.) Not every tool needs to handle every case of questionable style.

--
Brent Royal-Gordon
Architechies

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

I agree, but unfortunately it’s probably too late now.

···

On Apr 19, 2017, at 3:11 PM, Martin Waitz via swift-evolution <swift-evolution@swift.org> wrote:

Hi,

I think, it would be more natural to include the last newline.
Multi-line String literals are for multiple lines.
And each line ends in a \n. Otherwise it wouldn’t be a line.

Having
    """
    line 1
    """
    +
    """
    line 2
    """
    ==
    """
    line 1
    line 2
    """

makes a lot of sense to me.

Or do we want to magically add a trailing newline everywhere as we do in print()?
Better change print to only add the newline when necessary! (e.g. by adding a new parameter which defaults to „auto“)


Martin

Am 19.04.2017 um 23:51 schrieb Adrian Zubarev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

This is the natural way of text blocks. If you really need a blank line you can add one at the start/end or alternatively use \n.

"""

Foo

"""

// Equals "\nFoo\n"

--
Adrian Zubarev
Sent with Airmail

Am 19. April 2017 um 22:53:07, Vladimir.S via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

On 19.04.2017 23:03, Joe Groff via swift-evolution wrote:
> Proposal Link:
> https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md
>
> Hello Swift Community,
>
> The review of SE-0168: "Multi-Line String Literals" ran from April 6...12, 2017. The
> proposal is *accepted with revisions. *Community feedback was largely positive on the
> idea, though the discussion highlighted several under-specified aspects.
>
> - Questions arose about whether text could appear on the same line as the opening and
> closing delimiter, and how that would interact with the de-indentation algorithm. The
> core team feels that it is important to keep this feature focused on its purpose of
> allowing the easy embedding of pasted blocks of text, so *text inside the literal on
> the same line as either delimiter should be disallowed.*
>
> // Allowed, equal to "foo\nbar"
> """
> foo
> bar
> """

Could you clarify, shouldn't this be equal to "foo\nbar\n" ? I.e. with trailing \n
for "bar" line?
I didn't find any clarification about the injecting of line-end for last text
line(not for the """ delimiter).

>
> // Not allowed
> """foo
> bar
> """
>
> // Not allowed
> """
> foo
> bar"""
>
> This keeps the model straightforward to describe: a *single newline *is always
> stripped after the opening delimiter and before the closing one, and the closing
> delimiter's position always determines the indentation level of the entire literal.
> The core team acknowledges that single-line triple quoted strings have other uses in
> other languages, such as to avoid excessive escaping in a string that contains lots
> of literal quotes, 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. If nothing else, single-line triple
> quoted strings can be considered later as an additive feature.
>
> - The core team also believes that *underindentation or inconsistent tab/space usage
> within the indentation should be an error.* Every line inside the literal must begin
> with the exact sequence of spaces and tabs that precedes the closing delimiter.
>
> """
> <tab><space>this is OK
> <space><space>this is an error
> <space><tab>this is also an error
> <tab>under-indenting is an error too
> <tab><space><space>but you can go nuts after the indentation all you want
> <tab><space><tab>you do you
> <tab><space>"""
>
> - The quoted string should *normalize newlines* to \n in the value of the literal,
> regardless of whether the source file uses \n (Unix), \r\n (Windows), or \r (classic
> Mac) line endings. Likewise, when the compiler strips the initial and final newline
> from the literal value, it will strip one of any of the \n, \r\n, or \r line-ending
> sequences from both ends of the literal.
>
> // equal to "foo\nfoo\nfoo\nfoo"
> """^J
> foo^M^J
> foo^J
> foo^M
> foo^M
> """
>
> - It should be clarified that *multiline strings support the same escapes and
> interpolations* as single-line strings. This allows a literal """ to be written \""".
> Discussion 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; the core team had concerns
> about only allowing that inside multi-line literals and felt that that could also be
> considered later as an additive feature.
>
> Thanks John, Brent, and Tyler for the original proposal, and thanks to everyone who
> participated in the discussion!
>
> -Joe
> Review Manager
>
>
> _______________________________________________
> 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

_______________________________________________
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

I'm asking the core team for clarification on the point of the closing newline.

-Joe

···

On Apr 19, 2017, at 3:16 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

We had a very full debate about which way was superior during review; it was proposed to behave one way and the core team decided on the other. We have to let settled decisions be settled: that's the only way Swift Evolution will continue to work.

We had a very full debate about which way was superior during review; it
was proposed to behave one way and the core team decided on the other. We
have to let settled decisions be settled: that's the only way Swift
Evolution will continue to work.

···

On Wed, Apr 19, 2017 at 5:15 PM, Kevin Nattinger via swift-evolution < swift-evolution@swift.org> wrote:

I agree, but unfortunately it’s probably too late now.

On Apr 19, 2017, at 3:11 PM, Martin Waitz via swift-evolution < > swift-evolution@swift.org> wrote:

Hi,

I think, it would be more natural to include the last newline.
Multi-line String literals are for multiple lines.
And each line ends in a \n. Otherwise it wouldn’t be a line.

Having
    """
    line 1
    """
    +
    """
    line 2
    """
    ==
    """
    line 1
    line 2
    """

makes a lot of sense to me.

Or do we want to magically add a trailing newline everywhere as we do in
print()?
Better change print to only add the newline when necessary! (e.g. by
adding a new parameter which defaults to „auto“)


Martin

Am 19.04.2017 um 23:51 schrieb Adrian Zubarev via swift-evolution < > swift-evolution@swift.org>:

This is the natural way of text blocks. If you really need a blank line
you can add one at the start/end or alternatively use \n.

"""

Foo

"""

// Equals "\nFoo\n"

--
Adrian Zubarev
Sent with Airmail

Am 19. April 2017 um 22:53:07, Vladimir.S via swift-evolution (
swift-evolution@swift.org) schrieb:

On 19.04.2017 23:03, Joe Groff via swift-evolution wrote:
> Proposal Link:
> GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
proposals/0168-multi-line-string-literals.md
>
> Hello Swift Community,
>
> The review of SE-0168: "Multi-Line String Literals" ran from April
6...12, 2017. The
> proposal is *accepted with revisions. *Community feedback was largely
positive on the
> idea, though the discussion highlighted several under-specified aspects.
>
> - Questions arose about whether text could appear on the same line as
the opening and
> closing delimiter, and how that would interact with the de-indentation
algorithm. The
> core team feels that it is important to keep this feature focused on its
purpose of
> allowing the easy embedding of pasted blocks of text, so *text inside
the literal on
> the same line as either delimiter should be disallowed.*
>
> // Allowed, equal to "foo\nbar"
> """
> foo
> bar
> """

Could you clarify, shouldn't this be equal to "foo\nbar\n" ? I.e. with
trailing \n
for "bar" line?
I didn't find any clarification about the injecting of line-end for last
text
line(not for the """ delimiter).

>
> // Not allowed
> """foo
> bar
> """
>
> // Not allowed
> """
> foo
> bar"""
>
> This keeps the model straightforward to describe: a *single newline *is
always
> stripped after the opening delimiter and before the closing one, and the
closing
> delimiter's position always determines the indentation level of the
entire literal.
> The core team acknowledges that single-line triple quoted strings have
other uses in
> other languages, such as to avoid excessive escaping in a string that
contains lots
> of literal quotes, 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. If nothing else, single-line
triple
> quoted strings can be considered later as an additive feature.
>
> - The core team also believes that *underindentation or inconsistent
tab/space usage
> within the indentation should be an error.* Every line inside the
literal must begin
> with the exact sequence of spaces and tabs that precedes the closing
delimiter.
>
> """
> <tab><space>this is OK
> <space><space>this is an error
> <space><tab>this is also an error
> <tab>under-indenting is an error too
> <tab><space><space>but you can go nuts after the indentation all you want
> <tab><space><tab>you do you
> <tab><space>"""
>
> - The quoted string should *normalize newlines* to \n in the value of
the literal,
> regardless of whether the source file uses \n (Unix), \r\n (Windows), or
\r (classic
> Mac) line endings. Likewise, when the compiler strips the initial and
final newline
> from the literal value, it will strip one of any of the \n, \r\n, or \r
line-ending
> sequences from both ends of the literal.
>
> // equal to "foo\nfoo\nfoo\nfoo"
> """^J
> foo^M^J
> foo^J
> foo^M
> foo^M
> """
>
> - It should be clarified that *multiline strings support the same
escapes and
> interpolations* as single-line strings. This allows a literal """ to be
written \""".
> Discussion 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; the core team
had concerns
> about only allowing that inside multi-line literals and felt that that
could also be
> considered later as an additive feature.
>
> Thanks John, Brent, and Tyler for the original proposal, and thanks to
everyone who
> participated in the discussion!
>
> -Joe
> Review Manager
>
>
> _______________________________________________
> 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

_______________________________________________
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

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

Cool, thanks. Please do remind them, though, that not stripping the closing
newline (which is what was originally proposed) *and* not having the option
of using `\` to elide newlines (which is contrary to what was originally
proposed) would mean that all multi-line strings would mandatorily end in a
newline.

···

On Wed, Apr 19, 2017 at 5:24 PM, Joe Groff <jgroff@apple.com> wrote:

> On Apr 19, 2017, at 3:16 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:
>
> We had a very full debate about which way was superior during review; it
was proposed to behave one way and the core team decided on the other. We
have to let settled decisions be settled: that's the only way Swift
Evolution will continue to work.

I'm asking the core team for clarification on the point of the closing
newline.

You can use a plain text editor and no linter, or a plain text editor and a
linter, or an IDE and no linter, etc., and in any of these scenarios you
can already choose whether or not you want trailing newlines stripped. Why
should the compiler try to enforce any rules here?

Since Unicode is supported, it is never possible to look at a string
literal and be 100% sure of what glyphs are involved. We should be clear
that such a criterion cannot and should not be a design goal. If it
supports Unicode and is really literal, then confusables and invisibles
will make it impossible to be sure of what you see; you would have to
either stop supporting Unicode or stop being literal.

I'm not sure this "coding style" you describe can properly be thought of as
a multiline string literal. It sounds like what you want isn't multiline
(in fact, you want a new way to write a very long single-line string) and
it isn't literal (you want to use newlines in your code that do not
represent a literal newline). If there is something extremely critical
about a particular string, where you simply must start half of it on a
separate line to help the readers of your code understand what you are
doing, you can already do this by writing "foo" + [newline] "bar". Or you
could just let your editor soft-wrap your long string. Making your
single-line string wrap the same way in every IDE just doesn't seem like
it's related to or worth complicating the syntax for multiline string
literals. I would be strongly opposed to such a feature.

···

On Wed, Apr 19, 2017 at 23:42 Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote:

True, but this is not about IDEs or editors. The feature itself doesn’t
know what an editor is and what it capable of, nor should be ever rely on
that. Not everyone uses the same settings and you cannot be 100% sure to
expect the same string from looking at it, which was written in a different
editor if we don’t warn about trailing whitespaces now.

The trailing whitespaces might not do any harm for the currently accepted
version, but we’ll have to warn about them if we decide to add the trailing
backspace. As currently accepted we still have a hole to fill for coding
styles, we do not support multi-lined string literals for code formatting
only, nor do we have trailing precision for the same matter. (That’s what
the backslash was meant for.) That said, I cannot break up a really long
hardcoded string, which in my IDE is softly wrapped, into a multi-line
string literal so that it looks in every editor the same and still expect
the same result and be precise about the trailing whitespace characters.

--
Adrian Zubarev
Sent with Airmail

Am 20. April 2017 um 00:27:48, Brent Royal-Gordon via swift-evolution (
swift-evolution@swift.org) schrieb:

On Apr 19, 2017, at 3:18 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:

Other common tools like Git already flag trailing whitespace by default,

so even if Swift doesn't warn about it, you might still need to satisfy
other tools in your pipeline.

Isn't that an equally good argument for Swift *not* warning you about it?
If it's harmful, you'll have other tools in the pipeline to flag it for you.

Cosigned. We already have an Xcode setting to strip trailing whitespace, a
Git setting to flag it, and linter settings to remove it. (For instance,
SwiftFormat has a --trimwhitespace flag.) Not every tool needs to handle
every case of questionable style.

--
Brent Royal-Gordon
Architechies

_______________________________________________
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