These are my comments so far.
Regarding the use of _” and “_ : It works but I think the _ already has a
meaning elsewhere and may bring just a little bit of confusion at first. But
more than that, I’m not sure I like the way it looks aesthetically. I can’t
quite explain it. It is one character shorter than the triple quote, i.e. “””.
However, I wonder if other alternatives could work out better. For example,
here’s a couple:
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>"@
and with optional continuation quote it would look like this:
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>"@
Regarding the HEREDOC notation, all I can say is that it looks heavier. It may
be more flexible, but if @“”@ looks better (in my eyes) why would we want
another alternative. I would prefer to keep the one that looks better and
simpler.
> On May 10, 2016, at 2:53 AM, John Holdsworth via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> I’ve assembled a gist to summarise the main proposals of this thread.
>
> https://gist.github.com/johnno1962/5c325a16838ad3c73e0f109a514298bf
> <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
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
