[swift-evolution] multi-line string literals.

Wed May 11 13:34:27 CDT 2016

Inline

On 11.05.2016 21:04, Ricardo Parada wrote:
>
>> On May 11, 2016, at 12:55 PM, Vladimir.S <svabox at gmail.com
>> <mailto: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.

Oh, sorry :-) Will check the initial sender more carefully the next time.

>
>> 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.  :-)

Got it :-)

>
>>>
>>> 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:
>
>
> letsourceCode =@“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,

Yes.. this is why I asked about `"@` - closing delimiter
so.. what is the solution in your case ?

>
>
>>
>> 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 <mailto: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 <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>