On 12.04.2017 17:52, Thorsten Seitz via swift-evolution wrote:
Am 12.04.2017 um 15:40 schrieb Brent Royal-Gordon via swift-evolution
<[email protected]>:
Hey folks,
We've revised the proposal again. The main difference: You no longer need an
initial newline to enable indentation stripping, and stripping no longer
removes that newline even if it is present. (Adrian Zubarev and I believe some
others argued for this.) We
Hmm, not sure if I like these changes. I expect that almost all strings won't
begin with a newline and a majority won’t end with a newline. The new design
would require a leading backslash almost all the time and a trailing backslash
often, which is ugly:
let mystring = "““\
text text
text text\
"““
Agree with Thorsten. This is just ugly syntax for commonly used case.
Why not simple rule that content of multi-line string is all lines *between* leading
and trailing """ ? So, as was discussed, or you have single line """text""" or
multiline, where opening and closing """ should be on separate lines with text, and
text is lines strictly between.
Even more, I feel such solution will be more consistent, as trailing triple quotes
does not inject \n symbol -> so leading """ also should not inject it. In this case
""" is just a marker of start/end of multi-line string. Simple model, nice-looking
code for common cases, can tune emitting of \n symbol as you wish. No?
-Thorsten
disagreed with this at first, but it made more sense as we thought about it
more. There are a few things we like about it:
1. The rules and algorithm are simpler.
2. It accommodates more coding styles.
3. Every non-escaped newline in the literal now creates a corresponding
newline in the resulting string.
4. it's easy to get the old behavior back by backslashing the leading
newline.
Unfortunately, I think this precludes stripping the trailing newline by
default, but I think this is ultimately a simpler and better approach than the
previous draft.
Other changes:
* We realized we needed to make closing delimiter matching a little
more complicated if we wanted to allow one or two adjacent double-quote
characters that were part of the literal's contents. Oops.
* Tabs aren't actually allowed in ordinary string literals, so we now
explicitly mention that as a difference between the two types.
* We wrote some tests for the prototype (though they haven't been
updated for this new version yet).
* There were some other wording changes, particularly in the
indentation stripping rationale, but nothing that affects the actual design.
I understand John is working on a new version of his toolchain so people can
play with the prototype. We hope to have that ready for you all soon.
Let us know what you think of the revisions!
--
Brent Royal-Gordon
Architechies
_______________________________________________
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
