[swift-evolution] multi-line string literals.

Vladimir.S svabox at gmail.com
Wed May 11 09:50:17 CDT 2016


Did I miss the proposal for single quote?

Just found on 
https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md
 >---------------------<
Single-quotes '' for Character literals: Swift takes the approach of highly 
valuing Unicode. However, there are multiple concepts of a character that 
could make sense in Unicode, and none is so much more commonly used than 
the others that it makes sense to privilege them. We'd rather save single 
quoted literals for a greater purpose (e.g. non-escaped string literals).
 >---------------------<

So, what about using of single quote as "special" strings?

For example, I'd propose to use single quote quotation to say "this string 
should be used as-is, no escapes processing"

'some 1\total\\2\\\3 "sdfsdf" \(-: """ helllooo'

the only 'disallowed' symbol could be the single quote itself, but I 
propose the solution used in other languages - duplicate it if we need it 
in string:

'this '' is a single quote in string, and this is another'''

and also in multiline strings:

assert( xml == '<?xml version="1.0"?>
	'<catalog>
	'	<book id="bk101" empty="">
	'		<author>\(author)</author>
	// note '' here in string
	'		<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 XML.</description>
	'	</book>
	'</catalog>')

(also needs to duplicate single quote if in text. the compromise, yes.)

On 10.05.2016 9:53, John Holdsworth via swift-evolution wrote:
> 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
>
>         // swift-evolution thread:
>         //
> 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
>
>         // 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.
>
>         letstr = "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.
>
>         letauthor = "Gambardella, Matthew"
>
>         letxml = "<?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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>


More information about the swift-evolution mailing list