Optional dictionary subscripts

VladimirS · May 11, 2016, 2:50pm

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.

Multi-line String Zoo · GitHub

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
        // [Parse] Adjust Lexer to allow Multi-line string literals by johnno1962 · Pull Request #2275 · apple/swift · GitHub

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

rparada · May 11, 2016, 4:38pm

I did not suggest the single quote because it is commonly found in the English language and we would have to escape 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.

···

On May 11, 2016, at 10:50 AM, Vladimir.S via swift-evolution <swift-evolution@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.

Multi-line String Zoo · GitHub

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
       // [Parse] Adjust Lexer to allow Multi-line string literals by johnno1962 · Pull Request #2275 · apple/swift · GitHub

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

VladimirS · May 11, 2016, 4:55pm

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 ?

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.

Multi-line String Zoo · GitHub

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 //
[Parse] Adjust Lexer to allow Multi-line string literals by johnno1962 · Pull Request #2275 · apple/swift · GitHub

// swift-evolution thread: //
http://thread.gmane.org/gmane.comp.lang.swift.evolution/904/focus=15133

// These examples should load in the prototype toolchain available

···

On 11.05.2016 19:38, Ricardo Parada wrote:

On May 11, 2016, at 10:50 AM, Vladimir.S via swift-evolution >> <swift-evolution@swift.org> wrote:

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

_______________________________________________ swift-evolution
mailing list swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

DevAndArtist · April 3, 2017, 7:01am

Hello Swift community,

on Github there is a PR for this proposal, but I couldn’t find any up to date thread, so I’m going to start by replying to the last message I found, without the last content.

I really like where this proposal is going, and my personal preference are *continuation quotes*. However the proposed solution is still not perfect enough for me, because it still lacks of precise control about the trailing space characters in each line of a multi-line string.

Proposed version looks like this:

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>
    ""
I would like to pitch an enhancement to fix the last tiny part by adding the escaping character ‘' to the end of each line from 1 to (n - 1) of the n-lined string. This is similar to what Javascript allows us to do, except that we also have precise control about the leading space character through ’"’.

The proposed version will become this:

let xml = "<?xml version=\"1.0\"?>\
    "<catalog>\ // If you need you can comment here
    " <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>\
    ""
Here is another example:

let multilineString: String = "123__456__\ // indicates there is another part of the string on the next line
"__789_____\ // aways starts with `"` and ends with either `\` or `"`
"_____0_" // precise control about pre- and post-space-characters

let otherString = "\(someInstance)\ /* only comments are allowed in between */ "text \(someOtherInstance) text"
This is simply continuation quotes combined with backslash concatenation.

···

--
Adrian Zubarev
Sent with Airmail

rparada · May 11, 2016, 6:04pm

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,

···

On May 11, 2016, at 12:55 PM, Vladimir.S <svabox@gmail.com> wrote:
On 11.05.2016 19:38, Ricardo Parada wrote:

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@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.

Multi-line String Zoo · GitHub

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 //
[Parse] Adjust Lexer to allow Multi-line string literals by johnno1962 · Pull Request #2275 · apple/swift · GitHub

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

_______________________________________________ swift-evolution
mailing list swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

VladimirS · May 11, 2016, 6:34pm

Inline

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 ?

···

On 11.05.2016 21:04, Ricardo Parada wrote:

On May 11, 2016, at 12:55 PM, Vladimir.S <svabox@gmail.com >> <mailto:svabox@gmail.com>> wrote:
On 11.05.2016 19:38, Ricardo Parada wrote:

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@swift.org <mailto:swift-evolution@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.

Multi-line String Zoo · GitHub

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 //
[Parse] Adjust Lexer to allow Multi-line string literals by johnno1962 · Pull Request #2275 · apple/swift · GitHub

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

_______________________________________________ swift-evolution
mailing list swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

rparada · April 3, 2017, 2:00pm

What is the purpose of that backslash? It does not feel like an improvement.

I think we should focus on:

1. Looking pretty
2. Allow unescaped quote, double quote as well single/double apostrophe characters
3. Allow interpolation
4. No need to add the \n character for each line
5. It should have a continuation character
6. Keep it simple

Something like this:

let xml = M"<?xml version="1.0"?>
           "<catalog>
           " <book id="bk101" empty="">
           " <author>\(author)</author>
           " </book>
           "</catalog>
Or maybe this:

