<html><head><style>
body {
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
padding:1em;
margin:auto;
background:#fefefe;
}
h1, h2, h3, h4, h5, h6 {
font-weight: bold;
}
h1 {
color: #000000;
font-size: 28pt;
}
h2 {
border-bottom: 1px solid #CCCCCC;
color: #000000;
font-size: 24px;
}
h3 {
font-size: 18px;
}
h4 {
font-size: 16px;
}
h5 {
font-size: 14px;
}
h6 {
color: #777777;
background-color: inherit;
font-size: 14px;
}
hr {
height: 0.2em;
border: 0;
color: #CCCCCC;
background-color: #CCCCCC;
display: inherit;
}
p, blockquote, ul, ol, dl, li, table, pre {
margin: 15px 0;
}
a, a:visited {
color: #4183C4;
background-color: inherit;
text-decoration: none;
}
#message {
border-radius: 6px;
border: 1px solid #ccc;
display:block;
width:100%;
height:60px;
margin:6px 0px;
}
button, #ws {
font-size: 12 pt;
padding: 4px 6px;
border-radius: 5px;
border: 1px solid #bbb;
background-color: #eee;
}
code, pre, #ws, #message {
font-family: Monaco;
font-size: 10pt;
border-radius: 3px;
background-color: #F8F8F8;
color: inherit;
}
code {
border: 1px solid #EAEAEA;
margin: 0 2px;
padding: 0 5px;
}
pre {
border: 1px solid #CCCCCC;
overflow: auto;
padding: 4px 8px;
}
pre > code {
border: 0;
margin: 0;
padding: 0;
}
#ws { background-color: #f8f8f8; }
.bloop_markdown table {
border-collapse: collapse;
font-family: Helvetica, arial, freesans, clean, sans-serif;
color: rgb(51, 51, 51);
font-size: 15px; line-height: 25px;
padding: 0; }
.bloop_markdown table tr {
border-top: 1px solid #cccccc;
background-color: white;
margin: 0;
padding: 0; }
.bloop_markdown table tr:nth-child(2n) {
background-color: #f8f8f8; }
.bloop_markdown table tr th {
font-weight: bold;
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr td {
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr th :first-child, table tr td :first-child {
margin-top: 0; }
.bloop_markdown table tr th :last-child, table tr td :last-child {
margin-bottom: 0; }
.bloop_markdown blockquote{
border-left: 4px solid #dddddd;
padding: 0 15px;
color: #777777; }
blockquote > :first-child {
margin-top: 0; }
blockquote > :last-child {
margin-bottom: 0; }
code, pre, #ws, #message {
word-break: normal;
word-wrap: normal;
}
hr {
display: inherit;
}
.bloop_markdown :first-child {
-webkit-margin-before: 0;
}
code, pre, #ws, #message {
font-family: Menlo, Consolas, Liberation Mono, Courier, monospace;
}
.send { color:#77bb77; }
.server { color:#7799bb; }
.error { color:#AA0000; }</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="bloop_markdown"><p>That’s also the example that kept me thinking for a while.</p>
<hr>
<p>Overall the proposal is a great compromise to some issues I had with the first version. However I have a few more questions:</p>
<ul>
<li>Why can’t we make it consistent and let the compiler add a new line after the starting delimiter.</li>
</ul>
<pre><code class="swift">
let string = """↵
Swift↵
"""
// result
↵Swift↵
</code></pre>
<p>If one would would the behavior from the proposal it’s really easy to add a backslash after the starting delimiter.</p>
<pre><code class="swift">
let string = """\↵
Swift\↵
"""
// result
Swift
</code></pre>
<p>This would be consistent and less confusing to learn.</p>
<ul>
<li>Can’t we make the indent algorithm work like this instead?</li>
</ul>
<pre><code>let string = """\↵
····<tag>↵
······content text↵
····</tag>""" // Indent starts with the first non space character
// result
<tag>↵
··content text↵
</tag>
</code></pre>
<p>The line where the closing delimiter is trims all space chapters and the indent for the whole multi-line string is starting at the point where the first non-space chapters is in that line.</p>
<p>What do you think?</p>
<p>PS: If we’d get this feature in Swift, it would be nice if Xcode and other IDEs which supports Swift could show space characters that are inside a string literal (not other space character <- which is already supported), so it would be easier to tell what’s part of the string and what is not.</p>
<p></p></div><div class="bloop_original_html"><style>body{font-family:Helvetica,Arial;font-size:13px}</style><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <br> <div id="bloop_sign_1491922170216184064" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div> <br><p class="airmail_on">Am 11. April 2017 um 16:33:28, Vladimir.S via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>On 11.04.2017 16:35, John Holdsworth via swift-evolution wrote:<br>> I feel discussion on this proposal is nearing general agreement that while the gist of it<br>> it seems reasonable to many there is also not enough detail in it as submitted.<br>><br>> Brent has person-fully stepped in and rewritten the draft to translate it into a detailed<br>> specification which I’ve updated here:<br>><br>> https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md<br><br>Thank you for the detailed proposal.<br>FWIW, in general I support it, but have two objections/questions:<br><br>1. "Tripled string literals support backslash escapes and interpolation as normal, <br>except that you can also place a backslash immediately before a newline. This <br>indicates that the newline is merely for code formatting and should not be present in <br>the resulting string:"<br>- I think this a confusion point which should not be in this proposal. Currently in <br>"normal" strings we just can't have single backlash as it will generate "invalid <br>escape sequence in literal" warning.<br>Is this feature worth the added complexity? I'm not sure currently.<br><br>2. Seems like a mistake:<br>"Multi-line string with indentation stripping prevented by whitespace before leading <br>newline"<br><br>"""↵<br>····Hello↵<br>····world!"""<br><br>Creates a string with:<br><br>····↵<br>····Hello↵<br>····world!<br><br>I believe it should be just:<br><br>····Hello↵<br>····world!<br><br>><br>> Perhaps we could use the remaining time on the review to pre-evaluate this draft should<br>> we get the chance to resubmit with modifications to maximise its chances. Key questions:<br>><br>> 1) Does Swift need multi-line string literals?<br>> 2 ) Is “””long strings””” the way to go subject to a discussion about the precise<br>> delimiter<br>> 3) Is the “magic" leading whitespace removal a good idea to support indentation.<br>><br>> The main change on the revised proposal from the the original submitted is Thorsten’s<br>> suggestion that Windows line endings in a source file be normalised to \n in the literal.<br>><br>> John<br>><br>>> On 10 Apr 2017, at 12:09, Thorsten Seitz <tseitz42@icloud.com<br>>> <mailto:tseitz42@icloud.com>> wrote:<br>>><br>>><br>>>> Am 09.04.2017 um 18:29 schrieb John Holdsworth <mac@johnholdsworth.com<br>>>> <mailto:mac@johnholdsworth.com>>:<br>>>><br>>>> Hi, John here, the submitter of the proposal.<br>>>><br>>>> First up, I must apologise for putting Brent on the spot when I resubmitted this<br>>>> altered proposal from last year. That was my mistake.<br>>>><br>>>> Second up, apologies if the proposal is rather vague on details. In some sense<br>>>> this was intentional as I didn’t want to get too bogged down in specifics (and not<br>>>> at all to do with my limitations as a technical writer!)<br>>>><br>>>> I guess we need to build up consensus more slowly by asking the following<br>>>> questions separately so it can be resubmitted rather than giving a binary +/-1 on<br>>>> the proposal as it stands.<br>>>><br>>>> 1) Does Swift need multi-line string literals?<br>>><br>>> Yes.<br>>><br>>>> 2 ) Is “””long strings””” the way to go subject to a discussion about the precise<br>>>> delimiter<br>>><br>>> Yes.<br>>><br>>>> 3) Is the “magic" leading whitespace removal a good idea to support indentation.<br>>><br>>> Yes.<br>>><br>>>> 4) Does the proposal contain sufficient detail to be discussed/implemented<br>>><br>>> Thanks for the update! I only have the following issues left:<br>>><br>>> > All other escapes would be processed as before including interpolation, \n and "<br>>> You probably meant \“ instead of " here.<br>>><br>>> The proposal should state what kind of newline will be used within a multiline<br>>> string literal. I already proposed that it should be exactly the same as for \n and<br>>> not the newline character(s) actually used in the file (e.g. LF+CR or LF or CR), to<br>>> avoid issues when working on different platforms (Windows, Mac, Linux) and/or using<br>>> Git’s autocrlf feature.<br>>><br>>> The proposal should give an example how to create a multiline string literal which<br>>> ends with a newline (AFAIU there should be an empty line before the closing ""“).<br>>><br>>> -Thorsten<br>>><br>>>><br>>>> My answer to 1) is obviously yes and I think the discussion has come out about<br>>>> 50/50 so far so lets persevere...<br>>>><br>>>> Trying to fie down 2), a “””long string””” or @“long string”@ or _”long string”_<br>>>> or #”long string”# is a string literal inside a new delimiter. It would be<br>>>> processed exactly as it would a normal string including escapes and interpolation<br>>>> except the string can include unescaped “ or “" and newlines. Also, a \ at the<br>>>> end of the line would mean that particular newline is not included in the string.<br>>>><br>>>> For me, the goals of a long string are that it should be able to pasted in<br>>>> (almost) without modification from a text source and that syntax highlighting<br>>>> would work for the widest possible range of text editors and github. “””long<br>>>> string””” is just a trick Python uses to satisfy the second goal (for example this<br>>>> gist<br>>>> <https://gist.github.com/johnno1962/5c325a16838ad3c73e0f109a514298bf#file-multiline-swift-L97>) but<br>>>> highlighting also works for asymmetric delimiters such as @“long string”@ which<br>>>> avoid potential problems with “inversion”. Heredoc or a Swifty #equivalent does<br>>>> not satisfy this second goal at all well and IMHO it should be excluded. It would<br>>>> also be significantly more difficult to integrate into the Swift compiler.<br>>>><br>>>> Looking at 3) which is underspecified in the proposal perhaps, I’d consider it a<br>>>> “feature" but I can see it would be too magical for some. To specify it more you<br>>>> could say: if there is only whitespace between the last newline and the end of a<br>>>> multiline literal this whitespace will be stripped from all lines in the literal.<br>>>> If lines do not start with this exact sequence of whitespace a warning is emitted.<br>>>> In addition, if the first character in the literal is a newline it will be<br>>>> removed. This operation could be made explicit e.g. #trimLeft(“”"a literal""")<br>>>><br>>>> Perhaps we can find common ground on 1) and 2) and even 3) with a view to<br>>>> resubmitting if there is time. Seems mostly like we just need to discuss the<br>>>> delimiter further and decide whether the indent trimming is a bug or a feature to<br>>>> keep moving and not let another year slip by.<br>>>><br>>>> With respect to 4) I’m<br>>>> updating https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md as<br>>>> the proposal is discussed to fill in some of the gaps & I’ve prepared a toolchain<br>>>> for Swift 3 if you want to try an implementation out<br>>>> <http://johnholdsworth.com/swift-LOCAL-2017-04-09-a-osx.tar.gz><br>>>><br>>>>> On 9 Apr 2017, at 15:35, Thorsten Seitz via swift-evolution<br>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:<br>>>>><br>>>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md<br>>>>><br>>>>>> What is your evaluation of the proposal?<br>>>>><br>>>>> +1<br>>>>><br>>>>> My foremost expectation from multiline string literals is to be able to copy and<br>>>>> paste multiline string literals without having to fiddle with escape marks or<br>>>>> leading and trailing quotes or continuation characters. This is exactly what the<br>>>>> proposal provides and makes it easy to embed SQL, for example (using SQL<br>>>>> parameters and not string interpolation of course ;-)<br>>>>><br>>>>> The chosen deindentation rules seem very pragmatic and useful to me.<br>>>>><br>>>>> Additional features for multiline string literals can be added easily later.<br>>>>><br>>>>> I would expect multiline string literals to use the same newline character as<br>>>>> "\n“ does, regardless of the newline character actually used in the file.<br>>>>> Furthermore all normal escapes, e.g. \n, \t etc. should probably be available as<br>>>>> well.<br>>>>> This should be stated explicitly in the proposal.<br>>>>><br>>>>>> Is the problem being addressed significant enough to warrant a change to Swift?<br>>>>><br>>>>> Yes.<br>>>>><br>>>>>> Does this proposal fit well with the feel and direction of Swift?<br>>>>><br>>>>> Yes.<br>>>>><br>>>>>> If you have used other languages or libraries with a similar feature, how do you<br>>>>>> feel that this proposal compares to those?<br>>>>><br>>>>> For setting the ground it compares favourably.<br>>>>><br>>>>>> How much effort did you put into your review? A glance, a quick reading, or an<br>>>>>> in-depth study?<br>>>>><br>>>>> Followed most discussions, read the proposal.<br>>>>><br>>>>> -Thorsten<br>>>>><br>>>>> _______________________________________________<br>>>>> swift-evolution mailing list<br>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org><br>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution<br>>>><br>>><br>><br>><br>><br>> _______________________________________________<br>> swift-evolution mailing list<br>> swift-evolution@swift.org<br>> https://lists.swift.org/mailman/listinfo/swift-evolution<br>><br>_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></body></html>