[swift-evolution] multi-line string literals.

[John Holdsworth]

> On 4 May 2016, at 15:07, L. Mihalkovic <laurent.mihalkovic at gmail.com> wrote:
> 
> Cool job!.. Yup, you proceed by "widening the existing holes" to carry the missing info (eg Modifiers). Making direct changes to lexCharacter() is a step I thought might be a bit premature considering nothing is carved in stone yet. I was trying to advocate for a clean boundary between current behavior and new ones, such that we, as well as others, would be able to try alternative syntaxes by changing the content of clearly identified methods (as opposed to starting their own integration from scratch each time, or having to un-unstitch parts of multiple already not so simple methods). I guess I am also extra cautious in my own coding because this a lexer, and the more paths through something like lexCharacter() or getEncodedStringSegment(), the more difficult it might be to prove that all of them have been identified and exercised. Thx for inspiring my experimentations.
> 

Thanks (I think!). I’m not trying to disenfranchise other developers by trying to squeeze all functionality into the existing functions.
It’s the nature of the problem. Multiline strings, alternative delimiter _””_ and non processing of escapes (\’s) are orthogonal;
they can in theory be applied separately and together. Wouldn’t that require 8 separate implementations dependent on
the combination? Far easier to just use modality. The code is getting unruly but not beyond the pale yet.

It’s just a prototype anyway intended to help with specification and testing. Better take a step back.

Did we get near to acquiescence to any of the following as a prospective proposal (as I understand it)?

	1) Any string literal that is it not closed becomes a multiline literal if the first non-whitespace character on the next line is “

        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>\n"
        print(xml)


While this is not ideal in terms of having to massage data templates as you paste them in, it is the price of code that looks
easy on the eye. (In practice pasting into Xcode it will reformat your string anyway so editing will normally be required.)
What will other editors make of this novel format?

Optionally, for a separate proposal perhaps:

	2) As a convenience, if a literal starts with _” it must be terminated by “_ to avoid having to escape embedded “s.

        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>
            ""_ )

	3) Opening the floodgates to an alphabet of the literal modifiers, if the string starts e”a string” then all escape sequences
	including interpolation but not including \” and \<newline> are not processed but passed through into the literal intact.

        assert( e"\w\d+\(author)\n" == "\\w\\d+\\(author)\\n" );

	These modifiers are smuggled through the parsing process to code generation by storing them against the Token.

Very Optionally, and largely as an historical accident

	4) an r”regex” string will pass through non-standard escapes but still process \0, \r, \n, \”, \’, \\, \u{NNNN} and \(

        assert( r"\w\d+\(author)\n" == "\\w\\d+\(author)\n" ); // handy if you ask me

Brent, what is the state of the proposal document you prepared?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160504/a741ba6d/attachment.html>