let xml = """<?xml version="1.0"?>
            "<catalog>
            " <book id="bk101" empty="">
            " <author>\(author)</author>
            " </book>
            "</catalog>
In the first example the multiline literal is started with M". In the second example it starts with three double quotes """. I really have no preference. In both examples there is no need to have a \ or \n at the end of the line.

You can have quote characters in the string, including double quotes as shown by empty="". You can have interpolation, i.e. \(author).

You have a continuation character which helps as a visual guide and as a marker for the beginning of each line.

The multi string literal ends when there are no more continuation characters.

···

On Apr 3, 2017, at 3:01 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

on Github there is a PR for this proposal, but I couldn’t find any up to date thread, so I’m going to start by replying to the last message I found, without the last content.

I really like where this proposal is going, and my personal preference are *continuation quotes*. However the proposed solution is still not perfect enough for me, because it still lacks of precise control about the trailing space characters in each line of a multi-line string.

Proposed version looks like this:

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>
    ""
I would like to pitch an enhancement to fix the last tiny part by adding the escaping character ‘' to the end of each line from 1 to (n - 1) of the n-lined string. This is similar to what Javascript allows us to do, except that we also have precise control about the leading space character through ’"’.

The proposed version will become this:

let xml = "<?xml version=\"1.0\"?>\
    "<catalog>\ // If you need you can comment here
    " <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>\
    ""
Here is another example:

let multilineString: String = "123__456__\ // indicates there is another part of the string on the next line
                              "__789_____\ // aways starts with `"` and ends with either `\` or `"`
                              "_____0_" // precise control about pre- and post-space-characters

let otherString = "\(someInstance)\ /* only comments are allowed in between */ "text \(someOtherInstance) text"
This is simply continuation quotes combined with backslash concatenation.

--
Adrian Zubarev
Sent with Airmail

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Charlie_Monroe1 · April 3, 2017, 8:48am

While I long for multiline string literals, I'd also very like to see a different syntax as in many cases, these can be XML/HTML snippets and the use of quotes is ubiqituous. I'd very much like to see a variant where you can simply paste almost any string without escaping it.

For example, Scala uses a tripple-quote syntax... As we've gotten rid of ' for character literals, we could use it for multiline strings?

Or possibly tripple-apostrophe for multiline strings?

let xml = '''
<?xml version="1.0"?>
<catalog/>
'''

···

On Apr 3, 2017, at 9:01 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

on Github there is a PR for this proposal, but I couldn’t find any up to date thread, so I’m going to start by replying to the last message I found, without the last content.

I really like where this proposal is going, and my personal preference are *continuation quotes*. However the proposed solution is still not perfect enough for me, because it still lacks of precise control about the trailing space characters in each line of a multi-line string.

Proposed version looks like this:

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>
    ""
I would like to pitch an enhancement to fix the last tiny part by adding the escaping character ‘' to the end of each line from 1 to (n - 1) of the n-lined string. This is similar to what Javascript allows us to do, except that we also have precise control about the leading space character through ’"’.

The proposed version will become this:

let xml = "<?xml version=\"1.0\"?>\
    "<catalog>\ // If you need you can comment here
    " <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>\
    ""
Here is another example:

let multilineString: String = "123__456__\ // indicates there is another part of the string on the next line
                              "__789_____\ // aways starts with `"` and ends with either `\` or `"`
                              "_____0_" // precise control about pre- and post-space-characters

let otherString = "\(someInstance)\ /* only comments are allowed in between */ "text \(someOtherInstance) text"
This is simply continuation quotes combined with backslash concatenation.

--
Adrian Zubarev
Sent with Airmail

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

rparada · May 12, 2016, 2:48am

Hi Vladimir,

I don't really have a solution. Perhaps escaping the closing delimiter like this \"@

It is not pretty but I can't think of anything else. I imagine the other alternatives, i.e. the triple quote `"""` and the quote plus underscore `"_ ` have the same problem.

If we make the continuation quote required then we don't need a closing delimiter. That would solve the problem. But I've seen several people say they don't like the continuation quote because they want to be able to paste text and not have to worry much about formatting it afterwards.

···

On May 11, 2016, at 2:34 PM, Vladimir.S <svabox@gmail.com> wrote:

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 ?

DevAndArtist · April 3, 2017, 9:06am

My main concern with this approach is that you don’t have any control about indent and you loose pre- and post spacing characters.

