[swift-evolution] [Review] SE-0182 - String Newline Escaping
Vladimir.S
svabox at gmail.com
Thu Jul 13 09:00:13 CDT 2017
On 13.07.2017 14:41, Adrian Zubarev wrote:
> 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.
Yes, if one's editor will not drop trailing spaces in source lines. The feature can't
rely on belief that editor will not delete trailing spaces in source lines during the
save operation. Especially, if the same source file can be edited by different
devs/editors.
>
> 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.
>
Again, currently Swift prevents you from this mistake. You can't just write
"""
...
c:\
...
"""
(and also can't write incorrect escape sequence like "\!")
"ERROR at line x, col xx: invalid escape sequence in literal"
With new feature of newline escaping with backslash - Swift will not help you in this
particular case. Given that multiline strings help to copy&paste text into source -
such cases are possible.
Yes, I don't think this case is very important, and editor can show that backslash
with different color, but it shows that suggested solution can, in some cases,
produce problems that were not possible before. So just wanted to discuss.
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> On 13. July 2017 at 13:28:48, Vladimir.S (svabox at gmail.com <mailto: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
>> >
>
More information about the swift-evolution
mailing list