[swift-evolution] multi-line string literals.
Ricardo Parada
rparada at mac.com
Wed May 11 13:04:20 CDT 2016
> On May 11, 2016, at 12:55 PM, Vladimir.S <svabox at gmail.com> wrote:
>
>
> 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.
I don’t have a document. I’ve seen different proposals.
I have just been commenting on the proposals in this thread.
> 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)” ?
I cannot speak for them, but I think that if we want to get a feel about which alternatives get the most traction, I think all alternatives should be considered, including yours and mine. :-)
>>
>> 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.
>>
I don’t think we need to worry about the opening quote occurring in the text because we just need the closing delimiter to find out where it ends. For example:
let sourceCode = @“NSString *firstName = @“John”;
"NSString *lastName = @“Doe”;
“NSString *fullName = [NSString stringWithFormat: @“%@ %@“, firstName, lastName];"@
The one that would be a bit of a problem is the closing delimiter,
>
> 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
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160511/d4e898b5/attachment.html>
More information about the swift-evolution
mailing list