> Am 12.04.2017 um 14:36 schrieb Ricardo Parada via swift-evolution
> <[email protected]>:
>
> 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
> <[email protected] <mailto:[email protected]>> 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
>> ([email protected] <mailto:[email protected]>)
>> 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
>>> ([email protected] <mailto:[email protected]>) 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
>>>> >> <[email protected] <mailto:[email protected]>
>>>> >> <mailto:[email protected] <mailto:[email protected]>>>:
>>>> >>
>>>> >> 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
>>>> >> ([email protected] <mailto:[email protected]>
>>>> >> <mailto:[email protected] <mailto:[email protected]>>)
>>>> >> schrieb:
>>>> >>
>>>> >>>
>>>> >>>> On Apr 11, 2017, at 8:08 AM, Adrian Zubarev via swift-evolution
>>>> >>>> <[email protected] <mailto:[email protected]>
>>>> >>>> <mailto:[email protected]
>>>> >>>> <mailto:[email protected]>>> 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
>>>> >> [email protected] <mailto:[email protected]>
>>>> >> <mailto:[email protected] <mailto:[email protected]>>
>>>> >> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > swift-evolution mailing list
>>>> > [email protected] <mailto:[email protected]>
>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> > <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> >
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