A concatenating approach is a little tedious but it’s precise. In any situation a multi-lined string is not softly wrapped string, which implies that you will have to press enter for each new line you wish to have. IMHO adding two more characters for each line isn’t that harmful. ;-)

···

--
Adrian Zubarev
Sent with Airmail

Am 3. April 2017 um 10:49:02, Charlie Monroe (charlie@charliemonroe.net) schrieb:

While I long for multiline string literals, I'd also very like to see a different syntax as in many cases, these can be XML/HTML snippets and the use of quotes is ubiqituous. I'd very much like to see a variant where you can simply paste almost any string without escaping it.

For example, Scala uses a tripple-quote syntax... As we've gotten rid of ' for character literals, we could use it for multiline strings?

Or possibly tripple-apostrophe for multiline strings?

let xml = '''
<?xml version="1.0"?>
<catalog/>
'''

On Apr 3, 2017, at 9:01 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

on Github there is a PR for this proposal, but I couldn’t find any up to date thread, so I’m going to start by replying to the last message I found, without the last content.

I really like where this proposal is going, and my personal preference are *continuation quotes*. However the proposed solution is still not perfect enough for me, because it still lacks of precise control about the trailing space characters in each line of a multi-line string.

Proposed version looks like this:

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>
    ""
I would like to pitch an enhancement to fix the last tiny part by adding the escaping character ‘' to the end of each line from 1 to (n - 1) of the n-lined string. This is similar to what Javascript allows us to do, except that we also have precise control about the leading space character through ’"’.

The proposed version will become this:

let xml = "<?xml version=\"1.0\"?>\
    "<catalog>\ // If you need you can comment here
    " <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>\
    ""
Here is another example:

let multilineString: String = "123__456__\ // indicates there is another part of the string on the next line
"__789_____\ // aways starts with `"` and ends with either `\` or `"`
"_____0_" // precise control about pre- and post-space-characters

let otherString = "\(someInstance)\ /* only comments are allowed in between */ "text \(someOtherInstance) text"
This is simply continuation quotes combined with backslash concatenation.

--
Adrian Zubarev
Sent with Airmail

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

DevAndArtist · April 3, 2017, 2:23pm

At quick glance I disagree with (4). If your current string would contain something like "\n\n" would you really use another empty line with a single unescaped quote? If you’re not, you’ll end up adding a single \n, but that on the other than would be strange if you add it at the end of the line.

Multi-lined strings should not be abused for adding new lines to the string itself, however I’m fine with allowing single quotes without escaping them.

If we’d really go that path then I still could not format some really long hardcoded text for code readability in a multi lined string, just because of the fact that it will alter my original string by automatically adding new line characters.

let veryLongString1 = "word word word … word word word"

let veryLongString2 = """word word word
    word word word
    …
    word word word
    word word word"""

// Logically that string should be the same, however during the
// automatic new lines we'll get this

veryLongString1 == veryLongString2 // => false
What has the multi lined string solved here? Nothing.

···

--
Adrian Zubarev
Sent with Airmail

Am 3. April 2017 um 16:00:53, Ricardo Parada (rparada@mac.com) schrieb:

What is the purpose of that backslash? It does not feel like an improvement.

I think we should focus on:

1. Looking pretty
2. Allow unescaped quote, double quote as well single/double apostrophe characters
3. Allow interpolation
4. No need to add the \n character for each line
5. It should have a continuation character
6. Keep it simple

Something like this:

let xml = M"<?xml version="1.0"?>
           "<catalog>
           " <book id="bk101" empty="">
           " <author>\(author)</author>
           " </book>
           "</catalog>
Or maybe this:

let xml = """<?xml version="1.0"?>
            "<catalog>
            " <book id="bk101" empty="">
            " <author>\(author)</author>
            " </book>
            "</catalog>
In the first example the multiline literal is started with M". In the second example it starts with three double quotes """. I really have no preference. In both examples there is no need to have a \ or \n at the end of the line.

You can have quote characters in the string, including double quotes as shown by empty="". You can have interpolation, i.e. \(author).

You have a continuation character which helps as a visual guide and as a marker for the beginning of each line.

The multi string literal ends when there are no more continuation characters.

On Apr 3, 2017, at 3:01 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

on Github there is a PR for this proposal, but I couldn’t find any up to date thread, so I’m going to start by replying to the last message I found, without the last content.

