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

Hello Swift community,

The review of SE-0168 "Multi-Line String Literals" begins now and runs through April 12, 2017. The proposal is available here:

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

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at:

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md

Reply text
Other replies

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

• What is your evaluation of the proposal?

2 big thumbs up. :+1:t4::+1:t4:

• Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

• Does this proposal fit well with the feel and direction of Swift?

Yes.

• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Ruby’s multiline string literals are much more flexible (and varied). In theory, being able to provide your own delimiter makes sense (what if I need to type 3 quotes in my multiline string?!?!) but in practice just adds confusion, especially for beginners. Looking at code examples, it’s not obvious where the string literal ends. It also isn’t directly connected to regular string literals either.

ES2015 uses a similar approach as here, using back-ticks instead of triple quotes. That makes sense there, where they also use them for single line pattern strings, but again isn’t directly connected to other string literal syntax.

ObjCs strings have the benefit of controlling indentation much more predictably. If there’s anything I’m concerned about here, it’s that. But I don’t think that’s a high enough priority to sacrifice the other benefits of the proposed syntax. I would be happy to see that syntax added as an additive alternative in a future proposal (something like “line 1”\”line 2”).

• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

a quick reading

More information about the Swift evolution process is available at:

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Joe
Review Manager

David Beck
http://davidbeck.co
http://twitter.com/davbeck

Hey folks,

We've revised the proposal again. The main difference: You no longer need an initial newline to enable indentation stripping, and stripping no longer removes that newline even if it is present. (Adrian Zubarev and I believe some others argued for this.) We disagreed with this at first, but it made more sense as we thought about it more. There are a few things we like about it:

  1. The rules and algorithm are simpler.
  2. It accommodates more coding styles.
  3. Every non-escaped newline in the literal now creates a corresponding newline in the resulting string.
  4. it's easy to get the old behavior back by backslashing the leading newline.

Unfortunately, I think this precludes stripping the trailing newline by default, but I think this is ultimately a simpler and better approach than the previous draft.

Other changes:

  * We realized we needed to make closing delimiter matching a little more complicated if we wanted to allow one or two adjacent double-quote characters that were part of the literal's contents. Oops.
  * Tabs aren't actually allowed in ordinary string literals, so we now explicitly mention that as a difference between the two types.
  * We wrote some tests for the prototype (though they haven't been updated for this new version yet).
  * There were some other wording changes, particularly in the indentation stripping rationale, but nothing that affects the actual design.

I understand John is working on a new version of his toolchain so people can play with the prototype. We hope to have that ready for you all soon.

Let us know what you think of the revisions!

···

--
Brent Royal-Gordon
Architechies

  • What is your evaluation of the proposal?

I'm a -1 for several reasons, mostly subjective but still. First thing is that I'm generally not comfortable with encouraging the use of multi-line strings at all. These are things that usually should be templated or localised, and personally I don't see what's inconvenient about concatenating on those occasions where you can't (or just don't want to); I'm actually of the opinion that this is the kind of thing that should be awkward and annoying, to encourage developers to think about what they're doing.

IMHO, there are plenty of uses for multi-line strings that are entire valid and acceptable. SQL queries is the example I encounter the most in my day-to-day work. And concatenating makes working with them very cumbersome.

···

On 6 Apr 2017, at 22:34, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

On 6 Apr 2017, at 20:35, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

My second issue really is that, if the aim is simply to indent your multi-line string more nicely, then is this actually something that the language has to solve? I know we don't like to consider proposals purely from the perspective of what an IDE may, or may not, do, but this seems like a case where a good IDE could take:

let foo = "This is my
multi-line
text"

And display it visually to look like:

let foo = "This is my
  multi-line
  text"

This is basically what Xcode does for line-wrapped text right now. While it would mean people using more basic editors would still see the original, it's not really like that's a major problem.

Another alternative might be a compiler directive that is more explicit about what you want to do, for example:

let foo = #trimleft("
  This is my
    multi-line
  text
")

Here the directive would look at the text as a whole and see that all lines are indented by at least one tab, and so strip one tab from each line. There's probably a better name for the directive, but hopefully you hopefully get the idea, as this is much more explicit about what you want to do.

Also, one thing that really stands out with the proposal is how unwise the example is; the fact that the assertion relies on leading whitespace being stripped from the multi-line HTML makes it clear why things like this may not be a good idea, as if the code is edited to produce indented HTML then the assertion will fail, even if the HTML is still correct. The continuation quotes example makes this more obvious as it actually include some of the whitespace, so which is correct?

I don't want to seem too negative, I just think that whitespace stripping multi-line strings are a weird thing to want in a language. If an easier multi-line syntax has to be added then my preference would be for the alternative continuation quotes personally, as it's more explicit about what is included, though I still say there's nothing wrong with just doing the concatenation and newline characters IMO, as it's fully supported today and not really that much more burdensome to do (and it being a bit more difficult may be a good thing, as I say).

  • Is the problem being addressed significant enough to warrant a change to Swift?

Not really. We can already do multi-line by either putting newlines inside quotes and leaving out indentation, or by concatenating lines terminated with the new-line character. IMO these two existing options are enough as it is.

  • Does this proposal fit well with the feel and direction of Swift?

I'm not sure; in terms of simplicity I think that adding new syntax for multi-line strings is an unnecessary added complexity and something else to learn, and doesn't enable anything we can't already do fairly easily.

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

All of the proposed syntaxes are present in various languages, I've used many of them, and I know from my own bad habits that 99% of the time I shouldn't have :smirk:

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Followed the discussion and re-read the proposal.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I don't know if it will be reviewed for Swift 4, let alone be accepted, but I have a proposal in for a revised string interpolation protocol. One of the major use cases I considered was types which provided safe interpolation for things like markup languages and JSON. So, for instance, if you wrote this:

  let xml: XMLString = """
      <?xml version="1.0"?>
      <catalog>
          <book id="bk101" empty="">
              <author>\(author)</author>
              <title>XML Developer's Guide</title>
              <genre>Computer</genre>
              <price>44.95</price>
              <publish_date>2000-10-01</publish_date>
              <description>An in-depth look at creating applications with XML.</description>
          </book>
      </catalog>
      """

XMLString could escape `author` by default, unless it were itself an `XMLString` or you wrote the interpolation as `\(raw: author)`. And of course, this being Swift, `XMLString` would not necessarily have to be stated explicitly; it could come from being concatenated to an `XMLString`, passed in an `XMLString` parameter, or assigned to an `XMLString` property.

So I think this particular concern is orthogonal to the question of supporting multiline strings. Escaping safety is possible—it's just a separate feature.

