[swift-evolution] [Review] SE-0182 - String Newline Escaping
Adrian Zubarev
adrian.zubarev at devandartist.com
Thu Jul 13 06:41:01 CDT 2017
Well even if my last pitch won’t happen it’s still would be possible to have trailing whitespaces in """ in it’s last line, the issue is that they aren’t visible. We do not want to bring that discussion back now, but we definitely will post Swift 4 release.
That said the backslash in the last line simply should do nothing but still be allowed. This won’t complicate anything nor would it do any harm.
—
About c:\ well in that case it might look like a bug but it isn’t because you should always keep in mind that \ as a character should be escaped as well, so it should be c:\\ anyways. If you than would want to break your line then you’ll end up with c:\\\ which might look ugly but it’s a consequence of using \ for our main purpose.
--
Adrian Zubarev
Sent with Airmail
On 13. July 2017 at 13:28:48, Vladimir.S (svabox at gmail.com) wrote:
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 (adrian.zubarev at devandartist.com
> <mailto:adrian.zubarev at devandartist.com>) 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
>> (swift-evolution at swift.org <mailto:swift-evolution at swift.org>) 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
>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
>>> > swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170713/682e5437/attachment.html>
More information about the swift-evolution
mailing list