[Proposal] Newline escapes in Swift Strings

Evolution Discussion
1

Hello folks,

To keep things focused I opened up a new thread for this talk. Previously the discussion took place at the thread named [Accepted] SE-0168: Multi-Line String Literals.

John Holdsworth has provided a first draft in his PR: Newline escapes in Swift Strings by johnno1962 · Pull Request #695 · apple/swift-evolution · GitHub

I think we need to fine tune the proposal before it gets into the review process.

To quickly sum up, the previous proposal added support for multi-line string literals into Swift, where its model was squeezed to the minimum.

No text directly after/before the starting/closing tripled """ delimiters.

The string content line before the closing delimiter does not inject a new line to the final string, only lines before the last content line does.

Trailing spaces in each string content lines will produce a warning and hopefully provide a Fix-it to remove these, therefore there is no trailing precision added with the minimum model of the multi-line string literal. (This approach is editor/linter independent whatsoever.)

This follow up proposal will fix the last missing peace for multi-line string literals and additionally add new possibilities to the single quoted string literal as well.

This proposal should also not change the fact number two from above!

let s1 = """
   myStringExample
   """

let s2 = "myStringExample"

s1 == s2 // => true
Currently both string literals suffers from the following issue where long strings will produce a very hard to read literal. Notice, we don’t want to discuss here if we should or should not ever hardcode long string literals at all.

let myLongStringWithParagraphs = """
   Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
    
   Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
   """
    
let myLongLineString = "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat."
The current proposal solves that problem while also adding trailing precision for the tripled multi-line string literal and providing flexibility for code formatting for us developers in a editor independent fashion.

The example from above could be rewritten, while preserving the indent and producing the exact equivalent result strings as above.

let myLongStringWithParagraphs = """
   Lorem ipsum dolor sit amet, consectetur adipiscing elit, \
   sed do eiusmod tempor incididunt ut labore et dolore magna \
   aliqua. Ut enim ad minim veniam, quis nostrud exercitation \
   ullamco laboris nisi ut aliquip ex ea commodo consequat.
    
   Lorem ipsum dolor sit amet, consectetur adipiscing elit, \
   sed do eiusmod tempor incididunt ut labore et dolore magna \
   aliqua. Ut enim ad minim veniam, quis nostrud exercitation \
   ullamco laboris nisi ut aliquip ex ea commodo consequat.
   """
    
let myLongLineString = "Lorem ipsum dolor sit amet, \
   "consectetur adipiscing elit, sed do eiusmod tempor \
   "incididunt ut labore et dolore magna aliqua. Ut enim \
   "ad minim veniam, quis nostrud exercitation ullamco \
   "laboris nisi ut aliquip ex ea commodo consequat."
If this proposal will be accepted the trailing whitespaces inside a string literal will produce two different warnings with similar Fix-its.

// In the examples v1 and v2 the Fix-it will either ask you to delete the
// trailing space(s) or to a add a `\` after the last whitespace character.

let v1 = """
   123<space>
   """
    
let v2 = """
   abc
   123<space>
   """
    
// In the example v3 the Fix-it will either ask you to delete the
// trailing space(s) or to a add a `\n\` after the last whitespace
// character.
    
let v4 = """
   abc<space>
   123
   """

···

--
Adrian Zubarev
Sent with Airmail

2

So, independent of whether one thinks this is a good idea or not, the core
team wrote the following:

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.

It seems to me that, when the core team considers a feature and then
removes it from an accepted proposal, saying that it should be considered
_later_, that word doesn't mean immediately asking the community to
consider it again.

···

On Wed, Apr 26, 2017 at 2:14 PM, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote:

Hello folks,

To keep things focused I opened up a new thread for this talk. Previously
the discussion took place at the thread named [Accepted] SE-0168:
Multi-Line String Literals.

John Holdsworth has provided a first draft in his PR:
Newline escapes in Swift Strings by johnno1962 · Pull Request #695 · apple/swift-evolution · GitHub

I think we need to fine tune the proposal before it gets into the review
process.
------------------------------

To quickly sum up, the previous proposal added support for multi-line
string literals into Swift, where its model was squeezed to the minimum.

   1.

   No text directly after/before the starting/closing tripled """
   delimiters.
   2.

   The string content line before the closing delimiter does not inject a
   new line to the final string, only lines before the last content line does.
   3.

   Trailing spaces in each string content lines will produce a warning
   and hopefully provide a Fix-it to remove these, therefore there is no
   trailing precision added with the minimum model of the multi-line string
   literal. (This approach is editor/linter independent whatsoever.)

