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