It was simply a pitch ;) Adding comments it’s not important to me, but I
thought it could simply work after the backlash.
And multi-line comments /**/ should work fine and are not ambiguous because
they also have a clear single line purpose. Remember SE–0102 here public
/*closed*/ enum Never { /*no values*/ }?
I wasn’t talking about escaping comments but allowing comments after the end of
the current line of a multi-lined string which is explicitly annotated with a
backslash.
If no one likes that pitch, fine I don’t I don’t want to pursue the idea then.
;)
--
Adrian Zubarev
Sent with Airmail
Am 12. April 2017 um 15:43:04, Thorsten Seitz via swift-evolution
(swift-evolution@swift.org) schrieb:
Am 12.04.2017 um 14:56 schrieb Xiaodi Wu <xiaodi...@gmail.com>:
Sure, but keep in mind you're ultimately presenting a long string to the user.
Chances are if it needs commenting to the reader of the code, it needs
commenting to the reader of the string (which could be code itself, whether a
SQL query or something else).
Good point.
Can you give a use case where essentially you need two-tiered comments like
this?
Nope, just thought that Adrian’s idea seemed useful and not detrimental.
Actually I’m fine with or without comments.
-Thorsten
On Wed, Apr 12, 2017 at 07:47 Thorsten Seitz via swift-evolution
<swift-evolution@swift.org> wrote:
Am 12.04.2017 um 14:36 schrieb Ricardo Parada via swift-evolution
<swift-evolution@swift.org>:
I don't think I would use that. I don't find the aesthetics pleasant.
I would rather comment above the string literal.
It might be useful when many comments would be required where putting them in a
bunch above the literal would make it difficult to properly correlate them with
the respective pieces of the string.
Would the escape character cause the newline for the line to be ignored thereby
continuing the string on the next line?
Yes. The semantics of the backslash should not change, its presence just opens
the room for placing a comment.
To get a newline you would have to write \n\
let myString = "““
text text\n\ // comment
text text
““"
-Thorsten
On Apr 12, 2017, at 6:59 AM, Adrian Zubarev via swift-evolution
<swift-evolution@swift.org> wrote:
One last pitch, can we allow comments in multi-line strings if the string is
broken up by a backslash?
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
"""
You might have some interpolation and want to comment around it.
let foo = """
bar bar bar
bar \(x) bar\ // `x` does some magic
"""
--
Adrian Zubarev
Sent with Airmail
Am 12. April 2017 um 12:48:57, Adrian Zubarev (adrian.zuba...@devandartist.com)
schrieb:
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.
--
Adrian Zubarev
Sent with Airmail
Am 12. April 2017 um 12:42:17, Vladimir.S via swift-evolution
(swift-evolution@swift.org) schrieb:
On 12.04.2017 13:16, Thorsten Seitz via swift-evolution wrote:
>> Am 12.04.2017 um 10:11 schrieb Adrian Zubarev via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:
>>
>> Great explanation thank you Brent. I’m convinced about the closing delimiter
>> now. =)
>>
>> -------------------------------------------------------------------------------------
>>
>> If I understood correctly what Xiaodi Wu meant in his reply, then we could
>> simplify
>> the whole multi-line string literal and also remove the need of disabling the
>> stripping algorithm.
>>
>> We should ban these examples completely:
>>
>> |"""Hello·world!"""|
>>
>
> Being able to use ""“ for single line strings containing lots of " is useful
> in
> itself and explained in the motivational section of the proposal:
> "Tripled string literals can also do double duty as a syntax for handling
> short
> string literals with many internal quotation marks“
>
> -Thorsten
Yes, I also think the single line string can be very useful and we should not
disallow it.
But I agree that we should disallow multi-line cases when we have text on the
same
line with leading or trailing """ because this complicates the mental modal and
adds
confusion points.
I.e. I suggest to allow only two forms:
1. Single line: """this is "just" text""" (no line end will be inserted)
2. Multiline, where leading and trailing """ has no text after/before them and
*all*
the text is in lines *between* triple quotes:
"""
first line
second line
"""
One can use backslash at the line end to emulate all other needed cases. Like:
"""
first line \
second line\
"""
will produce "first line second line"
>
>> |"""Hello↵ world!""" |
>> |"""Hello↵ world!↵ """ |
>> |"""↵ Hello↵ world!""" |
>>
>> Instead an empty multi-line string literal would look like this:
>>
>> |"""↵ """ |
>>
>> To fix the above example you’d need to write it like this:
>>
>> |"""↵ Hello·world!\↵ """ |
>> |"""↵ Hello↵ world!\↵ """ |
>>
>> * Each line in between the delimiters would add implicit new lines if not
>> disabled by a backslash.
>> * The trailing precision is also handled by the backslash.
>> * The indent is handled by the closing delimiter.
>> * It’s easier to learn/teach.
>> * It’s easier to read, because most of the time the line where the starting
>> delimiter is, is filled with some other code.
>>
>> |let myString = """↵ ⇥ ⇥ Hello↵ ⇥ ⇥ world!\↵ ⇥ ⇥ """ |
>>
>> Now that would be a true multi-line string literal which needs at least two
>> lines
>> of code. If you’d need a single line literal,|""|is the obvious pick.
>>
>>
>>
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> Am 12. April 2017 um 02:32:33, Brent Royal-Gordon (br...@architechies.com
>> <mailto:br...@architechies.com>) schrieb:
>>
>>>
>>>> On Apr 11, 2017, at 8:08 AM, Adrian Zubarev via swift-evolution
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>
>>>> That’s also the example that kept me thinking for a while.
>>>>
>>>> -------------------------------------------------------------------------------------
>>>>
>>>> Overall the proposal is a great compromise to some issues I had with the
>>>> first
>>>> version. However I have a few more questions:
>>>>
>>>> * Why can’t we make it consistent and let the compiler add a new line
>>>> after the
>>>> starting delimiter.
>>>>
>>>> |
let string = """↵ Swift↵ """ // result ↵Swift↵ |
>>>>
>>>> If one would would the behavior from the proposal it’s really easy to add a
>>>> backslash after the starting delimiter.
>>>>
>>>> |
let string = """\↵ Swift\↵ """ // result Swift |
>>>>
>>>> This would be consistent and less confusing to learn.
>>>>
>>> That would mean that code like this:
>>>
>>> print("""
>>> A whole bunch of
>>> multiline text
>>> """)
>>> print("""
>>> A whole bunch more
>>> multiline text
>>> """)
>>>
>>> Will print (with - to indicate blank lines):
>>>
>>> -
>>> A whole bunch of
>>> multiline text
>>> -
>>> -
>>> A whole bunch more
>>> multiline text
>>> -
>>>
>>> This is, to a first approximation, never what you actually want the
>>> computer to do.
>>>>
>>>> * Can’t we make the indent algorithm work like this instead?
>>>>
>>>> |let string = """\↵ ····<tag>↵ ······content text↵ ····</tag>""" // Indent
>>>> starts
>>>> with the first non space character // result <tag>↵ ··content text↵ </tag>
>>>> |
>>>>
>>>> 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.
>>>>
>>> We could; I discuss that briefly in the very last section, on alternatives
>>> to the
>>> indentation stripping we specify:
>>>
>>> • Stripping indentation to match the depth of the least indented line:
>>> Instead of
>>> removing indentation to match the end delimiter, you remove indentation to
>>> match
>>> the least indented line of the string itself. The issue here is that, if
>>> all lines
>>> in a string should be indented, you can't use indentation stripping. Ruby
>>> 2.3 does
>>> this with its heredocs, and Python's dedent function also implements this
>>> behavior.
>>>
>>> That doesn't quite capture the entire breadth of the problem with this
>>> algorithm,
>>> though. What you'd like to do is say, "all of these lines are indented four
>>> columns, so we should remove four columns of indentation from each line".
>>> But you
>>> don't have columns; you have tabs and spaces, and they're incomparable
>>> because the
>>> compiler can't know what tab stops you set. So we'd end up calculating a
>>> common
>>> prefix of whitespace for all lines and removing that. But that means, when
>>> someone
>>> mixes tabs and spaces accidentally, you end up stripping an amount of
>>> indentation
>>> that is unrelated to anything visible in your code. We could perhaps emit a
>>> warning in some suspicious circumstances (like "every line has whitespace
>>> just
>>> past the end of indentation, but some use tabs and others use spaces"), but
>>> if we
>>> do, we can't know which one is supposed to be correct. With the proposed
>>> design,
>>> we know what's correct—the last line—and any deviation from it can be
>>> flagged *at
>>> the particular line which doesn't match our expectation*.
>>>
>>> Even without the tabs and spaces issue, consider the case where you
>>> accidentally
>>> don't indent a line far enough. With your algorithm, that's
>>> indistinguishable from
>>> wanting the other lines to be indented more than that one, so we generate a
>>> result
>>> you don't want and we don't (can't!) emit a warning to point out the
>>> mistake. With
>>> the proposed algorithm, we can notice there's an error and point to the
>>> line at fault.
>>>
>>> Having the closing delimiter always be on its own line and using it to
>>> decide how
>>> much whitespace to strip is better because it gives the compiler a firm
>>> baseline
>>> to work from. That means it can tell you what's wrong and where, instead of
>>> doing
>>> the dumb computer thing and computing a result that's technically correct
>>> but useless.
>>>>
>>>> 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.
>>>>
>>> That would be very nice indeed. The prototype's tokenizer simply
>>> concatenates
>>> together and computes the string literal's contents after whitespace
>>> stripping,
>>> but in principle, I think it could probably preserve enough information to
>>> tell
>>> SourceKit where the indentation ends and the literal content begins. (The
>>> prototype is John's department, though, not mine.) Xcode would then have to
>>> do
>>> something with that information, though, and swift-evolution can't make the
>>> Xcode
>>> team do so. But I'd love to see a faint reddish background behind tripled
>>> string
>>> literal content or a vertical line at the indentation boundary.
>>>
>>> In the meantime, this design *does* provide an unambiguous indicator of how
>>> much
>>> whitespace will be trimmed: however much is to the left of the closing
>>> delimiter.
>>> You just have to imagine the line extending upwards from there. I think
>>> that's an
>>> important thing to have.
>>>
>>> --
>>> 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
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
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