···

On Apr 7, 2017, at 2:15 PM, Félix Cloutier via swift-evolution <swift-evolution@swift.org> wrote:

I don't necessarily think that the concept is a bad idea, but I think that the interaction of Swift features facilitates poor coding decisions. For example, the proposal interpolates an `author` variable straight into an XML document, and suggests doing the same to JSON strings. To me, this shows that an important use case of the feature is to format payloads in a way that is known to cause vulnerabilities.

--
Brent Royal-Gordon
Architechies

Hi, John here, the submitter of the proposal.

First up, I must apologise for putting Brent on the spot when I resubmitted this altered proposal from last year. That was my mistake.

Second up, apologies if the proposal is rather vague on details. In some sense this was intentional as I didn’t want to get too bogged down in specifics (and not at all to do with my limitations as a technical writer!)

I guess we need to build up consensus more slowly by asking the following questions separately so it can be resubmitted rather than giving a binary +/-1 on the proposal as it stands.

1) Does Swift need multi-line string literals?
2 ) Is “””long strings””” the way to go subject to a discussion about the precise delimiter
3) Is the “magic" leading whitespace removal a good idea to support indentation.
4) Does the proposal contain sufficient detail to be discussed/implemented

My answer to 1) is obviously yes and I think the discussion has come out about 50/50 so far so lets persevere...

Trying to fie down 2), a “””long string””” or @“long string”@ or _”long string”_ or #”long string”# is a string literal inside a new delimiter. It would be processed exactly as it would a normal string including escapes and interpolation except the string can include unescaped “ or “" and newlines. Also, a \ at the end of the line would mean that particular newline is not included in the string.

For me, the goals of a long string are that it should be able to pasted in (almost) without modification from a text source and that syntax highlighting would work for the widest possible range of text editors and github. “””long string””” is just a trick Python uses to satisfy the second goal (for example this gist <Multi-line String Zoo · GitHub) but highlighting also works for asymmetric delimiters such as @“long string”@ which avoid potential problems with “inversion”. Heredoc or a Swifty #equivalent does not satisfy this second goal at all well and IMHO it should be excluded. It would also be significantly more difficult to integrate into the Swift compiler.

Looking at 3) which is underspecified in the proposal perhaps, I’d consider it a “feature" but I can see it would be too magical for some. To specify it more you could say: if there is only whitespace between the last newline and the end of a multiline literal this whitespace will be stripped from all lines in the literal. If lines do not start with this exact sequence of whitespace a warning is emitted. In addition, if the first character in the literal is a newline it will be removed. This operation could be made explicit e.g. #trimLeft(“”"a literal""")

Perhaps we can find common ground on 1) and 2) and even 3) with a view to resubmitting if there is time. Seems mostly like we just need to discuss the delimiter further and decide whether the indent trimming is a bug or a feature to keep moving and not let another year slip by.

With respect to 4) I’m updating https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md as the proposal is discussed to fill in some of the gaps & I’ve prepared a toolchain for Swift 3 if you want to try an implementation out <http://johnholdsworth.com/swift-LOCAL-2017-04-09-a-osx.tar.gz&gt;

···

On 9 Apr 2017, at 15:35, Thorsten Seitz via swift-evolution <swift-evolution@swift.org> wrote:

https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md
What is your evaluation of the proposal?

+1

My foremost expectation from multiline string literals is to be able to copy and paste multiline string literals without having to fiddle with escape marks or leading and trailing quotes or continuation characters. This is exactly what the proposal provides and makes it easy to embed SQL, for example (using SQL parameters and not string interpolation of course ;-)

The chosen deindentation rules seem very pragmatic and useful to me.

Additional features for multiline string literals can be added easily later.

I would expect multiline string literals to use the same newline character as "\n“ does, regardless of the newline character actually used in the file.
Furthermore all normal escapes, e.g. \n, \t etc. should probably be available as well.
This should be stated explicitly in the proposal.

Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

Does this proposal fit well with the feel and direction of Swift?

Yes.

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

For setting the ground it compares favourably.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Followed most discussions, read the proposal.

-Thorsten

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

+1 with the clarifications provided in the thread.

···

On Sun, Apr 9, 2017 at 4:44 AM, Howard Lovatt via swift-evolution < swift-evolution@swift.org> wrote:

Review of SE-0168 "Multi-Line String Literals"

• What is your evaluation of the proposal?

Yes good idea. Though I am not clear as to whether the final return before
the closing """ is included in the literal or not. If not, would a blank
line before """ enclose a return at the end. If yes, would the closing """
have to be on the same line to prevent a return at the end. It doesn't
really matter which option, but it wasn't clear to me what happens.

• Is the problem being addressed significant enough to warrant a change to
Swift?

Yes. Very handy on server side code.

• Does this proposal fit well with the feel and direction of Swift?

Yes, with the push onto server side it is a nice addition.

• If you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?

Yes. Lots of languages have similar.

• How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

Quick read.

-- Howard.

On 7 Apr 2017, at 5:35 am, Joe Groff <jgroff@apple.com> wrote:

review of SE-0168 "Multi-Line String Literals" begins now and runs through
April 12, 2017. The proposal is available here:

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

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at:

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager. When replying, please try to keep the proposal link at the
top of the message:

Proposal link:

GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
proposals/0167-swift-encoders.md

Reply text

Other replies

*What goes into a review?*

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

• What is your evaluation of the proposal?
• Is the problem being addressed significant enough to warrant a change to
Swift?
• Does this proposal fit well with the feel and direction of Swift?
• If you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

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

Hey folks,

We've revised the proposal again. The main difference: You no longer need an initial newline to enable indentation stripping, and stripping no longer removes that newline even if it is present. (Adrian Zubarev and I believe some others argued for this.) We disagreed with this at first, but it made more sense as we thought about it more. There are a few things we like about it:

  1. The rules and algorithm are simpler.
  2. It accommodates more coding styles.
  3. Every non-escaped newline in the literal now creates a corresponding newline in the resulting string.
  4. it's easy to get the old behavior back by backslashing the leading newline.

Unfortunately, I think this precludes stripping the trailing newline by default, but I think this is ultimately a simpler and better approach than the previous draft.