I really like where this proposal is going, and my personal preference are *continuation quotes*. However the proposed solution is still not perfect enough for me, because it still lacks of precise control about the trailing space characters in each line of a multi-line string.

Proposed version looks like this:

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>
    ""
I would like to pitch an enhancement to fix the last tiny part by adding the escaping character ‘' to the end of each line from 1 to (n - 1) of the n-lined string. This is similar to what Javascript allows us to do, except that we also have precise control about the leading space character through ’"’.

The proposed version will become this:

let xml = "<?xml version=\"1.0\"?>\
    "<catalog>\ // If you need you can comment here
    " <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>\
    ""
Here is another example:

let multilineString: String = "123__456__\ // indicates there is another part of the string on the next line
"__789_____\ // aways starts with `"` and ends with either `\` or `"`
"_____0_" // precise control about pre- and post-space-characters

let otherString = "\(someInstance)\ /* only comments are allowed in between */ "text \(someOtherInstance) text"
This is simply continuation quotes combined with backslash concatenation.

--
Adrian Zubarev
Sent with Airmail

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

cloutiertyler · April 21, 2017, 9:17am

I am very much a fan of this type of thing.

It's very clear that new line are included in the string. Leading white space is explicit. It is easy to align. It's easy to copy and paste. And there isn't excessive escaping.

···

On Apr 3, 2017, at 7:00 AM, Ricardo Parada via swift-evolution <swift-evolution@swift.org> wrote:

What is the purpose of that backslash? It does not feel like an improvement.

I think we should focus on:

1. Looking pretty
2. Allow unescaped quote, double quote as well single/double apostrophe characters
3. Allow interpolation
4. No need to add the \n character for each line
5. It should have a continuation character
6. Keep it simple

Something like this:

let xml = M"<?xml version="1.0"?>
           "<catalog>
           " <book id="bk101" empty="">
           " <author>\(author)</author>
           " </book>
           "</catalog>
Or maybe this:

let xml = """<?xml version="1.0"?>
            "<catalog>
            " <book id="bk101" empty="">
            " <author>\(author)</author>
            " </book>
            "</catalog>
In the first example the multiline literal is started with M". In the second example it starts with three double quotes """. I really have no preference. In both examples there is no need to have a \ or \n at the end of the line.

You can have quote characters in the string, including double quotes as shown by empty="". You can have interpolation, i.e. \(author).

You have a continuation character which helps as a visual guide and as a marker for the beginning of each line.

The multi string literal ends when there are no more continuation characters.

On Apr 3, 2017, at 3:01 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

on Github there is a PR for this proposal, but I couldn’t find any up to date thread, so I’m going to start by replying to the last message I found, without the last content.

I really like where this proposal is going, and my personal preference are *continuation quotes*. However the proposed solution is still not perfect enough for me, because it still lacks of precise control about the trailing space characters in each line of a multi-line string.

Proposed version looks like this:

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>
    ""
I would like to pitch an enhancement to fix the last tiny part by adding the escaping character ‘' to the end of each line from 1 to (n - 1) of the n-lined string. This is similar to what Javascript allows us to do, except that we also have precise control about the leading space character through ’"’.

The proposed version will become this:

let xml = "<?xml version=\"1.0\"?>\
    "<catalog>\ // If you need you can comment here
    " <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>\
    ""
Here is another example:

let multilineString: String = "123__456__\ // indicates there is another part of the string on the next line
                              "__789_____\ // aways starts with `"` and ends with either `\` or `"`
                              "_____0_" // precise control about pre- and post-space-characters

let otherString = "\(someInstance)\ /* only comments are allowed in between */ "text \(someOtherInstance) text"
This is simply continuation quotes combined with backslash concatenation.

--
Adrian Zubarev
Sent with Airmail

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Eduardo_Mourey_Lopez · May 12, 2016, 4:05am

Something like this might work

//string ends on the first line that doesnt start with a "
foo( @"<?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
    )

//additionally using a +" could be used to indicate a line break
foo( @"<?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
    )

···

On May 11, 2016, at 9:48 PM, Ricardo Parada via swift-evolution <swift-evolution@swift.org> wrote:

On May 11, 2016, at 2:34 PM, Vladimir.S <svabox@gmail.com> wrote:

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 ?

Hi Vladimir,

I don't really have a solution. Perhaps escaping the closing delimiter like this \"@

