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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