Other changes:

  * We realized we needed to make closing delimiter matching a little more complicated if we wanted to allow one or two adjacent double-quote characters that were part of the literal's contents. Oops.
  * Tabs aren't actually allowed in ordinary string literals, so we now explicitly mention that as a difference between the two types.
  * We wrote some tests for the prototype (though they haven't been updated for this new version yet).
  * There were some other wording changes, particularly in the indentation stripping rationale, but nothing that affects the actual design.

I understand John is working on a new version of his toolchain so people can play with the prototype. We hope to have that ready for you all soon.

Let us know what you think of the revisions!

I haven’t formally reviewed this proposal but have been following the thread. I generally like this proposal quite a bit. I have used multi-line strings quite a bit in other languages and this proposal does a really nice job of avoiding the small annoyances I’ve encountered. Thanks for your hard work! +1

···

On Apr 12, 2017, at 8:40 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

--
Brent Royal-Gordon
Architechies

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

Hi Brent, thank you for the hard work and the new revision. However I still would love to hear your opinion if we should drop the support for these kind of options:

"""Hello↵
world!"""

"""↵
Hello↵
world!"""

"""Hello↵
world!
"""
I tend to agree that it’s much simpler to only support a single line version and a version where the actual string is in between the delimiter lines but not directly after or before them. Personally I don’t think you would always want to indent your multi-line string that far to the right side.

let myReallyLongXMLConstantName = """<?xml version="1.0"?>
                                     <catalog>
                                        <book id="bk101" empty="">
                                           <author>John Doe</author>
                                           <title>XML Developer's Guide</title>
                                           <genre>Computer</genre>
                                           <price>44.95</price>
                                        </book>
                                     </catalog>\
                                     """
Instead it’s easer and readable enough to write it like this:

let myReallyLongXMLConstantName = """
    <?xml version="1.0"?>
        <catalog>
            <book id="bk101" empty="">
                <author>John Doe</author>
                <title>XML Developer's Guide</title>
                <genre>Computer</genre>
                <price>44.95</price>
            </book>
    </catalog>\
    """
The starting delimiter does not produce a new line, only each line in between does if not explicitly prevented with a backslash. If you’d wanted to add a new line at the top, you just simply add one or \n below the starting delimiter.

···

--
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 15:40:26, Brent Royal-Gordon via swift-evolution (swift-evolution@swift.org) schrieb:

Hey folks,

We've revised the proposal again. The main difference: You no longer need an initial newline to enable indentation stripping, and stripping no longer removes that newline even if it is present. (Adrian Zubarev and I believe some others argued for this.) We disagreed with this at first, but it made more sense as we thought about it more. There are a few things we like about it:

1. The rules and algorithm are simpler.
2. It accommodates more coding styles.
3. Every non-escaped newline in the literal now creates a corresponding newline in the resulting string.
4. it's easy to get the old behavior back by backslashing the leading newline.

Unfortunately, I think this precludes stripping the trailing newline by default, but I think this is ultimately a simpler and better approach than the previous draft.

Other changes:

* We realized we needed to make closing delimiter matching a little more complicated if we wanted to allow one or two adjacent double-quote characters that were part of the literal's contents. Oops.
* Tabs aren't actually allowed in ordinary string literals, so we now explicitly mention that as a difference between the two types.
* We wrote some tests for the prototype (though they haven't been updated for this new version yet).
* There were some other wording changes, particularly in the indentation stripping rationale, but nothing that affects the actual design.

I understand John is working on a new version of his toolchain so people can play with the prototype. We hope to have that ready for you all soon.

Let us know what you think of the revisions!

--
Brent Royal-Gordon
Architechies

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

I think I agree that the simplicity of the new rules outweigh the loss of the first newline’s automatic stripping. Good job!

···

On 12 Apr 2017, at 15:40, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

Hey folks,

We've revised the proposal again. The main difference: You no longer need an initial newline to enable indentation stripping, and stripping no longer removes that newline even if it is present. (Adrian Zubarev and I believe some others argued for this.) We disagreed with this at first, but it made more sense as we thought about it more. There are a few things we like about it:

  1. The rules and algorithm are simpler.
  2. It accommodates more coding styles.
  3. Every non-escaped newline in the literal now creates a corresponding newline in the resulting string.
  4. it's easy to get the old behavior back by backslashing the leading newline.

Unfortunately, I think this precludes stripping the trailing newline by default, but I think this is ultimately a simpler and better approach than the previous draft.

Other changes:

  * We realized we needed to make closing delimiter matching a little more complicated if we wanted to allow one or two adjacent double-quote characters that were part of the literal's contents. Oops.
  * Tabs aren't actually allowed in ordinary string literals, so we now explicitly mention that as a difference between the two types.
  * We wrote some tests for the prototype (though they haven't been updated for this new version yet).
  * There were some other wording changes, particularly in the indentation stripping rationale, but nothing that affects the actual design.

I understand John is working on a new version of his toolchain so people can play with the prototype. We hope to have that ready for you all soon.

Let us know what you think of the revisions!

--
Brent Royal-Gordon
Architechies

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

Hey folks,

We've revised the proposal again. The main difference: You no longer need an initial newline to enable indentation stripping, and stripping no longer removes that newline even if it is present. (Adrian Zubarev and I believe some others argued for this.) We

Hmm, not sure if I like these changes. I expect that almost all strings won't begin with a newline and a majority won’t end with a newline. The new design would require a leading backslash almost all the time and a trailing backslash often, which is ugly:

let mystring = "““\
    text text
    text text\
    "““

-Thorsten

···

Am 12.04.2017 um 15:40 schrieb Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org>:

disagreed with this at first, but it made more sense as we thought about it more. There are a few things we like about it:

  1. The rules and algorithm are simpler.
  2. It accommodates more coding styles.
  3. Every non-escaped newline in the literal now creates a corresponding newline in the resulting string.
  4. it's easy to get the old behavior back by backslashing the leading newline.

Unfortunately, I think this precludes stripping the trailing newline by default, but I think this is ultimately a simpler and better approach than the previous draft.

Other changes:

  * We realized we needed to make closing delimiter matching a little more complicated if we wanted to allow one or two adjacent double-quote characters that were part of the literal's contents. Oops.
  * Tabs aren't actually allowed in ordinary string literals, so we now explicitly mention that as a difference between the two types.
  * We wrote some tests for the prototype (though they haven't been updated for this new version yet).
  * There were some other wording changes, particularly in the indentation stripping rationale, but nothing that affects the actual design.

I understand John is working on a new version of his toolchain so people can play with the prototype. We hope to have that ready for you all soon.

Let us know what you think of the revisions!

--
Brent Royal-Gordon
Architechies

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

Hey Brent,

thanks a lot for working on multi-line strings!

You were also talking about """ heredocs.
I really liked that idea.
Have you abandoned this concept?

Given that triple-quotes in Swift are already quite different from the Python version,
we could as well go one step further and introduce quoted here-docs.

E.g.:
print(""")
Hello world.
"""

Is there any interest in something like this?
Should I invest some time in drafting a specification/proposal?

— Martin

···

Am 12.04.2017 um 15:40 schrieb Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org>:

Hey folks,

We've revised the proposal again. The main difference: You no longer need an initial newline to enable indentation stripping, and stripping no longer removes that newline even if it is present. (Adrian Zubarev and I believe some others argued for this.) We disagreed with this at first, but it made more sense as we thought about it more. There are a few things we like about it:

  1. The rules and algorithm are simpler.
  2. It accommodates more coding styles.
  3. Every non-escaped newline in the literal now creates a corresponding newline in the resulting string.
  4. it's easy to get the old behavior back by backslashing the leading newline.

Unfortunately, I think this precludes stripping the trailing newline by default, but I think this is ultimately a simpler and better approach than the previous draft.

Other changes:

  * We realized we needed to make closing delimiter matching a little more complicated if we wanted to allow one or two adjacent double-quote characters that were part of the literal's contents. Oops.
  * Tabs aren't actually allowed in ordinary string literals, so we now explicitly mention that as a difference between the two types.
  * We wrote some tests for the prototype (though they haven't been updated for this new version yet).
  * There were some other wording changes, particularly in the indentation stripping rationale, but nothing that affects the actual design.

I understand John is working on a new version of his toolchain so people can play with the prototype. We hope to have that ready for you all soon.

Let us know what you think of the revisions!

--
Brent Royal-Gordon
Architechies

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

Maybe, but with SQL I long moved on to using placeholders for variables, which makes most statements fairly compact. And in fact these days I almost entirely use stored procedures, so most SQL statements I work with are just enough to call a procedure.

Even so, while that may be an argument for the need for multi-line strings it's a use case that would still be better handled by continuation quotes IMO, but again, they don't offer so much added convenience over concatenation to really be worth it.

Also, just wanted to add, but those arguing against continuation quotes on the basis of pasting into Swift; you already can paste into Swift using regular double quotes, you just don't get to indent text and have the indentation magically handled for you. It's the magic handling of indentation that makes me most uncomfortable about the main proposal. This is why I mentioned the idea of using a compiler directive which would be more explicit in what's going on, as well as being more discoverable as it would provide something easy to search for. Like so:

let foo = #trimleft("
  foo
    bar
  baz
")

Becoming (behind the scenes):

let foo = "foo
  bar
baz"

It has the same benefits as heredocs but without any new syntax, and someone new to the language can just search for "Swift #trimleft" (or whatever it'd be called) to find out what it does exactly.

···

On 6 Apr 2017, at 21:47, David Hart <david@hartbit.com> wrote:

On 6 Apr 2017, at 22:34, Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 6 Apr 2017, at 20:35, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

  • What is your evaluation of the proposal?

I'm a -1 for several reasons, mostly subjective but still. First thing is that I'm generally not comfortable with encouraging the use of multi-line strings at all. These are things that usually should be templated or localised, and personally I don't see what's inconvenient about concatenating on those occasions where you can't (or just don't want to); I'm actually of the opinion that this is the kind of thing that should be awkward and annoying, to encourage developers to think about what they're doing.

IMHO, there are plenty of uses for multi-line strings that are entire valid and acceptable. SQL queries is the example I encounter the most in my day-to-day work. And concatenating makes working with them very cumbersome.

Daniel Duan

Hi, John here, the submitter of the proposal.

First up, I must apologise for putting Brent on the spot when I resubmitted this altered proposal from last year. That was my mistake.

Second up, apologies if the proposal is rather vague on details. In some sense this was intentional as I didn’t want to get too bogged down in specifics (and not at all to do with my limitations as a technical writer!)

I guess we need to build up consensus more slowly by asking the following questions separately so it can be resubmitted rather than giving a binary +/-1 on the proposal as it stands.

1) Does Swift need multi-line string literals?
2 ) Is “””long strings””” the way to go subject to a discussion about the precise delimiter
3) Is the “magic" leading whitespace removal a good idea to support indentation.
4) Does the proposal contain sufficient detail to be discussed/implemented

My answer to 1) is obviously yes and I think the discussion has come out about 50/50 so far so lets persevere...

Trying to fie down 2), a “””long string””” or @“long string”@ or _”long string”_ or #”long string”# is a string literal inside a new delimiter. It would be processed exactly as it would a normal string including escapes and interpolation except the string can include unescaped “ or “" and newlines. Also, a \ at the end of the line would mean that particular newline is not included in the string.

For me, the goals of a long string are that it should be able to pasted in (almost) without modification from a text source and that syntax highlighting would work for the widest possible range of text editors and github. “””long string””” is just a trick Python uses to satisfy the second goal (for example this gist) but highlighting also works for asymmetric delimiters such as @“long string”@ which avoid potential problems with “inversion”. Heredoc or a Swifty #equivalent does not satisfy this second goal at all well and IMHO it should be excluded. It would also be significantly more difficult to integrate into the Swift compiler.

Looking at 3) which is underspecified in the proposal perhaps, I’d consider it a “feature" but I can see it would be too magical for some. To specify it more you could say: if there is only whitespace between the last newline and the end of a multiline literal this whitespace will be stripped from all lines in the literal. If lines do not start with this exact sequence of whitespace a warning is emitted. In addition, if the first character in the literal is a newline it will be removed. This operation could be made explicit e.g. #trimLeft(“”"a literal""")

I'm a enthusiastic supporter for this idea. In a proposal, specificity is a virtue. The algorithm Brent described in his last post is precisely how I imagined this work. It's precise and succinct. I'd consider including it verbatim in the proposal :)

···

Sent from my iPhone

On Apr 9, 2017, at 9:29 AM, John Holdsworth via swift-evolution <swift-evolution@swift.org> wrote:

Perhaps we can find common ground on 1) and 2) and even 3) with a view to resubmitting if there is time. Seems mostly like we just need to discuss the delimiter further and decide whether the indent trimming is a bug or a feature to keep moving and not let another year slip by.

