> assert( xml != ei"""<?xml version="1.0"?>
> <catalog>
> <book id="bk101" empty="">
> <author>\(author)</author>
> <title>XML Developer's Guide</title>
> <genre>Computer</genre>
> <price>44.95</price>
> <publish_date>2000-10-01</publish_date>
> <description>An in-depth look at creating applications
> with XML.</description>
> </book>
> </catalog>
> """ )
The idea of auto-stripping whitespaces seemed nice initially, until I realized
it's not at all clear where the stripped whitespaces end and the included
whitespaces begin. It's already problematic for you own code (because even
knowing your own intent doesn't completely overcome the lack of perspective
this syntax offers), but imagine if it's someone else's. Will you be able to
figure out what spacing is meant to be a part of the string and which is not?
Quickly? Easily? Maybe, maybe not. It still won't be readily apparent, because
there's no point of reference. You're potentially reduced to counting
whitespaces to figure it out. Brent's proposal elegantly fixes this problem.
You have a clear point of reference, there's no issue of spaces vs tabs, no
trying to figure out exactly where the "true" whitespaces are beginning. Like
was mentioned, it would probably have to be relative to the leading whitespaces
on the closing delimiter line, but then there's no way to tell visually if
those are spaces or tabs, or how many there are, AND you have to sort of
mentally trace an invisible line upwards to "see" how the lines above relate.
This would drive me crazy. With leading quotes, it's obvious which lines don't
have included leading whitespaces, and the ones that do have a smaller relative
distance to what is the "left alignment margin" (so to speak) indicated by the
quotes.
This feels like we would be making it easier to make mistakes and harder to
determine actual spacing just to eliminate some extra quotes. I think the
proposal is the best balance of simplicity and practicality we're going to
achieve for *short* multi line strings, which is what this proposal is tying to
address. We can still introduce the """ or heredoc syntaxes for longer blocks
of text in the future.
Cole
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
