Actually this would be inconsistent. The lines in between the delimiters should
always add an implicit new line if not told otherwise with a backslash. If that
wouldn’t be the case than you won’t have any precision in the last line you
have there.
Assume you want to concatenate this string:
foo
bar baz
To do so you’d need extra spaces in your " baz" string, because of the
inconsistency. However the constant version I’m suggesting is more precise.
let myString = """
foo
bar \
"""
print(myString + "baz")
The last implicit new line which one would need to escape is a model artifact,
but it’s consistent that way.
The extra new line one would ever need to add manually would be only at the top
of a multi-line string.
// v1:
"""
foo
bar\
"""
// v2:
"""
\n\
foo
bar\
"""
// v3:
"""
\nfoo
bar\
"""
--
Adrian Zubarev
Sent with Airmail
Am 12. April 2017 um 19:41:14, Ricardo Parada via swift-evolution
([email protected]) schrieb:
Hi all,
I agree as well, I think we should make optimize for the most common case of
multi-line strings. A rule that says strip the first leading newline as well
as the trailing newline. So it's almost back to where Brent started with the
addition of removing the trailing newline.
Borrowing Adrian's example, I could just have this:
let myReallyLongXMLConstantName = """
<?xml version="1.0"?>
<catalog>
<book id="bk101" empty="">
<author>John Doe</author>
<title>XML Developer's Guide</title>
<genre>Computer</genre>
<price>44.95</price>
</book>
</catalog>
"""
If somebody wants the last line to include a newline at the end, they can just
add a \n at the end or an empty line.
So if I do this:
print(myReallyLongXMLConstantName)
print("Text right below")
It would output this:
<?xml version="1.0"?>
<catalog>
<book id="bk101" empty="">
<author>John Doe</author>
<title>XML Developer's Guide</title>
<genre>Computer</genre>
<price>44.95</price>
</book>
</catalog>
Test right below
Without removing the trailing newline then it would print like this:
<?xml version="1.0"?>
<catalog>
<book id="bk101" empty="">
<author>John Doe</author>
<title>XML Developer's Guide</title>
<genre>Computer</genre>
<price>44.95</price>
</book>
</catalog>
Test right below
On Apr 12, 2017, at 12:48 PM, Xiaodi Wu via swift-evolution
<[email protected]> wrote:
Agree. I prefer the new rules over the old, but considering common use cases,
stripping the leading and trailing newline makes for a more pleasant experience
than not stripping either of them.
I think that is generally worth prioritizing over a simpler algorithm or even
accommodating more styles. Moreover, a user who wants a trailing or leading
newline merely types an extra one if there is newline stripping, so no use
cases are made difficult, only a very common one is made more ergonomic.
On Wed, Apr 12, 2017 at 09:52 Thorsten Seitz via swift-evolution
<[email protected]> 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\
"““
-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
_______________________________________________
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