With respect to 4) I’m updating https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md as the proposal is discussed to fill in some of the gaps & I’ve prepared a toolchain for Swift 3 if you want to try an implementation out

On 9 Apr 2017, at 15:35, Thorsten Seitz via swift-evolution <swift-evolution@swift.org> wrote:

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

What is your evaluation of the proposal?

+1

My foremost expectation from multiline string literals is to be able to copy and paste multiline string literals without having to fiddle with escape marks or leading and trailing quotes or continuation characters. This is exactly what the proposal provides and makes it easy to embed SQL, for example (using SQL parameters and not string interpolation of course ;-)

The chosen deindentation rules seem very pragmatic and useful to me.

Additional features for multiline string literals can be added easily later.

I would expect multiline string literals to use the same newline character as "\n“ does, regardless of the newline character actually used in the file.
Furthermore all normal escapes, e.g. \n, \t etc. should probably be available as well.
This should be stated explicitly in the proposal.

Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

Does this proposal fit well with the feel and direction of Swift?

Yes.

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

For setting the ground it compares favourably.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Followed most discussions, read the proposal.

-Thorsten

_______________________________________________
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

Looking at 3) which is underspecified in the proposal perhaps, I’d consider it a “feature" but I can see it would be too magical for some. To specify it more you could say: if there is only whitespace between the last newline and the end of a multiline literal this whitespace will be stripped from all lines in the literal. If lines do not start with this exact sequence of whitespace a warning is emitted. In addition, if the first character in the literal is a newline it will be removed. This operation could be made explicit e.g. #trimLeft(“”"a literal"”")