------------------------------

This follow up proposal will fix the last missing peace for multi-line
string literals and additionally add new possibilities to the single quoted
string literal as well.

This proposal should also not change the fact number two from above!

let s1 = """
   myStringExample
   """

let s2 = "myStringExample"

s1 == s2 // => true

------------------------------

Currently both string literals suffers from the following issue where long
strings will produce a very hard to read literal. Notice, we don’t want to
discuss here if we should or should not ever hardcode long string literals
at all.

let myLongStringWithParagraphs = """
   Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

   Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
   """

let myLongLineString = "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat."

The current proposal solves that problem while also adding trailing
precision for the tripled multi-line string literal and providing
flexibility for code formatting for us developers in a editor independent
fashion.

The example from above could be rewritten, while preserving the indent and
producing the exact equivalent result strings as above.

let myLongStringWithParagraphs = """
   Lorem ipsum dolor sit amet, consectetur adipiscing elit, \
   sed do eiusmod tempor incididunt ut labore et dolore magna \
   aliqua. Ut enim ad minim veniam, quis nostrud exercitation \
   ullamco laboris nisi ut aliquip ex ea commodo consequat.

   Lorem ipsum dolor sit amet, consectetur adipiscing elit, \
   sed do eiusmod tempor incididunt ut labore et dolore magna \
   aliqua. Ut enim ad minim veniam, quis nostrud exercitation \
   ullamco laboris nisi ut aliquip ex ea commodo consequat.
   """

let myLongLineString = "Lorem ipsum dolor sit amet, \
   "consectetur adipiscing elit, sed do eiusmod tempor \
   "incididunt ut labore et dolore magna aliqua. Ut enim \
   "ad minim veniam, quis nostrud exercitation ullamco \
   "laboris nisi ut aliquip ex ea commodo consequat."

If this proposal will be accepted the trailing whitespaces inside a string
literal will produce two different warnings with similar Fix-its.

// In the examples v1 and v2 the Fix-it will either ask you to delete the
// trailing space(s) or to a add a `\` after the last whitespace character.

let v1 = """
   123<space>
   """

let v2 = """
   abc
   123<space>
   """

// In the example v3 the Fix-it will either ask you to delete the
// trailing space(s) or to a add a `\n\` after the last whitespace
// character.

let v4 = """
   abc<space>
   123
   """

--
Adrian Zubarev
Sent with Airmail

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

3

So, independent of whether one thinks this is a good idea or not, the core team wrote the following:

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

It seems to me that, when the core team considers a feature and then removes it from an accepted proposal, saying that it should be considered _later_, that word doesn't mean immediately asking the community to consider it again.

Ouch, fair enough, I apologise for waisting the communities time. The logic behind the new proposal was that newline escapes were removed from SE-0168 as they would have been inconsistent with regular strings. So, the next step seemed like testing the water with a new proposal with newline escapes for all strings while we are looking at string literals in general. I’m sorry if that and the tone of my last email was irritating.

Multi-line strings have already been merged as agreed so perhaps there is little point discussing this further. I've also come to realise that in practice, stripping the last newline off multiline strings for consistency is not an issue.

-John

···

On 26 Apr 2017, at 23:40, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

On Wed, Apr 26, 2017 at 2:14 PM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hello folks,

To keep things focused I opened up a new thread for this talk. Previously the discussion took place at the thread named [Accepted] SE-0168: Multi-Line String Literals.

John Holdsworth has provided a first draft in his PR: Newline escapes in Swift Strings by johnno1962 · Pull Request #695 · apple/swift-evolution · GitHub
I think we need to fine tune the proposal before it gets into the review process.

To quickly sum up, the previous proposal added support for multi-line string literals into Swift, where its model was squeezed to the minimum.