It is not pretty but I can't think of anything else. I imagine the other alternatives, i.e. the triple quote `"""` and the quote plus underscore `"_ ` have the same problem.

If we make the continuation quote required then we don't need a closing delimiter. That would solve the problem. But I've seen several people say they don't like the continuation quote because they want to be able to paste text and not have to worry much about formatting it afterwards.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

rparada · April 3, 2017, 2:29pm

I think we should focus on taking care of 99% of the cases. If you have a very long string then you use the good old fashioned string literal concatenation:

Let veryLongString2 = "word word word"
+ "word word word"
+ "word word word"

By the way, the multi-line string should allow \n\n, or as many as you may want to throw in there. I don't see a problem with that.

···

On Apr 3, 2017, at 10:23 AM, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:

At quick glance I disagree with (4). If your current string would contain something like "\n\n" would you really use another empty line with a single unescaped quote? If you’re not, you’ll end up adding a single \n, but that on the other than would be strange if you add it at the end of the line.

Multi-lined strings should not be abused for adding new lines to the string itself, however I’m fine with allowing single quotes without escaping them.

If we’d really go that path then I still could not format some really long hardcoded text for code readability in a multi lined string, just because of the fact that it will alter my original string by automatically adding new line characters.

let veryLongString1 = "word word word … word word word"

let veryLongString2 = """word word word
    word word word
    …
    word word word
    word word word"""

// Logically that string should be the same, however during the
// automatic new lines we'll get this

veryLongString1 == veryLongString2 // => false
What has the multi lined string solved here? Nothing.

--
Adrian Zubarev
Sent with Airmail

Am 3. April 2017 um 16:00:53, Ricardo Parada (rparada@mac.com <mailto:rparada@mac.com>) schrieb:

What is the purpose of that backslash? It does not feel like an improvement.

I think we should focus on:

1. Looking pretty
2. Allow unescaped quote, double quote as well single/double apostrophe characters
3. Allow interpolation
4. No need to add the \n character for each line
5. It should have a continuation character
6. Keep it simple

Something like this:

let xml = M"<?xml version="1.0"?>
           "<catalog>
           " <book id="bk101" empty="">
           " <author>\(author)</author>
           " </book>
           "</catalog>
Or maybe this:

let xml = """<?xml version="1.0"?>
            "<catalog>
            " <book id="bk101" empty="">
            " <author>\(author)</author>
            " </book>
            "</catalog>
In the first example the multiline literal is started with M". In the second example it starts with three double quotes """. I really have no preference. In both examples there is no need to have a \ or \n at the end of the line.

You can have quote characters in the string, including double quotes as shown by empty="". You can have interpolation, i.e. \(author).

You have a continuation character which helps as a visual guide and as a marker for the beginning of each line.

The multi string literal ends when there are no more continuation characters.

On Apr 3, 2017, at 3:01 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello Swift community,

on Github there is a PR for this proposal, but I couldn’t find any up to date thread, so I’m going to start by replying to the last message I found, without the last content.

I really like where this proposal is going, and my personal preference are *continuation quotes*. However the proposed solution is still not perfect enough for me, because it still lacks of precise control about the trailing space characters in each line of a multi-line string.

Proposed version looks like this:

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>
    ""
I would like to pitch an enhancement to fix the last tiny part by adding the escaping character ‘' to the end of each line from 1 to (n - 1) of the n-lined string. This is similar to what Javascript allows us to do, except that we also have precise control about the leading space character through ’"’.

The proposed version will become this:

let xml = "<?xml version=\"1.0\"?>\
    "<catalog>\ // If you need you can comment here
    " <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>\
    ""
Here is another example:

let multilineString: String = "123__456__\ // indicates there is another part of the string on the next line
                              "__789_____\ // aways starts with `"` and ends with either `\` or `"`
                              "_____0_" // precise control about pre- and post-space-characters

let otherString = "\(someInstance)\ /* only comments are allowed in between */ "text \(someOtherInstance) text"
This is simply continuation quotes combined with backslash concatenation.

--
Adrian Zubarev
Sent with Airmail

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

rparada · April 3, 2017, 2:32pm

Actually, it would be like this:

let veryLongString2 = "word word word" +
"word word word" +
"word word word"

···

On Apr 3, 2017, at 10:29 AM, Ricardo Parada via swift-evolution <swift-evolution@swift.org> wrote:

I think we should focus on taking care of 99% of the cases. If you have a very long string then you use the good old fashioned string literal concatenation:

Let veryLongString2 = "word word word"
  + "word word word"
   + "word word word"

By the way, the multi-line string should allow \n\n, or as many as you may want to throw in there. I don't see a problem with that.

On Apr 3, 2017, at 10:23 AM, Adrian Zubarev <adrian.zubarev@devandartist.com <mailto:adrian.zubarev@devandartist.com>> wrote:

At quick glance I disagree with (4). If your current string would contain something like "\n\n" would you really use another empty line with a single unescaped quote? If you’re not, you’ll end up adding a single \n, but that on the other than would be strange if you add it at the end of the line.

Multi-lined strings should not be abused for adding new lines to the string itself, however I’m fine with allowing single quotes without escaping them.

If we’d really go that path then I still could not format some really long hardcoded text for code readability in a multi lined string, just because of the fact that it will alter my original string by automatically adding new line characters.

let veryLongString1 = "word word word … word word word"

let veryLongString2 = """word word word
    word word word
    …
    word word word
    word word word"""

// Logically that string should be the same, however during the
// automatic new lines we'll get this

veryLongString1 == veryLongString2 // => false
What has the multi lined string solved here? Nothing.

--
Adrian Zubarev
Sent with Airmail

Am 3. April 2017 um 16:00:53, Ricardo Parada (rparada@mac.com <mailto:rparada@mac.com>) schrieb:

What is the purpose of that backslash? It does not feel like an improvement.

I think we should focus on:

1. Looking pretty
2. Allow unescaped quote, double quote as well single/double apostrophe characters
3. Allow interpolation
4. No need to add the \n character for each line
5. It should have a continuation character
6. Keep it simple

Something like this:

let xml = M"<?xml version="1.0"?>
           "<catalog>
           " <book id="bk101" empty="">
           " <author>\(author)</author>
           " </book>
           "</catalog>
Or maybe this:

let xml = """<?xml version="1.0"?>
            "<catalog>
            " <book id="bk101" empty="">
            " <author>\(author)</author>
            " </book>
            "</catalog>
In the first example the multiline literal is started with M". In the second example it starts with three double quotes """. I really have no preference. In both examples there is no need to have a \ or \n at the end of the line.

You can have quote characters in the string, including double quotes as shown by empty="". You can have interpolation, i.e. \(author).

You have a continuation character which helps as a visual guide and as a marker for the beginning of each line.

The multi string literal ends when there are no more continuation characters.

On Apr 3, 2017, at 3:01 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello Swift community,

on Github there is a PR for this proposal, but I couldn’t find any up to date thread, so I’m going to start by replying to the last message I found, without the last content.

I really like where this proposal is going, and my personal preference are *continuation quotes*. However the proposed solution is still not perfect enough for me, because it still lacks of precise control about the trailing space characters in each line of a multi-line string.

Proposed version looks like this:

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>
    ""
I would like to pitch an enhancement to fix the last tiny part by adding the escaping character ‘' to the end of each line from 1 to (n - 1) of the n-lined string. This is similar to what Javascript allows us to do, except that we also have precise control about the leading space character through ’"’.

The proposed version will become this:

let xml = "<?xml version=\"1.0\"?>\
    "<catalog>\ // If you need you can comment here
    " <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>\
    ""
Here is another example:

let multilineString: String = "123__456__\ // indicates there is another part of the string on the next line
                              "__789_____\ // aways starts with `"` and ends with either `\` or `"`
                              "_____0_" // precise control about pre- and post-space-characters

let otherString = "\(someInstance)\ /* only comments are allowed in between */ "text \(someOtherInstance) text"
This is simply continuation quotes combined with backslash concatenation.

--
Adrian Zubarev
Sent with Airmail

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Charlie_Monroe1 · April 3, 2017, 9:16am

You can. I wish I remembered the language this was in (not sure if it's in Scala), but you can do something like:

let xml = '''
    ><?xml version="1.0"?>
    ><catalog>
    > <...>
    ></catalog>
    '''

This way, if you care about the leading whitespace, you define the line beginning using "|".

Two characters aren't harmful, but in my experience when working with HTML strings, etc. the quote-escaping is extremely tedious.

···

On Apr 3, 2017, at 11:06 AM, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:

My main concern with this approach is that you don’t have any control about indent and you loose pre- and post spacing characters.

A concatenating approach is a little tedious but it’s precise. In any situation a multi-lined string is not softly wrapped string, which implies that you will have to press enter for each new line you wish to have. IMHO adding two more characters for each line isn’t that harmful. ;-)