Yeah, that was my one hesitation. I actually didn’t understand the scheme at first and thought *all* whitespace would be left-trimmed. What about just adding a `leftTrimLines()` or `deindent()`+`deindent(levels:Int)` or comparable string method, so you could just do something like this:

let json = """
    {
        "a": "b",
        "c": {
            "d": 3
        }
    }
""".deindent()

As a bonus, you can use this for non-literals should the need arise.

Perhaps we can find common ground on 1) and 2) and even 3) with a view to resubmitting if there is time. Seems mostly like we just need to discuss the delimiter further and decide whether the indent trimming is a bug or a feature to keep moving and not let another year slip by.

I’d really rather just see the core team accept this with a modification to trimming, otherwise I guarantee it’s not getting in this year.

···

On Apr 9, 2017, at 9:29 AM, John Holdsworth via swift-evolution <swift-evolution@swift.org> wrote:

Honestly, I think this is a little premature. If I had to summarize this thread, I think what I'm seeing is:

  1. We wish the proposal were more specific on a few points, like the de-indenting algorithm.

  2. We have lots of different pet syntaxes and preferences.

  3. But most of us are still in favor of accepting the proposal.

To back up that last point, I ran through the thread and tried to quickly figure out what everyone was thinking. These people seem to be opposed to the proposal:

  1. Haravikk doesn't like the de-indenting and seems iffy on multiline strings in general.
  2. David Waite wants a suite of different, orthogonal string literal features to get enough flexibility.
  3. Félix Cloutier is worried that supporting interpolation makes this feature a powerful footgun.
  4. Adrian Zubarev wants to extend single-quoted string literals instead of developing a second syntax.

These people want the proposal to be more specific, but appear to be in favor as long as the missing details don't reveal problems:

  1. Greg Parker (maybe?)
  2. Xiaodi Wu
  3. Gwendel Roué

And these people all seem basically positive, though sometimes with reservations or bikeshedding suggestions:

  1. Me
  2. Tony Allevato
  3. David Hart
  4. Daniel Duan
  5. Ricardo Parada
  6. Kevin Nattinger
  7. Víctor Pimentel Rodríguez
  8. Jarod Long (I think)
  9. Ben Cohen
  10. Thorsten Seitz
  11. Howard Lovatt
  12. T.J. Usiyan

Evolution reviews are not referenda, but I think it's fair to say that the sentiment is mostly positive.

(And if the core team does say they like the approach but want clarifications, I'd be happy to pitch in and earn the co-author credit!)

···

On Apr 9, 2017, at 9:29 AM, John Holdsworth via swift-evolution <swift-evolution@swift.org> wrote:

Perhaps we can find common ground on 1) and 2) and even 3) with a view to resubmitting if there is time. Seems mostly like we just need to discuss the delimiter further and decide whether the indent trimming is a bug or a feature to keep moving and not let another year slip by.

--
Brent Royal-Gordon
Architechies

Hi, John here, the submitter of the proposal.

First up, I must apologise for putting Brent on the spot when I resubmitted this altered proposal from last year. That was my mistake.

Second up, apologies if the proposal is rather vague on details. In some sense this was intentional as I didn’t want to get too bogged down in specifics (and not at all to do with my limitations as a technical writer!)

I guess we need to build up consensus more slowly by asking the following questions separately so it can be resubmitted rather than giving a binary +/-1 on the proposal as it stands.

1) Does Swift need multi-line string literals?

Hi John, I think it is a "nice to have" feature. This feature would enhance multi-line string literals by removing some of the hassles such as specifying \n in each line, escaping quote characters and the concatenation character for each line of text. But best of all, the string literal would look much better in our code.

2 ) Is “””long strings””” the way to go subject to a discussion about the precise delimiter

IMHO, I think the use of triple quote has the best feel and look.

I am one of the ones who had proposed several options that included a continuation character. I still like the aesthetics of having a continuation character, in particular, the quote character. For example:

let xml = """<?xml version="1.0"?>
            "<catalog>
            " <book id="bk101" empty="">
            " <author>\(author)</author>
            " <title>XML Developer's Guide</title>
            " <genre>Computer</genre>
            " <price>44.95</price>
            " <publish_date>2000-10-01</publish_date>
            " <description>An in-depth look at creating applications with XML.</description>
            " </book>
            "</catalog>

I had proposed that the multi-line string literal would end automatically when a line was found without the continuation character. This way when you start typing it, the editor would include one line at most. But I don't know if such an algorithm would be challenging for syntax highlighters.

I liked this option because it provided a visual guide of where each line started and found the indent of each line more predictable. But most importantly to me, this made the string literal look beautiful within my code.

One criticism of having a continuation character is the effort required adding the continuation character to each line. But that was okay with me because 90% of the time I typed in my string literal from scratch and indented it properly to fit with my other code.

I rarely ever copied / pasted a multi-line string literal directly into my code. Therefore, my goal was never to save typing, but rather to make my multi-line string literal look beautiful when surrounded by code.

I had also proposed to make the continuation character optional and turn off the automatic indentation stripping.

It is important not having to escape quotes in the the string literal. Mostly because the escaping can make the literal look ugly and a bit harder to read.

I also considered string interpolation a feature that would be nice to have. We already have it in normal string literals and I think It would be a mistake to not include it here.

The only downside to not having a closing """ is that the last line always included a newline. However, we could allow a backslash at the line to escape the newline character. As an alternative, the closing """ could be optionally specified in the last line when continuation characters are used. However, if no continuation character was used then the closing """ would be mandatory.

3) Is the “magic" leading whitespace removal a good idea to support indentation.

I think that is reasonable. I do consider leading white space removal a highly desirable feature.

