[swift-evolution] multi-line string literals.

Wed May 11 11:55:30 CDT 2016

On 11.05.2016 19:38, Ricardo Parada wrote:
> I did not suggest the single quote because it is commonly found in the
> English language and we would have to escape it.

Wel.. in your document you have a number of variants of multi-line 
'feature' implementations with different pros/cons for each.

Could you clarify, why this proposal with single quote can not be inside 
your document as just another variant with its own pros/cons ? Especially, 
as you can see, if "We'd rather save single quoted literals for a greater 
purpose (e.g. non-escaped string literals)" ?

>
> That is why I suggested a rare combination using the @" and "@ as the
> delimiters. Unless your text is Obj-C code it would be rare to find it.
>

And what do you suggest to do if we *have* `"@` inside the text we want to 
use ?

>
>
>> On May 11, 2016, at 10:50 AM, Vladimir.S via swift-evolution
>> <swift-evolution at swift.org> wrote:
>>
>> 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
>> _______________________________________________ swift-evolution
>> mailing list swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>