--
Adrian Zubarev
Sent with Airmail

Am 3. April 2017 um 10:49:02, Charlie Monroe (charlie@charliemonroe.net <mailto:charlie@charliemonroe.net>) schrieb:

While I long for multiline string literals, I'd also very like to see a different syntax as in many cases, these can be XML/HTML snippets and the use of quotes is ubiqituous. I'd very much like to see a variant where you can simply paste almost any string without escaping it.

For example, Scala uses a tripple-quote syntax... As we've gotten rid of ' for character literals, we could use it for multiline strings?

Or possibly tripple-apostrophe for multiline strings?

let xml = '''
<?xml version="1.0"?>
<catalog/>
'''

On Apr 3, 2017, at 9:01 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello Swift community,

on Github there is a PR for this proposal, but I couldn’t find any up to date thread, so I’m going to start by replying to the last message I found, without the last content.

I really like where this proposal is going, and my personal preference are *continuation quotes*. However the proposed solution is still not perfect enough for me, because it still lacks of precise control about the trailing space characters in each line of a multi-line string.

Proposed version looks like this:

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>
    ""
I would like to pitch an enhancement to fix the last tiny part by adding the escaping character ‘' to the end of each line from 1 to (n - 1) of the n-lined string. This is similar to what Javascript allows us to do, except that we also have precise control about the leading space character through ’"’.

The proposed version will become this:

let xml = "<?xml version=\"1.0\"?>\
    "<catalog>\ // If you need you can comment here
    " <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>\
    ""
Here is another example:

let multilineString: String = "123__456__\ // indicates there is another part of the string on the next line
                              "__789_____\ // aways starts with `"` and ends with either `\` or `"`
                              "_____0_" // precise control about pre- and post-space-characters

let otherString = "\(someInstance)\ /* only comments are allowed in between */ "text \(someOtherInstance) text"
This is simply continuation quotes combined with backslash concatenation.

--
Adrian Zubarev
Sent with Airmail

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

DevAndArtist · April 3, 2017, 2:40pm

What I was trying to say is that by automatically adding a new line character does not provide any benefit except of being lazy to type \n.

// In your model this would be equivalent
let s1 = "\n\n\n"
let s2 = """
    " // However in my model this is an empty string and should be banned
    "
    """ // That's also an empty string, but it that case it indicates the end of the multi lined string
I dislike the tradeoff of precision for laziness.

···

--
Adrian Zubarev
Sent with Airmail

Am 3. April 2017 um 16:29:44, Ricardo Parada (rparada@mac.com) schrieb:

By the way, the multi-line string should allow \n\n, or as many as you may want to throw in there. I don't see a problem with that.

DevAndArtist · April 3, 2017, 2:44pm

IMHO this is what multi-lined strings are meant for in first place, for better code readability without precision tradeoffs. You’re not expecting multi-lined chained methods to do something else as they’re meant for. We’re allowing multi lines there for readability not for more functionality.

That’s why I disagree that multi-line strings should add new lines automatically to the string.

···

--
Adrian Zubarev
Sent with Airmail

Am 3. April 2017 um 16:33:05, Ricardo Parada (rparada@mac.com) schrieb:

let veryLongString2 = "word word word" +
"word word word" +
"word word word"

DevAndArtist · April 21, 2017, 9:57am

Hi Tyler,

You’re a bit late indeed. The proposal got accepted with some modifications.

No single line expression (for now).
The last string content line does not add an implicit new line to the resulting string.
Text is always in lines (content lines) between the delimiter lines, but never directly after or before the delimiters.
The indent and stripping is solved by calculating the indent prefix for the closing delimiter, mismatch in content lines results in an error.
Trailing backslash is not included and can be proposed as an additional feature later.
It’s not yet clear if the final version will warn about trailing whitespaces (I’d prefer that). Otherwise the following example could have 1000 characters and no one will ever guess it correctly.
"""
Foo<space><space>…<space>
"""
That last issue can be solved nicely by a trailing backslash as well, because it makes the trailing whitespace boundary visible like the closing delimiter makes it visible for leading whitespaces. And at the same time it would allow us to escape the new line injection when it’s desired.