4) Does the proposal contain sufficient detail to be discussed/implemented

I think the proposal should include more examples and some edge cases that illustrate how this feature will work.

For example, if the last line does not have a newline character then I would end my string like this:

let xml = """<?xml version="1.0"?>
             <catalog>
                 <book id="bk101" empty="">
                     <author>\(author)</author>
                     <title>XML Developer's Guide</title>
                     <genre>Computer</genre>
                     <price>44.95</price>
                     <publish_date>2000-10-01</publish_date>
                     <description>An in-depth look at creating applications with XML.</description>
                 </book>
             </catalog>"""

What would be the amount of indentation stripped here? I would expect the white space preceding the last line containing the </catalog> would be the amount of indentation stripped from each line.

···

On Apr 9, 2017, at 12:29 PM, John Holdsworth via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

My answer to 1) is obviously yes and I think the discussion has come out about 50/50 so far so lets persevere...

Trying to fie down 2), a “””long string””” or @“long string”@ or _”long string”_ or #”long string”# is a string literal inside a new delimiter. It would be processed exactly as it would a normal string including escapes and interpolation except the string can include unescaped “ or “" and newlines. Also, a \ at the end of the line would mean that particular newline is not included in the string.

For me, the goals of a long string are that it should be able to pasted in (almost) without modification from a text source and that syntax highlighting would work for the widest possible range of text editors and github. “””long string””” is just a trick Python uses to satisfy the second goal (for example this gist <Multi-line String Zoo · GitHub) but highlighting also works for asymmetric delimiters such as @“long string”@ which avoid potential problems with “inversion”. Heredoc or a Swifty #equivalent does not satisfy this second goal at all well and IMHO it should be excluded. It would also be significantly more difficult to integrate into the Swift compiler.

Looking at 3) which is underspecified in the proposal perhaps, I’d consider it a “feature" but I can see it would be too magical for some. To specify it more you could say: if there is only whitespace between the last newline and the end of a multiline literal this whitespace will be stripped from all lines in the literal. If lines do not start with this exact sequence of whitespace a warning is emitted. In addition, if the first character in the literal is a newline it will be removed. This operation could be made explicit e.g. #trimLeft(“”"a literal""")

Perhaps we can find common ground on 1) and 2) and even 3) with a view to resubmitting if there is time. Seems mostly like we just need to discuss the delimiter further and decide whether the indent trimming is a bug or a feature to keep moving and not let another year slip by.

With respect to 4) I’m updating https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md as the proposal is discussed to fill in some of the gaps & I’ve prepared a toolchain for Swift 3 if you want to try an implementation out <http://johnholdsworth.com/swift-LOCAL-2017-04-09-a-osx.tar.gz&gt;

On 9 Apr 2017, at 15:35, Thorsten Seitz via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md
What is your evaluation of the proposal?

+1

My foremost expectation from multiline string literals is to be able to copy and paste multiline string literals without having to fiddle with escape marks or leading and trailing quotes or continuation characters. This is exactly what the proposal provides and makes it easy to embed SQL, for example (using SQL parameters and not string interpolation of course ;-)

The chosen deindentation rules seem very pragmatic and useful to me.

Additional features for multiline string literals can be added easily later.

I would expect multiline string literals to use the same newline character as "\n“ does, regardless of the newline character actually used in the file.
Furthermore all normal escapes, e.g. \n, \t etc. should probably be available as well.
This should be stated explicitly in the proposal.

Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

Does this proposal fit well with the feel and direction of Swift?

Yes.

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

For setting the ground it compares favourably.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Followed most discussions, read the proposal.

-Thorsten

_______________________________________________
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

Hi, John here, the submitter of the proposal.

First up, I must apologise for putting Brent on the spot when I resubmitted this altered proposal from last year. That was my mistake.

Second up, apologies if the proposal is rather vague on details. In some sense this was intentional as I didn’t want to get too bogged down in specifics (and not at all to do with my limitations as a technical writer!)

I guess we need to build up consensus more slowly by asking the following questions separately so it can be resubmitted rather than giving a binary +/-1 on the proposal as it stands.

1) Does Swift need multi-line string literals?

Yes.

2 ) Is “””long strings””” the way to go subject to a discussion about the precise delimiter

Yes.

3) Is the “magic" leading whitespace removal a good idea to support indentation.

Yes.

4) Does the proposal contain sufficient detail to be discussed/implemented

Thanks for the update! I only have the following issues left:

All other escapes would be processed as before including interpolation, \n and "

You probably meant \“ instead of " here.

The proposal should state what kind of newline will be used within a multiline string literal. I already proposed that it should be exactly the same as for \n and not the newline character(s) actually used in the file (e.g. LF+CR or LF or CR), to avoid issues when working on different platforms (Windows, Mac, Linux) and/or using Git’s autocrlf feature.

The proposal should give an example how to create a multiline string literal which ends with a newline (AFAIU there should be an empty line before the closing ""“).

-Thorsten

···

Am 09.04.2017 um 18:29 schrieb John Holdsworth <mac@johnholdsworth.com>:

My answer to 1) is obviously yes and I think the discussion has come out about 50/50 so far so lets persevere...

Trying to fie down 2), a “””long string””” or @“long string”@ or _”long string”_ or #”long string”# is a string literal inside a new delimiter. It would be processed exactly as it would a normal string including escapes and interpolation except the string can include unescaped “ or “" and newlines. Also, a \ at the end of the line would mean that particular newline is not included in the string.

For me, the goals of a long string are that it should be able to pasted in (almost) without modification from a text source and that syntax highlighting would work for the widest possible range of text editors and github. “””long string””” is just a trick Python uses to satisfy the second goal (for example this gist <Multi-line String Zoo · GitHub) but highlighting also works for asymmetric delimiters such as @“long string”@ which avoid potential problems with “inversion”. Heredoc or a Swifty #equivalent does not satisfy this second goal at all well and IMHO it should be excluded. It would also be significantly more difficult to integrate into the Swift compiler.

Looking at 3) which is underspecified in the proposal perhaps, I’d consider it a “feature" but I can see it would be too magical for some. To specify it more you could say: if there is only whitespace between the last newline and the end of a multiline literal this whitespace will be stripped from all lines in the literal. If lines do not start with this exact sequence of whitespace a warning is emitted. In addition, if the first character in the literal is a newline it will be removed. This operation could be made explicit e.g. #trimLeft(“”"a literal""")

Perhaps we can find common ground on 1) and 2) and even 3) with a view to resubmitting if there is time. Seems mostly like we just need to discuss the delimiter further and decide whether the indent trimming is a bug or a feature to keep moving and not let another year slip by.