No text directly after/before the starting/closing tripled """ delimiters.

The string content line before the closing delimiter does not inject a new line to the final string, only lines before the last content line does.

Trailing spaces in each string content lines will produce a warning and hopefully provide a Fix-it to remove these, therefore there is no trailing precision added with the minimum model of the multi-line string literal. (This approach is editor/linter independent whatsoever.)

This follow up proposal will fix the last missing peace for multi-line string literals and additionally add new possibilities to the single quoted string literal as well.

This proposal should also not change the fact number two from above!

let s1 = """
   myStringExample
   """

let s2 = "myStringExample"

s1 == s2 // => true
Currently both string literals suffers from the following issue where long strings will produce a very hard to read literal. Notice, we don’t want to discuss here if we should or should not ever hardcode long string literals at all.

let myLongStringWithParagraphs = """
   Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
    
   Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
   """
    
let myLongLineString = "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat."
The current proposal solves that problem while also adding trailing precision for the tripled multi-line string literal and providing flexibility for code formatting for us developers in a editor independent fashion.

The example from above could be rewritten, while preserving the indent and producing the exact equivalent result strings as above.

let myLongStringWithParagraphs = """
   Lorem ipsum dolor sit amet, consectetur adipiscing elit, \
   sed do eiusmod tempor incididunt ut labore et dolore magna \
   aliqua. Ut enim ad minim veniam, quis nostrud exercitation \
   ullamco laboris nisi ut aliquip ex ea commodo consequat.
    
   Lorem ipsum dolor sit amet, consectetur adipiscing elit, \
   sed do eiusmod tempor incididunt ut labore et dolore magna \
   aliqua. Ut enim ad minim veniam, quis nostrud exercitation \
   ullamco laboris nisi ut aliquip ex ea commodo consequat.
   """
    
let myLongLineString = "Lorem ipsum dolor sit amet, \
   "consectetur adipiscing elit, sed do eiusmod tempor \
   "incididunt ut labore et dolore magna aliqua. Ut enim \
   "ad minim veniam, quis nostrud exercitation ullamco \
   "laboris nisi ut aliquip ex ea commodo consequat."
If this proposal will be accepted the trailing whitespaces inside a string literal will produce two different warnings with similar Fix-its.

// In the examples v1 and v2 the Fix-it will either ask you to delete the
// trailing space(s) or to a add a `\` after the last whitespace character.

let v1 = """
   123<space>
   """
    
let v2 = """
   abc
   123<space>
   """
    
// In the example v3 the Fix-it will either ask you to delete the
// trailing space(s) or to a add a `\n\` after the last whitespace
// character.
    
let v4 = """
   abc<space>
   123
   """

--
Adrian Zubarev
Sent with Airmail

_______________________________________________
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

4

That is correct, however you can interpret this in two ways. You just covered the first way. The second one is, that the feature was rejected from the main proposal because it seemed inconsistent if it would *only* apply to multi-line strings. The discussion after the accepted proposal has showed us that the feature for the backslash could be extended further to cover all string literals, not only the tripled one.

I think it’s worth pushing this forward. :)

···

--
Adrian Zubarev
Sent with Airmail

Am 27. April 2017 um 00:40:59, Xiaodi Wu (xiaodi.wu@gmail.com) schrieb:

So, independent of whether one thinks this is a good idea or not, the core team wrote the following:

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.

It seems to me that, when the core team considers a feature and then removes it from an accepted proposal, saying that it should be considered _later_, that word doesn't mean immediately asking the community to consider it again.

On Wed, Apr 26, 2017 at 2:14 PM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:
Hello folks,

To keep things focused I opened up a new thread for this talk. Previously the discussion took place at the thread named [Accepted] SE-0168: Multi-Line String Literals.

John Holdsworth has provided a first draft in his PR: Newline escapes in Swift Strings by johnno1962 · Pull Request #695 · apple/swift-evolution · GitHub

I think we need to fine tune the proposal before it gets into the review process.

To quickly sum up, the previous proposal added support for multi-line string literals into Swift, where its model was squeezed to the minimum.

No text directly after/before the starting/closing tripled """ delimiters.

The string content line before the closing delimiter does not inject a new line to the final string, only lines before the last content line does.

Trailing spaces in each string content lines will produce a warning and hopefully provide a Fix-it to remove these, therefore there is no trailing precision added with the minimum model of the multi-line string literal. (This approach is editor/linter independent whatsoever.)

This follow up proposal will fix the last missing peace for multi-line string literals and additionally add new possibilities to the single quoted string literal as well.

This proposal should also not change the fact number two from above!

let s1 = """
   myStringExample
   """

let s2 = "myStringExample"

s1 == s2 // => true
Currently both string literals suffers from the following issue where long strings will produce a very hard to read literal. Notice, we don’t want to discuss here if we should or should not ever hardcode long string literals at all.

let myLongStringWithParagraphs = """
   Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
     
   Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
   """
     
let myLongLineString = "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat."
The current proposal solves that problem while also adding trailing precision for the tripled multi-line string literal and providing flexibility for code formatting for us developers in a editor independent fashion.

The example from above could be rewritten, while preserving the indent and producing the exact equivalent result strings as above.

let myLongStringWithParagraphs = """
   Lorem ipsum dolor sit amet, consectetur adipiscing elit, \
   sed do eiusmod tempor incididunt ut labore et dolore magna \
   aliqua. Ut enim ad minim veniam, quis nostrud exercitation \
   ullamco laboris nisi ut aliquip ex ea commodo consequat.
     
   Lorem ipsum dolor sit amet, consectetur adipiscing elit, \
   sed do eiusmod tempor incididunt ut labore et dolore magna \
   aliqua. Ut enim ad minim veniam, quis nostrud exercitation \
   ullamco laboris nisi ut aliquip ex ea commodo consequat.
   """
     
let myLongLineString = "Lorem ipsum dolor sit amet, \
   "consectetur adipiscing elit, sed do eiusmod tempor \
   "incididunt ut labore et dolore magna aliqua. Ut enim \
   "ad minim veniam, quis nostrud exercitation ullamco \
   "laboris nisi ut aliquip ex ea commodo consequat."
If this proposal will be accepted the trailing whitespaces inside a string literal will produce two different warnings with similar Fix-its.

// In the examples v1 and v2 the Fix-it will either ask you to delete the
// trailing space(s) or to a add a `\` after the last whitespace character.

let v1 = """
   123<space>
   """
     
let v2 = """
   abc
   123<space>
   """
     
// In the example v3 the Fix-it will either ask you to delete the
// trailing space(s) or to a add a `\n\` after the last whitespace
// character.
     
let v4 = """
   abc<space>
   123
   """

--
Adrian Zubarev
Sent with Airmail

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

5

So, independent of whether one thinks this is a good idea or not, the core
team wrote the following:

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

It seems to me that, when the core team considers a feature and then
removes it from an accepted proposal, saying that it should be considered
_later_, that word doesn't mean immediately asking the community to
consider it again.

Ouch, fair enough, I apologise for waisting the communities time. The
logic behind the new proposal was that newline escapes were removed from
SE-0168 as they would have been inconsistent with regular strings. So, the
next step seemed like testing the water with a new proposal with newline
escapes for all strings while we are looking at string literals in general.
I’m sorry if that and the tone of my last email was irritating.

Multi-line strings have already been merged as agreed so perhaps there is
little point discussing this further. I've also come to realise that in
practice, stripping the last newline off multiline strings for consistency
is not an issue.

I'd imagine that this was part of the idea of "later": let the current
design percolate by giving people real-world experience with it. If, as
proponents have argued, trailing spaces are a key issue, you'll find people
who haven't even followed the discussion chiming in to say, gee, let's get
an additive solution to the problem. If, as I surmise, it's not an issue,
then we won't need to add anything further.

-John

···

On Thu, Apr 27, 2017 at 5:50 AM, John Holdsworth <mac@johnholdsworth.com> wrote:

On 26 Apr 2017, at 23:40, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:

On Wed, Apr 26, 2017 at 2:14 PM, Adrian Zubarev via swift-evolution < > swift-evolution@swift.org> wrote:

Hello folks,

To keep things focused I opened up a new thread for this talk. Previously
the discussion took place at the thread named [Accepted] SE-0168:
Multi-Line String Literals.

John Holdsworth has provided a first draft in his PR:
Newline escapes in Swift Strings by johnno1962 · Pull Request #695 · apple/swift-evolution · GitHub

I think we need to fine tune the proposal before it gets into the review
process.
------------------------------

To quickly sum up, the previous proposal added support for multi-line
string literals into Swift, where its model was squeezed to the minimum.

   1.

   No text directly after/before the starting/closing tripled """
   delimiters.
   2.

   The string content line before the closing delimiter does not inject
   a new line to the final string, only lines before the last content line
   does.
   3.

   Trailing spaces in each string content lines will produce a warning
   and hopefully provide a Fix-it to remove these, therefore there is no
   trailing precision added with the minimum model of the multi-line string
   literal. (This approach is editor/linter independent whatsoever.)

------------------------------

This follow up proposal will fix the last missing peace for multi-line
string literals and additionally add new possibilities to the single quoted
string literal as well.

This proposal should also not change the fact number two from above!

let s1 = """
   myStringExample
   """

let s2 = "myStringExample"

s1 == s2 // => true

------------------------------

Currently both string literals suffers from the following issue where
long strings will produce a very hard to read literal. Notice, we don’t
want to discuss here if we should or should not ever hardcode long string
literals at all.

let myLongStringWithParagraphs = """
   Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

   Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
   """

let myLongLineString = "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat."

The current proposal solves that problem while also adding trailing
precision for the tripled multi-line string literal and providing
flexibility for code formatting for us developers in a editor independent
fashion.

The example from above could be rewritten, while preserving the indent
and producing the exact equivalent result strings as above.

let myLongStringWithParagraphs = """
   Lorem ipsum dolor sit amet, consectetur adipiscing elit, \
   sed do eiusmod tempor incididunt ut labore et dolore magna \
   aliqua. Ut enim ad minim veniam, quis nostrud exercitation \
   ullamco laboris nisi ut aliquip ex ea commodo consequat.

   Lorem ipsum dolor sit amet, consectetur adipiscing elit, \
   sed do eiusmod tempor incididunt ut labore et dolore magna \
   aliqua. Ut enim ad minim veniam, quis nostrud exercitation \
   ullamco laboris nisi ut aliquip ex ea commodo consequat.
   """

let myLongLineString = "Lorem ipsum dolor sit amet, \
   "consectetur adipiscing elit, sed do eiusmod tempor \
   "incididunt ut labore et dolore magna aliqua. Ut enim \
   "ad minim veniam, quis nostrud exercitation ullamco \
   "laboris nisi ut aliquip ex ea commodo consequat."

If this proposal will be accepted the trailing whitespaces inside a
string literal will produce two different warnings with similar Fix-its.

// In the examples v1 and v2 the Fix-it will either ask you to delete the
// trailing space(s) or to a add a `\` after the last whitespace character.

let v1 = """
   123<space>
   """

let v2 = """
   abc
   123<space>
   """

// In the example v3 the Fix-it will either ask you to delete the
// trailing space(s) or to a add a `\n\` after the last whitespace
// character.

let v4 = """
   abc<space>
   123
   """

--
Adrian Zubarev
Sent with Airmail

_______________________________________________
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

6

That is correct, however you can interpret this in two ways. You just
covered the first way. The second one is, that the feature was rejected
from the main proposal because it seemed inconsistent if it would *only*
apply to multi-line strings.

One thing I really appreciate about the core team is how carefully and
clearly they express their thinking. It is unambiguous that inconsistency
was one of the reasons the feature was removed from the proposal, but it
was not the only reason. It doesn't say, "The core team had concerns...and
_therefore_ felt that that could be considered later...." It says, "The
core team had concerns...and felt that that could _also_ be considered
later...." So, to recap:

* The feature has been considered once, and the decision is not to accept
it.
* Usually, this means that the decision is not to be revisited, but the
core team says that the feature can be considered again, _later_.
* If a new design is proposed for the feature (_later_), it needs to
address concerns about inconsistency.

The discussion after the accepted proposal has showed us that the feature

···

On Thu, Apr 27, 2017 at 8:05 AM, Adrian Zubarev < adrian.zubarev@devandartist.com> wrote:

for the backslash could be extended further to cover all string literals,
not only the tripled one.

I think it’s worth pushing this forward. :)

--
Adrian Zubarev
Sent with Airmail

Am 27. April 2017 um 00:40:59, Xiaodi Wu (xiaodi.wu@gmail.com) schrieb:

So, independent of whether one thinks this is a good idea or not, the core
team wrote the following:

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

It seems to me that, when the core team considers a feature and then
removes it from an accepted proposal, saying that it should be considered
_later_, that word doesn't mean immediately asking the community to
consider it again.

On Wed, Apr 26, 2017 at 2:14 PM, Adrian Zubarev via swift-evolution < > swift-evolution@swift.org> wrote:

Hello folks,

To keep things focused I opened up a new thread for this talk. Previously
the discussion took place at the thread named [Accepted] SE-0168:
Multi-Line String Literals.

John Holdsworth has provided a first draft in his PR:
Newline escapes in Swift Strings by johnno1962 · Pull Request #695 · apple/swift-evolution · GitHub

I think we need to fine tune the proposal before it gets into the review
process.
------------------------------

To quickly sum up, the previous proposal added support for multi-line
string literals into Swift, where its model was squeezed to the minimum.

   1.

   No text directly after/before the starting/closing tripled """
   delimiters.
   2.

   The string content line before the closing delimiter does not inject
   a new line to the final string, only lines before the last content line
   does.
   3.

   Trailing spaces in each string content lines will produce a warning
   and hopefully provide a Fix-it to remove these, therefore there is no
   trailing precision added with the minimum model of the multi-line string
   literal. (This approach is editor/linter independent whatsoever.)