The concatenation is a no go for my issue. I always used small strings to showcase the problem, but in reality the string I was speaking about could be very long similar to this example: long-string.swift · GitHub

That’s why I pursue the addition of the trailing backslash.

···

--
Adrian Zubarev
Sent with Airmail

Am 21. April 2017 um 11:17:19, Tyler Cloutier (cloutiertyler@aol.com) schrieb:

I am very much a fan of this type of thing.

It's very clear that new line are included in the string. Leading white space is explicit. It is easy to align. It's easy to copy and paste. And there isn't excessive escaping.

On Apr 3, 2017, at 7:00 AM, Ricardo Parada via swift-evolution <swift-evolution@swift.org> wrote:

What is the purpose of that backslash? It does not feel like an improvement.

I think we should focus on:

1. Looking pretty
2. Allow unescaped quote, double quote as well single/double apostrophe characters
3. Allow interpolation
4. No need to add the \n character for each line
5. It should have a continuation character
6. Keep it simple

Something like this:

let xml = M"<?xml version="1.0"?>
           "<catalog>
           " <book id="bk101" empty="">
           " <author>\(author)</author>
           " </book>
           "</catalog>
Or maybe this:

let xml = """<?xml version="1.0"?>
            "<catalog>
            " <book id="bk101" empty="">
            " <author>\(author)</author>
            " </book>
            "</catalog>
In the first example the multiline literal is started with M". In the second example it starts with three double quotes """. I really have no preference. In both examples there is no need to have a \ or \n at the end of the line.

You can have quote characters in the string, including double quotes as shown by empty="". You can have interpolation, i.e. \(author).

You have a continuation character which helps as a visual guide and as a marker for the beginning of each line.

The multi string literal ends when there are no more continuation characters.

On Apr 3, 2017, at 3:01 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

on Github there is a PR for this proposal, but I couldn’t find any up to date thread, so I’m going to start by replying to the last message I found, without the last content.

I really like where this proposal is going, and my personal preference are *continuation quotes*. However the proposed solution is still not perfect enough for me, because it still lacks of precise control about the trailing space characters in each line of a multi-line string.

Proposed version looks like this:

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>
    ""
I would like to pitch an enhancement to fix the last tiny part by adding the escaping character ‘' to the end of each line from 1 to (n - 1) of the n-lined string. This is similar to what Javascript allows us to do, except that we also have precise control about the leading space character through ’"’.

The proposed version will become this:

let xml = "<?xml version=\"1.0\"?>\
    "<catalog>\ // If you need you can comment here
    " <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>\
    ""
Here is another example:

let multilineString: String = "123__456__\ // indicates there is another part of the string on the next line
"__789_____\ // aways starts with `"` and ends with either `\` or `"`
"_____0_" // precise control about pre- and post-space-characters

let otherString = "\(someInstance)\ /* only comments are allowed in between */ "text \(someOtherInstance) text"
This is simply continuation quotes combined with backslash concatenation.

--
Adrian Zubarev
Sent with Airmail

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Lmpessoa · May 12, 2016, 4:36pm

I'm not in favour of multiline strings. I believe such strings should be
stored in plain files and loaded as needed. It makes both the code and the
string cleaner to read and maintain. I've had experiences with many
languages that offer that resource and I could see what your code can
become in terms of maintainability when you have such feature on the
language.

-1 from me.

- Leonardo

···

On 12 May 2016 at 01:05, Eduardo Mourey Lopez Ne via swift-evolution < swift-evolution@swift.org> wrote:

Something like this might work

//string ends on the first line that doesnt start with a "
foo( @"<?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
    )

//additionally using a +" could be used to indicate a line break
foo( @"<?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
    )

On May 11, 2016, at 9:48 PM, Ricardo Parada via swift-evolution < > swift-evolution@swift.org> wrote:

On May 11, 2016, at 2:34 PM, Vladimir.S <svabox@gmail.com> wrote:

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 ?

Hi Vladimir,

I don't really have a solution. Perhaps escaping the closing delimiter
like this \"@

It is not pretty but I can't think of anything else. I imagine the other
alternatives, i.e. the triple quote `"""` and the quote plus underscore
`"_ ` have the same problem.

If we make the continuation quote required then we don't need a closing
delimiter. That would solve the problem. But I've seen several people say
they don't like the continuation quote because they want to be able to
paste text and not have to worry much about formatting it afterwards.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution