[swift-evolution] multi-line string literals.
John Holdsworth
mac at johnholdsworth.com
Tue May 10 01:53:53 CDT 2016
I’ve assembled a gist to summarise the main proposals of this thread.
https://gist.github.com/johnno1962/5c325a16838ad3c73e0f109a514298bf
At the moment there seem to be four proposals for multi-line strings:
1) Bent’s proposal for continuation quotes where if a conventional string
does not close, if the first non-whitespace character of the next line is “
(or perhaps |) the string is continued. This gives you precise control
over exactly what is in the string.
2) Tyler's original proposal involving strings that can contain newlines
delimited “””like this“”” as they are in python or, _”like this“_. This works
well in external editors and on github. Indentation is catered for by stripping
any whitespace before the closing quote from all lines in the string.
3) HEREDOC syntax <<“TAG” or <<‘TAG’ taken from languages like Perl
subject to the same indentation removal rules as “””strings””” above. This
has the advantage that the literal is clearly separated from your code.
4) Heck it all, why not all three syntaxes or some combination.
(There is a separate feature that all string literals can be prefixed by
e as in e”\w\d+” to turn of all escape processing for another day)
While the Swift Lexer could easily accommodate all these syntaxes there was
talk early on that Swift has more of a "one way, maximally elegant” ethos and
indeed I find it difficult imagine the Swift Book breathlessly describing all three
formats so I’m wondering if push came to shove which format people would chose?
My vote having undergone a "road to damascus" moment now we know it is
available sooner rather than later is.. HEREDOC! It’s well understood and
while at first it would seem to not be a good fit for Swift produces clear code.
Votes?
John
// Multi-line string proposals
// https://github.com/apple/swift/pull/2275 <https://github.com/apple/swift/pull/2275>
// swift-evolution thread:
// http://thread.gmane.org/gmane.comp.lang.swift.evolution/904/focus=15133 <http://thread.gmane.org/gmane.comp.lang.swift.evolution/904/focus=15133>
// These examples should load in the prototype toolchain available here:
// http://johnholdsworth.com/swift-LOCAL-2016-05-09-a-osx.tar.gz <http://johnholdsworth.com/swift-LOCAL-2016-05-09-a-osx.tar.gz>
// The prototype currently parses three new forms of quoting
// These new types are still string literals for the grammar.
"the existing string literal format"
_"a format that does not require you to escape " characters"_ // possibly redundant
"""a python-style syntax that will accept "'s and newlines in the string"""
<<"HEREDOC"
A full heredoc implementation (will always end in a newline)
HEREDOC
// These strings can be modified by prefixing the string by letters
// There is currently only one, "e" to disable escape processing.
// This is primarily used when specifying regular expressions.
let str = "print(\"Hello, world!\\n\")"
assert( e"print(\"Hello, world!\n\")" == str )
assert( e_"print("Hello, world!\n")"_ == str )
assert( e"""print("Hello, world!\n")""" == str )
// Continuation quotes allow you to extend a standard string literal
// over multiple lines. If a string does not close on a line and the
// first non-whitespace character on the next line is " that line
// will be a contination of the string including the newline character
// (unless it is escaped). Interpolation and escapes process as before
// unless the first segment of the string is modified by the "e" prefix.
// The advantage of this format allows you to indent while giving
// you precise control of exactly what is going into the literal.
let author = "Gambardella, Matthew"
let xml = "<?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>
""
print(xml)
// Perhaps, to avoid the zera crossing effect in text editors due to
// the unbalanced quotes, the continuation character could be "|".
// (newlines escaped with \ and blank lines are discarded.)
assert( xml == "\
|<?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>
|" )
// _""_ quoted strings also suppport these behaviours but don't require
// escaping of embedded " characters. Think of them as a being modifier
// on conventional string literals. They support continuation quotes.
assert( xml == _"<?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>\n"_ )
// _"strings"_ could allow newlines and replace """strings""" discussed next
assert( xml == _"<?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 triple quoted strings can contain newlines and, unless modified by "e"
// will process interpolations and not require escaping of ". To allow indenting,
// any whitespace characters that preceed the closing """ will be removed from
// each line of the final literal. A warning is shown if lines do not contain
// the exact same indentation characters. Any intial linefeed is also removed.
// The advantage of this format is the """ introducer works well when syntax
// highlighting in external editors and github as quotes are always balanced.
assert( xml == """
<?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>
""" )
assert( xml != e"""<?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>
""" )
// heredoc syntax comes in two variants <<"TAG" and <<'TAG' (non-escaping, "e" prefix)
// It applies the same indentation removal rules as does """. This change has wider
// ramifications for the toolchain as compiler tokens are no longer in file order
// and will take a while for a few problems to be ironed out. The more consistent
// <<e"TAG" is a rather clumsy alternative to <<'TAG' for non-escaping strings.
// HEREDOC's advantage is that the literal no longer interrupts the flow of your code.
assert( (<<"XML" + <<"XML") == xml + xml )
<?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>
XML
<?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>
XML
// For text you do not want to contain newlines, escape them using \
print( <<"LOREM" )
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt \
ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco \
laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in \
voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat \
non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.\
LOREM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160510/7b49fd11/attachment-0001.html>
More information about the swift-evolution
mailing list