I also would oppose comments inside multi-line strings because one place I imagine using it is in Swift code generation and I also want to generate comments, and it seems pointless to have to escape those.<br><br>Let's not over-engineer this and end up with feature creep. A simple multi-line string that takes its contents more or less verbatim (with the exception of necessary escapes, interpolation, and dedenting) is fine.<br><div class="gmail_quote"><div dir="ltr">On Wed, Apr 12, 2017 at 5:50 AM Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Right, I think it might be too much.<br class="gmail_msg"><br class="gmail_msg">Consider that the multi-line literal could be code with comments in it, but that you could also escape and embed an actual multi-line comment with \ /* */ that isn't part of the multi-line literal code with multi-line comments! How confusing!<br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Wed, Apr 12, 2017 at 07:36 Ricardo Parada via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="gmail_msg"><div class="gmail_msg">I don't think I would use that. I don't find the aesthetics pleasant. <br class="gmail_msg">I would rather comment above the string literal. </div><div id="m_-5053092981287344633m_-5298301120532425476AppleMailSignature" class="gmail_msg"><br class="gmail_msg"></div><div id="m_-5053092981287344633m_-5298301120532425476AppleMailSignature" class="gmail_msg">Would the escape character cause the newline for the line to be ignored thereby continuing the string on the next line?</div></div><div dir="auto" class="gmail_msg"><div id="m_-5053092981287344633m_-5298301120532425476AppleMailSignature" class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg">On Apr 12, 2017, at 6:59 AM, Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="m_-5053092981287344633m_-5298301120532425476bloop_markdown gmail_msg"><p class="gmail_msg">One last pitch, can we allow comments in multi-line strings if the string is broken up by a backslash?</p>
<pre class="gmail_msg"><code class="m_-5053092981287344633m_-5298301120532425476swift gmail_msg">
let myString = """
text text
text text text \ // Comment allowed in the current line here, but not in the line above it
text text text \ /* this type of comment is fine too */
text text\// notice whitespace can be ignored
"""
</code></pre>
<p class="gmail_msg">You might have some interpolation and want to comment around it.</p>
<pre class="gmail_msg"><code class="m_-5053092981287344633m_-5298301120532425476swift gmail_msg">let foo = """
bar bar bar
bar \(x) bar\ // `x` does some magic
"""
</code></pre>
<p class="gmail_msg"></p></div><div class="m_-5053092981287344633m_-5298301120532425476bloop_original_html gmail_msg"><div id="m_-5053092981287344633m_-5298301120532425476bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto" class="gmail_msg"><br class="gmail_msg"></div> <br class="gmail_msg"> <div id="m_-5053092981287344633m_-5298301120532425476bloop_sign_1491994413280799744" class="m_-5053092981287344633m_-5298301120532425476bloop_sign gmail_msg"><div style="font-family:helvetica,arial;font-size:13px" class="gmail_msg">-- <br class="gmail_msg">Adrian Zubarev<br class="gmail_msg">Sent with Airmail</div></div> <br class="gmail_msg"><p class="m_-5053092981287344633m_-5298301120532425476airmail_on gmail_msg">Am 12. April 2017 um 12:48:57, Adrian Zubarev (<a href="mailto:adrian.zubarev@devandartist.com" class="gmail_msg" target="_blank">adrian.zubarev@devandartist.com</a>) schrieb:</p> <blockquote type="cite" class="m_-5053092981287344633m_-5298301120532425476clean_bq gmail_msg"><span class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"></div><div class="gmail_msg">
<div class="m_-5053092981287344633m_-5298301120532425476bloop_markdown gmail_msg">
<p class="gmail_msg">Actually I’m fine with such a compromise. Such a model has
everything we’ve asked for, it’s easy, it has both leading and
trailing precision and implicit new lines where needed.</p>
</div>
<div class="m_-5053092981287344633m_-5298301120532425476bloop_original_html gmail_msg">
<div id="m_-5053092981287344633m_-5298301120532425476bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto" class="gmail_msg">
<br class="gmail_msg"></div>
<br class="gmail_msg">
<div id="m_-5053092981287344633m_-5298301120532425476bloop_sign_1491994049751838976" class="m_-5053092981287344633m_-5298301120532425476bloop_sign gmail_msg">
<div style="font-family:helvetica,arial;font-size:13px" class="gmail_msg">
-- <br class="gmail_msg">
Adrian Zubarev<br class="gmail_msg">
Sent with Airmail</div>
</div>
<br class="gmail_msg">
<p class="m_-5053092981287344633m_-5298301120532425476airmail_on gmail_msg">Am 12. April 2017 um 12:42:17, Vladimir.S via
swift-evolution (<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>)
schrieb:</p>
<blockquote type="cite" class="m_-5053092981287344633m_-5298301120532425476clean_bq gmail_msg">
<div class="gmail_msg">
<div class="gmail_msg"><span class="gmail_msg">On 12.04.2017 13:16, Thorsten Seitz via swift-evolution
wrote:<br class="gmail_msg">
>> Am 12.04.2017 um 10:11 schrieb Adrian Zubarev via
swift-evolution<br class="gmail_msg">
>> <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>
<<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">mailto:swift-evolution@swift.org</a>>>:<br class="gmail_msg">
>><br class="gmail_msg">
>> Great explanation thank you Brent. I’m convinced about the
closing delimiter now. =)<br class="gmail_msg">
>><br class="gmail_msg">
>>
-------------------------------------------------------------------------------------<br class="gmail_msg">
>><br class="gmail_msg">
>> If I understood correctly what Xiaodi Wu meant in his
reply, then we could simplify<br class="gmail_msg">
>> the whole multi-line string literal and also remove the
need of disabling the<br class="gmail_msg">
>> stripping algorithm.<br class="gmail_msg">
>><br class="gmail_msg">
>> We should ban these examples completely:<br class="gmail_msg">
>><br class="gmail_msg">
>> |"""Hello·world!"""|<br class="gmail_msg">
>><br class="gmail_msg">
><br class="gmail_msg">
> Being able to use ""“ for single line strings containing lots
of " is useful in<br class="gmail_msg">
> itself and explained in the motivational section of the
proposal:<br class="gmail_msg">
> "Tripled string literals can also do double duty as a syntax
for handling short<br class="gmail_msg">
> string literals with many internal quotation marks“<br class="gmail_msg">
><br class="gmail_msg">
> -Thorsten<br class="gmail_msg">
<br class="gmail_msg">
Yes, I also think the single line string can be very useful and we
should not<br class="gmail_msg">
disallow it.<br class="gmail_msg">
<br class="gmail_msg">
But I agree that we should disallow multi-line cases when we have
text on the same<br class="gmail_msg">
line with leading or trailing """ because this complicates the
mental modal and adds<br class="gmail_msg">
confusion points.<br class="gmail_msg">
<br class="gmail_msg">
I.e. I suggest to allow only two forms:<br class="gmail_msg">
1. Single line: """this is "just" text""" (no line end will be
inserted)<br class="gmail_msg">
2. Multiline, where leading and trailing """ has no text
after/before them and *all*<br class="gmail_msg">
the text is in lines *between* triple quotes:<br class="gmail_msg">
"""<br class="gmail_msg">
first line<br class="gmail_msg">
second line<br class="gmail_msg">
"""<br class="gmail_msg">
<br class="gmail_msg">
One can use backslash at the line end to emulate all other needed
cases. Like:<br class="gmail_msg">
<br class="gmail_msg">
"""<br class="gmail_msg">
first line \<br class="gmail_msg">
second line\<br class="gmail_msg">
"""<br class="gmail_msg">
<br class="gmail_msg">
will produce "first line second line"<br class="gmail_msg">
<br class="gmail_msg">
><br class="gmail_msg">
>> |"""Hello↵ world!""" |<br class="gmail_msg">
>> |"""Hello↵ world!↵ """ |<br class="gmail_msg">
>> |"""↵ Hello↵ world!""" |<br class="gmail_msg">
>><br class="gmail_msg">
>> Instead an empty multi-line string literal would look like
this:<br class="gmail_msg">
>><br class="gmail_msg">
>> |"""↵ """ |<br class="gmail_msg">
>><br class="gmail_msg">
>> To fix the above example you’d need to write it like
this:<br class="gmail_msg">
>><br class="gmail_msg">
>> |"""↵ Hello·world!\↵ """ |<br class="gmail_msg">
>> |"""↵ Hello↵ world!\↵ """ |<br class="gmail_msg">
>><br class="gmail_msg">
>> * Each line in between the delimiters would add implicit
new lines if not<br class="gmail_msg">
>> disabled by a backslash.<br class="gmail_msg">
>> * The trailing precision is also handled by the
backslash.<br class="gmail_msg">
>> * The indent is handled by the closing delimiter.<br class="gmail_msg">
>> * It’s easier to learn/teach.<br class="gmail_msg">
>> * It’s easier to read, because most of the time the line
where the starting<br class="gmail_msg">
>> delimiter is, is filled with some other code.<br class="gmail_msg">
>><br class="gmail_msg">
>> |let myString = """↵ ⇥ ⇥ Hello↵ ⇥ ⇥ world!\↵ ⇥ ⇥ """
|<br class="gmail_msg">
>><br class="gmail_msg">
>> Now that would be a true multi-line string literal which
needs at least two lines<br class="gmail_msg">
>> of code. If you’d need a single line literal,|""|is the
obvious pick.<br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> --<br class="gmail_msg">
>> Adrian Zubarev<br class="gmail_msg">
>> Sent with Airmail<br class="gmail_msg">
>><br class="gmail_msg">
>> Am 12. April 2017 um 02:32:33, Brent Royal-Gordon
(<a href="mailto:brent@architechies.com" class="gmail_msg" target="_blank">brent@architechies.com</a><br class="gmail_msg">
>> <<a href="mailto:brent@architechies.com" class="gmail_msg" target="_blank">mailto:brent@architechies.com</a>>) schrieb:<br class="gmail_msg">
>><br class="gmail_msg">
>>><br class="gmail_msg">
>>>> On Apr 11, 2017, at 8:08 AM, Adrian Zubarev via
swift-evolution<br class="gmail_msg">
>>>> <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>
<<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">mailto:swift-evolution@swift.org</a>>> wrote:<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> That’s also the example that kept me thinking for
a while.<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>>
-------------------------------------------------------------------------------------<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> Overall the proposal is a great compromise to some
issues I had with the first<br class="gmail_msg">
>>>> version. However I have a few more
questions:<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> * Why can’t we make it consistent and let the
compiler add a new line after the<br class="gmail_msg">
>>>> starting delimiter.<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> |
let string = """↵ Swift↵ """ // result ↵Swift↵
|<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> If one would would the behavior from the proposal
it’s really easy to add a<br class="gmail_msg">
>>>> backslash after the starting delimiter.<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> |
let string = """\↵ Swift\↵ """ // result Swift
|<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> This would be consistent and less confusing to
learn.<br class="gmail_msg">
>>>><br class="gmail_msg">
>>> That would mean that code like this:<br class="gmail_msg">
>>><br class="gmail_msg">
>>> print("""<br class="gmail_msg">
>>> A whole bunch of<br class="gmail_msg">
>>> multiline text<br class="gmail_msg">
>>> """)<br class="gmail_msg">
>>> print("""<br class="gmail_msg">
>>> A whole bunch more<br class="gmail_msg">
>>> multiline text<br class="gmail_msg">
>>> """)<br class="gmail_msg">
>>><br class="gmail_msg">
>>> Will print (with - to indicate blank lines):<br class="gmail_msg">
>>><br class="gmail_msg">
>>> -<br class="gmail_msg">
>>> A whole bunch of<br class="gmail_msg">
>>> multiline text<br class="gmail_msg">
>>> -<br class="gmail_msg">
>>> -<br class="gmail_msg">
>>> A whole bunch more<br class="gmail_msg">
>>> multiline text<br class="gmail_msg">
>>> -<br class="gmail_msg">
>>><br class="gmail_msg">
>>> This is, to a first approximation, never what you
actually want the computer to do.<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> * Can’t we make the indent algorithm work like
this instead?<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> |let string = """\↵ ····<tag>↵ ······content
text↵ ····</tag>""" // Indent starts<br class="gmail_msg">
>>>> with the first non space character // result
<tag>↵ ··content text↵ </tag> |<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> The line where the closing delimiter is trims all
space chapters and the indent<br class="gmail_msg">
>>>> for the whole multi-line string is starting at the
point where the first<br class="gmail_msg">
>>>> non-space chapters is in that line.<br class="gmail_msg">
>>>><br class="gmail_msg">
>>> We could; I discuss that briefly in the very last
section, on alternatives to the<br class="gmail_msg">
>>> indentation stripping we specify:<br class="gmail_msg">
>>><br class="gmail_msg">
>>> • Stripping indentation to match the depth of the
least indented line: Instead of<br class="gmail_msg">
>>> removing indentation to match the end delimiter, you
remove indentation to match<br class="gmail_msg">
>>> the least indented line of the string itself. The
issue here is that, if all lines<br class="gmail_msg">
>>> in a string should be indented, you can't use
indentation stripping. Ruby 2.3 does<br class="gmail_msg">
>>> this with its heredocs, and Python's dedent function
also implements this behavior.<br class="gmail_msg">
>>><br class="gmail_msg">
>>> That doesn't quite capture the entire breadth of the
problem with this algorithm,<br class="gmail_msg">
>>> though. What you'd like to do is say, "all of these
lines are indented four<br class="gmail_msg">
>>> columns, so we should remove four columns of
indentation from each line". But you<br class="gmail_msg">
>>> don't have columns; you have tabs and spaces, and
they're incomparable because the<br class="gmail_msg">
>>> compiler can't know what tab stops you set. So we'd
end up calculating a common<br class="gmail_msg">
>>> prefix of whitespace for all lines and removing that.
But that means, when someone<br class="gmail_msg">
>>> mixes tabs and spaces accidentally, you end up
stripping an amount of indentation<br class="gmail_msg">
>>> that is unrelated to anything visible in your code. We
could perhaps emit a<br class="gmail_msg">
>>> warning in some suspicious circumstances (like "every
line has whitespace just<br class="gmail_msg">
>>> past the end of indentation, but some use tabs and
others use spaces"), but if we<br class="gmail_msg">
>>> do, we can't know which one is supposed to be correct.
With the proposed design,<br class="gmail_msg">
>>> we know what's correct—the last line—and any deviation
from it can be flagged *at<br class="gmail_msg">
>>> the particular line which doesn't match our
expectation*.<br class="gmail_msg">
>>><br class="gmail_msg">
>>> Even without the tabs and spaces issue, consider the
case where you accidentally<br class="gmail_msg">
>>> don't indent a line far enough. With your algorithm,
that's indistinguishable from<br class="gmail_msg">
>>> wanting the other lines to be indented more than that
one, so we generate a result<br class="gmail_msg">
>>> you don't want and we don't (can't!) emit a warning to
point out the mistake. With<br class="gmail_msg">
>>> the proposed algorithm, we can notice there's an error
and point to the line at fault.<br class="gmail_msg">
>>><br class="gmail_msg">
>>> Having the closing delimiter always be on its own line
and using it to decide how<br class="gmail_msg">
>>> much whitespace to strip is better because it gives
the compiler a firm baseline<br class="gmail_msg">
>>> to work from. That means it can tell you what's wrong
and where, instead of doing<br class="gmail_msg">
>>> the dumb computer thing and computing a result that's
technically correct but useless.<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> PS: If we’d get this feature in Swift, it would be
nice if Xcode and other IDEs<br class="gmail_msg">
>>>> which supports Swift could show space characters
that are inside a string literal<br class="gmail_msg">
>>>> (not other space character <- which is already
supported), so it would be easier<br class="gmail_msg">
>>>> to tell what’s part of the string and what is
not.<br class="gmail_msg">
>>>><br class="gmail_msg">
>>> That would be very nice indeed. The prototype's
tokenizer simply concatenates<br class="gmail_msg">
>>> together and computes the string literal's contents
after whitespace stripping,<br class="gmail_msg">
>>> but in principle, I think it could probably preserve
enough information to tell<br class="gmail_msg">
>>> SourceKit where the indentation ends and the literal
content begins. (The<br class="gmail_msg">
>>> prototype is John's department, though, not mine.)
Xcode would then have to do<br class="gmail_msg">
>>> something with that information, though, and
swift-evolution can't make the Xcode<br class="gmail_msg">
>>> team do so. But I'd love to see a faint reddish
background behind tripled string<br class="gmail_msg">
>>> literal content or a vertical line at the indentation
boundary.<br class="gmail_msg">
>>><br class="gmail_msg">
>>> In the meantime, this design *does* provide an
unambiguous indicator of how much<br class="gmail_msg">
>>> whitespace will be trimmed: however much is to the
left of the closing delimiter.<br class="gmail_msg">
>>> You just have to imagine the line extending upwards
from there. I think that's an<br class="gmail_msg">
>>> important thing to have.<br class="gmail_msg">
>>><br class="gmail_msg">
>>> --<br class="gmail_msg">
>>> Brent Royal-Gordon<br class="gmail_msg">
>>> Architechies<br class="gmail_msg">
>>><br class="gmail_msg">
>><br class="gmail_msg">
>> _______________________________________________<br class="gmail_msg">
>> swift-evolution mailing list<br class="gmail_msg">
>> <a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>
<<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">mailto:swift-evolution@swift.org</a>><br class="gmail_msg">
>>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> swift-evolution mailing list<br class="gmail_msg">
> <a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
><br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></span></div>
</div>
</blockquote>
</div>
<div class="m_-5053092981287344633m_-5298301120532425476bloop_markdown gmail_msg"></div>
</div></div></span></blockquote></div><div class="m_-5053092981287344633m_-5298301120532425476bloop_markdown gmail_msg"><p class="gmail_msg"></p></div></div></blockquote><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><span class="gmail_msg">_______________________________________________</span><br class="gmail_msg"><span class="gmail_msg">swift-evolution mailing list</span><br class="gmail_msg"><span class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a></span><br class="gmail_msg"><span class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class="gmail_msg"></div></blockquote></div>_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>