With respect to 4) I’m updating https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md as the proposal is discussed to fill in some of the gaps & I’ve prepared a toolchain for Swift 3 if you want to try an implementation out <http://johnholdsworth.com/swift-LOCAL-2017-04-09-a-osx.tar.gz&gt;

On 9 Apr 2017, at 15:35, Thorsten Seitz via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md
What is your evaluation of the proposal?

+1

My foremost expectation from multiline string literals is to be able to copy and paste multiline string literals without having to fiddle with escape marks or leading and trailing quotes or continuation characters. This is exactly what the proposal provides and makes it easy to embed SQL, for example (using SQL parameters and not string interpolation of course ;-)

The chosen deindentation rules seem very pragmatic and useful to me.

Additional features for multiline string literals can be added easily later.

I would expect multiline string literals to use the same newline character as "\n“ does, regardless of the newline character actually used in the file.
Furthermore all normal escapes, e.g. \n, \t etc. should probably be available as well.
This should be stated explicitly in the proposal.

Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

Does this proposal fit well with the feel and direction of Swift?

Yes.

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

For setting the ground it compares favourably.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Followed most discussions, read the proposal.

-Thorsten

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

This is the most logical newline stripping behavior in my opinion. It's very easy to think about -- all the lines in-between the triple quotes are the contents of the string. Leading and trailing newlines are easily added if desired by adding extra lines.

To support that model, I also agree with the suggestion that we shouldn't allow multiline string contents on the same line as the opening or closing delimiters. They are multiline strings after all, so I don't see much value in supporting that.

On a separate note, I'd like to bring up the de-indentation behavior I described earlier again. I still feel that having the position of the closing delimiter determine how much whitespace is de-indented is not very natural or intuitive, since I don't think there is any precedent in standard Swift styling to indent a closing delimiter to the same level as its content. Stripping the most common whitespace possible from each line seems to be a much more intuitive and flexible solution in terms of formatting, and it's still compatible with the proposed formatting if that's anyone's preference.

The only functional limitation that I see is that if you can't have leading whitespace in the interpreted string if you actually want that. That doesn't seem like a very important use case to me, but if we think it is important, it could be supported by something like having a backslash in the leading whitespace at the location where it should be preserved from.

If we're set on the proposed behavior, have we considered what happens if the closing delimiter goes beyond the non-whitespace content of the string?

let string = """
aa
bb
cc
"""

Does it strip the non-whitespace characters? Does it strip up to the non-whitespace characters? Does it generate an error?

Jarod

···

On Apr 12, 2017, 10:41 -0700, Ricardo Parada via swift-evolution <swift-evolution@swift.org>, wrote:

Hi all,

I agree as well, I think we should make optimize for the most common case of multi-line strings. A rule that says strip the first leading newline as well as the trailing newline. So it's almost back to where Brent started with the addition of removing the trailing newline.

Borrowing Adrian's example, I could just have this:

let myReallyLongXMLConstantName = """
   <?xml version="1.0"?>
   <catalog>
       <book id="bk101" empty="">
           <author>John Doe</author>
           <title>XML Developer's Guide</title>
           <genre>Computer</genre>
           <price>44.95</price>
       </book>
   </catalog>
   """
If somebody wants the last line to include a newline at the end, they can just add a \n at the end or an empty line.

So if I do this:

print(myReallyLongXMLConstantName)
print("Text right below")
It would output this:

<?xml version="1.0"?>
<catalog>
<book id="bk101" empty="">
<author>John Doe</author>
<title>XML Developer's Guide</title>
<genre>Computer</genre>
<price>44.95</price>
</book>
</catalog>
Test right below

Without removing the trailing newline then it would print like this:

<?xml version="1.0"?>
<catalog>
<book id="bk101" empty="">
<author>John Doe</author>
<title>XML Developer's Guide</title>
<genre>Computer</genre>
<price>44.95</price>
</book>
</catalog>

Test right below