------------------------------

This follow up proposal will fix the last missing peace for multi-line
string literals and additionally add new possibilities to the single quoted
string literal as well.

This proposal should also not change the fact number two from above!

let s1 = """
   myStringExample
   """

let s2 = "myStringExample"

s1 == s2 // => true

------------------------------

Currently both string literals suffers from the following issue where
long strings will produce a very hard to read literal. Notice, we don’t
want to discuss here if we should or should not ever hardcode long string
literals at all.

let myLongStringWithParagraphs = """
   Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

   Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
   """

let myLongLineString = "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat."

The current proposal solves that problem while also adding trailing
precision for the tripled multi-line string literal and providing
flexibility for code formatting for us developers in a editor independent
fashion.

The example from above could be rewritten, while preserving the indent
and producing the exact equivalent result strings as above.

let myLongStringWithParagraphs = """
   Lorem ipsum dolor sit amet, consectetur adipiscing elit, \
   sed do eiusmod tempor incididunt ut labore et dolore magna \
   aliqua. Ut enim ad minim veniam, quis nostrud exercitation \
   ullamco laboris nisi ut aliquip ex ea commodo consequat.

   Lorem ipsum dolor sit amet, consectetur adipiscing elit, \
   sed do eiusmod tempor incididunt ut labore et dolore magna \
   aliqua. Ut enim ad minim veniam, quis nostrud exercitation \
   ullamco laboris nisi ut aliquip ex ea commodo consequat.
   """

let myLongLineString = "Lorem ipsum dolor sit amet, \
   "consectetur adipiscing elit, sed do eiusmod tempor \
   "incididunt ut labore et dolore magna aliqua. Ut enim \
   "ad minim veniam, quis nostrud exercitation ullamco \
   "laboris nisi ut aliquip ex ea commodo consequat."

If this proposal will be accepted the trailing whitespaces inside a
string literal will produce two different warnings with similar Fix-its.

// In the examples v1 and v2 the Fix-it will either ask you to delete the
// trailing space(s) or to a add a `\` after the last whitespace character.

let v1 = """
   123<space>
   """

let v2 = """
   abc
   123<space>
   """

// In the example v3 the Fix-it will either ask you to delete the
// trailing space(s) or to a add a `\n\` after the last whitespace
// character.

let v4 = """
   abc<space>
   123
   """

--
Adrian Zubarev
Sent with Airmail

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