On 13.07.2017 9:24, Adrian Zubarev via swift-evolution wrote:
> One more thing I wanted to add.
>
> I would remove the restriction of
>
> An escape character at the end of the last line of a literal is an error, as no
> newlines follow.
>
> from this proposal and allow the trailing backslash in the last line which won’t do
> harm to anything. The idea behind this is that one could annotate whitespaces in the
> last line:
>
> |""" My very long string<space>\ in Swift 👻<space><space><space>\ """ |
>
Support this opinion. Otherwise, how we can explicitly preserve whitespaces in last
line?
But in general, I wonder if this feature(newline escaping) can produce
hard-to-find
bugs. For example, currently we can't have such string:
let s = """
...
In Windows you have paths like C:\
...
"""
// invalid escape sequence in literal
but with newline escaping, it seems(am I correct?) we can have such string
without
any error/warning, and the result text will not be what author planned. Depend
on
where such string will be used(template/JSON/SQL/etc), this can lead to
not-obvious
hard to find bugs.
Probably, this should not be just '\' but real escape sequence like '\_' (you
can't
have it currently in string, so seems OK to introduce it for newline escaping).
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> On 13. July 2017 at 08:14:03, Adrian Zubarev ([email protected]
> <mailto:[email protected]>) wrote:
>
>> Can you please elaborate?
>>
>> —
>>
>> In general I, as one of the co-authors, am for this additional change. However,
>> personally I would be against adding the new line escaping feature to the single
>> double-quote string literal, because it will create asymmetry.
>>
>> For instance in a future proposal it’s likely we’d also allow the multi-line string
>> literal |"""| to be written in a single line without any new line escaping, for
>> strings that contain lots of double-quotes:
>>
>> |let myString1 = """{"id": "OpenNew", "label": "Open New"}""" // old and current
>> version let myString2 = "{\"id\": \"OpenNew\", \"label\": \"Open New\"}" |
>>
>> Considering that proposal would be accepted we’d have two ways to express the
>> multi-line string literal:
>>
>> |// horizontal """Swift""" // vertical """ Swift """ |
>>
>> Now about the previously mentioned asymmetry, if we’d accept in the current
>> proposal and include new line escaping in a single double-quoted string literal
>> eventually someone will find that again /inconsistent/ and ask to align
>> |"""|-literal to allow:
>>
>> |"""abc \ def""" // Symmetrical counterpart is from the current proposal "abc \
def" |
>>
>> However this model was completely abandoned by the previous proposal and should be
>> avoided at all cost even in the future, because it does not any value to the
>> expressiveness, but only complicates the model.
>>
>> —
>>
>> On the other hand if we’re really considering adding this to |"|-literal, then it
>> should be only possible if the |"|-literal gets a similar /vertical/ version like
>> the |"""|-literal.
>>
>> Notice that in that scenario:
>>
>> * we need borrow the indent mechanism from |"""|
>> * the trailing |\| can be omitted after the last character on the current
string line
>> * the trailing |\| is only used for annotate trailing whitespaces
(|"|-liteal
>> does not add implicit new lines at all, it’s always should stay explicit
about
>> everything)
>>
>> Something like that:
>>
>> |// #1 " a\ b\ " == "ab" // #1.1 " a b " == "ab" // #2 " a \ b \ " == "a b " // #3 "
>> c \ d \ " == " c d " |
>>
>> By now it should be clearly visible that this extension for the |"|-literal does
>> not add anything what the |"""|-literal cannot already solve nicely!
>>
>> That said, let’s keep it simple and only add the |\| to vertical
|"""|-literal.
>>
>>
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> On 13. July 2017 at 02:10:30, Taylor Swift via swift-evolution
>> ([email protected] <mailto:[email protected]>) wrote:
>>
>>> as is, this will mess up the “collapse” feature in most text editors,, it should
>>> not be added unless indentation removal is added too
>>>
>>> On Wed, Jul 12, 2017 at 7:48 PM, T.J. Usiyan via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> +1
>>>
>>> Maintaining parity between single and multi line strings is nice even
though
>>> breaking scope is a strong argument against actually using this with
single
>>> line literals.
>>>
>>> On Wed, Jul 12, 2017 at 7:15 PM, Timothy Wood via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>>
>>> +1 This seems great to me. It seems worth calling out how escaping
of
>>> backslashes and escaping of newlines interact for testing:
>>>
>>>
>>> let s = """
>>> line fragment ending in backslash \\\
>>> and
>>> line fragment ending in backslash \\\
>>> \\followed by line fragment starting with backslash
>>> """
>>>
>>> I would expect to get "line fragment ending in backslash \\and\nline
>>> fragment ending in backslash\\\\followed by line fragment starting
with
>>> backslash”, that is, escaped backslashes at the end of line
fragments
>>> should be retained, and whatever concatenates line fragments
shouldn’t
>>> accidentally double-interpret backslashes.
>>>
>>> Alternatively:
>>>
>>> let s = """
>>> line ending in backslash \\
>>> and
>>> line ending in backslash \\
>>> \\followed by line starting with backslash
>>> """
>>>
>>> seems like it should produce the result "line ending in backslash
>>> \\\nand\nline ending in backslash\\\n\\followed by line starting
with
>>> backslash”, that is, the consumption of escaped backslashes should
happen
>>> before considering if there is an extra backslash on the end of the
line
>>> for an escaped newline.
>>>
>>> -tim
>>>
>>>
>>>
>>> > On Jul 12, 2017, at 3:52 PM, Chris Lattner via swift-evolution
<[email protected] <mailto:[email protected]>> wrote:
>>> >
>>> > Hello Swift community,
>>> >
>>> > Context: As part of winding down work on Swift 4, we are
considering SE-0182 as a refinement to SE-0168. We are specifically not
>>> opening the floodgates for new proposals just yet, and it is not
>>> considered in scope to resyntax all of multi-line string literals.
We’re
>>> just discussing this one potential small-scope refinement to an
existing
>>> Swift 4 feature.
>>> >
>>> >
>>> > The review of "String Newline Escaping" begins now and runs
through July 17, 2017. The proposal is available here:
>>> >
https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md
>>>
<https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.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
>>> <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:
>>> >
>>> > 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?
>>> >
>>> > More information about the Swift evolution process is available
at:
>>> > https://github.com/apple/swift-evolution/blob/master/process.md
>>> <https://github.com/apple/swift-evolution/blob/master/process.md>
>>> >
>>> >
>>> > Thank you,
>>> >
>>> > Chris Lattner
>>> > Review Manager
>>> > _______________________________________________
>>> > 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
>
>
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