> On Apr 12, 2017, at 12:48 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:
>
> Agree. I prefer the new rules over the old, but considering common use cases, stripping the leading and trailing newline makes for a more pleasant experience than not stripping either of them.
>
> I think that is generally worth prioritizing over a simpler algorithm or even accommodating more styles. Moreover, a user who wants a trailing or leading newline merely types an extra one if there is newline stripping, so no use cases are made difficult, only a very common one is made more ergonomic.
> > On Wed, Apr 12, 2017 at 09:52 Thorsten Seitz via swift-evolution <swift-evolution@swift.org> wrote:
> > > > Am 12.04.2017 um 15:40 schrieb Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org>:
> > > >
> > > > Hey folks,
> > > >
> > > >
> > > > We've revised the proposal again. The main difference: You no longer need an initial newline to enable indentation stripping, and stripping no longer removes that newline even if it is present. (Adrian Zubarev and I believe some others argued for this.) We
> > >
> > > Hmm, not sure if I like these changes. I expect that almost all strings won't begin with a newline and a majority won’t end with a newline. The new design would require a leading backslash almost all the time and a trailing backslash often, which is ugly:
> > >
> > > let mystring = "““\
> > > text text
> > > text text\
> > > "““
> > >
> > > -Thorsten
> > >
> > >
> > > > disagreed with this at first, but it made more sense as we thought about it more. There are a few things we like about it:
> > > >
> > > > 1. The rules and algorithm are simpler.
> > > > 2. It accommodates more coding styles.
> > > > 3. Every non-escaped newline in the literal now creates a corresponding newline in the resulting string.
> > > > 4. it's easy to get the old behavior back by backslashing the leading newline.
> > > >
> > > > Unfortunately, I think this precludes stripping the trailing newline by default, but I think this is ultimately a simpler and better approach than the previous draft.
> > > >
> > > > Other changes:
> > > >
> > > > * We realized we needed to make closing delimiter matching a little more complicated if we wanted to allow one or two adjacent double-quote characters that were part of the literal's contents. Oops.
> > > > * Tabs aren't actually allowed in ordinary string literals, so we now explicitly mention that as a difference between the two types.
> > > > * We wrote some tests for the prototype (though they haven't been updated for this new version yet).
> > > > * There were some other wording changes, particularly in the indentation stripping rationale, but nothing that affects the actual design.
> > > >
> > > > I understand John is working on a new version of his toolchain so people can play with the prototype. We hope to have that ready for you all soon.
> > > >
> > > > Let us know what you think of the revisions!
> > > >
> > > > --
> > > > 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
> _______________________________________________
> 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 all,

I agree as well, I think we should make optimize for the most common case of multi-line strings. A rule that says strip the first leading newline as well as the trailing newline. So it's almost back to where Brent started with the addition of removing the trailing newline.

Borrowing Adrian's example, I could just have this:

let myReallyLongXMLConstantName = """
    <?xml version="1.0"?>
    <catalog>
        <book id="bk101" empty="">
            <author>John Doe</author>
            <title>XML Developer's Guide</title>
            <genre>Computer</genre>
            <price>44.95</price>
        </book>
    </catalog>
    """
If somebody wants the last line to include a newline at the end, they can just add a \n at the end or an empty line.

So if I do this:
print(myReallyLongXMLConstantName)
print("Text right below")
It would output this:

<?xml version="1.0"?>
<catalog>
     <book id="bk101" empty="">
         <author>John Doe</author>
         <title>XML Developer's Guide</title>
         <genre>Computer</genre>
         <price>44.95</price>
     </book>
</catalog>
Test right below

Without removing the trailing newline then it would print like this:

<?xml version="1.0"?>
<catalog>
     <book id="bk101" empty="">
         <author>John Doe</author>
         <title>XML Developer's Guide</title>
         <genre>Computer</genre>
         <price>44.95</price>
     </book>
</catalog>

Test right below

···

On Apr 12, 2017, at 12:48 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

Agree. I prefer the new rules over the old, but considering common use cases, stripping the leading and trailing newline makes for a more pleasant experience than not stripping either of them.

I think that is generally worth prioritizing over a simpler algorithm or even accommodating more styles. Moreover, a user who wants a trailing or leading newline merely types an extra one if there is newline stripping, so no use cases are made difficult, only a very common one is made more ergonomic.
On Wed, Apr 12, 2017 at 09:52 Thorsten Seitz via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> Am 12.04.2017 um 15:40 schrieb Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:
>
> Hey folks,
>
>
> We've revised the proposal again. The main difference: You no longer need an initial newline to enable indentation stripping, and stripping no longer removes that newline even if it is present. (Adrian Zubarev and I believe some others argued for this.) We

Hmm, not sure if I like these changes. I expect that almost all strings won't begin with a newline and a majority won’t end with a newline. The new design would require a leading backslash almost all the time and a trailing backslash often, which is ugly:

let mystring = "““\
    text text
    text text\
    "““

-Thorsten

> disagreed with this at first, but it made more sense as we thought about it more. There are a few things we like about it:
>
> 1. The rules and algorithm are simpler.
> 2. It accommodates more coding styles.
> 3. Every non-escaped newline in the literal now creates a corresponding newline in the resulting string.
> 4. it's easy to get the old behavior back by backslashing the leading newline.
>
> Unfortunately, I think this precludes stripping the trailing newline by default, but I think this is ultimately a simpler and better approach than the previous draft.
>
> Other changes:
>
> * We realized we needed to make closing delimiter matching a little more complicated if we wanted to allow one or two adjacent double-quote characters that were part of the literal's contents. Oops.
> * Tabs aren't actually allowed in ordinary string literals, so we now explicitly mention that as a difference between the two types.
> * We wrote some tests for the prototype (though they haven't been updated for this new version yet).
> * There were some other wording changes, particularly in the indentation stripping rationale, but nothing that affects the actual design.
>
> I understand John is working on a new version of his toolchain so people can play with the prototype. We hope to have that ready for you all soon.
>
> Let us know what you think of the revisions!
>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> 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 messed up the indent in the example, where is the corrected version:

let myReallyLongXMLConstantName = """
    <?xml version="1.0"?>
    <catalog>
        <book id="bk101" empty="">
            <author>John Doe</author>
            <title>XML Developer's Guide</title>
            <genre>Computer</genre>
            <price>44.95</price>
        </book>
    </catalog>\
    """

···

--
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 16:05:59, Adrian Zubarev (adrian.zubarev@devandartist.com) schrieb:

Hi Brent, thank you for the hard work and the new revision. However I still would love to hear your opinion if we should drop the support for these kind of options:

"""Hello↵
world!"""

"""↵
Hello↵
world!"""

"""Hello↵
world!
"""
I tend to agree that it’s much simpler to only support a single line version and a version where the actual string is in between the delimiter lines but not directly after or before them. Personally I don’t think you would always want to indent your multi-line string that far to the right side.

let myReallyLongXMLConstantName = """<?xml version="1.0"?>
                                     <catalog>
                                        <book id="bk101" empty="">
                                           <author>John Doe</author>
                                           <title>XML Developer's Guide</title>
                                           <genre>Computer</genre>
                                           <price>44.95</price>
                                        </book>
                                     </catalog>\
                                     """
Instead it’s easer and readable enough to write it like this:

let myReallyLongXMLConstantName = """
    <?xml version="1.0"?>
        <catalog>
            <book id="bk101" empty="">
                <author>John Doe</author>
                <title>XML Developer's Guide</title>
                <genre>Computer</genre>
                <price>44.95</price>
            </book>
    </catalog>\
    """
The starting delimiter does not produce a new line, only each line in between does if not explicitly prevented with a backslash. If you’d wanted to add a new line at the top, you just simply add one or \n below the starting delimiter.

--
Adrian Zubarev
Sent with Airmail

Am 12. April 2017 um 15:40:26, Brent Royal-Gordon via swift-evolution (swift-evolution@swift.org) schrieb:

Hey folks,

We've revised the proposal again. The main difference: You no longer need an initial newline to enable indentation stripping, and stripping no longer removes that newline even if it is present. (Adrian Zubarev and I believe some others argued for this.) We disagreed with this at first, but it made more sense as we thought about it more. There are a few things we like about it:

1. The rules and algorithm are simpler.
2. It accommodates more coding styles.
3. Every non-escaped newline in the literal now creates a corresponding newline in the resulting string.
4. it's easy to get the old behavior back by backslashing the leading newline.

Unfortunately, I think this precludes stripping the trailing newline by default, but I think this is ultimately a simpler and better approach than the previous draft.

Other changes:

* We realized we needed to make closing delimiter matching a little more complicated if we wanted to allow one or two adjacent double-quote characters that were part of the literal's contents. Oops.
* Tabs aren't actually allowed in ordinary string literals, so we now explicitly mention that as a difference between the two types.
* We wrote some tests for the prototype (though they haven't been updated for this new version yet).
* There were some other wording changes, particularly in the indentation stripping rationale, but nothing that affects the actual design.

I understand John is working on a new version of his toolchain so people can play with the prototype. We hope to have that ready for you all soon.

Let us know what you think of the revisions!

--
Brent Royal-Gordon
Architechies

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