Re: [swift-evolution] multi-line string literals.

[Adrian Zubarev via swift-evolution]

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…
"""
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: 
https://gist.github.com/DevAndArtist/345ce0920de62349c1079e18201aea94

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 (cloutierty...@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 
 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"
   "
   " 
   " \(author)
   " 
   "
Or maybe this:

let xml = """
"
" 
" \(author)
" 
"
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 
 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 = "
"
"
"\(author)
"XML Developer's Guide
"Computer
"44.95
"2000-10-01
"An in-depth look at creating applications with 
XML.
"
"
""
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 = "\   
"\ // If you need you can comment here
"\
"\(author)\
"XML Developer's Guide\
"Computer\
"44.95\
"2000-10-01\
"An in-depth look at creating applications with 
XML.\
"\
"\
""
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 

Re: [swift-evolution] multi-line string literals.

[Tyler Cloutier via swift-evolution]

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 
>  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"
>"
>" 
>" \(author)
>" 
>"
> Or maybe this:
> 
> let xml = """
> "
> " 
> " \(author)
> " 
> "
> 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 
>>  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 = "
>> "
>> "
>> "\(author)
>> "XML Developer's Guide
>> "Computer
>> "44.95
>> "2000-10-01
>> "An in-depth look at creating applications with 
>> XML.
>> "
>> "
>> ""
>> 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 = "\  
>> "\ // If you need you can comment here
>> "\
>> "\(author)\
>> "XML Developer's Guide\
>> "Computer\
>> "44.95\
>> "2000-10-01\
>> "An in-depth look at creating applications with 
>> XML.\
>> "\
>> "\
>> ""
>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] multi-line string literals.

[Tyler Cloutier via swift-evolution]

This is probably too late, and I still have to read over the rest of the 
thread, but one possibility would be to just concatenate adjacent string 
literals (where a one sided string literal extends until the end of the line.

E.g. In your example:

let string = "Hello   " // Three trailing space characters
 "Swift
"   4.0" // Three leading space characters print(string)
 // prints:
Hello___Swift
___4.0
 where _ is a space character
My iPad is really fighting me here, but you see what I mean. And unclosed quote 
on a line could simply include the new line character as part of the string. A 
closed quote on a line does not include the new line.



> On Apr 3, 2017, at 2:35 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Simply because it’s always a zero to n space characters at the start of the 
> line and at its end. You cannot predict the need of every multi-line string.
> 
> I don’t disagree that typing out some extra " and \ is tedious, but what I 
> really like about it is, it’s precise.
> 
> let string =  
> "Hello   \ // Three trailing space characters
> "Swift\
> "   4.0"   // Three leading space characters
>  
> print(string) // prints: "Hello___Swift___4.0" where _ ist a space character
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 3. April 2017 um 11:27:58, Charlie Monroe (char...@charliemonroe.net) 
> schrieb:
> 
>> Yes, but with ", you need to escape " occurrences - which is a fairly common 
>> character - I'd say more common than |.
>> 
>> The trailing whitespace - why can't it just be included in the string 
>> automatically? Just for supporting comments?
>> 
>>> On Apr 3, 2017, at 11:19 AM, Adrian Zubarev 
>>>  wrote:
>>> 
>>> This is almost the same as proposed, but we use " instead of |, however you 
>>> still don’t have trailing space characters covered like this.
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 3. April 2017 um 11:16:41, Charlie Monroe (char...@charliemonroe.net) 
>>> schrieb:
>>> 
 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 = '''
 | 
 | 
 | <...>
 | 
 '''
 
 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 
>  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 (char...@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 = '''
>>  
>>  
>> '''
>> 
>> 
>>> On Apr 3, 2017, at 9:01 AM, Adrian Zubarev via swift-evolution 
>>>  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 = "
>>> "
>>> "
>>> "\(author)
>>> "XML Developer's Guide
>>> "Computer
>>> "44.95
>>> "2000-10-01
>>> "An in-depth look at creating applications 
>>> with XML.
>>> "
>>> "

Re: [swift-evolution] multi-line string literals.

[Thorsten Seitz via swift-evolution]

> Am 03.04.2017 um 17:09 schrieb Ricardo Parada via swift-evolution 
> :
> 
> Hi Adrian,
> 
> I'm not sure if I am understanding what you are saying.
> 
> To me a multi-line string literal is not about continuing a "very long 
> string" into the next line.  
> 
> To me a multi-line string literal is about having a string literal that 
> represents multiple lines of text, where each line is separated by a new line 
> character.  It's just like when you look at a text file in the editor and you 
> don't see the \n at the end of each line.  You just see multiple lines of 
> text.  Same philosophy applies here, but with some useful features such as 
> being able to use escape \, interpolation and quotes mainly.

Same for me. I'd like to be able to copy a multiline string as it is without 
having any control characters in there, e.g. imagine an SQL query which can 
just be copied over into a databse tool and executed there without having to 
remove leading and trailing characters.

I have nothing against *optional* leading and/or trailing control characters 
for improved precision when required. 

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

Re: [swift-evolution] multi-line string literals.

[Nick Keets via swift-evolution]

To me the discussion about precision of multiline strings is missing the
point. The biggest use case of this would be when using swift in a more
script-like fashion. You just paste something, add a
.components(separatedBy: “\n”).map { something() } and you print the result.

If you need precision, localizations, etc, multiline strings don’t have too
much to offer. You could just use plain + with marginal overhead. Or use
resource files.

On Mon, Apr 3, 2017 at 11:18 PM, Ricardo Parada via swift-evolution <
swift-evolution@swift.org> wrote:

> Why would backslashes at the end of each line be a nice idea?
>
> Sent from my iPhone
>
> On Apr 3, 2017, at 2:44 PM, Paweł Wojtkowiak via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I think that there's nothing wrong with two "tools" for the same task in
> this case. Multiline strings look better in the code and are easier to read
> and can serve many purposes. By reading different texts from swift dev team
> I feel like this is something the language was designed with in mind.
> They're also easier to type and it needn't neccessarily be a string
> presented to the user.
>
> Lets say I want a simple json literal for testing purposes - reading from
> a file takes much more effort comparing to inserting it directly in the
> code. Taking out every new line character makes it hard to read, and
> inserting quotes and pluses every line both needs extra effort and also
> decreases readability. Adding it as a multiline string would make a perfect
> solution for this to me.
>
> There are so many other cases where this could be useful too. I like how
> python has the """ and I think this would be a good direction to go,
> although this is true that python uses indentation in a different way, so I
> think backslashes at the end of each line would be a nice idea - this is
> still better than concatenating each line with " and +, and would have the
> least readability impact. Also, it could be treated as a literal and be
> evaluated at compile time.
>
> I just checked with -O and without and was surprised to find that `let x =
> "abc" + "def" + "ghi"` wasn't collapsed into a single string literal
> "abcdefghi" in the generated assembly code. Maybe it's more difficult than
> it is in some other languages because of operator overloads and different
> kinds of text literals (strings, extended grapheme clusters, Unicode
> scalars)?
>
> Regardless of the reasons, a separate syntax isn't the right way to
> achieve this optimization—the compiler should just do it automatically.
> Like Ricardo, "multi-line string literals" should be reserved for string
> literals that include the newline characters that are used to break them up
> in source. The idea of supporting something like the Python example above
> just provides two ways to do the same thing, which I don't think we really
> need.
>
>
> On Mon, Apr 3, 2017 at 8:18 AM Ricardo Parada via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> I would think that the concatenation would get resolved at runtime,
>> unless the compiler gets smart about it.  But either way I do not see it as
>> a problem.  The reason is that I don't remember ever worrying about the
>> performance of concatenating a few lines of text.  :-)
>>
>> Thanks
>>
>>
>> On Apr 3, 2017, at 11:13 AM, Adrian Zubarev > com> wrote:
>>
>> To me a literal a single entity which is solved at compile time. The
>> concatenation is however resolved at runtime if I’m not mistaken here (it
>> might be optimized at compile time but I still would expect a function
>> executed a couple of times at runtime).
>>
>> Please correct me if I’m wrong here.
>>
>>
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> Am 3. April 2017 um 17:10:36, Ricardo Parada (rpar...@mac.com) schrieb:
>>
>> How is that better than this?
>>
>> template = "This is the first line.\n" +
>> "This is the second line.\n" +
>> "This is the third line."
>>
>>
>> On Apr 3, 2017, at 10:42 AM, Ricardo Parada via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> It look prettier without the \n
>>
>> It's not laziness.
>>
>> I want my code to look pretty.
>>
>>
>> On Apr 3, 2017, at 10:40 AM, Adrian Zubarev > com> wrote:
>>
>> 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 (rpar...@mac.com) schrieb:
>>
>> By the way, the multi-line string should allow \n\n, or as many as 

Re: [swift-evolution] multi-line string literals.

[Ricardo Parada via swift-evolution]

Why would backslashes at the end of each line be a nice idea?

Sent from my iPhone

> On Apr 3, 2017, at 2:44 PM, Paweł Wojtkowiak via swift-evolution 
>  wrote:
> 
> I think that there's nothing wrong with two "tools" for the same task in this 
> case. Multiline strings look better in the code and are easier to read and 
> can serve many purposes. By reading different texts from swift dev team I 
> feel like this is something the language was designed with in mind. They're 
> also easier to type and it needn't neccessarily be a string presented to the 
> user. 
> 
> Lets say I want a simple json literal for testing purposes - reading from a 
> file takes much more effort comparing to inserting it directly in the code. 
> Taking out every new line character makes it hard to read, and inserting 
> quotes and pluses every line both needs extra effort and also decreases 
> readability. Adding it as a multiline string would make a perfect solution 
> for this to me.
> 
> There are so many other cases where this could be useful too. I like how 
> python has the """ and I think this would be a good direction to go, although 
> this is true that python uses indentation in a different way, so I think 
> backslashes at the end of each line would be a nice idea - this is still 
> better than concatenating each line with " and +, and would have the least 
> readability impact. Also, it could be treated as a literal and be evaluated 
> at compile time.
> 
>> I just checked with -O and without and was surprised to find that `let x = 
>> "abc" + "def" + "ghi"` wasn't collapsed into a single string literal 
>> "abcdefghi" in the generated assembly code. Maybe it's more difficult than 
>> it is in some other languages because of operator overloads and different 
>> kinds of text literals (strings, extended grapheme clusters, Unicode 
>> scalars)?
>> 
>> Regardless of the reasons, a separate syntax isn't the right way to achieve 
>> this optimization—the compiler should just do it automatically. Like 
>> Ricardo, "multi-line string literals" should be reserved for string literals 
>> that include the newline characters that are used to break them up in 
>> source. The idea of supporting something like the Python example above just 
>> provides two ways to do the same thing, which I don't think we really need.
>> 
>> 
>>> On Mon, Apr 3, 2017 at 8:18 AM Ricardo Parada via swift-evolution 
>>>  wrote:
>>> 
>>> I would think that the concatenation would get resolved at runtime, unless 
>>> the compiler gets smart about it.  But either way I do not see it as a 
>>> problem.  The reason is that I don't remember ever worrying about the 
>>> performance of concatenating a few lines of text.  :-)
>>> 
>>> Thanks
>>> 
>>> 
 On Apr 3, 2017, at 11:13 AM, Adrian Zubarev 
  wrote:
 
 To me a literal a single entity which is solved at compile time. The 
 concatenation is however resolved at runtime if I’m not mistaken here (it 
 might be optimized at compile time but I still would expect a function 
 executed a couple of times at runtime).
 
 Please correct me if I’m wrong here.
 
 
 
 
 -- 
 Adrian Zubarev
 Sent with Airmail
 
 Am 3. April 2017 um 17:10:36, Ricardo Parada (rpar...@mac.com) schrieb:
 
> How is that better than this?
> 
> template = "This is the first line.\n" +
> "This is the second line.\n" +
> "This is the third line."
> 
>> On Apr 3, 2017, at 10:42 AM, Ricardo Parada via swift-evolution 
>>  wrote:
>> 
>> It look prettier without the \n
>> 
>> It's not laziness.
>> 
>> I want my code to look pretty.
>> 
>> 
>>> On Apr 3, 2017, at 10:40 AM, Adrian Zubarev 
>>>  wrote:
>>> 
>>> 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 (rpar...@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.
 
>>> 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> 

Re: [swift-evolution] multi-line string literals.

[Tony Allevato via swift-evolution]

On Mon, Apr 3, 2017 at 12:53 PM Ben Rimmington  wrote:

>  (Merged 10 days ago)
>

That's a relief! I thought I was losing my mind that such an obvious
optimization had been left on the floor, especially when I also thought I
remembered it working before.


>
> > On 3 Apr 2017, at 20:32, Charlie Monroe wrote:
> >
> >> On Apr 3, 2017, at 9:25 PM, Ben Rimmington wrote:
> >>
> >>> On 3 Apr 2017, at 17:55, Tony Allevato wrote:
> >>>
> >>> I just checked with -O and without and was surprised to find that `let
> x = "abc" + "def" + "ghi"` wasn't collapsed into a single string literal
> "abcdefghi" in the generated assembly code. Maybe it's more difficult than
> it is in some other languages because of operator overloads and different
> kinds of text literals (strings, extended grapheme clusters, Unicode
> scalars)?
> >>
> >> Is this a regression since Swift 2.0 added the optimization?
> >
> > I'd say it's a regression since 3.0 since I remember testing the
> optimizer even being able to put together this during compile time:
> >
> > struct URLString {
> >   let urlString: String
> >
> >   init(host: String, path: String, query: String) {
> >   self.urlString = "http://; + host + path + "?" + query
> >   }
> > }
> >
> > URLString(host: "apple.com", path: "/mac", query: "target=imac")
> >
> > This produced a single string literal - I confirmed this using MachOView
> on the final binary...
> >
> >>  * Concatenation of Swift string literals, including across
> multiple lines, is
> >>now a guaranteed compile-time optimization, even at `-Onone`.
> **(19125926)**
> >>
> >> <
> https://github.com/apple/swift/blame/97db3931f2c5a21ea87ad6e71cdecbec325bff91/CHANGELOG.md#L1329-L1330
> >
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] multi-line string literals.

[Tony Allevato via swift-evolution]

Hi Pavel, you've misunderstood what I was saying. :)

I was focused specifically on the example Adrian posted a few messages up,
where he cited wanting something like Python's implicit concatenation when
a string is broken across multiple lines but each segment is still quoted;
as Ricardo pointed out, that's not a significant improvement over adding +
to the end of each line, and it's what I meant when I said doing the same
things two ways.

I'd be much more supportive of *true* multi-line strings or heredocs where
the newlines that are part of the string in the source code are also part
of the string—not just implicit concatenation around line breaks, but
retaining the structure of the string as well. That's not two ways to do
the same thing, since the latter isn't supported yet by Swift. So we're
probably in agreement.

That being said, while I can see the necessity, I'm actually not a fan of
large strings in the middle of source code for many of the reasons cited
already—I think it's a bit of a code smell to embed that much data in the
source, and editors can have difficulty handling it when the syntax
highlighting context changes to drastically. In my ideal world, I'd like a
way for me to import the contents of an external file as a String or a
binary blob so that it still gets brought into the data segment but it's
not a huge chunk of unrelated content in the middle of my logic.

That's a harder sell when you think of the Apple OS use cases because you
can just load data from bundled resources, but it might be more valuable in
server contexts, and if they could support interpolation as well, that
would be a powerful templating mechanism as well.


On Mon, Apr 3, 2017 at 11:44 AM Paweł Wojtkowiak 
wrote:

> I think that there's nothing wrong with two "tools" for the same task in
> this case. Multiline strings look better in the code and are easier to read
> and can serve many purposes. By reading different texts from swift dev team
> I feel like this is something the language was designed with in mind.
> They're also easier to type and it needn't neccessarily be a string
> presented to the user.
>
> Lets say I want a simple json literal for testing purposes - reading from
> a file takes much more effort comparing to inserting it directly in the
> code. Taking out every new line character makes it hard to read, and
> inserting quotes and pluses every line both needs extra effort and also
> decreases readability. Adding it as a multiline string would make a perfect
> solution for this to me.
>
> There are so many other cases where this could be useful too. I like how
> python has the """ and I think this would be a good direction to go,
> although this is true that python uses indentation in a different way, so I
> think backslashes at the end of each line would be a nice idea - this is
> still better than concatenating each line with " and +, and would have the
> least readability impact. Also, it could be treated as a literal and be
> evaluated at compile time.
>
> I just checked with -O and without and was surprised to find that `let x =
> "abc" + "def" + "ghi"` wasn't collapsed into a single string literal
> "abcdefghi" in the generated assembly code. Maybe it's more difficult than
> it is in some other languages because of operator overloads and different
> kinds of text literals (strings, extended grapheme clusters, Unicode
> scalars)?
>
> Regardless of the reasons, a separate syntax isn't the right way to
> achieve this optimization—the compiler should just do it automatically.
> Like Ricardo, "multi-line string literals" should be reserved for string
> literals that include the newline characters that are used to break them up
> in source. The idea of supporting something like the Python example above
> just provides two ways to do the same thing, which I don't think we really
> need.
>
>
> On Mon, Apr 3, 2017 at 8:18 AM Ricardo Parada via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> I would think that the concatenation would get resolved at runtime, unless
> the compiler gets smart about it.  But either way I do not see it as a
> problem.  The reason is that I don't remember ever worrying about the
> performance of concatenating a few lines of text.  :-)
>
> Thanks
>
> On Apr 3, 2017, at 11:13 AM, Adrian Zubarev <
> adrian.zuba...@devandartist.com> wrote:
>
> To me a literal a single entity which is solved at compile time. The
> concatenation is however resolved at runtime if I’m not mistaken here (it
> might be optimized at compile time but I still would expect a function
> executed a couple of times at runtime).
>
> Please correct me if I’m wrong here.
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 3. April 2017 um 17:10:36, Ricardo Parada (rpar...@mac.com) schrieb:
>
> How is that better than this?
>
> template = "This is the first line.\n" +
> "This is the second line.\n" +
> "This is the third line."
>
>
> On Apr 3, 2017, 

Re: [swift-evolution] multi-line string literals.

[Charlie Monroe via swift-evolution]

Thanks! Unfortunately, it didn't make it to Xcode 8.3...

> On Apr 3, 2017, at 9:53 PM, Ben Rimmington  wrote:
> 
>  (Merged 10 days ago)
> 
>> On 3 Apr 2017, at 20:32, Charlie Monroe wrote:
>> 
>>> On Apr 3, 2017, at 9:25 PM, Ben Rimmington wrote:
>>> 
 On 3 Apr 2017, at 17:55, Tony Allevato wrote:
 
 I just checked with -O and without and was surprised to find that `let x = 
 "abc" + "def" + "ghi"` wasn't collapsed into a single string literal 
 "abcdefghi" in the generated assembly code. Maybe it's more difficult than 
 it is in some other languages because of operator overloads and different 
 kinds of text literals (strings, extended grapheme clusters, Unicode 
 scalars)?
>>> 
>>> Is this a regression since Swift 2.0 added the optimization?
>> 
>> I'd say it's a regression since 3.0 since I remember testing the optimizer 
>> even being able to put together this during compile time:
>> 
>> struct URLString {
>>  let urlString: String
>> 
>>  init(host: String, path: String, query: String) {
>>  self.urlString = "http://; + host + path + "?" + query
>>  }
>> }
>> 
>> URLString(host: "apple.com", path: "/mac", query: "target=imac")
>> 
>> This produced a single string literal - I confirmed this using MachOView on 
>> the final binary...
>> 
>>> * Concatenation of Swift string literals, including across multiple 
>>> lines, is
>>>   now a guaranteed compile-time optimization, even at `-Onone`. 
>>> **(19125926)**
>>> 
>>> 

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

Re: [swift-evolution] multi-line string literals.

[Ben Rimmington via swift-evolution]

 (Merged 10 days ago)

> On 3 Apr 2017, at 20:32, Charlie Monroe wrote:
> 
>> On Apr 3, 2017, at 9:25 PM, Ben Rimmington wrote:
>> 
>>> On 3 Apr 2017, at 17:55, Tony Allevato wrote:
>>> 
>>> I just checked with -O and without and was surprised to find that `let x = 
>>> "abc" + "def" + "ghi"` wasn't collapsed into a single string literal 
>>> "abcdefghi" in the generated assembly code. Maybe it's more difficult than 
>>> it is in some other languages because of operator overloads and different 
>>> kinds of text literals (strings, extended grapheme clusters, Unicode 
>>> scalars)?
>> 
>> Is this a regression since Swift 2.0 added the optimization?
> 
> I'd say it's a regression since 3.0 since I remember testing the optimizer 
> even being able to put together this during compile time:
> 
> struct URLString {
>   let urlString: String
> 
>   init(host: String, path: String, query: String) {
>   self.urlString = "http://; + host + path + "?" + query
>   }
> }
> 
> URLString(host: "apple.com", path: "/mac", query: "target=imac")
> 
> This produced a single string literal - I confirmed this using MachOView on 
> the final binary...
> 
>>  * Concatenation of Swift string literals, including across multiple 
>> lines, is
>>now a guaranteed compile-time optimization, even at `-Onone`. 
>> **(19125926)**
>> 
>> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] multi-line string literals.

[Charlie Monroe via swift-evolution]

> On Apr 3, 2017, at 9:25 PM, Ben Rimmington via swift-evolution 
>  wrote:
> 
> 
>> On 3 Apr 2017, at 17:55, Tony Allevato wrote:
>> 
>> I just checked with -O and without and was surprised to find that `let x = 
>> "abc" + "def" + "ghi"` wasn't collapsed into a single string literal 
>> "abcdefghi" in the generated assembly code. Maybe it's more difficult than 
>> it is in some other languages because of operator overloads and different 
>> kinds of text literals (strings, extended grapheme clusters, Unicode 
>> scalars)?
> 
> Is this a regression since Swift 2.0 added the optimization?

I'd say it's a regression since 3.0 since I remember testing the optimizer even 
being able to put together this during compile time:

struct URLString {
let urlString: String

init(host: String, path: String, query: String) {
self.urlString = "http://; + host + path + "?" + query
}
}

URLString(host: "apple.com ", path: "/mac", query: 
"target=imac")

This produced a single string literal - I confirmed this using MachOView on the 
final binary...

> 
>   * Concatenation of Swift string literals, including across multiple 
> lines, is
> now a guaranteed compile-time optimization, even at `-Onone`. 
> **(19125926)**
> 
> 
> 
> -- Ben
> 
> ___
> 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

Re: [swift-evolution] multi-line string literals.

[Vladimir.S via swift-evolution]

On 03.04.2017 19:58, Peter Dillinger via swift-evolution wrote:

Can we try to enumerate the potential hazards and potential useful features 
associated with multi-line strings?  Then perhaps you can judge various 
proposals based on them.


Potential hazards:

H1) Forgotten '+' (plus).  This affects the current idiom where you could end up with 
part of your intended string going missing (with a compiler warning) because you forgot 
to put + between string fragments on adjacent lines.  (Making this a compiler error was 
rejected in thread "Disallowing many expressions with unused result".)

H2) Forgotten ',' (comma).  If adjacent string tokens (potentially on separate 
lines) are implicitly concatenated (as in C/C++), that makes it easy to 
mis-specify arrays of strings, as in
var a = [
  "a",
  "b"
  "c"]
which would have only two elements.  This could also affect intended tuples, 
but with much higher likelihood of being caught by the compiler.

H3) No recovery for tokenization / syntax highlighting.  IMHO, this is the big drawback of Python-style """ 
strings.  If you jump to an arbitrary point in the source code, you don't know whether you're inside a """, 
and AFAIK there's no reliable, automatic way to figure out if the next """ enters or exits a multi-line 
string.  As someone who has dealt with building syntax highlighters, the property of a predictable tokenizer state after 
newline (as in languages like Java or C# - either default state or multiline comment) is really nice.  Yes, multiline 
comments are kind of ugly, but they at least tend to be self-correcting because the entry and exit character sequences are 
different!  Requiring some kind of continuation character generally facilitates immediate recovery.

H4) Unclear escaping / newline / indentation semantics.  This has been under 
heavy discussion and I don't have much to add.


Potentially useful features:

F1) Interpolation.  There's less value if it's difficult to embed evaluated 
code.

F2) Raw embedding.  There's less value if it's difficult to construct literals 
from raw strings, because of the need for escaping / continuation characters 
etc.


Another imperfect proposal:

Support two forms of multiline strings:
* one with escaping, interpolation, and embedded newlines only with \n, 
delimited with \\\ and ///


Why we need it ? It's the same as concatenating strings currently.


* one with no escaping that includes written newlines in the string, delimited 
with ``` and '''


IMO it is very useful to have string interpolation for such multi-line 
strings. So, in this case we should be able to escape '\(' and this means 
that we need to escape at least backslash. I'm not sure about usefulness of 
the "as-is" multi-string.


I think multi-line string should:
* Allows string interpolation
* But only backslash itself must be escaped (to support interpolation), 
other symbols without escaping

* Begin/End marker is  \" (or probably end marker is "\)
(looks similar to /* which opens multi-line comments)
* It appends '\n' for each *new* line in text(if text is of one line - no 
new line symbol will be added)

* Leading and trailing whitespace will be trimmed
(for opening marker - leading spaces after marker and before the actual 
text will be preserved,
for closing marker - trailing spaces after text and before marker will be 
preserved)


var str =
\"

  \(pathValue)

"\

And if you need to control whitespace:

var str =
\""\ + "\n"+
\""\  + "\n"+
\"  \(pathValue)"\ + "\n"+
\""\


sendText(
\"Text line1
Text \(value)
Text line3"\
)


Both forms would be subject to further restrictions to aid readability and use 
of indentation:
* The three-character begin or end delimiter must be on a line by itself, only 
with optional leading whitespace (spaces and/or tabs).
* Each line up to and including the end delimiter must exactly copy the leading 
whitespace used for the begin delimiter, and that whitespace is not included in 
the contents of the parsed string literal.

For example:
var x =
```


  C:\Foo

'''
Or:
send(
\\\
\n
\n  \(path)\n\n
///
)

Or:
let f =
```

'''

Maybe there should be a way to omit the trailing newline from a ``` ''' string, 
but I don't have a specific proposal.



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

Re: [swift-evolution] multi-line string literals.

[Ben Rimmington via swift-evolution]

> On 3 Apr 2017, at 17:55, Tony Allevato wrote:
> 
> I just checked with -O and without and was surprised to find that `let x = 
> "abc" + "def" + "ghi"` wasn't collapsed into a single string literal 
> "abcdefghi" in the generated assembly code. Maybe it's more difficult than it 
> is in some other languages because of operator overloads and different kinds 
> of text literals (strings, extended grapheme clusters, Unicode scalars)?

Is this a regression since Swift 2.0 added the optimization?

* Concatenation of Swift string literals, including across multiple 
lines, is
  now a guaranteed compile-time optimization, even at `-Onone`. 
**(19125926)**



-- Ben

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

Re: [swift-evolution] multi-line string literals.

[Paweł Wojtkowiak via swift-evolution]

I think that there's nothing wrong with two "tools" for the same task in this 
case. Multiline strings look better in the code and are easier to read and can 
serve many purposes. By reading different texts from swift dev team I feel like 
this is something the language was designed with in mind. They're also easier 
to type and it needn't neccessarily be a string presented to the user. 

Lets say I want a simple json literal for testing purposes - reading from a 
file takes much more effort comparing to inserting it directly in the code. 
Taking out every new line character makes it hard to read, and inserting quotes 
and pluses every line both needs extra effort and also decreases readability. 
Adding it as a multiline string would make a perfect solution for this to me.

There are so many other cases where this could be useful too. I like how python 
has the """ and I think this would be a good direction to go, although this is 
true that python uses indentation in a different way, so I think backslashes at 
the end of each line would be a nice idea - this is still better than 
concatenating each line with " and +, and would have the least readability 
impact. Also, it could be treated as a literal and be evaluated at compile time.

> I just checked with -O and without and was surprised to find that `let x = 
> "abc" + "def" + "ghi"` wasn't collapsed into a single string literal 
> "abcdefghi" in the generated assembly code. Maybe it's more difficult than it 
> is in some other languages because of operator overloads and different kinds 
> of text literals (strings, extended grapheme clusters, Unicode scalars)?
> 
> Regardless of the reasons, a separate syntax isn't the right way to achieve 
> this optimization―the compiler should just do it automatically. Like Ricardo, 
> "multi-line string literals" should be reserved for string literals that 
> include the newline characters that are used to break them up in source. The 
> idea of supporting something like the Python example above just provides two 
> ways to do the same thing, which I don't think we really need.
> 
> 
>> On Mon, Apr 3, 2017 at 8:18 AM Ricardo Parada via swift-evolution 
>>  wrote:
>> 
>> I would think that the concatenation would get resolved at runtime, unless 
>> the compiler gets smart about it.  But either way I do not see it as a 
>> problem.  The reason is that I don't remember ever worrying about the 
>> performance of concatenating a few lines of text.  :-)
>> 
>> Thanks
>> 
>> 
>>> On Apr 3, 2017, at 11:13 AM, Adrian Zubarev 
>>>  wrote:
>>> 
>>> To me a literal a single entity which is solved at compile time. The 
>>> concatenation is however resolved at runtime if I’m not mistaken here (it 
>>> might be optimized at compile time but I still would expect a function 
>>> executed a couple of times at runtime).
>>> 
>>> Please correct me if I’m wrong here.
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 3. April 2017 um 17:10:36, Ricardo Parada (rpar...@mac.com) schrieb:
>>> 
 How is that better than this?
 
 template = "This is the first line.\n" +
 "This is the second line.\n" +
 "This is the third line."
 
> On Apr 3, 2017, at 10:42 AM, Ricardo Parada via swift-evolution 
>  wrote:
> 
> It look prettier without the \n
> 
> It's not laziness.
> 
> I want my code to look pretty.
> 
> 
>> On Apr 3, 2017, at 10:40 AM, Adrian Zubarev 
>>  wrote:
>> 
>> 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 (rpar...@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.
>>> 
>> 
>> 
> 
> ___
> 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
___
swift-evolution mailing list

Re: [swift-evolution] multi-line string literals.

[Peter Dillinger via swift-evolution]

Can we try to enumerate the potential hazards and potential useful features 
associated with multi-line strings?  Then perhaps you can judge various 
proposals based on them.


Potential hazards:

H1) Forgotten '+' (plus).  This affects the current idiom where you could end 
up with part of your intended string going missing (with a compiler warning) 
because you forgot to put + between string fragments on adjacent lines.  
(Making this a compiler error was rejected in thread "Disallowing many 
expressions with unused result".)

H2) Forgotten ',' (comma).  If adjacent string tokens (potentially on separate 
lines) are implicitly concatenated (as in C/C++), that makes it easy to 
mis-specify arrays of strings, as in
var a = [
  "a",
  "b"
  "c"]
which would have only two elements.  This could also affect intended tuples, 
but with much higher likelihood of being caught by the compiler.

H3) No recovery for tokenization / syntax highlighting.  IMHO, this is the big 
drawback of Python-style """ strings.  If you jump to an arbitrary point in the 
source code, you don't know whether you're inside a """, and AFAIK there's no 
reliable, automatic way to figure out if the next """ enters or exits a 
multi-line string.  As someone who has dealt with building syntax highlighters, 
the property of a predictable tokenizer state after newline (as in languages 
like Java or C# - either default state or multiline comment) is really nice.  
Yes, multiline comments are kind of ugly, but they at least tend to be 
self-correcting because the entry and exit character sequences are different!  
Requiring some kind of continuation character generally facilitates immediate 
recovery.

H4) Unclear escaping / newline / indentation semantics.  This has been under 
heavy discussion and I don't have much to add.


Potentially useful features:

F1) Interpolation.  There's less value if it's difficult to embed evaluated 
code.

F2) Raw embedding.  There's less value if it's difficult to construct literals 
from raw strings, because of the need for escaping / continuation characters 
etc.


Another imperfect proposal:

Support two forms of multiline strings:
* one with escaping, interpolation, and embedded newlines only with \n, 
delimited with \\\ and ///
* one with no escaping that includes written newlines in the string, delimited 
with ``` and '''
Both forms would be subject to further restrictions to aid readability and use 
of indentation:
* The three-character begin or end delimiter must be on a line by itself, only 
with optional leading whitespace (spaces and/or tabs).
* Each line up to and including the end delimiter must exactly copy the leading 
whitespace used for the begin delimiter, and that whitespace is not included in 
the contents of the parsed string literal.

For example:
var x =
```


  C:\Foo

'''
Or:
send(
\\\
\n
\n  \(path)\n\n
///
)

Or:
let f =
```

'''

Maybe there should be a way to omit the trailing newline from a ``` ''' string, 
but I don't have a specific proposal.


-- 
Peter Dillinger, Ph.D.
Software Engineering Manager, Coverity Analysis, Software Integrity Group | 
Synopsys
www.synopsys.com/software
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] multi-line string literals.

[Tony Allevato via swift-evolution]

I just checked with -O and without and was surprised to find that `let x =
"abc" + "def" + "ghi"` wasn't collapsed into a single string literal
"abcdefghi" in the generated assembly code. Maybe it's more difficult than
it is in some other languages because of operator overloads and different
kinds of text literals (strings, extended grapheme clusters, Unicode
scalars)?

Regardless of the reasons, a separate syntax isn't the right way to achieve
this optimization—the compiler should just do it automatically. Like
Ricardo, "multi-line string literals" should be reserved for string
literals that include the newline characters that are used to break them up
in source. The idea of supporting something like the Python example above
just provides two ways to do the same thing, which I don't think we really
need.


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

>
> I would think that the concatenation would get resolved at runtime, unless
> the compiler gets smart about it.  But either way I do not see it as a
> problem.  The reason is that I don't remember ever worrying about the
> performance of concatenating a few lines of text.  :-)
>
> Thanks
>
>
> On Apr 3, 2017, at 11:13 AM, Adrian Zubarev <
> adrian.zuba...@devandartist.com> wrote:
>
> To me a literal a single entity which is solved at compile time. The
> concatenation is however resolved at runtime if I’m not mistaken here (it
> might be optimized at compile time but I still would expect a function
> executed a couple of times at runtime).
>
> Please correct me if I’m wrong here.
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 3. April 2017 um 17:10:36, Ricardo Parada (rpar...@mac.com) schrieb:
>
> How is that better than this?
>
> template = "This is the first line.\n" +
> "This is the second line.\n" +
> "This is the third line."
>
>
> On Apr 3, 2017, at 10:42 AM, Ricardo Parada via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> It look prettier without the \n
>
> It's not laziness.
>
> I want my code to look pretty.
>
>
> On Apr 3, 2017, at 10:40 AM, Adrian Zubarev <
> adrian.zuba...@devandartist.com> wrote:
>
> 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 (rpar...@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.
>
>
>
> ___
> 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] multi-line string literals.

[Ricardo Parada via swift-evolution]

I would think that the concatenation would get resolved at runtime, unless the 
compiler gets smart about it.  But either way I do not see it as a problem.  
The reason is that I don't remember ever worrying about the performance of 
concatenating a few lines of text.  :-)

Thanks


> On Apr 3, 2017, at 11:13 AM, Adrian Zubarev  
> wrote:
> 
> To me a literal a single entity which is solved at compile time. The 
> concatenation is however resolved at runtime if I’m not mistaken here (it 
> might be optimized at compile time but I still would expect a function 
> executed a couple of times at runtime).
> 
> Please correct me if I’m wrong here.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 3. April 2017 um 17:10:36, Ricardo Parada (rpar...@mac.com 
> ) schrieb:
> 
>> How is that better than this?
>> 
>> template = "This is the first line.\n" +
>> "This is the second line.\n" +
>> "This is the third line."
>> 
>>> On Apr 3, 2017, at 10:42 AM, Ricardo Parada via swift-evolution 
>>> > wrote:
>>> 
>>> It look prettier without the \n
>>> 
>>> It's not laziness.
>>> 
>>> I want my code to look pretty.
>>> 
>>> 
 On Apr 3, 2017, at 10:40 AM, Adrian Zubarev 
 > 
 wrote:
 
 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 (rpar...@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.
> 
 
 
>>> 
>>> ___
>>> 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

Re: [swift-evolution] multi-line string literals.

[Adrian Zubarev via swift-evolution]

To me a literal a single entity which is solved at compile time. The 
concatenation is however resolved at runtime if I’m not mistaken here (it might 
be optimized at compile time but I still would expect a function executed a 
couple of times at runtime).

Please correct me if I’m wrong here.



-- 
Adrian Zubarev
Sent with Airmail

Am 3. April 2017 um 17:10:36, Ricardo Parada (rpar...@mac.com) schrieb:

How is that better than this?

template = "This is the first line.\n" +
"This is the second line.\n" +
"This is the third line."

On Apr 3, 2017, at 10:42 AM, Ricardo Parada via swift-evolution 
 wrote:

It look prettier without the \n

It's not laziness.

I want my code to look pretty.


On Apr 3, 2017, at 10:40 AM, Adrian Zubarev  
wrote:

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



___
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

Re: [swift-evolution] multi-line string literals.

[Ricardo Parada via swift-evolution]

How is that better than this?

template = "This is the first line.\n" +
"This is the second line.\n" +
"This is the third line."

> On Apr 3, 2017, at 10:42 AM, Ricardo Parada via swift-evolution 
>  wrote:
> 
> It look prettier without the \n
> 
> It's not laziness.
> 
> I want my code to look pretty.
> 
> 
>> On Apr 3, 2017, at 10:40 AM, Adrian Zubarev > > wrote:
>> 
>> 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 (rpar...@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.
>>> 
>> 
>> 
> 
> ___
> 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

Re: [swift-evolution] multi-line string literals.

[Ricardo Parada via swift-evolution]

Hi Adrian,

I'm not sure if I am understanding what you are saying.

To me a multi-line string literal is not about continuing a "very long string" 
into the next line.  

To me a multi-line string literal is about having a string literal that 
represents multiple lines of text, where each line is separated by a new line 
character.  It's just like when you look at a text file in the editor and you 
don't see the \n at the end of each line.  You just see multiple lines of text. 
 Same philosophy applies here, but with some useful features such as being able 
to use escape \, interpolation and quotes mainly.

The continuation character serves as a visual guide of the beginning of each 
line and to help you align/indent the multiple lines of text.

I was proposing that the multi-line string literal automatically ends when 
there is no continuation character on the next line.  But it could also use the 
same one that was used to start it, either """ or "M.

I am sure we'll find a hole in every proposed solution, but I think the one 
that takes care of 99% of the cases should be the one.

Regards


> On Apr 3, 2017, at 10:44 AM, Adrian Zubarev  
> wrote:
> 
> 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 (rpar...@mac.com 
> ) schrieb:
> 
>> let veryLongString2 = "word word word" +
>> "word word word" +
>>   "word word word"
>> 
> 
> 

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

Re: [swift-evolution] multi-line string literals.

[Adrian Zubarev via swift-evolution]

Ideally what I personally really want is something like in python:

template = ("This is the first line.\n"
"This is the second line.\n"
"This is the third line.")


-- 
Adrian Zubarev
Sent with Airmail

Am 3. April 2017 um 16:44:24, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

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 (rpar...@mac.com) schrieb:

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

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

Re: [swift-evolution] multi-line string literals.

[Adrian Zubarev via swift-evolution]

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 (rpar...@mac.com) schrieb:

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

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

Re: [swift-evolution] multi-line string literals.

[Ricardo Parada via swift-evolution]

It look prettier without the \n

It's not laziness.

I want my code to look pretty.


> On Apr 3, 2017, at 10:40 AM, Adrian Zubarev  
> wrote:
> 
> 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 (rpar...@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.
>> 
> 
> 

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

Re: [swift-evolution] multi-line string literals.

[Adrian Zubarev via swift-evolution]

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

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

Re: [swift-evolution] multi-line string literals.

[Ricardo Parada via swift-evolution]

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 
>  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 > > 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 (rpar...@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"
>>>"
>>>" 
>>>" \(author)
>>>" 
>>>"
>>> Or maybe this:
>>> 
>>> let xml = """
>>> "
>>> " 
>>> " \(author)
>>> " 
>>> "
>>> 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 
 > 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 = "
 "
 "
 "\(author)
 "XML Developer's Guide
 "Computer
 "44.95
 "2000-10-01
 "An in-depth look at creating applications with 
 XML.
 "
 "
 ""
 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 = "\   
 "\ // If you need you can comment here
 "\
 "\(author)\

[swift-evolution] multi-line string literals

[Robert Bennett via swift-evolution]

To throw another idea into the mix: the string surrounded with double quotes, 
each line beginning and ending with a single quote.

let foo = "This is my '
'multi line string '
'with lots of spaces at'
'the end of the above line '
'and more at the start of '
'   this line."


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

Re: [swift-evolution] multi-line string literals.

[Ricardo Parada via swift-evolution]

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  
> 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 (rpar...@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"
>>"
>>" 
>>" \(author)
>>" 
>>"
>> Or maybe this:
>> 
>> let xml = """
>> "
>> " 
>> " \(author)
>> " 
>> "
>> 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 
>>> > 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 = "
>>> "
>>> "
>>> "\(author)
>>> "XML Developer's Guide
>>> "Computer
>>> "44.95
>>> "2000-10-01
>>> "An in-depth look at creating applications with 
>>> XML.
>>> "
>>> "
>>> ""
>>> 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 = "\   
>>> "\ // If you need you can comment here
>>> "\
>>> "\(author)\
>>> "XML Developer's Guide\
>>> "Computer\
>>> "44.95\
>>> "2000-10-01\
>>> "An in-depth look at creating applications with 
>>> XML.\
>>> "\
>>> "\
>>> ""
>>> Here is another example:
>>> 
>>> let multilineString: String = "123__456__\ // indicates there is another 
>>> part of the string on the next line
>>>   "__789_\ 

Re: [swift-evolution] multi-line string literals.

[Adrian Zubarev via swift-evolution]

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 (rpar...@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"
   "
   " 
   " \(author)
   " 
   "
Or maybe this:

let xml = """
"
" 
" \(author)
" 
"
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 
 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 = "
"
"
"\(author)
"XML Developer's Guide
"Computer
"44.95
"2000-10-01
"An in-depth look at creating applications with 
XML.
"
"
""
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 = "\   
"\ // If you need you can comment here
"\
"\(author)\
"XML Developer's Guide\
"Computer\
"44.95\
"2000-10-01\
"An in-depth look at creating applications with 
XML.\
"\
"\
""
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

Re: [swift-evolution] multi-line string literals.

[Adrian Zubarev via swift-evolution]

To be honest operator concatenation at compile time is confusing and would be 
really inconsistent to the whole language.

func + (lhs: String, ras: String) -> A { … }

let a: A = "abc" + "def"
This will break that model and disallow that pattern even if it could make some 
sense in a specific context of your code design.

But yeah, I don’t know if we should really encourage multi-line comments too 
much; if I had my way we’d somehow make them more awkward to use, just to stop 
people using them 
That made my day :D



-- 
Adrian Zubarev
Sent with Airmail

Am 3. April 2017 um 15:39:11, Haravikk (swift-evolut...@haravikk.me) schrieb:

I still don't really see what's so wrong with just doing:

let foo = "This my " +
  "multiline " +
  "string"

It's only one or two characters more than other proposed styles, and IMO it's 
not something that should come up all that often; I'm kind of uncomfortable 
with the idea of encouraging multi-line strings in code, as really these should 
be localised properly instead.

If there needs to be an alternative I'd say just allow omission of the 
concatenation operator like so:

let foo = "This my "
  "multiline "
  "string"

The caveat for this is that we would need to disallow a string as a statement, 
or require explicit concatenation anywhere it might be ambiguous like so:

let foo = "This my "
  "multiline "
  "string".capitalized // Warning: Use concatenation (+) or let _ = to 
disambiguate

This would need become one of the following:

let foo = "This my "
  "multiline " + // Clearly concatenated
  "string".capitalized


let foo = "This my " +
  "multiline "
let _ = "string".capitalized // Clearly separate for some reason

But yeah, I don't know if we should really encourage multi-line comments too 
much; if I had my way we'd somehow make them more awkward to use, just to stop 
people using them 

On 3 Apr 2017, at 13:36, Adrian Zubarev via swift-evolution 
 wrote:

I don’t really think this is about how to indicate a multi-lined string, where 
the string starts and ends with something like ", ' or """ is trivial to me. 
It’s just a decision to make. However the main debate I see with that topic is 
the ambiguity from the readers perspective.

In your example I assume you want a result to match this: “my multiline 
string”, but what if you need precision? Should we really fallback to single 
line string then? What if you want to print some XML file with all it’s indent 
calculated with whitespaces rather than tabs? The multiline version like that 
won’t work, and if your string is huge you’ll end up at a place where we 
already are. This doesn’t solve the main then because we could otherwise simply 
allow this today:

let string = "my
multiline
string"
I’m only speaking for my personal preference, others might see it completely 
different. However I’m totally sure multiline strings solve more than simply 
being able to write them so that the compiler is satisfied.

As a compromise for everyone we possibly could come up with a way which serves 
both, simplicity and precision. 

For the next bikeshedding example I’m going to use ' for multi-lined strings:

// Simplicity which supports indent but at a cost of no   
// leading or trailing space characters
let string1 = 'my
multiline
string'

print(string1) // prints "mymultilinestring"

let string2 = 'my \   
multiline \
string'
  
// Trailing precision
print(string2) // prints "my multiline string"

let string3 = 'my
' multiline
' string'
  
// Leading precision
print(string3) // prints "my multiline string"

let string4 = 'my \
' multiline \
' string'
  
// Leading and trailing precision
print(string4) // prints "my  multiline  string" (Note: 2x two whitespaces)

let string5 = 'my\
'multiline\
'string'
  
// Leading and trailing precision
// Provide a fix-it to remove some `\` and `'` characters
// because it equals `string1`
print(string5) // prints "mymultilinestring"

let string6 = 'my \
'multiline \
'string'
  
// Leading and trailing precision
// Provide a fix-it to remove some `'` characters
// because it equals `string2`
print(string6) // prints "my multiline string"

let string7 = 'my\
' multiline\
' string'
  
// Leading and trailing precision
// Provide a fix-it to remove some `\` characters
// because it equals `string3`
print(string7) // prints "my multiline string"
Comments should be only allowed after the escaping character. string1 can only 
have comments after the last line of that string.

I think a model like this could have the best from both worlds.

Personally I dislike the idea of """ and would rather want a model from above 
with " and \ or as written.




-- 
Adrian Zubarev
Sent with Airmail

Am 3. April 2017 um 11:56:12, Daniel Leping (dan...@crossroadlabs.xyz) schrieb:

What about """ 

Re: [swift-evolution] multi-line string literals.

[Ricardo Parada via swift-evolution]

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"
   "
   " 
   " \(author)
   " 
   "
Or maybe this:

let xml = """
"
" 
" \(author)
" 
"
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 
>  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 = "
> "
> "
> "\(author)
> "XML Developer's Guide
> "Computer
> "44.95
> "2000-10-01
> "An in-depth look at creating applications with 
> XML.
> "
> "
> ""
> 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 = "\  
> "\ // If you need you can comment here
> "\
> "\(author)\
> "XML Developer's Guide\
> "Computer\
> "44.95\
> "2000-10-01\
> "An in-depth look at creating applications with 
> XML.\
> "\
> "\
> ""
> 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

Re: [swift-evolution] multi-line string literals.

[Adrian Zubarev via swift-evolution]

New line character \n should not become part of the string itself, that would 
be really confusing and inconsistent to other escaped characters.

let mys1 = """my"
"multiline"
"string"""
The idea is in general the same as I showed it, my version might be really 
overcomplicated, but you’ve got the point there and that’s what we want for 
everyone. The multi-lined string (if it ever makes it) should be intuitive (and 
swifty).

One argument for using " is the similarity to the string literel we’re already 
familiar with. If you decide to split your long string literal into multilines, 
it shouldn’t force you to rewrite the outer characters. Ideally you should be 
able to simple hitting enter a couple of times and thats it (in that case your 
string does not need space characters).

let string1 = "content"
let string2 = "
content
"
And we just need to come up with precision characters that will suite everyone.

let string = "my [right_pricision_character]
[left_pricision_character]multiline [right_pricision_character]
[left_pricision_character]string"
Just replace [left_pricision_character] and [right_pricision_character] with 
something more _swifty_.



-- 
Adrian Zubarev
Sent with Airmail

Am 3. April 2017 um 15:36:37, Daniel Leping (dan...@crossroadlabs.xyz) schrieb:

I think it quite some overcomplicates the situation. I would prefer:
1. Distinct multiline strings, (e.g. not " but rather """)
2. We could use something like this for precision:
let mys1 = """my"
"multiline"
"string"""
// equivalent to "mymultilinestring"

let mys2 = """my
           multiline
           string"""
// equivalent to "my\nmultiline\nstring"


This looks simpler to me, still you can do everything with it.

On Mon, 3 Apr 2017 at 15:36 Adrian Zubarev  
wrote:
I don’t really think this is about how to indicate a multi-lined string, where 
the string starts and ends with something like ", ' or """ is trivial to me. 
It’s just a decision to make. However the main debate I see with that topic is 
the ambiguity from the readers perspective.

In your example I assume you want a result to match this: “my multiline 
string”, but what if you need precision? Should we really fallback to single 
line string then? What if you want to print some XML file with all it’s indent 
calculated with whitespaces rather than tabs? The multiline version like that 
won’t work, and if your string is huge you’ll end up at a place where we 
already are. This doesn’t solve the main then because we could otherwise simply 
allow this today:

let string = "my
multiline
string"
I’m only speaking for my personal preference, others might see it completely 
different. However I’m totally sure multiline strings solve more than simply 
being able to write them so that the compiler is satisfied.

As a compromise for everyone we possibly could come up with a way which serves 
both, simplicity and precision.

For the next bikeshedding example I’m going to use ' for multi-lined strings:

// Simplicity which supports indent but at a cost of no   
// leading or trailing space characters
let string1 = 'my
multiline
string'

print(string1) // prints "mymultilinestring"

let string2 = 'my \   
multiline \
string'
  
// Trailing precision
print(string2) // prints "my multiline string"

let string3 = 'my
' multiline
' string'
  
// Leading precision
print(string3) // prints "my multiline string"

let string4 = 'my \
' multiline \
' string'
  
// Leading and trailing precision
print(string4) // prints "my  multiline  string" (Note: 2x two whitespaces)

let string5 = 'my\
'multiline\
'string'
  
// Leading and trailing precision
// Provide a fix-it to remove some `\` and `'` characters
// because it equals `string1`
print(string5) // prints "mymultilinestring"

let string6 = 'my \
'multiline \
'string'
  
// Leading and trailing precision
// Provide a fix-it to remove some `'` characters
// because it equals `string2`
print(string6) // prints "my multiline string"

let string7 = 'my\
' multiline\
' string'
  
// Leading and trailing precision
// Provide a fix-it to remove some `\` characters
// because it equals `string3`
print(string7) // prints "my multiline string"
Comments should be only allowed after the escaping character. string1 can only 
have comments after the last line of that string.

I think a model like this could have the best from both worlds.

Personally I dislike the idea of """ and would rather want a model from above 
with " and \ or as written.



-- 
Adrian Zubarev
Sent with Airmail

Am 3. April 2017 um 11:56:12, Daniel Leping (dan...@crossroadlabs.xyz) schrieb:

What about """ notation?

It could become something like:
let mys = """my
          multiline
          string"""

On Mon, 3 Apr 2017 at 12:35 Adrian Zubarev via swift-evolution 

Re: [swift-evolution] multi-line string literals.

[Haravikk via swift-evolution]

I still don't really see what's so wrong with just doing:

let foo = "This my " +
  "multiline " +
  "string"

It's only one or two characters more than other proposed styles, and IMO it's 
not something that should come up all that often; I'm kind of uncomfortable 
with the idea of encouraging multi-line strings in code, as really these should 
be localised properly instead.

If there needs to be an alternative I'd say just allow omission of the 
concatenation operator like so:

let foo = "This my "
  "multiline "
  "string"

The caveat for this is that we would need to disallow a string as a statement, 
or require explicit concatenation anywhere it might be ambiguous like so:

let foo = "This my "
  "multiline "
  "string".capitalized // Warning: Use concatenation (+) or let _ = to 
disambiguate

This would need become one of the following:

let foo = "This my "
  "multiline " + // Clearly concatenated
  "string".capitalized


let foo = "This my " +
  "multiline "
let _ = "string".capitalized // Clearly separate for some reason

But yeah, I don't know if we should really encourage multi-line comments too 
much; if I had my way we'd somehow make them more awkward to use, just to stop 
people using them 

> On 3 Apr 2017, at 13:36, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I don’t really think this is about how to indicate a multi-lined string, 
> where the string starts and ends with something like ", ' or """ is trivial 
> to me. It’s just a decision to make. However the main debate I see with that 
> topic is the ambiguity from the readers perspective.
> 
> In your example I assume you want a result to match this: “my multiline 
> string”, but what if you need precision? Should we really fallback to single 
> line string then? What if you want to print some XML file with all it’s 
> indent calculated with whitespaces rather than tabs? The multiline version 
> like that won’t work, and if your string is huge you’ll end up at a place 
> where we already are. This doesn’t solve the main then because we could 
> otherwise simply allow this today:
> 
> let string = "my
> multiline
> string"
> I’m only speaking for my personal preference, others might see it completely 
> different. However I’m totally sure multiline strings solve more than simply 
> being able to write them so that the compiler is satisfied.
> 
> As a compromise for everyone we possibly could come up with a way which 
> serves both, simplicity and precision. 
> 
> For the next bikeshedding example I’m going to use ' for multi-lined strings:
> 
> // Simplicity which supports indent but at a cost of no  
> // leading or trailing space characters
> let string1 = 'my
> multiline
> string'
> 
> print(string1) // prints "mymultilinestring"
> 
> let string2 = 'my \  
> multiline \
> string'
>  
> // Trailing precision
> print(string2) // prints "my multiline string"
> 
> let string3 = 'my
> ' multiline
> ' string'
>  
> // Leading precision
> print(string3) // prints "my multiline string"
> 
> let string4 = 'my \
> ' multiline \
> ' string'
>  
> // Leading and trailing precision
> print(string4) // prints "my  multiline  string" (Note: 2x two whitespaces)
> 
> let string5 = 'my\
> 'multiline\
> 'string'
>  
> // Leading and trailing precision
> // Provide a fix-it to remove some `\` and `'` characters
> // because it equals `string1`
> print(string5) // prints "mymultilinestring"
> 
> let string6 = 'my \
> 'multiline \
> 'string'
>  
> // Leading and trailing precision
> // Provide a fix-it to remove some `'` characters
> // because it equals `string2`
> print(string6) // prints "my multiline string"
> 
> let string7 = 'my\
> ' multiline\
> ' string'
>  
> // Leading and trailing precision
> // Provide a fix-it to remove some `\` characters
> // because it equals `string3`
> print(string7) // prints "my multiline string"
> Comments should be only allowed after the escaping character. string1 can 
> only have comments after the last line of that string.
> 
> I think a model like this could have the best from both worlds.
> 
> Personally I dislike the idea of """ and would rather want a model from above 
> with " and \ or as written.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 3. April 2017 um 11:56:12, Daniel Leping (dan...@crossroadlabs.xyz 
> ) schrieb:
> 
>> What about """ notation?
>> 
>> It could become something like:
>> let mys = """my
>>   multiline
>>   string"""
>> 
>> On Mon, 3 Apr 2017 at 12:35 Adrian Zubarev via swift-evolution 
>> > wrote:
>> Simply because it’s always a zero to n space characters at the start of the 
>> line 

Re: [swift-evolution] multi-line string literals.

[Daniel Leping via swift-evolution]

I think it quite some overcomplicates the situation. I would prefer:
1. Distinct multiline strings, (e.g. not " but rather """)
2. We could use something like this for precision:
let mys1 = """my"
"multiline"
"string"""
// equivalent to "mymultilinestring"

let mys2 = """my
   multiline
   string"""
// equivalent to "my\nmultiline\nstring"


This looks simpler to me, still you can do everything with it.

On Mon, 3 Apr 2017 at 15:36 Adrian Zubarev 
wrote:

> I don’t really think this is about how to indicate a multi-lined string,
> where the string starts and ends with something like ", ' or """ is
> trivial to me. It’s just a decision to make. However the main debate I see
> with that topic is the ambiguity from the readers perspective.
>
> In your example I assume you want a result to match this: “my multiline
> string”, but what if you need precision? Should we really fallback to
> single line string then? What if you want to print some XML file with all
> it’s indent calculated with whitespaces rather than tabs? The multiline
> version like that won’t work, and if your string is huge you’ll end up at a
> place where we already are. This doesn’t solve the main then because we
> could otherwise simply allow this today:
>
> let string = "my
> multiline
> string"
>
> I’m only speaking for my personal preference, others might see it
> completely different. However I’m totally sure multiline strings solve more
> than simply being able to write them so that the compiler is satisfied.
>
> As a compromise for everyone we possibly could come up with a way which
> serves both, simplicity and precision.
>
> For the next bikeshedding example I’m going to use ' for multi-lined
> strings:
>
> // Simplicity which supports indent but at a cost of no
> // leading or trailing space characters
> let string1 = 'my
> multiline
> string'
>
> print(string1) // prints "mymultilinestring"
>
> let string2 = 'my \
> multiline \
> string'
>
> // Trailing precision
> print(string2) // prints "my multiline string"
>
> let string3 = 'my
> ' multiline
> ' string'
>
> // Leading precision
> print(string3) // prints "my multiline string"
>
> let string4 = 'my \
> ' multiline \
> ' string'
>
> // Leading and trailing precision
> print(string4) // prints "my  multiline  string" (Note: 2x two whitespaces)
>
> let string5 = 'my\
> 'multiline\
> 'string'
>
> // Leading and trailing precision
> // Provide a fix-it to remove some `\` and `'` characters
> // because it equals `string1`
> print(string5) // prints "mymultilinestring"
>
> let string6 = 'my \
> 'multiline \
> 'string'
>
> // Leading and trailing precision
> // Provide a fix-it to remove some `'` characters
> // because it equals `string2`
> print(string6) // prints "my multiline string"
>
> let string7 = 'my\
> ' multiline\
> ' string'
>
> // Leading and trailing precision
> // Provide a fix-it to remove some `\` characters
> // because it equals `string3`
> print(string7) // prints "my multiline string"
>
> Comments should be only allowed after the escaping character. string1 can
> only have comments after the last line of that string.
>
> I think a model like this could have the best from both worlds.
> --
>
> Personally I dislike the idea of """ and would rather want a model from
> above with " and \ or as written.
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 3. April 2017 um 11:56:12, Daniel Leping (dan...@crossroadlabs.xyz)
> schrieb:
>
> What about """ notation?
>
> It could become something like:
> let mys = """my
>   multiline
>   string"""
>
> On Mon, 3 Apr 2017 at 12:35 Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Simply because it’s always a zero to n space characters at the start of
> the line and at its end. You cannot predict the need of every multi-line
> string.
>
> I don’t disagree that typing out some extra " and \ is tedious, but what
> I really like about it is, it’s precise.
>
> let string =
> "Hello   \ // Three trailing space characters
> "Swift\
> "   4.0"   // Three leading space characters
>
> print(string) // prints: "Hello___Swift___4.0" where _ ist a space character
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 3. April 2017 um 11:27:58, Charlie Monroe (char...@charliemonroe.net)
> schrieb:
>
> Yes, but with ", you need to escape " occurrences - which is a fairly
> common character - I'd say more common than |.
>
> The trailing whitespace - why can't it just be included in the string
> automatically? Just for supporting comments?
>
> On Apr 3, 2017, at 11:19 AM, Adrian Zubarev <
> adrian.zuba...@devandartist.com> wrote:
>
> This is almost the same as proposed, but we use " instead of |, however
> you still don’t have trailing space characters covered like this.
>
>
>
> --
> 

Re: [swift-evolution] multi-line string literals.

[Adrian Zubarev via swift-evolution]

I don’t really think this is about how to indicate a multi-lined string, where 
the string starts and ends with something like ", ' or """ is trivial to me. 
It’s just a decision to make. However the main debate I see with that topic is 
the ambiguity from the readers perspective.

In your example I assume you want a result to match this: “my multiline 
string”, but what if you need precision? Should we really fallback to single 
line string then? What if you want to print some XML file with all it’s indent 
calculated with whitespaces rather than tabs? The multiline version like that 
won’t work, and if your string is huge you’ll end up at a place where we 
already are. This doesn’t solve the main then because we could otherwise simply 
allow this today:

let string = "my
multiline
string"
I’m only speaking for my personal preference, others might see it completely 
different. However I’m totally sure multiline strings solve more than simply 
being able to write them so that the compiler is satisfied.

As a compromise for everyone we possibly could come up with a way which serves 
both, simplicity and precision.

For the next bikeshedding example I’m going to use ' for multi-lined strings:

// Simplicity which supports indent but at a cost of no  
// leading or trailing space characters
let string1 = 'my
multiline
string'

print(string1) // prints "mymultilinestring"

let string2 = 'my \  
multiline \
string'
 
// Trailing precision
print(string2) // prints "my multiline string"

let string3 = 'my
' multiline
' string'
 
// Leading precision
print(string3) // prints "my multiline string"

let string4 = 'my \
' multiline \
' string'
 
// Leading and trailing precision
print(string4) // prints "my  multiline  string" (Note: 2x two whitespaces)

let string5 = 'my\
'multiline\
'string'
 
// Leading and trailing precision
// Provide a fix-it to remove some `\` and `'` characters
// because it equals `string1`
print(string5) // prints "mymultilinestring"

let string6 = 'my \
'multiline \
'string'
 
// Leading and trailing precision
// Provide a fix-it to remove some `'` characters
// because it equals `string2`
print(string6) // prints "my multiline string"

let string7 = 'my\
' multiline\
' string'
 
// Leading and trailing precision
// Provide a fix-it to remove some `\` characters
// because it equals `string3`
print(string7) // prints "my multiline string"
Comments should be only allowed after the escaping character. string1 can only 
have comments after the last line of that string.

I think a model like this could have the best from both worlds.

Personally I dislike the idea of """ and would rather want a model from above 
with " and \ or as written.



-- 
Adrian Zubarev
Sent with Airmail

Am 3. April 2017 um 11:56:12, Daniel Leping (dan...@crossroadlabs.xyz) schrieb:

What about """ notation?

It could become something like:
let mys = """my
          multiline
          string"""

On Mon, 3 Apr 2017 at 12:35 Adrian Zubarev via swift-evolution 
 wrote:
Simply because it’s always a zero to n space characters at the start of the 
line and at its end. You cannot predict the need of every multi-line string.

I don’t disagree that typing out some extra " and \ is tedious, but what I 
really like about it is, it’s precise.

let string =   
"Hello   \ // Three trailing space characters
"Swift\
"   4.0"   // Three leading space characters
  
print(string) // prints: "Hello___Swift___4.0" where _ ist a space character


-- 
Adrian Zubarev
Sent with Airmail

Am 3. April 2017 um 11:27:58, Charlie Monroe (char...@charliemonroe.net) 
schrieb:

Yes, but with ", you need to escape " occurrences - which is a fairly common 
character - I'd say more common than |.

The trailing whitespace - why can't it just be included in the string 
automatically? Just for supporting comments?

On Apr 3, 2017, at 11:19 AM, Adrian Zubarev  
wrote:

This is almost the same as proposed, but we use " instead of |, however you 
still don’t have trailing space characters covered like this.




-- 
Adrian Zubarev
Sent with Airmail

Am 3. April 2017 um 11:16:41, Charlie Monroe (char...@charliemonroe.net) 
schrieb:

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 = '''
| 
| 
| <...>
| 
'''

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  
wrote:

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

Re: [swift-evolution] multi-line string literals.

[Daniel Leping via swift-evolution]

What about """ notation?

It could become something like:
let mys = """my
  multiline
  string"""

On Mon, 3 Apr 2017 at 12:35 Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> Simply because it’s always a zero to n space characters at the start of
> the line and at its end. You cannot predict the need of every multi-line
> string.
>
> I don’t disagree that typing out some extra " and \ is tedious, but what
> I really like about it is, it’s precise.
>
> let string =
> "Hello   \ // Three trailing space characters
> "Swift\
> "   4.0"   // Three leading space characters
>
> print(string) // prints: "Hello___Swift___4.0" where _ ist a space character
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 3. April 2017 um 11:27:58, Charlie Monroe (char...@charliemonroe.net)
> schrieb:
>
> Yes, but with ", you need to escape " occurrences - which is a fairly
> common character - I'd say more common than |.
>
> The trailing whitespace - why can't it just be included in the string
> automatically? Just for supporting comments?
>
> On Apr 3, 2017, at 11:19 AM, Adrian Zubarev <
> adrian.zuba...@devandartist.com> wrote:
>
> This is almost the same as proposed, but we use " instead of |, however
> you still don’t have trailing space characters covered like this.
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 3. April 2017 um 11:16:41, Charlie Monroe (char...@charliemonroe.net)
> schrieb:
>
> 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 = '''
> |
> |
> | <...>
> |
> '''
>
> 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.zuba...@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 (char...@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 = '''
> 
> 
> '''
>
>
> 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 = "
> "
> "
> "\(author)
> "XML Developer's Guide
> "Computer
> "44.95
> "2000-10-01
> "An in-depth look at creating applications with 
> XML.
> "
> "
> ""
>
> 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 = "\
> "\ // If you need you can comment here
> "\
> "\(author)\
> "XML Developer's Guide\
> "Computer\
> "44.95\
> "2000-10-01\
> "An in-depth look at creating applications with 
> XML.\
> "\
> "\
> ""
>
> 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 

Re: [swift-evolution] multi-line string literals.

[Adrian Zubarev via swift-evolution]

Simply because it’s always a zero to n space characters at the start of the 
line and at its end. You cannot predict the need of every multi-line string.

I don’t disagree that typing out some extra " and \ is tedious, but what I 
really like about it is, it’s precise.

let string =  
"Hello   \ // Three trailing space characters
"Swift\
"   4.0"   // Three leading space characters
 
print(string) // prints: "Hello___Swift___4.0" where _ ist a space character


-- 
Adrian Zubarev
Sent with Airmail

Am 3. April 2017 um 11:27:58, Charlie Monroe (char...@charliemonroe.net) 
schrieb:

Yes, but with ", you need to escape " occurrences - which is a fairly common 
character - I'd say more common than |.

The trailing whitespace - why can't it just be included in the string 
automatically? Just for supporting comments?

On Apr 3, 2017, at 11:19 AM, Adrian Zubarev  
wrote:

This is almost the same as proposed, but we use " instead of |, however you 
still don’t have trailing space characters covered like this.




-- 
Adrian Zubarev
Sent with Airmail

Am 3. April 2017 um 11:16:41, Charlie Monroe (char...@charliemonroe.net) 
schrieb:

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 = '''
| 
| 
| <...>
| 
'''

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  
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 (char...@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 = '''
 
 
'''


On Apr 3, 2017, at 9:01 AM, Adrian Zubarev via swift-evolution 
 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 = "
"
"
"\(author)
"XML Developer's Guide
"Computer
"44.95
"2000-10-01
"An in-depth look at creating applications with 
XML.
"
"
""
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 = "\ 
"\ // If you need you can comment here
"\
"\(author)\
"XML Developer's Guide\
"Computer\
"44.95\
"2000-10-01\
"An in-depth look at creating applications with 
XML.\
"\
"\
""
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





___

Re: [swift-evolution] multi-line string literals.

[Charlie Monroe via swift-evolution]

Yes, but with ", you need to escape " occurrences - which is a fairly common 
character - I'd say more common than |.

The trailing whitespace - why can't it just be included in the string 
automatically? Just for supporting comments?

> On Apr 3, 2017, at 11:19 AM, Adrian Zubarev  
> wrote:
> 
> This is almost the same as proposed, but we use " instead of |, however you 
> still don’t have trailing space characters covered like this.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 3. April 2017 um 11:16:41, Charlie Monroe (char...@charliemonroe.net 
> ) schrieb:
> 
>> 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 = '''
>> | 
>> | 
>> | <...>
>> | 
>> '''
>> 
>> 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 
>>> > 
>>> 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 (char...@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 = '''
  
  
 '''
 
 
> On Apr 3, 2017, at 9:01 AM, Adrian Zubarev via swift-evolution 
> > 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 = "
> "
> "
> "\(author)
> "XML Developer's Guide
> "Computer
> "44.95
> "2000-10-01
> "An in-depth look at creating applications with 
> XML.
> "
> "
> ""
> 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 = "\
> "\ // If you need you can comment here
> "\
> "\(author)\
> "XML Developer's Guide\
> "Computer\
> "44.95\
> "2000-10-01\
> "An in-depth look at creating applications with 
> XML.\
> "\
> "\
> ""
> 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
> 
> 

Re: [swift-evolution] multi-line string literals.

[Adrian Zubarev via swift-evolution]

This is almost the same as proposed, but we use " instead of |, however you 
still don’t have trailing space characters covered like this.



-- 
Adrian Zubarev
Sent with Airmail

Am 3. April 2017 um 11:16:41, Charlie Monroe (char...@charliemonroe.net) 
schrieb:

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 = '''
| 
| 
| <...>
| 
'''

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  
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 (char...@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 = '''
 
 
'''


On Apr 3, 2017, at 9:01 AM, Adrian Zubarev via swift-evolution 
 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 = "
"
"
"\(author)
"XML Developer's Guide
"Computer
"44.95
"2000-10-01
"An in-depth look at creating applications with 
XML.
"
"
""
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 = "\
"\ // If you need you can comment here
"\
"\(author)\
"XML Developer's Guide\
"Computer\
"44.95\
"2000-10-01\
"An in-depth look at creating applications with 
XML.\
"\
"\
""
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

Re: [swift-evolution] multi-line string literals.

[Adrian Zubarev via swift-evolution]

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 (char...@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 = '''
 
 
'''


On Apr 3, 2017, at 9:01 AM, Adrian Zubarev via swift-evolution 
 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 = "
"
"
"\(author)
"XML Developer's Guide
"Computer
"44.95
"2000-10-01
"An in-depth look at creating applications with 
XML.
"
"
""
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 = "\   
"\ // If you need you can comment here
"\
"\(author)\
"XML Developer's Guide\
"Computer\
"44.95\
"2000-10-01\
"An in-depth look at creating applications with 
XML.\
"\
"\
""
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

Re: [swift-evolution] multi-line string literals.

[Charlie Monroe via swift-evolution]

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 = '''
 
 
'''


> On Apr 3, 2017, at 9:01 AM, Adrian Zubarev via swift-evolution 
>  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 = "
> "
> "
> "\(author)
> "XML Developer's Guide
> "Computer
> "44.95
> "2000-10-01
> "An in-depth look at creating applications with 
> XML.
> "
> "
> ""
> 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 = "\  
> "\ // If you need you can comment here
> "\
> "\(author)\
> "XML Developer's Guide\
> "Computer\
> "44.95\
> "2000-10-01\
> "An in-depth look at creating applications with 
> XML.\
> "\
> "\
> ""
> 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

Re: [swift-evolution] multi-line string literals.

[Adrian Zubarev via swift-evolution]

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 = "
"
"
"\(author)
"XML Developer's Guide
"Computer
"44.95
"2000-10-01
"An in-depth look at creating applications with 
XML.
"
"
""
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 = "\  
"\ // If you need you can comment here
"\
"\(author)\
"XML Developer's Guide\
"Computer\
"44.95\
"2000-10-01\
"An in-depth look at creating applications with 
XML.\
"\
"\
""
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

Re: [swift-evolution] multi-line string literals.

[Leonardo Pessoa via swift-evolution]

That's my point. You start with a little two-line string and when you see
you have those all over your code. A feature is never bad but a feature
that may be misused creates temptation to go for bad programming practices,
like "I'm using it just this once" and once you're there you never stop.

You can still have multiline string in Swift by concatenating strings as
you already pointed but that discourages you from having too many lines
glued like this. The approach of loading them from a file makes the code
cleaner to read and the string cleaner to maintain and not having the means
to have the lines in your code will push you to do the right thing and load
them from a file from start.


On 13 May 2016 at 01:16, Ricardo Parada  wrote:

> I don't think the intent of multi-line string literals is to replace files
> or templating libraries. I use those all the time and are superior.
>
> I think it would be handy and make it more pleasant to use for simple
> cases.
>
> Who has not run into a little multi-line literal in your code where you
> concatenate the pieces using +, add \n at the end of each line and have to
> escape quotes?
>
>
> On May 12, 2016, at 12:36 PM, Leonardo Pessoa  wrote:
>
> 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( @"
>>"
>>"   
>>"   \(author)
>>"   XML Developer's Guide
>>"   Computer
>>"   44.95
>>"   2000-10-01
>>"   An in-depth look at creating applications
>> withXML.
>>"   
>>"\n
>> )
>>
>> //additionally using a +" could be used to indicate a line break
>> foo( @"
>>   +"
>>   +"   
>>   +"   \(author)
>>   +"   XML Developer's Guide
>>   +"   Computer
>>   +"   44.95
>>   +"   2000-10-01
>>   +"   An in-depth look at creating applications
>> withXML.
>>   +"   
>>   +"\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  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
>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] multi-line string literals.

[Ricardo Parada via swift-evolution]

I don't think the intent of multi-line string literals is to replace files or 
templating libraries. I use those all the time and are superior. 

I think it would be handy and make it more pleasant to use for simple cases. 

Who has not run into a little multi-line literal in your code where you 
concatenate the pieces using +, add \n at the end of each line and have to 
escape quotes?


> On May 12, 2016, at 12:36 PM, Leonardo Pessoa  wrote:
> 
> 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 
>>  wrote:
>> Something like this might work
>> 
>> //string ends on the first line that doesnt start with a "
>> foo( @"
>>"
>>"   
>>"   \(author)
>>"   XML Developer's Guide
>>"   Computer
>>"   44.95
>>"   2000-10-01
>>"   An in-depth look at creating applications with   
>>  XML.
>>"   
>>"\n
>> )
>> 
>> //additionally using a +" could be used to indicate a line break
>> foo( @"
>>   +"
>>   +"   
>>   +"   \(author)
>>   +"   XML Developer's Guide
>>   +"   Computer
>>   +"   44.95
>>   +"   2000-10-01
>>   +"   An in-depth look at creating applications with   
>>  XML.
>>   +"   
>>   +"\n
>> )
>> 
>>> On May 11, 2016, at 9:48 PM, Ricardo Parada via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> 
>>> On May 11, 2016, at 2:34 PM, Vladimir.S  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
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] multi-line string literals.

[Vladimir.S via swift-evolution]

Inline

On 11.05.2016 21:04, Ricardo Parada wrote:



On May 11, 2016, at 12:55 PM, Vladimir.S > wrote:


On 11.05.2016 19:38, Ricardo Parada wrote:

I did not suggest the single quote because it is commonly found in the
English language and we would have to escape it.


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


I don’t have a document.  I’ve seen different proposals.
I have just been commenting on the proposals in this thread.


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




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


I cannot speak for them, but I think that if we want to get a feel about
which alternatives get the most traction, I think all alternatives should
be considered, including yours and mine.  :-)


Got it :-)





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



I don’t think we need to worry about the opening quote occurring in the
text because we just need the closing delimiter to find out where it ends.
 For example:


letsourceCode =@“NSString *firstName = @“John”;
  "NSString *lastName = @“Doe”;
  “NSString *fullName = [NSString stringWithFormat: @“%@
%@“, firstName, lastName];"@

The one that would be a bit of a problem is the closing delimiter,


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






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





On May 11, 2016, at 10:50 AM, Vladimir.S via swift-evolution
> 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 == ' ' ' '\(author) // note '' here in
string 'XML Developer''s Guide '
Computer '44.95 '
2000-10-01 'An
in-depth look at XML. ' '')

(also needs to duplicate single quote if in text. the compromise,
yes.)


On 10.05.2016 9:53, John Holdsworth via swift-evolution wrote: I’ve
assembled a gist to summarise the main proposals of this thread.

https://gist.github.com/johnno1962/5c325a16838ad3c73e0f109a514298bf

At the moment there seem to be four proposals for multi-line
strings:

1) Bent’s proposal for continuation quotes where if a conventional
string does not close, if the first non-whitespace character of the
next line is “ (or perhaps |) the string is continued. This gives
you precise control over exactly what is in the string.

2) Tyler's original proposal involving strings that can contain
newlines delimited “””like this“”” as they are in python or, _”like
this“_. This works well in external editors and on github.
Indentation is catered for by stripping any whitespace before the
closing quote from all lines in the string.

3) HEREDOC syntax <<“TAG” or <<‘TAG’ taken from languages like Perl
subject to the same indentation removal rules as “””strings”””
above. This has the advantage that the literal is clearly separated
from your code.

4) Heck it all, why not all three syntaxes or some combination.

(There is a separate feature that all string literals can be
prefixed by e as in e”\w\d+” to turn of all escape processing for
another day)

While the Swift Lexer could easily accommodate all these syntaxes
there was talk early on that Swift has more of a "one way, maximally
elegant” ethos and indeed I find it difficult imagine the Swift Book
breathlessly describing all three formats so I’m wondering if push
came to shove which format people would chose?

My vote having undergone a "road to damascus" moment now we know it
is available sooner rather than 

Re: [swift-evolution] multi-line string literals.

[Ricardo Parada via swift-evolution]

> On May 11, 2016, at 12:55 PM, Vladimir.S  wrote:
> 
> 
> On 11.05.2016 19:38, Ricardo Parada wrote:
>> I did not suggest the single quote because it is commonly found in the
>> English language and we would have to escape it.
> 
> Wel.. in your document you have a number of variants of multi-line 'feature' 
> implementations with different pros/cons for each.

I don’t have a document.  I’ve seen different proposals.  
I have just been commenting on the proposals in this thread.

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

I cannot speak for them, but I think that if we want to get a feel about which 
alternatives get the most traction, I think all alternatives should be 
considered, including yours and mine.  :-)

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

I don’t think we need to worry about the opening quote occurring in the text 
because we just need the closing delimiter to find out where it ends.  For 
example:


let sourceCode = @“NSString *firstName = @“John”;
  "NSString *lastName = @“Doe”;
  “NSString *fullName = [NSString stringWithFormat: @“%@ %@“, 
firstName, lastName];"@

The one that would be a bit of a problem is the closing delimiter,


> 
> And what do you suggest to do if we *have* `"@` inside the text we want to 
> use ?
> 
>> 
>> 
>>> On May 11, 2016, at 10:50 AM, Vladimir.S via swift-evolution
>>>  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 == ' ' '>> empty=""> '\(author) // note '' here in
>>> string 'XML Developer''s Guide '
>>> Computer '44.95 '
>>> 2000-10-01 'An
>>> in-depth look at XML. ' '')
>>> 
>>> (also needs to duplicate single quote if in text. the compromise,
>>> yes.)
>>> 
 On 10.05.2016 9:53, John Holdsworth via swift-evolution wrote: I’ve
 assembled a gist to summarise the main proposals of this thread.
 
 https://gist.github.com/johnno1962/5c325a16838ad3c73e0f109a514298bf
 
 At the moment there seem to be four proposals for multi-line
 strings:
 
 1) Bent’s proposal for continuation quotes where if a conventional
 string does not close, if the first non-whitespace character of the
 next line is “ (or perhaps |) the string is continued. This gives
 you precise control over exactly what is in the string.
 
 2) Tyler's original proposal involving strings that can contain
 newlines delimited “””like this“”” as they are in python or, _”like
 this“_. This works well in external editors and on github.
 Indentation is catered for by stripping any whitespace before the
 closing quote from all lines in the string.
 
 3) HEREDOC syntax <<“TAG” or <<‘TAG’ taken from languages like Perl
 subject to the same indentation removal rules as “””strings”””
 above. This has the advantage that the literal is clearly separated
 from your code.
 
 4) Heck it all, why not all three syntaxes or some combination.
 
 (There is a separate feature that all string literals can be
 prefixed by e as in e”\w\d+” to turn of all escape processing for
 another day)
 
 While the Swift Lexer could easily accommodate all these syntaxes
 there was talk early on that Swift has more of a "one way, maximally
 elegant” ethos and indeed I find it difficult imagine the Swift Book
 breathlessly describing all three formats so I’m wondering if push
 came to shove which format people would chose?
 

Re: [swift-evolution] multi-line string literals.

[Vladimir.S via swift-evolution]

On 11.05.2016 19:38, Ricardo Parada wrote:

I did not suggest the single quote because it is commonly found in the
English language and we would have to escape it.


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


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




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



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






On May 11, 2016, at 10:50 AM, Vladimir.S via swift-evolution
 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 == ' ' ' '\(author) // note '' here in
string 'XML Developer''s Guide '
Computer '44.95 '
2000-10-01 'An
in-depth look at XML. ' '')

(also needs to duplicate single quote if in text. the compromise,
yes.)


On 10.05.2016 9:53, John Holdsworth via swift-evolution wrote: I’ve
assembled a gist to summarise the main proposals of this thread.

https://gist.github.com/johnno1962/5c325a16838ad3c73e0f109a514298bf

At the moment there seem to be four proposals for multi-line
strings:

1) Bent’s proposal for continuation quotes where if a conventional
string does not close, if the first non-whitespace character of the
next line is “ (or perhaps |) the string is continued. This gives
you precise control over exactly what is in the string.

2) Tyler's original proposal involving strings that can contain
newlines delimited “””like this“”” as they are in python or, _”like
this“_. This works well in external editors and on github.
Indentation is catered for by stripping any whitespace before the
closing quote from all lines in the string.

3) HEREDOC syntax <<“TAG” or <<‘TAG’ taken from languages like Perl
subject to the same indentation removal rules as “””strings”””
above. This has the advantage that the literal is clearly separated
from your code.

4) Heck it all, why not all three syntaxes or some combination.

(There is a separate feature that all string literals can be
prefixed by e as in e”\w\d+” to turn of all escape processing for
another day)

While the Swift Lexer could easily accommodate all these syntaxes
there was talk early on that Swift has more of a "one way, maximally
elegant” ethos and indeed I find it difficult imagine the Swift Book
breathlessly describing all three formats so I’m wondering if push
came to shove which format people would chose?

My vote having undergone a "road to damascus" moment now we know it
is available sooner rather than later is.. HEREDOC! It’s well
understood and while at first it would seem to not be a good fit for
Swift produces clear code.

Votes?

John


// Multi-line string proposals //
https://github.com/apple/swift/pull/2275

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




// These examples should load in the prototype toolchain available

here: //
http://johnholdsworth.com/swift-LOCAL-2016-05-09-a-osx.tar.gz

// The prototype currently parses three new forms of quoting //
These new types are still string literals for the grammar.

"the existing string literal format" _"a format that does not
require you to escape " characters"_ // possibly redundant """a
python-style syntax that will accept "'s and newlines in the
string""" <<"HEREDOC" A full heredoc implementation (will always end
in a newline) HEREDOC

// These strings can be modified by prefixing the string by letters
// There is currently only one, "e" to disable escape processing. //
This is primarily used when specifying regular expressions.

letstr = "print(\"Hello, world!\\n\")"

assert( 

Re: [swift-evolution] multi-line string literals.

[Ricardo Parada via swift-evolution]

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 
>  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 == '
>'
>'
>'\(author)
>// note '' here in string
>'XML Developer''s Guide
>'Computer
>'44.95
>'2000-10-01
>'An in-depth look at XML.
>'
>'')
> 
> (also needs to duplicate single quote if in text. the compromise, yes.)
> 
>> On 10.05.2016 9:53, John Holdsworth via swift-evolution wrote:
>> I’ve assembled a gist to summarise the main proposals of this thread.
>> 
>> https://gist.github.com/johnno1962/5c325a16838ad3c73e0f109a514298bf
>> 
>> At the moment there seem to be four proposals for multi-line strings:
>> 
>> 1) Bent’s proposal for continuation quotes where if a conventional string
>> does not close, if the first non-whitespace character of the next line is “
>> (or perhaps |) the string is continued. This gives you precise control
>> over exactly what is in the string.
>> 
>> 2) Tyler's original proposal involving strings that can contain newlines
>> delimited “””like this“”” as they are in python or, _”like this“_. This works
>> well in external editors and on github. Indentation is catered for by
>> stripping
>> any whitespace before the closing quote from all lines in the string.
>> 
>> 3) HEREDOC syntax <<“TAG” or <<‘TAG’ taken from languages like Perl
>> subject to the same indentation removal rules as “””strings””” above. This
>> has the advantage that the literal is clearly separated from your code.
>> 
>> 4) Heck it all, why not all three syntaxes or some combination.
>> 
>> (There is a separate feature that all string literals can be prefixed by
>> e as in e”\w\d+” to turn of all escape processing for another day)
>> 
>> While the Swift Lexer could easily accommodate all these syntaxes there was
>> talk early on that Swift has more of a "one way, maximally elegant” ethos and
>> indeed I find it difficult imagine the Swift Book breathlessly describing
>> all three
>> formats so I’m wondering if push came to shove which format people would 
>> chose?
>> 
>> My vote having undergone a "road to damascus" moment now we know it is
>> available sooner rather than later is.. HEREDOC! It’s well understood and
>> while at first it would seem to not be a good fit for Swift produces clear
>> code.
>> 
>> Votes?
>> 
>> John
>> 
>> 
>>// Multi-line string proposals
>>// https://github.com/apple/swift/pull/2275
>> 
>>// swift-evolution thread:
>>//
>> http://thread.gmane.org/gmane.comp.lang.swift.evolution/904/focus=15133
>> 
>>// These examples should load in the prototype toolchain available
>> here:
>>// http://johnholdsworth.com/swift-LOCAL-2016-05-09-a-osx.tar.gz
>> 
>>// The prototype currently parses three new forms of quoting
>>// These new types are still string literals for the grammar.
>> 
>>"the existing string literal format"
>>_"a format that does not require you to escape " characters"_ //
>> possibly redundant
>>"""a python-style syntax that will accept "'s and newlines in the
>> string"""
>><<"HEREDOC"
>>A full heredoc implementation (will always end in a newline)
>>HEREDOC
>> 
>>// These strings can be modified by prefixing the string by letters
>>// There is currently only one, "e" to disable escape processing.
>>// This is primarily used when specifying regular expressions.
>> 
>>letstr = "print(\"Hello, world!\\n\")"
>> 
>>assert( e"print(\"Hello, world!\n\")"== str )
>>assert( 

Re: [swift-evolution] multi-line string literals.

[Vladimir.S via swift-evolution]

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 == '
'
'   
'   \(author)
// note '' here in string
'   XML Developer''s Guide
'   Computer
'   44.95
'   2000-10-01
'   An in-depth look at XML.
'   
'')

(also needs to duplicate single quote if in text. the compromise, yes.)

On 10.05.2016 9:53, John Holdsworth via swift-evolution wrote:

I’ve assembled a gist to summarise the main proposals of this thread.

https://gist.github.com/johnno1962/5c325a16838ad3c73e0f109a514298bf

At the moment there seem to be four proposals for multi-line strings:

1) Bent’s proposal for continuation quotes where if a conventional string
does not close, if the first non-whitespace character of the next line is “
(or perhaps |) the string is continued. This gives you precise control
over exactly what is in the string.

2) Tyler's original proposal involving strings that can contain newlines
delimited “””like this“”” as they are in python or, _”like this“_. This works
well in external editors and on github. Indentation is catered for by
stripping
any whitespace before the closing quote from all lines in the string.

3) HEREDOC syntax <<“TAG” or <<‘TAG’ taken from languages like Perl
subject to the same indentation removal rules as “””strings””” above. This
has the advantage that the literal is clearly separated from your code.

4) Heck it all, why not all three syntaxes or some combination.

(There is a separate feature that all string literals can be prefixed by
e as in e”\w\d+” to turn of all escape processing for another day)

While the Swift Lexer could easily accommodate all these syntaxes there was
talk early on that Swift has more of a "one way, maximally elegant” ethos and
indeed I find it difficult imagine the Swift Book breathlessly describing
all three
formats so I’m wondering if push came to shove which format people would chose?

My vote having undergone a "road to damascus" moment now we know it is
available sooner rather than later is.. HEREDOC! It’s well understood and
while at first it would seem to not be a good fit for Swift produces clear
code.

Votes?

John


// Multi-line string proposals
// https://github.com/apple/swift/pull/2275

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

// These examples should load in the prototype toolchain available
here:
// http://johnholdsworth.com/swift-LOCAL-2016-05-09-a-osx.tar.gz

// The prototype currently parses three new forms of quoting
// These new types are still string literals for the grammar.

"the existing string literal format"
_"a format that does not require you to escape " characters"_ //
possibly redundant
"""a python-style syntax that will accept "'s and newlines in the
string"""
<<"HEREDOC"
A full heredoc implementation (will always end in a newline)
HEREDOC

// These strings can be modified by prefixing the string by letters
// There is currently only one, "e" to disable escape processing.
// This is primarily used when specifying regular expressions.

letstr = "print(\"Hello, world!\\n\")"

assert( e"print(\"Hello, world!\n\")"== str )
assert( e_"print("Hello, world!\n")"_ == str )
assert( e"""print("Hello, world!\n")""" == str )

// Continuation quotes allow you to extend a standard string literal
// over multiple lines. If a string does not close on a line and the
// first non-whitespace character on the next line is " that line
// will be a contination of the string including the newline character
// (unless it is escaped). Interpolation and escapes process as before
// unless the first segment of the string is modified by the 

Re: [swift-evolution] multi-line string literals.

[Thorsten Seitz via swift-evolution]

+1 for the proposal as a starting point


> Am 30.04.2016 um 04:37 schrieb Brent Royal-Gordon via swift-evolution 
> :
> 
>> This would ultimately be my favorite approach. I do like the underscores, 
>> because they're unobtrusive and don't distract the eye, but I'm interested 
>> to see alternative suggestions. However, I understand this is not considered 
>> in scope for the current proposal. Is the intention to propose alternate 
>> delimiters for Swift 3 now or wait?
> 
> My goal is to get Swift 3 string literals to the minimum viable feature set 
> for tasks like scripting, templating, using regex libraries, and generating 
> code. In my mind, the features I discuss in the "Future directions for string 
> literals" section break down like this:
> 
> ABSOLUTELY NECESSARY—I definitely intend to propose these for Swift 3.
> 
> * Readable multiline strings
> * Ability to disable escapes

yep


> 
> REALLY NICE TO HAVE—We'll see how much the community wants them, and how much 
> the core team thinks it can handle.
> 
> * Alternate delimiters

What’s the use for these if we already can disable escapes (after implementing 
the absolutely necessary proposals)?


> * Ability to disable escapes except for interpolation (and perhaps to 
> selectively disable other escapes)

That would be really useful (I would tend to push it up into the absolutely 
necessary category :-)


> 
> REALLY NICE TO HAVE, BUT WE CAN'T—I would love to do these, but they're too 
> hard for Swift 3.
> 
> * Very long, minimally massaged strings (i.e. heredocs)

Useful, but IMO not very pressing IF the tools support pasting multi line 
strings and adding/removing the leading marker


> 
> CONVENIENCES—If we had infinite time...but we don't. And they might be dumb 
> anyway.
> 
> * Whitespace normalization
> * Embedded comments

Embedded comments would be *very* nice. Absolutely sufficient would be the 
ability to embed line comments and empty lines, i.e. something like

let foo = 
"blabla
"blabla

// some comment here
"blabla
"blabla

// another comment here
"blabla
"blabla

I’m not sure whether more complicated embedded comments (i.e. comments in the 
same line as a string line) would be worth the effort but might be doable with 
a modifier allowing them, e.g.
c“blabla // some comment
This kind of embedding is certainly out of scope for Swift 3 and possibly Swift 
4, but I’m hoping that line comments and empty lines might be even possible in 
Swift 3 :-)

-Thorsten


> * Localization
> * Default modifier control
> 
> NOT INVENTED YET—Requires huge supporting designs we just don't have.
> 
> * Regex literals
> * User-specified modifiers
> 
> I think we should definitely propose the items in "Absolutely Necessary" and 
> consider proposing the ones in "Really Nice To Have" for Swift 3. I think we 
> should definitely do the "Really Nice To Have, But We Can't" item in Swift 4. 
> I think we should revisit and consider the others in Swift 4 and beyond.
> 
> * * *
> 
> I have intentionally described these features very broadly. For instance, I 
> said "alternate delimiters", not "the `_` modifier". The specific designs I 
> sketched in the proposal are merely examples of solutions to that class of 
> problem. Here are a whole slew of other designs just for alternate delimiters:
> 
> * Use a different identifier-but-not-capitalizable character, like `$`.
> * Use a different single-character ASCII delimiter, like `'`.
> * Use a different multi-character delimiter, like `"""`.
> * Use a different Unicode delimiter, like smart quotes (`“foo ”`) or French 
> quotes (`«foo»`) or Japanese quotes (`⸢foo⸥`).
> * Permit arbitrary delimiters bounded by some specific, known character, like 
> (just making this up) `'~'`.
> 
> That's just off the top of my head—there are probably a hundred more of 
> these. What is presented in the "Future directions for string literals" 
> section is a series of *example* solutions to illustrate the problems that 
> need solving, not necessarily the exact thing we must write a proposal for in 
> a few months or years. It's a sketch, not a roadmap.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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

Re: [swift-evolution] multi-line string literals.

[John Holdsworth via swift-evolution]

I’ve assembled a gist to summarise the main proposals of this thread.

https://gist.github.com/johnno1962/5c325a16838ad3c73e0f109a514298bf

At the moment there seem to be four proposals for multi-line strings:

1) Bent’s proposal for continuation quotes where if a conventional string
does not close, if the first non-whitespace character of the next line is “
(or perhaps |) the string is continued. This gives you precise control
over exactly what is in the string.

2) Tyler's original proposal involving strings that can contain newlines
delimited “””like this“”” as they are in python or, _”like this“_. This works
well in external editors and on github. Indentation is catered for by stripping 
any whitespace before the closing quote from all lines in the string.

3) HEREDOC syntax <<“TAG” or <<‘TAG’ taken from languages like Perl 
subject to the same indentation removal rules as “””strings””” above. This
has the advantage that the literal is clearly separated from your code.

4) Heck it all, why not all three syntaxes or some combination.

(There is a separate feature that all string literals can be prefixed by
e as in e”\w\d+” to turn of all escape processing for another day)

While the Swift Lexer could easily accommodate all these syntaxes there was
talk early on that Swift has more of a "one way, maximally elegant” ethos and 
indeed I find it difficult imagine the Swift Book breathlessly describing all 
three
formats so I’m wondering if push came to shove which format people would chose?

My vote having undergone a "road to damascus" moment now we know it is
available sooner rather than later is.. HEREDOC! It’s well understood and
while at first it would seem to not be a good fit for Swift produces clear code.

Votes?

John


// Multi-line string proposals
// https://github.com/apple/swift/pull/2275 


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


// These examples should load in the prototype toolchain available here:
// http://johnholdsworth.com/swift-LOCAL-2016-05-09-a-osx.tar.gz 


// The prototype currently parses three new forms of quoting
// These new types are still string literals for the grammar.

"the existing string literal format"
_"a format that does not require you to escape " characters"_ // 
possibly redundant
"""a python-style syntax that will accept "'s and newlines in the 
string"""
<<"HEREDOC"
A full heredoc implementation (will always end in a newline)
HEREDOC

// These strings can be modified by prefixing the string by letters
// There is currently only one, "e" to disable escape processing.
// This is primarily used when specifying regular expressions.

let str = "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.

let author = "Gambardella, Matthew"

let xml = "
"
"   
"   \(author)
"   XML Developer's Guide
"   Computer
"   44.95
"   2000-10-01
"   An in-depth look at creating applications with 
XML.
"   
"
""
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 == "\
|
|
|   
|   \(author)
|   XML Developer's Guide
|   Computer
|   44.95
|   2000-10-01
|   An in-depth look at creating \
|applications with XML.

|   
|
|" )


// _""_ quoted strings also suppport these behaviours but don't require
// escaping of embedded " characters. Think of them as a being modifier

Re: [swift-evolution] multi-line string literals.

[Vladimir.S via swift-evolution]

Btw, in c# we have @ to drop escapes:
@"c:\Docs\Source\a.txt"  // rather than "c:\\Docs\\Source\\a.txt"
@"""Ahoy!"" cried the captain." // "Ahoy!" cried the captain.

and(!) also as 'marker' that allows to use keywords as identifiers:
class @class
{
   public static void @static(bool @bool) {..}
..
}

so, probably it is OK to have backtick also as 'special' string marker in 
Swift ?

`abc "def" \(hahaha /// \total-10`

Also, wanted to drop some alternatives:
* what  about single quote? like
'abc "def" \(hahaha /// \total-10'
(if single quote appear in text - it should be doubled, so
'example '' - is a "single" quote'

* what about @ like in c# for string literals just to say "do not process 
escapes" (double quotes should be doubled) :

@"this just text \( \t \n but with ""double quotes"""

* what about $".."$ to mark a sting as-is, without escapes, without 
interpolation, allows double quote without escaping(putting twice)? Yes, "$ 
combination will not be allowed inside of such string.



On 09.05.2016 1:13, Brent Royal-Gordon via swift-evolution wrote:

By the way has the backtick or triple backtick been considered?


Backticks already have a meaning—they "quote" an identifier which would
otherwise be taken as a keyword.

--
Brent Royal-Gordon
Sent from my iPhone

On May 8, 2016, at 2:58 PM, Ricardo Parada > wrote:


The _" and "_  are a good alternative I think.

For some reason the underscore bothers me: it doesn't look as good
aesthetically as others, and because it is already used for a couple of
other things in Swift (to make large numbers readable and as a
placeholder to discard a value).






On May 7, 2016, at 7:24 PM, L. Mihalkovic > wrote:



Regards
(From mobile)


On May 8, 2016, at 12:49 AM, Ricardo Parada via swift-evolution
> wrote:



It seems to me like this would take care of what is needed 99% of the
time.

I've seen many who don't favor continuation quotes.

The other option could be triple quote """ and make the continuation
quote optional. Not using the continuation quote would require the
closing triple quote """


For having built a prototype, I've come to realize that there are more
alternatives.

This is some of my own tests:
https://gist.github.com/lmihalkovic/718d1b8f2ae6f7f6ba2ef8da07b64c1c

The idea of these M/e or any other similar prefix remind me of my perl
days (there were a lot of these), and IMO have little to do with the
rest of Swift.


On May 7, 2016, at 9:48 AM, Brent Royal-Gordon via swift-evolution
> wrote:

```
// Something like:
let xml = M"
   "
   "
   "\(author)
   "
   "
```

___
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


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

Re: [swift-evolution] multi-line string literals.

[Brent Royal-Gordon via swift-evolution]

> By the way has the backtick or triple backtick been considered?

Backticks already have a meaning—they "quote" an identifier which would 
otherwise be taken as a keyword. 

-- 
Brent Royal-Gordon
Sent from my iPhone

> On May 8, 2016, at 2:58 PM, Ricardo Parada  wrote:
> 
> The _" and "_  are a good alternative I think. 
> 
> For some reason the underscore bothers me: it doesn't look as good 
> aesthetically as others, and because it is already used for a couple of other 
> things in Swift (to make large numbers readable and as a placeholder to 
> discard a value). 
> 
> 
> 
> 
> 
>> On May 7, 2016, at 7:24 PM, L. Mihalkovic  
>> wrote:
>> 
>> 
>> 
>> Regards
>> (From mobile)
>> 
>>> On May 8, 2016, at 12:49 AM, Ricardo Parada via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> 
>>> It seems to me like this would take care of what is needed 99% of the time. 
>>> 
>>> I've seen many who don't favor continuation quotes. 
>>> 
>>> The other option could be triple quote """ and make the continuation quote 
>>> optional. Not using the continuation quote would require the closing triple 
>>> quote """
>> 
>> For having built a prototype, I've come to realize that there are more 
>> alternatives. 
>> 
>> This is some of my own tests:
>> https://gist.github.com/lmihalkovic/718d1b8f2ae6f7f6ba2ef8da07b64c1c
>> 
>> The idea of these M/e or any other similar prefix remind me of my perl days 
>> (there were a lot of these), and IMO have little to do with the rest of 
>> Swift. 
>> 
 On May 7, 2016, at 9:48 AM, Brent Royal-Gordon via swift-evolution 
  wrote:
 
 ```
 // Something like:
 let xml = M"
"
"
"\(author)
"
"
 ```
>>> ___
>>> 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

Re: [swift-evolution] multi-line string literals.

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On May 8, 2016, at 12:49 AM, Ricardo Parada via swift-evolution 
>  wrote:
> 
> 
> 
> It seems to me like this would take care of what is needed 99% of the time. 
> 
> I've seen many who don't favor continuation quotes. 
> 
> The other option could be triple quote """ and make the continuation quote 
> optional. Not using the continuation quote would require the closing triple 
> quote """
> 

For having built a prototype, I've come to realize that there are more 
alternatives. 

This is some of my own tests:
https://gist.github.com/lmihalkovic/718d1b8f2ae6f7f6ba2ef8da07b64c1c

The idea of these M/e or any other similar prefix remind me of my perl days 
(there were a lot of these), and IMO have little to do with the rest of Swift. 

>> On May 7, 2016, at 9:48 AM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>> ```
>> // Something like:
>> let xml = M"
>>  "
>>  "
>>  "\(author)
>>  "
>>  "
>> ```
> ___
> 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

Re: [swift-evolution] multi-line string literals.

[L. Mihalkovic via swift-evolution]

I have a simple working prototype where the following just works

Let v = _" "key": "value" "_

I am working on adding 

Let v =
   /* this is a template */
   _" "key": "value" "_

Let v @string_literal(json) = 
   /* this is a template */
   _" "key": "value" "_

This strikes me as far less intrusive on the current compiler structure
Regards
(From mobile)

On May 7, 2016, at 3:48 PM, Brent Royal-Gordon via swift-evolution 
 wrote:

>> Would you all be so kind to take a look at what I suggested
>> and wrote appr. a week ago? (data lines) 
>> This is with using:
>>\@   for verbatim as-is character data  
>> and
>>\\ for character data with processing of \ escaped chars and \(var)
>> 
>> The advantage of what I describe is that apart from that a data line starts 
>> with
>>  \@   or  \\
>> No delimiters involved at the start and end of a pack of data lines,
>> which, if I have seen this correctly, is nowhere the case with the other 
>> suggestions
>> here.
> 
> I addressed suggestions of that type in the third draft of the proposal 
> (although the precise example I used was using `"` as the data line marker):
> 
> ### Don't require the end quote
> 
> Since each line is marked with a continuation quote, in theory, the end 
> quote is redundant; the string could simply end after the last line 
> with a continuation quote.
> 
> ```
> // Something like:
> let xml = M"
>   "
>   "   
>   "   \(author)
>   "   
>   "
> ```
> 
> Alternatively, the `M` modifier could be left out (which would require 
> quotes on that line to be escaped), or a different 
> character or character sequence could be used. There was a fair bit of 
> bikeshedding on this; in some cases, a single post suggested several 
> syntaxes with slightly different semantics (such as different escaping 
> rules). Some marked the first and/or last line differently from the 
> other lines. What they all have in common is that the beginning of each 
> line is marked in some way, but the end is not, even at the end of the 
> literal.
> 
> Because there is no end delimiter—only a start-of-line marker—these 
> designs may not require you to escape quotes; thus, they could 
> potentially obviate the need for an alternate delimiter feature as 
> well. Depending on the design, however, many of them have issues:
> 
> * In most designs, it is possible to create a single-line string with 
>  the feature, but the resulting code tends to be ugly and awkward.
> 
> * If the last line is marked the same as the others and the user forgets 
>  the marker on a line, the compiler has no way to notice, except by 
>  diagnosing errors caused by treating a line of a string literal as 
>  code. Since some lines of string content will be valid code (such as 
>  blank lines or C-style comments), these mistakes may pass unnoticed.
> 
> * If the last line is marked the same as the others, then commenting 
>  out a line of a string literal, inserting a blank line in the middle 
>  of a string literal, or just in general inserting some sort of valid 
>  Swift code in the middle of a string literal would break the literal 
>  in half, once again potentially forming syntactically valid but 
>  incorrect Swift code.
> 
> * Generally, the more these constructs work to avoid the above 
>  problems, the uglier and less quote-like they end up looking, and 
>  the more complex they will be for the parser.
> 
> Finally, all approaches share one fundamental issue.
> 
> String literals are expressions, and so they ought to have a syntax 
> which can be nested inside other expressions. Line-oriented features 
> like these don't work well as expressions, because you normally place 
> several expressions on a single line, nesting them inside one another. 
> Thus, these features may be awkward to use in any but the simplest 
> ways.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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

Re: [swift-evolution] multi-line string literals.

[Brent Royal-Gordon via swift-evolution]

Would you all be so kind to take a look at what I suggestedand wrote appr. a week ago? (data lines) This is with using:    \@   for verbatim as-is character data  and    \\ for character data with processing of \ escaped chars and \(var)The advantage of what I describe is that apart from that a data line starts with  \@   or  \\No delimiters involved at the start and end of a pack of data lines,which, if I have seen this correctly, is nowhere the case with the other suggestionshere.I addressed suggestions of that type in the third draft of the proposal (although the precise example I used was using `"` as the data line marker):### Don't require the end quoteSince each line is marked with a continuation quote, in theory, the end quote is redundant; the string could simply end after the last line with a continuation quote.```// Something like:let xml = M"   "   "	   "		\(author)   "	   "```Alternatively, the `M` modifier could be left out (which would require quotes on that line to be escaped), or a different character or character sequence could be used. There was a fair bit of bikeshedding on this; in some cases, a single post suggested several syntaxes with slightly different semantics (such as different escaping rules). Some marked the first and/or last line differently from the other lines. What they all have in common is that the beginning of each line is marked in some way, but the end is not, even at the end of the literal.Because there is no end delimiter—only a start-of-line marker—these designs may not require you to escape quotes; thus, they could potentially obviate the need for an alternate delimiter feature as well. Depending on the design, however, many of them have issues:* In most designs, it is possible to create a single-line string with   the feature, but the resulting code tends to be ugly and awkward.* If the last line is marked the same as the others and the user forgets   the marker on a line, the compiler has no way to notice, except by   diagnosing errors caused by treating a line of a string literal as   code. Since some lines of string content will be valid code (such as   blank lines or C-style comments), these mistakes may pass unnoticed.* If the last line is marked the same as the others, then commenting   out a line of a string literal, inserting a blank line in the middle   of a string literal, or just in general inserting some sort of valid   Swift code in the middle of a string literal would break the literal   in half, once again potentially forming syntactically valid but   incorrect Swift code.* Generally, the more these constructs work to avoid the above   problems, the uglier and less quote-like they end up looking, and   the more complex they will be for the parser.Finally, all approaches share one fundamental issue.String literals are expressions, and so they ought to have a syntax which can be nested inside other expressions. Line-oriented features like these don't work well as expressions, because you normally place several expressions on a single line, nesting them inside one another. Thus, these features may be awkward to use in any but the simplest ways.-- Brent Royal-GordonArchitechies___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] multi-line string literals.

[ted van gaalen via swift-evolution]

hello,
Have read all? conversations about this subject...

Would you all be so kind to take a look at what I suggested
and wrote appr. a week ago? (data lines) 
This is with using:
\@   for verbatim as-is character data  
and
\\ for character data with processing of \ escaped chars and \(var)

The advantage of what I describe is that apart from that a data line starts with
  \@   or  \\
No delimiters involved at the start and end of a pack of data lines,
which, if I have seen this correctly, is nowhere the case with the other 
suggestions
here.
--
In the meantime I've seen and read more about FP. Some nice and even humoristic 
videos about this subject. This brought me a different and more nuanced 
impression
about functional programming and how I can use it.. This contrasts highly with 
the view of some more or less fanatic individuals, (biasing my 
impressions)which believe they take part in a holy war, rolling with tanks all 
over the programing landscape. They spoil it all like people with extreme views 
tend to do in all aspects on our beautiful blue planet. In any case I was 
relieved, feeling a lot better and seeing how it can be succesfully integrated 
into Swift makes me feel more relaxed about most chances and enhancements that 
can make Swift a very unique and state of the art language. It can be 
harmonious with OOP as well, which is great. It could be that both forms melt 
together easily. So, it is sometimes not so easy to keep an open mind, as we 
are all subjective beings, instinctively defensive against new things...to go 
beyond what we are "certain" of.. 
Kind Regards, TedvG
no more time now . moving boxes..physical container objects :o}
www.ravelnotes.com
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] multi-line string literals.

[Tyler Cloutier via swift-evolution]

> On May 5, 2016, at 10:52 PM, Brent Royal-Gordon  
> wrote:
> 
>> As far as mixed whitespace, I think the only sane thing to do would be to 
>> only allow leading tabs *or* spaces.  Mixing tabs and spaces in the leading 
>> whitespace would be a syntax error.  All lines in the string would need to 
>> use tabs or all lines use spaces, you could not have one line with tabs and 
>> another with spaces.  This would keep the compiler out of the business of 
>> making any assumptions or guesses, would not be a problem often, and would 
>> be very easy to fix if it ever happens accidentally.
> 
> The sane thing to do would be to require every line be prefixed with 
> *exactly* the same sequence of characters as the closing delimiter line. 
> Anything else (except perhaps a completely blank line, to permit whitespace 
> trimming) would be a syntax error.
> 

Yes, this I think would be the way to do it.

> But take a moment to consider the downsides before you leap to adopt this 
> solution.
> 
> 1. You have introduced tab-space confusion into the equation.

Agreed, and that’s never fun since they are invisible. Confusing for people new 
to programming, I imagine.

> 
> 2. You have introduced trailing-newline confusion into the equation.

Yes, you are absolutely right and I missed this one in my response. I assume 
you are referring to whether or not there is a new line after , and 
if so how do you get rid of it without messing up the whitespace trimming.

Is this not also a problem for heredocs (if you want to use the closing 
delimiter to mark how much whitespace to trim)?

> 
> 3. The #escaped and #marginStripped keywords are now specific to multiline 
> strings; #escaped in particular will be attractive there for tasks like 
> regexes. You will have to invent a different syntax for it there.

These were just straw man proposals, I don’t think that is what they 
should/would be. Just throwing the general idea out there.

> 
> 4. This form of `"""` is not useful for not having to escape `"` in a 
> single-line string; you now have to invent a separate mechanism for that.

True, unless you don’t mind taking up 3 lines to do it.

> 
> 5. You can't necessarily look at a line and tell whether it's code or string. 
> And—especially with the #escaped-style constructs—the delimiters don't 
> necessarily "pop" visually; they're too small and easy to miss compared to 
> the text they contain. In extremis, you actually have to look at the entire 
> file from top to bottom, counting the `"""`s to figure out whether you're in 
> a string or not. Granted, you *usually* can tell from context, but it's a far 
> cry from what continuation quotes offer.

To be fair, syntax highlighting also helps with this, but it’s quite possible 
you are looking at the code in a context where it is not available.

I don’t see how the #compilerDirective modifiers make the delimiters any less 
visible, though 

And, the same could be said for heredoc delimiters, I think. Although, that 
really depends on what the delimiters are.

> 
> 6. You are now forcing *any* string literal of more than one line to include 
> two extra lines devoted wholly to the quoting syntax. In my Swift-generating 
> example, that would change shorter snippets like this:
> 
> code +=  "
>  "static var messages: [HTTPStatus: String] = [
>  ""
> 
> Into things like this:
> 
> code +=  """
>  
>  static var messages: [HTTPStatus: String] = [
> 
>  """
> 
> To my mind, the second syntax is actually *heavier*, despite not requiring 
> every line be marked, because it takes two extra lines and additional 
> punctuation.

> 
> 7. You are also introducing visual ambiguity into the equation—in the above 
> example, the left margin is now ambiguous to the eye (even if it's not 
> ambiguous to the compiler). You could recover it by permitting non-whitespace 
> prefix characters:
> 
> code +=  """
> |
> |static var messages: [HTTPStatus: String] = [
> |
> |"""
> 
> ...but then we're back to annotating every line, *plus* we have the leading 
> and trailing `"""` lines. Worst of both worlds.
> 

This is a good point. It takes up 5 lines, and you quite possibly will still 
have to go about counting spaces. It would be worse for the more whitespace you 
have.


> 8. In longer examples, you are dividing the expression in half in a way that 
> makes it difficult to read. For instance, consider this code:
> 
> socket.send( 
> """ #escaped #marginStripped 
> 
> 
>
>\(author)
>XML Developer's Guide
>Computer
>44.95
>2000-10-01
>An in-depth look at creating applications 
> with XML.
>
> 
>

Re: [swift-evolution] multi-line string literals.

[L Mihalkovic via swift-evolution]

> On May 6, 2016, at 7:13 PM, L Mihalkovic  wrote:
> 
> As I (believe I) start to understand the parser, I somehow think that doing 
> something like the following would 
> not violate (not take too much risk) the current Lexer/Parser
> be somewhat reasonable to implement
> address many of the reqs I read 
> leave some infrastructure in the Lexer/Parser to add more feature without 
> needing to go back to square 0 next time
> 
> Any thoughts?!
> 
> 
> #!/usr/bin/env xcrun swift
> 
> let s1 = "{\"key1\": \"stringValue\"}"
> 
> let s2 = _"{"key1": "stringValue"}"_
> 
> let s3 =
> /* this is the same template */
> _"{"key1": "stringValue"}"_
> 
> let s4 =
> /* this is (almost) the same template */
> _"
> {
>   "key1": "stringValue"
>   , "key2": "stringValue"
> }
> "_
> 
> let s5 = @literal(json)
>   /* this is exactly the same template as s4 */
>   _"
>   {
> "key1": "stringValue"
> , "key2": "stringValue"
>   }
>   "_
> 

sorry for the mistake, but I think the more appropriate way to say that should 
have been

let s5: @literal(json) String = 
  /* this is exactly the same template as s4 */
  _"
  {
"key1": "stringValue"
, "key2": "stringValue"
  }
  "_


> let s6 = @literal(json)
>   /* this is exactly the same template as s5 */
>   _"
>   |{
>   |  "key1": "stringValue"
>   |  , "key2": "stringValue"
>   |}
>   "_
> 

same for s6 which should read

let s6: @literal(json) String = ...

I have not checked it the following would be enough

let s6: @literal(json)  = ...

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

Re: [swift-evolution] multi-line string literals.

[L Mihalkovic via swift-evolution]

As I (believe I) start to understand the parser, I somehow think that doing 
something like the following would 
not violate (not take too much risk) the current Lexer/Parser
be somewhat reasonable to implement
address many of the reqs I read 
leave some infrastructure in the Lexer/Parser to add more feature without 
needing to go back to square 0 next time

Any thoughts?!


#!/usr/bin/env xcrun swift

let s1 = "{\"key1\": \"stringValue\"}"

let s2 = _"{"key1": "stringValue"}"_

let s3 =
/* this is the same template */
_"{"key1": "stringValue"}"_

let s4 =
/* this is (almost) the same template */
_"
{
  "key1": "stringValue"
  , "key2": "stringValue"
}
"_

let s5 = @literal(json)
  /* this is exactly the same template as s4 */
  _"
  {
"key1": "stringValue"
, "key2": "stringValue"
  }
  "_

let s6 = @literal(json)
  /* this is exactly the same template as s5 */
  _"
  |{
  |  "key1": "stringValue"
  |  , "key2": "stringValue"
  |}
  "_

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

Re: [swift-evolution] multi-line string literals.

[Matthew Johnson via swift-evolution]

Sent from my iPad

On May 6, 2016, at 12:52 AM, Brent Royal-Gordon  wrote:

>> As far as mixed whitespace, I think the only sane thing to do would be to 
>> only allow leading tabs *or* spaces.  Mixing tabs and spaces in the leading 
>> whitespace would be a syntax error.  All lines in the string would need to 
>> use tabs or all lines use spaces, you could not have one line with tabs and 
>> another with spaces.  This would keep the compiler out of the business of 
>> making any assumptions or guesses, would not be a problem often, and would 
>> be very easy to fix if it ever happens accidentally.
> 
> The sane thing to do would be to require every line be prefixed with 
> *exactly* the same sequence of characters as the closing delimiter line. 
> Anything else (except perhaps a completely blank line, to permit whitespace 
> trimming) would be a syntax error.

Yes, this is the important implication of what I suggested.

> 
> But take a moment to consider the downsides before you leap to adopt this 
> solution.
> 
> 1. You have introduced tab-space confusion into the equation.
> 
> 2. You have introduced trailing-newline confusion into the equation.

I don't think confusion is the right word.  When tabs and spaces are mixed 
accidentally the compiler can offer a very clear error message.  The problem is 
easy to understand and easy to fix.

The new line question is really just a matter of learning how the language 
works and then doing the right thing.  Confusion only exists if you don't know 
the language, which can be said about pretty much any feature.  

> 
> 3. The #escaped and #marginStripped keywords are now specific to multiline 
> strings; #escaped in particular will be attractive there for tasks like 
> regexes. You will have to invent a different syntax for it there.

The syntax for those was not my suggestion.  

> 
> 4. This form of `"""` is not useful for not having to escape `"` in a 
> single-line string; you now have to invent a separate mechanism for that.

I was only commenting on the leading space issue.  If you prefer heredoc syntax 
that is fine with me.
> 
> 5. You can't necessarily look at a line and tell whether it's code or string. 
> And—especially with the #escaped-style constructs—the delimiters don't 
> necessarily "pop" visually; they're too small and easy to miss compared to 
> the text they contain. In extremis, you actually have to look at the entire 
> file from top to bottom, counting the `"""`s to figure out whether you're in 
> a string or not. Granted, you *usually* can tell from context, but it's a far 
> cry from what continuation quotes offer.

This has never been a problem for me.  I have used heredocs extensively in the 
past.
> 
> 6. You are now forcing *any* string literal of more than one line to include 
> two extra lines devoted wholly to the quoting syntax. In my Swift-generating 
> example, that would change shorter snippets like this:
> 
> code +=  "
>  "static var messages: [HTTPStatus: String] = [
>  ""
> 
> Into things like this:
> 
> code +=  """
>  
>  static var messages: [HTTPStatus: String] = [
> 
>  """
> 
> To my mind, the second syntax is actually *heavier*, despite not requiring 
> every line be marked, because it takes two extra lines and additional 
> punctuation.

Granted.  But in my experience multi-line string literals are usually not so 
short.  This has never bothered me in work with heredocs.
> 
> 7. You are also introducing visual ambiguity into the equation—in the above 
> example, the left margin is now ambiguous to the eye (even if it's not 
> ambiguous to the compiler). You could recover it by permitting non-whitespace 
> prefix characters:
> 
> code +=  """
> |
> |static var messages: [HTTPStatus: String] = [
> |
> |"""
> 
> ...but then we're back to annotating every line, *plus* we have the leading 
> and trailing `"""` lines. Worst of both worlds.

This is a reasonable point and one I hadn't thought of.  I never had a problem 
with it when working with heredocs, but I can see where occasionally this would 
make a difference.

> 
> 8. In longer examples, you are dividing the expression in half in a way that 
> makes it difficult to read. For instance, consider this code:
> 
> socket.send( 
> """ #escaped #marginStripped 
> 
> 
>
>\(author)
>XML Developer's Guide
>Computer
>44.95
>2000-10-01
>An in-depth look at creating applications 
> with XML.
>
> 
> """.data(using: NSUTF8StringEncoding))
> 
> The effect—particularly with even larger literals than this—is not unlike 
> pausing in the middle of reading an article to 

Re: [swift-evolution] multi-line string literals.

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 6, 2016, at 12:14 AM, L. Mihalkovic  
> wrote:
> 
> Inline
> 
> Regards
> (From mobile)
> 
>> On May 6, 2016, at 4:13 AM, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> 
 On May 5, 2016, at 8:27 PM, Tyler Cloutier via swift-evolution 
  wrote:
 
 
> On May 5, 2016, at 5:08 PM, John Holdsworth via swift-evolution 
>  wrote:
> 
> 
>> On 5 May 2016, at 14:17, David Hart  wrote:
>> 
>> 
> 
>> On 05 May 2016, at 12:30, Michael Peternell via swift-evolution 
>>  wrote:
>> 
>> it's not a secret that I'm not a big fan of the proposal. The third 
>> draft doesn't change this and it's unlikely that any future draft will, 
>> because for me, the problem are the continuation quotes, and for Brent 
>> it seems like they are a must-have-feature (correct me if I'm wrong.)
> 
> I agree with all you said. I’m fairly sure I would never vote for Brent’s 
> proposal simply because of the existence of continuation quotes, no 
> matter the amount of reasoning behind it. They are simply too unwieldy, 
> cumbersome and unfriendly to modification.
> 
> I could see either your proposal, or your proposal without the HERE_DOCs 
> but using Tyler’s/Scala’s .stripMargin. Do you think you could start a 
> formal proposal?
 
 
 Adapting the original proposal if you’re not a fan of continuation quotes..
 
 It’s possible to have a multiline “””python””” multi-line string but 
 tidily indented.
 As suggested earlier in this thread the lexer can strip the margin on the 
 basis of
 the whitespace before the closing quote as per Perl6 (This could be a 
 modifier “I”
 but might as well be the default TBH.) Would this be the best of both 
 worlds?
 
 assert( xml == i"""
 
 

\(author)
XML Developer's Guide
Computer
44.95
2000-10-01
An in-depth look at creating applications 
 with XML.

 
 ""” )
 
 Other modifiers can also be applied such as “no-escapes"
 
 assert( xml != ei"""
 

\(author)
XML Developer's Guide
Computer
44.95
2000-10-01
An in-depth look at creating applications 
 with XML.

 
 """ )
 
 I’d hope this would satisfy any need for <>>> 
 Or you could support both continuation and indented python style:
 http://johnholdsworth.com/swift-LOCAL-2016-05-05-a-osx.tar.gz
 
 John
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> I’m of the opinion that either of these are reasonable solutions, and both 
>>> offer different tradeoffs. I’m probably partial to the continuation quotes, 
>>> because I don’t want to be guessing about what is going to end up being in 
>>> my string and what won’t.  
>>> 
 assert( xml != ei"""
 

\(author)
XML Developer's Guide
Computer
44.95
2000-10-01
An in-depth look at creating applications 
 with XML.

 
 ""” )
>>> 
>>> For example, is there a new line after ?
>>> How would the indenting work if it were immediately followed by triple 
>>> quotes: ”””
>>> I would really like the first line to be lined up with the rest of the xml. 
>>> Is that going to introduce a newline into the top of the string?
>>> 
>>> Could we just enforce that no characters on the lines of the triple quotes 
>>> would be included in the string, very much like the heredoc syntax?
>>> 
>>> assert( xml != ei"”” The text I’m typing here would cause a 
>>> compiler error.
>>> 
>>> 
>>>
>>>\(author)
>>>XML Developer's Guide
>>>Computer
>>>44.95
>>>2000-10-01
>>>An in-depth look at creating applications 
>>> with XML.
>>>
>>> 
>>> same here   ""” )
>>> 
>>> Then it’s very clear what the whitespace stripping will do. But what about 
>>> mixed tab vs whitespace? What is the 

Re: [swift-evolution] multi-line string literals.

[Michael Peternell via swift-evolution]

> Am 06.05.2016 um 05:24 schrieb Ricardo Parada :
> 
> I think that is another one of the advantages of using the continuation 
> quotes. 
> 
> Sent from my iPhone
> 
>> On May 5, 2016, at 4:51 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>> I think it's nice that I can look at any line—out of context, random 
>> access—and see which parts are string literals.

Hmm, I use syntax highlighting for this ;)

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

Re: [swift-evolution] multi-line string literals.

[Cole Campbell via swift-evolution]

> assert( xml != ei"""
> 
>
>\(author)
>XML Developer's Guide
>Computer
>44.95
>2000-10-01
>An in-depth look at creating applications 
> with XML.
>
> 
> """ )

The idea of auto-stripping whitespaces seemed nice initially, until I realized 
it's not at all clear where the stripped whitespaces end and the included 
whitespaces begin. It's already problematic for you own code (because even 
knowing your own intent doesn't completely overcome the lack of perspective 
this syntax offers), but imagine if it's someone else's. Will you be able to 
figure out what spacing is meant to be a part of the string and which is not? 
Quickly? Easily? Maybe, maybe not. It still won't be readily apparent, because 
there's no point of reference. You're potentially reduced to counting 
whitespaces to figure it out. Brent's proposal elegantly fixes this problem. 
You have a clear point of reference, there's no issue of spaces vs tabs, no 
trying to figure out exactly where the "true" whitespaces are beginning. Like 
was mentioned, it would probably have to be relative to the leading whitespaces 
on the closing delimiter line, but then there's no way to tell visually if 
those are spaces or tabs, or how many there are, AND you have to sort of 
mentally trace an invisible line upwards to "see" how the lines above relate. 
This would drive me crazy. With leading quotes, it's obvious which lines don't 
have included leading whitespaces, and the ones that do have a smaller relative 
distance to what is the "left alignment margin" (so to speak) indicated by the 
quotes.

This feels like we would be making it easier to make mistakes and harder to 
determine actual spacing just to eliminate some extra quotes. I think the 
proposal is the best balance of simplicity and practicality we're going to 
achieve for *short* multi line strings, which is what this proposal is tying to 
address. We can still introduce the """ or heredoc syntaxes for longer blocks 
of text in the future.

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

Re: [swift-evolution] multi-line string literals.

[Brent Royal-Gordon via swift-evolution]

> As far as mixed whitespace, I think the only sane thing to do would be to 
> only allow leading tabs *or* spaces.  Mixing tabs and spaces in the leading 
> whitespace would be a syntax error.  All lines in the string would need to 
> use tabs or all lines use spaces, you could not have one line with tabs and 
> another with spaces.  This would keep the compiler out of the business of 
> making any assumptions or guesses, would not be a problem often, and would be 
> very easy to fix if it ever happens accidentally.

The sane thing to do would be to require every line be prefixed with *exactly* 
the same sequence of characters as the closing delimiter line. Anything else 
(except perhaps a completely blank line, to permit whitespace trimming) would 
be a syntax error.

But take a moment to consider the downsides before you leap to adopt this 
solution.

1. You have introduced tab-space confusion into the equation.

2. You have introduced trailing-newline confusion into the equation.

3. The #escaped and #marginStripped keywords are now specific to multiline 
strings; #escaped in particular will be attractive there for tasks like 
regexes. You will have to invent a different syntax for it there.

4. This form of `"""` is not useful for not having to escape `"` in a 
single-line string; you now have to invent a separate mechanism for that.

5. You can't necessarily look at a line and tell whether it's code or string. 
And—especially with the #escaped-style constructs—the delimiters don't 
necessarily "pop" visually; they're too small and easy to miss compared to the 
text they contain. In extremis, you actually have to look at the entire file 
from top to bottom, counting the `"""`s to figure out whether you're in a 
string or not. Granted, you *usually* can tell from context, but it's a far cry 
from what continuation quotes offer.

6. You are now forcing *any* string literal of more than one line to include 
two extra lines devoted wholly to the quoting syntax. In my Swift-generating 
example, that would change shorter snippets like this:

code +=  "
 "static var messages: [HTTPStatus: String] = [
 ""

Into things like this:

code +=  """
 
 static var messages: [HTTPStatus: String] = [

 """

To my mind, the second syntax is actually *heavier*, despite not requiring 
every line be marked, because it takes two extra lines and additional 
punctuation.

7. You are also introducing visual ambiguity into the equation—in the above 
example, the left margin is now ambiguous to the eye (even if it's not 
ambiguous to the compiler). You could recover it by permitting non-whitespace 
prefix characters:

code +=  """
|
|static var messages: [HTTPStatus: String] = [
|
|"""

...but then we're back to annotating every line, *plus* we have the leading and 
trailing `"""` lines. Worst of both worlds.

8. In longer examples, you are dividing the expression in half in a way that 
makes it difficult to read. For instance, consider this code:

socket.send( 
""" #escaped #marginStripped 


   
   \(author)
   XML Developer's Guide
   Computer
   44.95
   2000-10-01
   An in-depth look at creating applications with 
XML.
   

""".data(using: NSUTF8StringEncoding))

The effect—particularly with even larger literals than this—is not unlike 
pausing in the middle of reading an article to watch a movie. What were we 
talking about again?

This problem is neatly avoided by a heredoc syntax, which keeps the expression 
together and then collects the string below it:

socket.send(""".data(using: NSUTF8StringEncoding))


   
   \(author)
   XML Developer's Guide
   Computer
   44.95
   2000-10-01
   An in-depth look at creating applications with 
XML.
   

"""

(I'm assuming there's no need for #escaped or #marginStripped; they're both 
enabled by default.)

* * *

Let's actually talk about heredocs. Leaving aside indentation (which can be 
applied to either feature) and the traditional token choices (which can be 
changed), I think these are the pros of heredocs compared to Python 
triple-quotes:

H1: Doesn't break up expressions, as discussed above.
H2: Literal content formatting is completely unaffected by code formatting, 
including the first and last lines.

Here are the pros of Python triple-quotes compared to heredocs:

P1: Simpler to explain: "like a string literal, but really big".
P2: Lighter syntactic weight, enough to make`"""` usable as a single-line 
syntax.
P3: Less trailing-newline 

Re: [swift-evolution] multi-line string literals.

[L. Mihalkovic via swift-evolution]

Inline

Regards
(From mobile)

> On May 6, 2016, at 4:13 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>>> On May 5, 2016, at 8:27 PM, Tyler Cloutier via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On May 5, 2016, at 5:08 PM, John Holdsworth via swift-evolution 
  wrote:
 
 
> On 5 May 2016, at 14:17, David Hart  wrote:
> 
> 
 
> On 05 May 2016, at 12:30, Michael Peternell via swift-evolution 
>  wrote:
> 
> it's not a secret that I'm not a big fan of the proposal. The third draft 
> doesn't change this and it's unlikely that any future draft will, because 
> for me, the problem are the continuation quotes, and for Brent it seems 
> like they are a must-have-feature (correct me if I'm wrong.)
 
 I agree with all you said. I’m fairly sure I would never vote for Brent’s 
 proposal simply because of the existence of continuation quotes, no matter 
 the amount of reasoning behind it. They are simply too unwieldy, 
 cumbersome and unfriendly to modification.
 
 I could see either your proposal, or your proposal without the HERE_DOCs 
 but using Tyler’s/Scala’s .stripMargin. Do you think you could start a 
 formal proposal?
>>> 
>>> 
>>> Adapting the original proposal if you’re not a fan of continuation quotes..
>>> 
>>> It’s possible to have a multiline “””python””” multi-line string but tidily 
>>> indented.
>>> As suggested earlier in this thread the lexer can strip the margin on the 
>>> basis of
>>> the whitespace before the closing quote as per Perl6 (This could be a 
>>> modifier “I”
>>> but might as well be the default TBH.) Would this be the best of both 
>>> worlds?
>>> 
>>> assert( xml == i"""
>>> 
>>> 
>>>
>>>\(author)
>>>XML Developer's Guide
>>>Computer
>>>44.95
>>>2000-10-01
>>>An in-depth look at creating applications 
>>> with XML.
>>>
>>> 
>>> ""” )
>>> 
>>> Other modifiers can also be applied such as “no-escapes"
>>> 
>>> assert( xml != ei"""
>>> 
>>>
>>>\(author)
>>>XML Developer's Guide
>>>Computer
>>>44.95
>>>2000-10-01
>>>An in-depth look at creating applications 
>>> with XML.
>>>
>>> 
>>> """ )
>>> 
>>> I’d hope this would satisfy any need for <>> 
>>> Or you could support both continuation and indented python style:
>>> http://johnholdsworth.com/swift-LOCAL-2016-05-05-a-osx.tar.gz
>>> 
>>> John
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> I’m of the opinion that either of these are reasonable solutions, and both 
>> offer different tradeoffs. I’m probably partial to the continuation quotes, 
>> because I don’t want to be guessing about what is going to end up being in 
>> my string and what won’t. 
>> 
>>> assert( xml != ei"""
>>> 
>>>
>>>\(author)
>>>XML Developer's Guide
>>>Computer
>>>44.95
>>>2000-10-01
>>>An in-depth look at creating applications 
>>> with XML.
>>>
>>> 
>>> ""” )
>> 
>> For example, is there a new line after ?
>> How would the indenting work if it were immediately followed by triple 
>> quotes: ”””
>> I would really like the first line to be lined up with the rest of the xml. 
>> Is that going to introduce a newline into the top of the string?
>> 
>> Could we just enforce that no characters on the lines of the triple quotes 
>> would be included in the string, very much like the heredoc syntax?
>> 
>> assert( xml != ei"”” The text I’m typing here would cause a compiler 
>> error.
>> 
>> 
>>
>>\(author)
>>XML Developer's Guide
>>Computer
>>44.95
>>2000-10-01
>>An in-depth look at creating applications 
>> with XML.
>>
>> 
>> same here   ""” )
>> 
>> Then it’s very clear what the whitespace stripping will do. But what about 
>> mixed tab vs whitespace? What is the behavior in that case?
> 
> 
> I’m jumping into this thread late and have only followed bits of it so I 
> apologize if I’m repeating anything.
> 
> I really like the idea of having leading space stripped automatically without 
> requiring the continuation 

Re: [swift-evolution] multi-line string literals.

[Ricardo Parada via swift-evolution]

If we use triple quotes (i.e. """) at the beginning of the multi line string 
literal and again at the end, it seems very unlikely that the heredoc notation 
would be needed. 

I would simplify and remove the heredoc alternative from the proposal. 

Also, for those of us who like the continuation quotes, I think the 
continuation quotes could be optional. For example this:

let html = """
". 
" \(title)
".A paragraph.
". 
"
"""

would be equivalent to:


let html = """
. 
 \(title)
.A paragraph.
. 

"""

What do you think?



> On May 5, 2016, at 2:13 PM, L Mihalkovic via swift-evolution 
>  wrote:
> 
> 
>> On May 5, 2016, at 12:30 PM, Michael Peternell via swift-evolution 
>>  wrote:
>> 
>> Hi,
>> 
>> it's not a secret that I'm not a big fan of the proposal. The third draft 
>> doesn't change this and it's unlikely that any future draft will, because 
>> for me, the problem are the continuation quotes, and for Brent it seems like 
>> they are a must-have-feature (correct me if I'm wrong.)
>> 
>> I just wanted to say that I have drafted a proposal that solves the issues 
>> that I have encountered. (It's here: 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/016219.html
>>  )
>> - it allows pasting text as-is
>> - it allows creating string literals where leading space on each line is 
>> stripped (while keeping indentation differences intact)
>> - it allows creating string literals where leading space on each line is not 
>> stripped
>> - optionally it allows strings to be raw, without any string interpolation 
>> or escaping whatsoever
>> - in none of the literals you have to write "> empty=\"\">", you can just write "". This also 
>> lets you copy text out of the program source and back into a HTML file.
>> 
>> It had the idea that maybe the motivation behind continuation quotes is to 
>> make using multiline strings harder to use; in order to discourage their use 
>> at all. Two points to consider:
>> - people who don't want to use MSL will not, even if you throw Python-like 
>> """multi-line strings""" at them.
>> - people who want to use them do it, even if there is no MSL available. I 
>> saw that in Objective-C, with multiple lines of HTML and CSS wrapped into a 
>> big multiline objc-string-literal and thrown at a WebView. I could send the 
>> literal to the console before sending it to the WebView and it was basically 
>> unreadable. I eventually refactored it to put the thing into a file (also 
>> because the HTML grew in space, and the inline-literal became impractical)
>> - my most important point: if someone uses multiple lines of HTML or CSS or 
>> XML directly within the code, I want it to look okay. I don't want an MSL 
>> feature that is so unwieldy that people voluntarily not use it; it would be 
>> better to have no MSL at all.
>> 
>> I don't think that multiline strings are a must-have feature for a language, 
>> because they are not used very often. (I included an example of a good use 
>> case in my proposal.) I acknowledge that in many programming cases it would 
>> be better to not put a huge pile of text directly into the source, but to 
>> load the text from a file at runtime. But even when these MSL are misused, I 
>> prefer to read a """python multiline string""" over a 
>> "concatenated\n"+"Java\n"+"String".
>> 
>> -Michael
> 
> 
> Hi Michael. hope this helps  
> https://gist.github.com/lmihalkovic/11f2b1b23b78bbb9cbf0292ffc480b3d
> 
> 
> ___
> 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

Re: [swift-evolution] multi-line string literals.

[Ricardo Parada via swift-evolution]

I think that is another one of the advantages of using the continuation quotes. 

Sent from my iPhone

> On May 5, 2016, at 4:51 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
>   
> I think it's nice that I can look at any line—out of context, random 
> access—and see which parts are string literals.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] multi-line string literals.

[Matthew Johnson via swift-evolution]

> On May 5, 2016, at 8:27 PM, Tyler Cloutier via swift-evolution 
>  wrote:
> 
> 
>> On May 5, 2016, at 5:08 PM, John Holdsworth via swift-evolution 
>> > wrote:
>> 
>> 
>>> On 5 May 2016, at 14:17, David Hart >> > wrote:
>>> 
>>> 
 On 05 May 2016, at 12:30, Michael Peternell via swift-evolution 
 > wrote:
 
 it's not a secret that I'm not a big fan of the proposal. The third draft 
 doesn't change this and it's unlikely that any future draft will, because 
 for me, the problem are the continuation quotes, and for Brent it seems 
 like they are a must-have-feature (correct me if I'm wrong.)
>>> 
>>> I agree with all you said. I’m fairly sure I would never vote for Brent’s 
>>> proposal simply because of the existence of continuation quotes, no matter 
>>> the amount of reasoning behind it. They are simply too unwieldy, cumbersome 
>>> and unfriendly to modification.
>>> 
>>> I could see either your proposal, or your proposal without the HERE_DOCs 
>>> but using Tyler’s/Scala’s .stripMargin. Do you think you could start a 
>>> formal proposal?
>> 
>> 
>> Adapting the original proposal if you’re not a fan of continuation quotes..
>> 
>> It’s possible to have a multiline “””python””” multi-line string but tidily 
>> indented.
>> As suggested earlier in this thread the lexer can strip the margin on the 
>> basis of
>> the whitespace before the closing quote as per Perl6 (This could be a 
>> modifier “I”
>> but might as well be the default TBH.) Would this be the best of both worlds?
>> 
>> assert( xml == i"""
>> 
>> 
>>
>>\(author)
>>XML Developer's Guide
>>Computer
>>44.95
>>2000-10-01
>>An in-depth look at creating applications 
>> with XML.
>>
>> 
>> ""” )
>> 
>> Other modifiers can also be applied such as “no-escapes"
>> 
>> assert( xml != ei"""
>> 
>>
>>\(author)
>>XML Developer's Guide
>>Computer
>>44.95
>>2000-10-01
>>An in-depth look at creating applications 
>> with XML.
>>
>> 
>> """ )
>> 
>> I’d hope this would satisfy any need for <> 
>> Or you could support both continuation and indented python style:
>> http://johnholdsworth.com/swift-LOCAL-2016-05-05-a-osx.tar.gz 
>> 
>> 
>> John
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> I’m of the opinion that either of these are reasonable solutions, and both 
> offer different tradeoffs. I’m probably partial to the continuation quotes, 
> because I don’t want to be guessing about what is going to end up being in my 
> string and what won’t.  
> 
>> assert( xml != ei"""
>> 
>>
>>\(author)
>>XML Developer's Guide
>>Computer
>>44.95
>>2000-10-01
>>An in-depth look at creating applications 
>> with XML.
>>
>> 
>> ""” )
> 
> For example, is there a new line after ?
> How would the indenting work if it were immediately followed by triple 
> quotes: ”””
> I would really like the first line to be lined up with the rest of the xml. 
> Is that going to introduce a newline into the top of the string?
> 
> Could we just enforce that no characters on the lines of the triple quotes 
> would be included in the string, very much like the heredoc syntax?
> 
> assert( xml != ei"”” The text I’m typing here would cause a compiler 
> error.
> 
> 
>
>\(author)
>XML Developer's Guide
>Computer
>44.95
>2000-10-01
>An in-depth look at creating applications 
> with XML.
>
> 
> same here   ""” )
> 
> Then it’s very clear what the whitespace stripping will do. But what about 
> mixed tab vs whitespace? What is the behavior in that case?


I’m jumping into this thread late and have only followed bits of it so I 
apologize if I’m repeating anything.

I really like the idea of having leading space stripped automatically without 
requiring the continuation quotes.  I have done my share of leading space 
stripping in the past when working with heredocs.  

Re: [swift-evolution] multi-line string literals.

[Tyler Cloutier via swift-evolution]

> On May 5, 2016, at 6:27 PM, Tyler Cloutier via swift-evolution 
>  wrote:
> 
> 
>> On May 5, 2016, at 5:08 PM, John Holdsworth via swift-evolution 
>> > wrote:
>> 
>> 
>>> On 5 May 2016, at 14:17, David Hart >> > wrote:
>>> 
>>> 
 On 05 May 2016, at 12:30, Michael Peternell via swift-evolution 
 > wrote:
 
 it's not a secret that I'm not a big fan of the proposal. The third draft 
 doesn't change this and it's unlikely that any future draft will, because 
 for me, the problem are the continuation quotes, and for Brent it seems 
 like they are a must-have-feature (correct me if I'm wrong.)
>>> 
>>> I agree with all you said. I’m fairly sure I would never vote for Brent’s 
>>> proposal simply because of the existence of continuation quotes, no matter 
>>> the amount of reasoning behind it. They are simply too unwieldy, cumbersome 
>>> and unfriendly to modification.
>>> 
>>> I could see either your proposal, or your proposal without the HERE_DOCs 
>>> but using Tyler’s/Scala’s .stripMargin. Do you think you could start a 
>>> formal proposal?
>> 
>> 
>> Adapting the original proposal if you’re not a fan of continuation quotes..
>> 
>> It’s possible to have a multiline “””python””” multi-line string but tidily 
>> indented.
>> As suggested earlier in this thread the lexer can strip the margin on the 
>> basis of
>> the whitespace before the closing quote as per Perl6 (This could be a 
>> modifier “I”
>> but might as well be the default TBH.) Would this be the best of both worlds?
>> 
>> assert( xml == i"""
>> 
>> 
>>
>>\(author)
>>XML Developer's Guide
>>Computer
>>44.95
>>2000-10-01
>>An in-depth look at creating applications 
>> with XML.
>>
>> 
>> ""” )
>> 
>> Other modifiers can also be applied such as “no-escapes"
>> 
>> assert( xml != ei"""
>> 
>>
>>\(author)
>>XML Developer's Guide
>>Computer
>>44.95
>>2000-10-01
>>An in-depth look at creating applications 
>> with XML.
>>
>> 
>> """ )
>> 
>> I’d hope this would satisfy any need for <> 
>> Or you could support both continuation and indented python style:
>> http://johnholdsworth.com/swift-LOCAL-2016-05-05-a-osx.tar.gz 
>> 
>> 
>> John
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> I’m of the opinion that either of these are reasonable solutions, and both 
> offer different tradeoffs. I’m probably partial to the continuation quotes, 
> because I don’t want to be guessing about what is going to end up being in my 
> string and what won’t.  
> 
>> assert( xml != ei"""
>> 
>>
>>\(author)
>>XML Developer's Guide
>>Computer
>>44.95
>>2000-10-01
>>An in-depth look at creating applications 
>> with XML.
>>
>> 
>> ""” )
> 
> For example, is there a new line after ?
> How would the indenting work if it were immediately followed by triple 
> quotes: ”””
> I would really like the first line to be lined up with the rest of the xml. 
> Is that going to introduce a newline into the top of the string?
> 
> Could we just enforce that no characters on the lines of the triple quotes 
> would be included in the string, very much like the heredoc syntax?
> 
> assert( xml != ei"”” The text I’m typing here would cause a compiler 
> error.
> 
> 
>
>\(author)
>XML Developer's Guide
>Computer
>44.95
>2000-10-01
>An in-depth look at creating applications 
> with XML.
>
> 
> same here   ""” )
> 
> Then it’s very clear what the whitespace stripping will do. But what about 
> mixed tab vs whitespace? What is the behavior in that case?
> 
> Tyler
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Then you could even, if you were so daring, put the string modifiers in the 
string as compiler directives.

assert( xml != 
  

Re: [swift-evolution] multi-line string literals.

[John Holdsworth via swift-evolution]

> On 5 May 2016, at 14:17, David Hart  wrote:
> 
> 
>> On 05 May 2016, at 12:30, Michael Peternell via swift-evolution 
>> > wrote:
>> 
>> it's not a secret that I'm not a big fan of the proposal. The third draft 
>> doesn't change this and it's unlikely that any future draft will, because 
>> for me, the problem are the continuation quotes, and for Brent it seems like 
>> they are a must-have-feature (correct me if I'm wrong.)
> 
> I agree with all you said. I’m fairly sure I would never vote for Brent’s 
> proposal simply because of the existence of continuation quotes, no matter 
> the amount of reasoning behind it. They are simply too unwieldy, cumbersome 
> and unfriendly to modification.
> 
> I could see either your proposal, or your proposal without the HERE_DOCs but 
> using Tyler’s/Scala’s .stripMargin. Do you think you could start a formal 
> proposal?


Adapting the original proposal if you’re not a fan of continuation quotes..

It’s possible to have a multiline “””python””” multi-line string but tidily 
indented.
As suggested earlier in this thread the lexer can strip the margin on the basis 
of
the whitespace before the closing quote as per Perl6 (This could be a modifier 
“I”
but might as well be the default TBH.) Would this be the best of both worlds?

assert( xml == i"""


   
   \(author)
   XML Developer's Guide
   Computer
   44.95
   2000-10-01
   An in-depth look at creating applications with 
XML.
   

""” )

Other modifiers can also be applied such as “no-escapes"

assert( xml != ei"""

   
   \(author)
   XML Developer's Guide
   Computer
   44.95
   2000-10-01
   An in-depth look at creating applications with 
XML.
   

""" )

I’d hope this would satisfy any need for 

John

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

Re: [swift-evolution] multi-line string literals.

[Brent Royal-Gordon via swift-evolution]

> It had the idea that maybe the motivation behind continuation quotes is to 
> make using multiline strings harder to use; in order to discourage their use 
> at all.

Absolutely not, and frankly I resent the implication.

I'm looking at a space where (in my opinion) all existing designs are ugly and 
inelegant and trying to find something better. There are *reasons* Swift 2 
doesn't allow newlines in quote marks; I'm trying to address them, not ignore 
them. There are nasty formatting problems; I'm trying to solve them, not 
tolerate them. There are significant context-sensitivity issues; I'm trying to 
fix them, not punt the problem to a syntax highlighter that is absent or 
incorrect in half of our tools.

Here's a piece of code-generating code I once wrote, ported to this prototype:

https://gist.github.com/brentdax/8a8ee1f6028230f68ed85b7f3ebc95bf

(The actual code generation starts on line 93.) 

And here's the same code in (beta-era) Swift 2:


https://github.com/brentdax/WebResponder/blob/master/WebResponderCore/WebResponderCore/codes2swift.swift

I think the new version is an improvement over the old. I think I like it 
better than I would with `"""` or heredocs forcing things against the left 
margin. I think it's nice that I can look at any line—out of context, random 
access—and see which parts are string literals. I think if I want to add a doc 
comment to each of the constants it generates, I have to do a little awkward 
code shuffling, but the result is worth it:

for statusLine in statusLines {
code +=  "/// The HTTP \(statusLine.code) \(statusLine.message) 
status, used with `HTTPResponseType.status`.
 "\(statusLine.constant)
 "
 ""
}

Overall, I find this code a lot more pleasant to read than it was in Swift 2, 
and somewhat more pleasant than it would be with `"""` or a heredoc. Maybe you 
don't agree; maybe you'd rather import some other language's warts. I 
understand—those warts come with convenience advantages, and you might prefer 
that convenience to the other things.

But at least have the basic respect for opposing viewpoints not to impugn my 
motives because you disagree with me or don't like what I suggest. That is just 
not nice.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] multi-line string literals.

[Ricardo Parada via swift-evolution]

I like the continuation quote. It makes the code stay pretty. It doesn't break 
the indentation of your code. If you take out the continuation quote then 
things look out of place, as if someone pasted text in the middle of your code 
by mistake. I don't like the heredoc notation either for the same reasons.

I envision being able to type the opening multi line quote, i.e. M" and then 
pasting multi line text from the clipboard. The editor would do a smart paste 
prepending the lines of text with the continuation character.  

Let's keep our code looking  pretty and focus on the main things:

1. Allow interpolation 
2. Remove the need to add the \n character for each line
3. Remove the need to escape the double quote and apostrophe
4. Keep it simple

I would be fine just with this:

let xml = M"
  "
  " 
  " \(author)
  " 
  "



> On May 5, 2016, at 9:17 AM, David Hart via swift-evolution 
>  wrote:
> 
> 
>> On 05 May 2016, at 12:30, Michael Peternell via swift-evolution 
>> > wrote:
>> 
>> it's not a secret that I'm not a big fan of the proposal. The third draft 
>> doesn't change this and it's unlikely that any future draft will, because 
>> for me, the problem are the continuation quotes, and for Brent it seems like 
>> they are a must-have-feature (correct me if I'm wrong.)
> 
> I agree with all you said. I’m fairly sure I would never vote for Brent’s 
> proposal simply because of the existence of continuation quotes, no matter 
> the amount of reasoning behind it. They are simply too unwieldy, cumbersome 
> and unfriendly to modification.
> 
> I could see either your proposal, or your proposal without the HERE_DOCs but 
> using Tyler’s/Scala’s .stripMargin. Do you think you could start a formal 
> proposal?
> ___
> 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

Re: [swift-evolution] multi-line string literals.

[Ricardo Parada via swift-evolution]

I like the continuation quote. It makes the code stay pretty. It doesn't break 
the indentation of your code. If you take out the continuation quote then 
things look out of place, as if someone pasted text in the middle of your code 
by mistake. I don't like the heredoc notation either for the same reasons.

I envision being able to type the opening multi line quote, i.e. M" and then 
pasting multi line text from the clipboard. The editor would do a smart paste 
prepending the lines of text with the continuation character.  

Let's keep our code looking  pretty and focus on the main things:

1. Allow interpolation 
2. Remove the need to add the \n character for each line
3. Remove the need to escape the double quote and apostrophe
4. Keep it simple

I would be fine just with this:

let xml = M"
   "
   " 
   "   \(author)
   " 
   "



> On May 5, 2016, at 9:17 AM, David Hart via swift-evolution 
>  wrote:
> 
> 
>> On 05 May 2016, at 12:30, Michael Peternell via swift-evolution 
>>  wrote:
>> 
>> it's not a secret that I'm not a big fan of the proposal. The third draft 
>> doesn't change this and it's unlikely that any future draft will, because 
>> for me, the problem are the continuation quotes, and for Brent it seems like 
>> they are a must-have-feature (correct me if I'm wrong.)
> 
> I agree with all you said. I’m fairly sure I would never vote for Brent’s 
> proposal simply because of the existence of continuation quotes, no matter 
> the amount of reasoning behind it. They are simply too unwieldy, cumbersome 
> and unfriendly to modification.
> 
> I could see either your proposal, or your proposal without the HERE_DOCs but 
> using Tyler’s/Scala’s .stripMargin. Do you think you could start a formal 
> proposal?
> ___
> 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

Re: [swift-evolution] multi-line string literals.

[L Mihalkovic via swift-evolution]

> On May 5, 2016, at 12:30 PM, Michael Peternell via swift-evolution 
>  wrote:
> 
> Hi,
> 
> it's not a secret that I'm not a big fan of the proposal. The third draft 
> doesn't change this and it's unlikely that any future draft will, because for 
> me, the problem are the continuation quotes, and for Brent it seems like they 
> are a must-have-feature (correct me if I'm wrong.)
> 
> I just wanted to say that I have drafted a proposal that solves the issues 
> that I have encountered. (It's here: 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/016219.html
>  )
> - it allows pasting text as-is
> - it allows creating string literals where leading space on each line is 
> stripped (while keeping indentation differences intact)
> - it allows creating string literals where leading space on each line is not 
> stripped
> - optionally it allows strings to be raw, without any string interpolation or 
> escaping whatsoever
> - in none of the literals you have to write "", 
> you can just write "". This also lets you 
> copy text out of the program source and back into a HTML file.
> 
> It had the idea that maybe the motivation behind continuation quotes is to 
> make using multiline strings harder to use; in order to discourage their use 
> at all. Two points to consider:
> - people who don't want to use MSL will not, even if you throw Python-like 
> """multi-line strings""" at them.
> - people who want to use them do it, even if there is no MSL available. I saw 
> that in Objective-C, with multiple lines of HTML and CSS wrapped into a big 
> multiline objc-string-literal and thrown at a WebView. I could send the 
> literal to the console before sending it to the WebView and it was basically 
> unreadable. I eventually refactored it to put the thing into a file (also 
> because the HTML grew in space, and the inline-literal became impractical)
> - my most important point: if someone uses multiple lines of HTML or CSS or 
> XML directly within the code, I want it to look okay. I don't want an MSL 
> feature that is so unwieldy that people voluntarily not use it; it would be 
> better to have no MSL at all.
> 
> I don't think that multiline strings are a must-have feature for a language, 
> because they are not used very often. (I included an example of a good use 
> case in my proposal.) I acknowledge that in many programming cases it would 
> be better to not put a huge pile of text directly into the source, but to 
> load the text from a file at runtime. But even when these MSL are misused, I 
> prefer to read a """python multiline string""" over a 
> "concatenated\n"+"Java\n"+"String".
> 
> -Michael


Hi Michael. hope this helps  
https://gist.github.com/lmihalkovic/11f2b1b23b78bbb9cbf0292ffc480b3d


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

Re: [swift-evolution] multi-line string literals.

[Doug McKenna via swift-evolution]

It was not obvious reading this proposal whether comment lines or empty lines 
could be inserted in the middle of the multi-line string (MLS).

For instance, would the following be syntactically legal or not:

let cat = "

  /* Add as many book specs here as you want */

  " 
  " \(author)
  " 

  // More to come

  ""


As someone who has had to write C source code that outputs boilerplate and 
customized code in another language, I think it should be legal to comment on 
the structure of a multi-line string at the most direct and appropriate spot 
within that string, without ill effect, as illustrated above.

What this means is that the failure to end a line with a " when that line 
begins with " means looking ahead not just to the next input line, but to the 
next non-blank (after stripping any comments and/or trailing whitespace) line 
that begins with a " (legal continuation of MLS), or anything else (illegal 
continuation of MLS).


- Doug McKenna
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] multi-line string literals.

[David Hart via swift-evolution]

> On 05 May 2016, at 12:30, Michael Peternell via swift-evolution 
>  wrote:
> 
> it's not a secret that I'm not a big fan of the proposal. The third draft 
> doesn't change this and it's unlikely that any future draft will, because for 
> me, the problem are the continuation quotes, and for Brent it seems like they 
> are a must-have-feature (correct me if I'm wrong.)

I agree with all you said. I’m fairly sure I would never vote for Brent’s 
proposal simply because of the existence of continuation quotes, no matter the 
amount of reasoning behind it. They are simply too unwieldy, cumbersome and 
unfriendly to modification.

I could see either your proposal, or your proposal without the HERE_DOCs but 
using Tyler’s/Scala’s .stripMargin. Do you think you could start a formal 
proposal?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] multi-line string literals.

[Michael Peternell via swift-evolution]

Hi,

it's not a secret that I'm not a big fan of the proposal. The third draft 
doesn't change this and it's unlikely that any future draft will, because for 
me, the problem are the continuation quotes, and for Brent it seems like they 
are a must-have-feature (correct me if I'm wrong.)

I just wanted to say that I have drafted a proposal that solves the issues that 
I have encountered. (It's here: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/016219.html
 )
- it allows pasting text as-is
- it allows creating string literals where leading space on each line is 
stripped (while keeping indentation differences intact)
- it allows creating string literals where leading space on each line is not 
stripped
- optionally it allows strings to be raw, without any string interpolation or 
escaping whatsoever
- in none of the literals you have to write "", 
you can just write "". This also lets you 
copy text out of the program source and back into a HTML file.

It had the idea that maybe the motivation behind continuation quotes is to make 
using multiline strings harder to use; in order to discourage their use at all. 
Two points to consider:
- people who don't want to use MSL will not, even if you throw Python-like 
"""multi-line strings""" at them.
- people who want to use them do it, even if there is no MSL available. I saw 
that in Objective-C, with multiple lines of HTML and CSS wrapped into a big 
multiline objc-string-literal and thrown at a WebView. I could send the literal 
to the console before sending it to the WebView and it was basically 
unreadable. I eventually refactored it to put the thing into a file (also 
because the HTML grew in space, and the inline-literal became impractical)
- my most important point: if someone uses multiple lines of HTML or CSS or XML 
directly within the code, I want it to look okay. I don't want an MSL feature 
that is so unwieldy that people voluntarily not use it; it would be better to 
have no MSL at all.

I don't think that multiline strings are a must-have feature for a language, 
because they are not used very often. (I included an example of a good use case 
in my proposal.) I acknowledge that in many programming cases it would be 
better to not put a huge pile of text directly into the source, but to load the 
text from a file at runtime. But even when these MSL are misused, I prefer to 
read a """python multiline string""" over a "concatenated\n"+"Java\n"+"String".

-Michael

> Am 05.05.2016 um 04:57 schrieb Brent Royal-Gordon via swift-evolution 
> :
> 
>> Brent, what is the state of the proposal document you prepared?
> 
> The state is that there is now a third draft, pasted below.
> 
> The main change in this version is that I've included a *lot* of rationale 
> around what I think needs to be done to strings overall. This kind of bloats 
> the proposal, but I'm not sure if there's a better way to make clear why it's 
> tackling the problems it is.
> 
> John: I have not moved your trailing backslash suggestion back into the 
> proposal yet, simply because I haven't decided how to write it up yet. I 
> probably will unless others strongly think it should be subsetted out.
> 
> Dave: This obliquely addresses some of the points in your email, but I intend 
> to reply more directly soon. Sorry, life has been happening to me during the 
> last few days.
> Multiline string literals
>   • Proposal: SE-
>   • Author(s): Brent Royal-Gordon, John Holdsworth, Tyler Cloutier
>   • Status: Third Draft
>   • Review manager: TBD
> Introduction
> 
> In Swift 2.2, the only means to insert a newline into a string literal is the 
> \n escape. String literals specified in this way are generally ugly and 
> unreadable. We propose a multiline string feature emphasizing code 
> readability which is a straightforward extension of our existing string 
> literals and appears to be exceptionally easy to implement.
> 
> This proposal is the first step in a larger plan to improve how string 
> literals address various challenging use cases. By itself, it is not meant to 
> solve all problems with string escaping or the representation of long string 
> literals. However, it is an important step in that direction, and it does 
> modestly improve on the status quo even for those use cases which we intend 
> to address more directly later.
> 
> See the "Motivation" section for the overall goals of this project, and the 
> "Future directions for string literals in general" section for a sketch of 
> how we might achieve those goals.
> 
> Swift-evolution threads: multi-line string literals. (April), multi-line 
> string literals (December)
> 
> Third draft notes
> 
>   • Expands the "Motivation" section to discuss the overall string 
> improvement project, including a list of goals, and reworks the "Future 
> directions for string literals in general" section to theme it around the new 
> list of goals and to 

Re: [swift-evolution] multi-line string literals.

[L. Mihalkovic via swift-evolution]

Rust and Scala support macros, C++ has templates, and even the venerable C has 
#defines. Introducing mera-programming is by no means easy as it generally 
equates introducing a second, more limited, language inside the original. There 
exists today an opportunity to take advantage of the string literal effort 
* provide a minimalmultiline literal extension
* provide a general mechanism into the current parser for dealing with 
"pockets" of semantically tagged contents into the stream of implicitely 
swift-tagged characters

The latter could be used at a later date for
* custom colorization schemes 
* custom validation

It is conceivable to reserve one of these semantic tags, say SWIFT_SIL for the 
introduction of SIL code in multiline litterals as a test of what macros in 
swift might be.

Done clealy, this scheme has the advantage of
* very minimal intrusion into the existing parser, reducing the risk of 
unwantes side effects
* very minimal level of commitment to featureset of string literals
* maximum open doors regarding what can be added via future via content tags 
(imagine using mime types as tags, while allowing the mirror API to query the 
tag value)
* a simple pathway for the introduction of macros, even supporting different 
types of macro types, none of which requiring changes to the parser once the 
proposed first step is in place

Regards
(From mobile)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] multi-line string literals.

[Tyler Fleming Cloutier via swift-evolution]

Comments inline.

> On May 4, 2016, at 7:57 PM, Brent Royal-Gordon  wrote:
> They separate indentation from the string's contents. Traditional multiline 
> strings usually include all of the content between the start and end 
> delimiters, including leading whitespace. This means that it's usually 
> impossible to indent a multiline string, so including one breaks up the flow 
> of the surrounding code, making it less readable. Some languages apply 
> heuristics, either at compile time or through runtime string manipulation 
> functions, to try to remove indentation, but like all heuristics, these are 
> mistake-prone and murky.
> 
> Continuation quotes neatly avoid this problem. Whitespace before the 
> continuation quote is indentation used to format the source code; whitespace 
> after the continuation quote is part of the string literal. The 
> interpretation of the code is perfectly clear to both compiler and programmer.
> 
> 
Although I agree that there can be problems with runtime manipulation, the 
Scala implementation of stripMargin does, in a way, solve the "n delimiter” 
problem, by allowing you to specify which character should be used for the 
margin marker.  For example,

val s = """
  |Line 1.
  |Line 2.
  |Line 3.""".stripMargin

Source: http://alvinalexander.com/scala/scala-multiline-strings-heredoc-syntax

There are a few issues with this off the bat. First, if you are unfamiliar with 
stripMargin it’s not clear if the first line counts as a newline.

\n
Line 1.\n
Line 2.\n
Line 3.\n

vs

Line 1.\n
Line 2.\n
Line 3.\n

and what about:

val s = “""
  |Line 1.

  |Line 2.
  |Line 3.""”.stripMargin

or

val s = “”"|
  |Line 1.
  |Line 2.
  |Line 3.""”.stripMargin

or

val s = “”"
  |Line 1.
  |Line 2.
  |Line 3.
  |""”.stripMargin


Secondly, due to the start and end delimiters, it doesn’t play as nicely with 
indentation as a single column of quote characters. Furthermore, it requires a 
lot of massaging to get a pasted string to be correct especially because it’s 
difficult to have the editor auto-format since the delimiters are really just 
part of the string.

Plus this has the other issues that you mentioned in terms of syntax 
highlighting, errors, and finding delimiters. Still I think that it does solve 
some of the more major problems and it has the nice property of being 
extensible with a simple standard library change. I don’t think that these 
benefits outweigh these points and the points you brought up, but perhaps it 
should be included in alternatives considered with the reasons for and against? 
>  
> Future
>  directions for multiline string literals
> 
> We could permit comments before encountering a continuation quote to be 
> counted as whitespace, and permit empty lines in the middle of string 
> literals. This would allow you to comment out whole lines in the literal.
> 
> We could allow you to put a trailing backslash on a line to indicate that the 
> newline isn't "real" and should be omitted from the literal's contents. 
> Holdsworth's prototype includes this feature.
> 
> 
Alternately, you could just close the quote on that line, perhaps? As in the 
limerick below.

let limerick = "Here’s a multiline literal string
   "It’s a cool, kinda fun, sort of thing
   "It's got newlines galore
   "but not anymore "
   "'cause I've capped the above line with bling"

This could be implemented by concatenating adjacent strings together 
automatically. However, I’m far from a compiler hacker, would an implementation 
like that be too complicated for the type checker?


>  
> A
>  general mechanism: String literal modifiers
> 
> We may introduce the concept of string literal modifiers to alter the 
> interpretation of string literals. These would become the basis for many 
> future string literal features.
> 
> A string literal modifier is a cluster of identifier characters which goes 
> before a string literal and adjusts the way it is parsed. Modifers only alter 
> the interpretation of the text in the literal, not the type of data it 
> produces; for instance, there will never be something like the 
> UTF-8/UTF-16/UTF-32 literal modifiers in C++. 
> 
> Modifiers can be attached to both single-line and multiline literals, and 
> could also be attached to other literal syntaxes which might be introduced in 
> the future. When used with multiline strings, only the starting quote needs 
> to carry the modifiers, not the continuation quotes.
> 
> In one potential design, uppercase modifier characters enable a feature; 
> lowercase characters disable a feature.
> 
> Our prototype also includes basic support for string modifiers, although the 
> specific behavior of the modifiers in the 

Re: [swift-evolution] multi-line string literals.

[John Holdsworth via swift-evolution]

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

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

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

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

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

let xml = "\
"
"
"   
"   \(author)
"   XML Developer's Guide
"   Computer
"   44.95
"   2000-10-01
"   An in-depth look at creating \
"applications with XML.
"   
"\n"
print(xml)


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

Optionally, for a separate proposal perhaps:

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

assert( xml == _"
"
"   
"   \(author)
"   XML Developer's Guide
"   Computer
"   44.95
"   2000-10-01
"   An in-depth look at creating applications with 
XML.
"   
"
""_ )

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

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

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

Very Optionally, and largely as an historical accident

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

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

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


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

Re: [swift-evolution] multi-line string literals.

[John Holdsworth via swift-evolution]

… response inline

> On May 2, 2016, at 2:23 PM, John Holdsworth  > wrote:
> 
>> 
>>> I'm having trouble getting the `e` modifier to work as advertised, at least 
>>> for the sequence `\\`. For example, `print(e"")` prints two 
>>> backslashes, and `print(e"\\\")` seems to try to escape the string literal. 
>>> I'm currently envisioning `e` as disabling *all* backslash escapes, so 
>>> these behaviors wouldn't be appropriate. It also looks like interpolation 
>>> is still enabled in `e` strings.
>>> 
>>> Since other things like `print(e"\w+")` work just fine, I'm guessing this 
>>> is a bug in the proposal's sketches (not being clear enough about the 
>>> expected behavior), not your code.
>>> 
>>> I've written a gist with some tests to show how I expect things to work:
>>> 
>>> https://gist.github.com/brentdax/be3c032bc7e0c101d7ba8b72cd1a692e 
>>> 
>> The problem here is that I’ve not implemented unescaped literals fully as it 
>> would require changes outside the lexer.
>> This is because the string is first lexed and tokenised by one piece of code 
>> Lexer::lexStringLiteral but later
>> on in the code generation phase it generates the actual literal in a 
>> function Lexer::getEncodedStringSegment.
>> This is passed the same string from the source file but does not know what 
>> modifiers should be applied. As a result
>> normal escapes are still processed. All the “e” flag does is silence the 
>> error for invalid escapes during tokenising.
> 
> Lexer just lays ropes around certain areas to tell what's where. sometimes 
> this is not enough for extra semantics. this is the reason why i went down 
> the path of a custom string_multiline_literal token. It looks like you might 
> want to consider that path too. If you do, you might consider the merits of 
> suggesting that half the work be put in place now, allowing both our 
> experimentations (and other more sophisticated) to lean on it, as an 
> alternative to just directly adding extra conditional code in the default 
> lexer code.

Not sure what you mean here. It’s the modifiers that have a greater effect on 
lexing, not whether a string is multi-line. IMO it’s 
probably best to avoid creating a separate string_multiline_literal token as 
that would require visiting the grammar everywhere
a string could occur. If you want to see what I mean I’ve committed a change 
which uses 3 extra bits to the Token structure to
carry modifiers applied from the lexing stage to code generation so 
non-escaping strings can finally be handled correctly.

https://github.com/apple/swift/pull/2275
new toolchain: http://johnholdsworth.com/swift-LOCAL-2016-05-04-a-osx.tar.gz 


The following now holds

assert( e"\w\d+\(author)\n" == "\\w\\d+\\(author)\\n" );
assert( r"\w\d+\(author)\n" == "\\w\\d+\(author)\n" ); // previous 
implementation

John


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

Re: [swift-evolution] multi-line string literals.

[L. Mihalkovic via swift-evolution]

inline

Regards
(From mobile)

On May 2, 2016, at 2:23 PM, John Holdsworth > wrote:

> 
>> I'm having trouble getting the `e` modifier to work as advertised, at least 
>> for the sequence `\\`. For example, `print(e"")` prints two backslashes, 
>> and `print(e"\\\")` seems to try to escape the string literal. I'm currently 
>> envisioning `e` as disabling *all* backslash escapes, so these behaviors 
>> wouldn't be appropriate. It also looks like interpolation is still enabled 
>> in `e` strings.
>> 
>> Since other things like `print(e"\w+")` work just fine, I'm guessing this is 
>> a bug in the proposal's sketches (not being clear enough about the expected 
>> behavior), not your code.
>> 
>> I've written a gist with some tests to show how I expect things to work:
>> 
>>  https://gist.github.com/brentdax/be3c032bc7e0c101d7ba8b72cd1a692e 
>> 
> The problem here is that I’ve not implemented unescaped literals fully as it 
> would require changes outside the lexer.
> This is because the string is first lexed and tokenised by one piece of code 
> Lexer::lexStringLiteral but later
> on in the code generation phase it generates the actual literal in a function 
> Lexer::getEncodedStringSegment.
> This is passed the same string from the source file but does not know what 
> modifiers should be applied. As a result
> normal escapes are still processed. All the “e” flag does is silence the 
> error for invalid escapes during tokenising.

Lexer just lays ropes around certain areas to tell what's where. sometimes this 
is not enough for extra semantics. this is the reason why i went down the path 
of a custom string_multiline_literal token. It looks like you might want to 
consider that path too. If you do, you might consider the merits of suggesting 
that half the work be put in place now, allowing both our experimentations (and 
other more sophisticated) to lean on it, as an alternative to just directly 
adding extra conditional code in the default lexer code.

> Having encountered this limitation I managed to persuade myself this is what 
> you want anyway but perhaps few would agree,
> What has been implemented is more of an r”” than a e”” that solves the 
> “picket fence” problem where you can also interpolate
> into convenient regex literals. This is all beyond the scope of this proposal 
> anyway so I’ll leave that battle for another day.
> The changes to the compiler for anything else would be a step up in terms of 
> disruption.

I found that by separating new from existing in Lexer using a new token, you 
can go further along without really disrupting the original flow. Having a 
custom token would give your a differentiation point to know how to treat the 
contents differently. As a concrete eg, this is my way to deal with 2 character 
prefix/postfix around multiline literals while keeping the existing 
interpolation logic in place:

void Lexer::getStringLiteralSegments(UNCHANGED SIG) {
  // normal initialization

  // drop double character marker of multiline literals
  if (Str.is(tok::string_multiline_literal)) {
Bytes = Bytes.drop_front().drop_back();
  }
  
  // normal segmenter below
}

Just thinking… another way to differentiation could be to seed the second lexer 
with a specific initial token to giving it a different context to interpret 
incoming chars from. Would probably give you the extra context you seem to be 
looking for (without widening the signature of the existing parse/lexer 
communication channel).

@dabrahams / @clattner
Might I ask if it would be possible to have even a very high level yup/nope 
answer regarding the feasibility of using the temporary lexer swapping facility 
to inline SIL contents as the body of multiline string literal expression? 

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

Re: [swift-evolution] multi-line string literals.

[Dave Abrahams via swift-evolution]

on Sat Apr 30 2016, David Waite  wrote:

> In my opinion, one problem is that we don’t have a reference to a
> laundry or wish list of what features we would like around string
> literals in the language. Without evaluating a proposal against all of
> those features (moves forward, doesn’t impact, creates later issues
> for) it is hard to evaluate.

+1, thank you!

> My guess here at an exhaustive list:
>
> Main goals:
> - reduce the impact on readability when dealing with certain kinds of string 
> literals
> - reduce the amount of editing needed when inserting/referencing text from an 
> external source to be used as a string literal
>
> Specific tasks/asks:
> - for large string literals, reduce the amount of editing needed to span 
> multiple lines
> - for strings literals meant to represent multi-line text, allow the visual 
> newline to be used rather than an encoding
>   (note: this may mean in the first case newlines are considered
> formatting of the literal, while in the second they are considered
> part of the represented text)
> - with string literals spanning multiple lines, allow for the author
> to indent the literal to match flow with surrounding code without
> impacting the represented text
> - allow for text with double quotes to be represented in a string literal 
> without requiring those quotes to be escaped
> - have the ability to disable all/most escape interpretation to reduce impact 
> on readability of certain text
> - take into account that regular expressions, when added, will likely
> require different escaping rules than text string literals
>
> Approach-specific
> - if allowing for inline blocks of strings delimited by start/end points e.g. 
> here docs, data segments
>   - if the block end is on its own line, control whether that newline is 
> part of the represented text
>
> -DW
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Dave

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

Re: [swift-evolution] multi-line string literals.

[Chris Blessing via swift-evolution]

Hi swift-evo,

Forgive my naive interjection here.  I’ve enjoyed lurking on this list and 
watching all the discussions around topics I don’t even fully understand, but 
this one strikes me.

I certainly agree that multi-line literals should be undistorted, and I also 
agree that they should be 100% easy to edit/read in the source. To that end, my 
(hold your breath) PHP dev days made great use of the heredoc syntax. I know it 
has been covered in this thread but I haven’t seen any compelling reason why it 
shouldn’t be the solution to this wanted feature.

var myString = <<>>  // ends here

String interpolation could be implemented as-is:

var myString = <<>>


There are a few constraints from PHP land which might make this easier (? 
simpler?) to implement:

- multi-line string contents begin on the NEXT line after the opening heredoc 
operator
- closing operator MUST have no prefix characters (so it must be directly after 
the last line of the string, and cannot be indented)
—> this means source code formatting can be a tad out of alignment with the 
rest of your code but then what multi-line string isn’t?
-> in fact the behavior is very similar to a  block of HTML, 
whitespace counts!

Benefits include:

- absolutely no need for a line-by-line delimiter
- any character could be supported in the multi-line block
- string interpolation is completely possible (and could be made optional if 
that speeds things up)
- parser errors would be pretty simple to read and should be sufficient to 
prevent compile-time errors


Again apologies if this has already been shot down, and yes I fully admit that 
I don’t even know the origin of heredoc syntax (it’s probably something awful 
or great from the past) but objectively, I can’t see too many downsides to this 
solution.

With humility,

-Chris


> On May 2, 2016, at 7:47 AM, Rainer Brockerhoff via swift-evolution 
>  wrote:
> 
> On 5/2/16 09:53, Brent Royal-Gordon via swift-evolution wrote:
>>  When you are embedding enormous string literals in source code, you 
>>  must put undistorted representation of the string above all other 
>>  considerations. If the design which best permits the string to be 
>>  written verbatim is ugly, bulky, unlike other language constructs, 
>>  disruptive to code readability, error-prone, arbitrary, difficult to 
>>  parse, or otherwise a wart on the language, that is simply the price we 
>>  have to pay for that feature.
> 
> +1. I've tried to write this up a few times, but couldn't find a
> satisfactory syntax; still, how about introducing "named comments" or
> "footnotes in comments" like this:
> 
> /*#label#
> ...N lines of unescaped, as-is text
> #*/
> 
> and elsewhere in source referring to this with some #construct(label)
> syntax?
> 
>>  But it's a different story for short multiline strings. When you are 
>>  writing a little bit of text, but still more than one line, you don't 
>>  want to disrupt your code's indentation, add whole lines just for 
>>  delimiters, insert bizarre or cryptic tokens into your code, or create 
>>  syntax errors which take ten minutes to trace back to their source. You 
>>  want a different feature, with different tradeoffs.
> 
> At least for Xcode having a "paste as escaped string" would solve this,
> other platforms/editors could have a standard macro with the same
> effect. Of course readability of the pasted literal would suffer.
> 
> 
> -- 
> Rainer Brockerhoff  
> Belo Horizonte, Brazil
> "In the affairs of others even fools are wise
> In their own business even sages err."
> http://brockerhoff.net/blog/
> 
> ___
> 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

Re: [swift-evolution] multi-line string literals.

[Rainer Brockerhoff via swift-evolution]

On 5/2/16 09:53, Brent Royal-Gordon via swift-evolution wrote:
>   When you are embedding enormous string literals in source code, you 
>   must put undistorted representation of the string above all other 
>   considerations. If the design which best permits the string to be 
>   written verbatim is ugly, bulky, unlike other language constructs, 
>   disruptive to code readability, error-prone, arbitrary, difficult to 
>   parse, or otherwise a wart on the language, that is simply the price we 
>   have to pay for that feature.

+1. I've tried to write this up a few times, but couldn't find a
satisfactory syntax; still, how about introducing "named comments" or
"footnotes in comments" like this:

/*#label#
...N lines of unescaped, as-is text
#*/

and elsewhere in source referring to this with some #construct(label)
syntax?

>   But it's a different story for short multiline strings. When you are 
>   writing a little bit of text, but still more than one line, you don't 
>   want to disrupt your code's indentation, add whole lines just for 
>   delimiters, insert bizarre or cryptic tokens into your code, or create 
>   syntax errors which take ten minutes to trace back to their source. You 
>   want a different feature, with different tradeoffs.

At least for Xcode having a "paste as escaped string" would solve this,
other platforms/editors could have a standard macro with the same
effect. Of course readability of the pasted literal would suffer.


-- 
Rainer Brockerhoff  
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."
http://brockerhoff.net/blog/

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

Re: [swift-evolution] multi-line string literals.

[LM via swift-evolution]

Inline

Regards
LM
(From mobile)

> On May 2, 2016, at 2:23 PM, John Holdsworth  wrote:
> 
> 
>> I'm having trouble getting the `e` modifier to work as advertised, at least 
>> for the sequence `\\`. For example, `print(e"")` prints two backslashes, 
>> and `print(e"\\\")` seems to try to escape the string literal. I'm currently 
>> envisioning `e` as disabling *all* backslash escapes, so these behaviors 
>> wouldn't be appropriate. It also looks like interpolation is still enabled 
>> in `e` strings.
>> 
>> Since other things like `print(e"\w+")` work just fine, I'm guessing this is 
>> a bug in the proposal's sketches (not being clear enough about the expected 
>> behavior), not your code.
>> 
>> I've written a gist with some tests to show how I expect things to work:
>> 
>>  https://gist.github.com/brentdax/be3c032bc7e0c101d7ba8b72cd1a692e
> 
> The problem here is that I’ve not implemented unescaped literals fully as it 
> would require changes outside the lexer.

I think you are correct, I am looking at Parse.cpp and further down the 
pipeline.

Here is a 1¢ thought born out of this exploration: 

%1 = _"[aapl_sil]"\
// inline sil code (macro-like)
...
// more code
...
"_

Just a different kind of string literal contents... understood by the ide 
(completion/syntax chk) and processed by the compiler at the right stage. Who 
knows where really adventurous devs might take something like this?


> This is because the string is first lexed and tokenised by one piece of code 
> Lexer::lexStringLiteral but later
> on in the code generation phase it generates the actual literal in a function 
> Lexer::getEncodedStringSegment.
> This is passed the same string from the source file but does not know what 
> modifiers should be applied. As a result
> normal escapes are still processed. All the “e” flag does is silence the 
> error for invalid escapes during tokenising.
> 
> assert( e"\w\d+\(author)\n" == "\\w\\d+\(author)\n" );
> 
> Having encountered this limitation I managed to persuade myself this is what 
> you want anyway but perhaps few would agree,
> What has been implemented is more of an r”” than a e”” that solves the 
> “picket fence” problem where you can also interpolate
> into convenient regex literals. This is all beyond the scope of this proposal 
> anyway so I’ll leave that battle for another day.
> The changes to the compiler for anything else would be a step up in terms of 
> disruption.
> 
>>> and one new feature that \ before a newline ignores the newline.
>> 
>> This is in the "Future directions for multiline strings" section of the 
>> proposal. Having implemented this, how do you feel about it? Does it seem 
>> like such a no-brainer that we should just incorporate it into the proposal?
> 
> I agree, lets move it into scope.
> 
> Latest toolchain with the ability to have more than one modifier as you 
> suggest is now:
> http://johnholdsworth.com/swift-LOCAL-2016-05-02-a-osx.tar.gz
> 
> John
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] multi-line string literals.

[Brent Royal-Gordon via swift-evolution]

> So I’m pretty late to the discussion here, but my question is; do we really 
> want to encourage large blocks of text in code?

It's not written up, but it has occurred to me that, rather than having `"""` 
strings or even heredocs for large chunks of text, we might want something 
which puts the text at the end of the file, or even in a separate file. I even 
have some vague ideas about what that might look like.

But that is so *massively* out of scope for Swift 3 that I don't think it's 
worth contemplating right now. There are so many interesting possibilities we 
virtually have to punt.

The latest draft of my proposal adds this section:

### An aside: Small and large multiline strings

The first entry in the list above, "Putting newlines in string 
literals", might be thought of as a subset of the fourth, "putting very 
large quantities of text in string literals". (In fact, *all* of the 
entries could perhaps be subsumed by the fourth.) However, we believe 
they are best addressed as separate goals, using separate features.

When you are embedding enormous string literals in source code, you 
must put undistorted representation of the string above all other 
considerations. If the design which best permits the string to be 
written verbatim is ugly, bulky, unlike other language constructs, 
disruptive to code readability, error-prone, arbitrary, difficult to 
parse, or otherwise a wart on the language, that is simply the price we 
have to pay for that feature.

But it's a different story for short multiline strings. When you are 
writing a little bit of text, but still more than one line, you don't 
want to disrupt your code's indentation, add whole lines just for 
delimiters, insert bizarre or cryptic tokens into your code, or create 
syntax errors which take ten minutes to trace back to their source. You 
want a different feature, with different tradeoffs.

It is that feature which this proposal seeks to design.

I envision that, during Swift 3, people will indeed use multiline string 
literals for very long strings. But eventually (hopefully by 4), we will have 
some other feature specifically designed and optimized for that task, and 
multiline string literals will only be used for relatively short strings where 
the "really long string" feature would be too clunky. I mean things like error 
messages, short snippets of HTML, stuff like that. Things you write in your 
source code, rather than designing somewhere else and then copying to your 
source code.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] multi-line string literals.

[John Holdsworth via swift-evolution]

> I'm having trouble getting the `e` modifier to work as advertised, at least 
> for the sequence `\\`. For example, `print(e"")` prints two backslashes, 
> and `print(e"\\\")` seems to try to escape the string literal. I'm currently 
> envisioning `e` as disabling *all* backslash escapes, so these behaviors 
> wouldn't be appropriate. It also looks like interpolation is still enabled in 
> `e` strings.
> 
> Since other things like `print(e"\w+")` work just fine, I'm guessing this is 
> a bug in the proposal's sketches (not being clear enough about the expected 
> behavior), not your code.
> 
> I've written a gist with some tests to show how I expect things to work:
> 
>   https://gist.github.com/brentdax/be3c032bc7e0c101d7ba8b72cd1a692e

The problem here is that I’ve not implemented unescaped literals fully as it 
would require changes outside the lexer.
This is because the string is first lexed and tokenised by one piece of code 
Lexer::lexStringLiteral but later
on in the code generation phase it generates the actual literal in a function 
Lexer::getEncodedStringSegment.
This is passed the same string from the source file but does not know what 
modifiers should be applied. As a result
normal escapes are still processed. All the “e” flag does is silence the error 
for invalid escapes during tokenising.

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

Having encountered this limitation I managed to persuade myself this is what 
you want anyway but perhaps few would agree,
What has been implemented is more of an r”” than a e”” that solves the “picket 
fence” problem where you can also interpolate
into convenient regex literals. This is all beyond the scope of this proposal 
anyway so I’ll leave that battle for another day.
The changes to the compiler for anything else would be a step up in terms of 
disruption.

>> and one new feature that \ before a newline ignores the newline.
> 
> This is in the "Future directions for multiline strings" section of the 
> proposal. Having implemented this, how do you feel about it? Does it seem 
> like such a no-brainer that we should just incorporate it into the proposal?

I agree, lets move it into scope.

Latest toolchain with the ability to have more than one modifier as you suggest 
is now:
http://johnholdsworth.com/swift-LOCAL-2016-05-02-a-osx.tar.gz

John

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

Re: [swift-evolution] multi-line string literals.

[Basem Emara via swift-evolution]

I’ve been trying to keep up with this thread and this crossed my mind too. Of 
course, we don’t want to rule out multi-line strings because of readability and 
flexibility (Python “”” or Markdown’s ```…``` would be my vote). However, a 
built-in tempting engine like Mustache would be progressive and powerful.

> On May 2, 2016, at 6:31 AM, Haravikk via swift-evolution 
>  wrote:
> 
> So I’m pretty late to the discussion here, but my question is; do we really 
> want to encourage large blocks of text in code? They tend to bloat things, 
> especially if they’re not used very often, and even if they are, any large 
> chunk of text can be loaded from file and cached if (and when) necessary. If 
> you need to process it, then some kind of templating system would be better.
> 
> I dunno, I just feel like if you’re storing enough text that the current 
> syntax becomes burdensome, then perhaps the text should be stored elsewhere? 
> I’d rather discourage big blocks of text in code personally.
> ___
> 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

Re: [swift-evolution] multi-line string literals.

[Brent Royal-Gordon via swift-evolution]

> My only reservation is what external editors will make of these strings as 
> there
> is no precedent in another programming language I am aware of.

I understand what you mean. The `e` syntax is similar to some things in other 
languages (C# uses `@`, Python uses `r`, etc.), but so far as I'm aware, we're 
breaking new ground with the other stuff.

On the other hand, we'd hardly be the first language to do exotic things for 
multiline strings or alternate delimiters. I think people who use general 
purpose text editors are used to this stuff not always working quite right.

> I’ve updated the "reference toolchain" and PR for testing and review.
> 
> http://johnholdsworth.com/swift-LOCAL-2016-05-01-a-osx.tar.gz
> https://github.com/apple/swift/pull/2275

Thank you. It is super-cool to be able to take these things out for a test 
drive.

> This implementation still contains the “e” modifier as an example of how they
> would be lexed (which I’ll remove before submission as it is outside the 
> scope 
> of this proposal)

I left a line comment in the pull request about how it's been implemented, but 
this is great for testing the ergonomics.

I'm having trouble getting the `e` modifier to work as advertised, at least for 
the sequence `\\`. For example, `print(e"")` prints two backslashes, and 
`print(e"\\\")` seems to try to escape the string literal. I'm currently 
envisioning `e` as disabling *all* backslash escapes, so these behaviors 
wouldn't be appropriate. It also looks like interpolation is still enabled in 
`e` strings.

Since other things like `print(e"\w+")` work just fine, I'm guessing this is a 
bug in the proposal's sketches (not being clear enough about the expected 
behavior), not your code.

I've written a gist with some tests to show how I expect things to work:

https://gist.github.com/brentdax/be3c032bc7e0c101d7ba8b72cd1a692e

I haven't looked into Stdlib's testing tools, so I wrote a chunk of code that 
uses an old Perl testing format I know by heart. If these tests look useful, 
I'd be happy to help adapt them to the Swift test suite.

If you want to look instead of run, the actual tests start around line 100. As 
I write this, it currently has three failures and two to-do tests (the todos 
use `e` and `_` at the same time). There are also a couple examples of expected 
compiler errors at the bottom of the file that you can uncomment.

> and one new feature that \ before a newline ignores the newline.

This is in the "Future directions for multiline strings" section of the 
proposal. Having implemented this, how do you feel about it? Does it seem like 
such a no-brainer that we should just incorporate it into the proposal?

> In this implementation modifiers can only be applied to the first segment of 
> the literal.

That is how I imagine this would work. For instance:

let swiftCode = e_"print("hello, world!\n")
 "print("How are you today?")"_

Note that the continuation quote on the second line doesn't say `e` or `_`; it 
is merely a reminder that we are parsing a string literal, and doesn't need 
those things.

(If we wanted to, of course, we *could* require them. But I don't see much 
benefit—it would make changing modifiers burdensome.)

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] multi-line string literals.

[L. Mihalkovic via swift-evolution]

On May 2, 2016, at 1:49 AM, Brent Royal-Gordon  wrote:

>>• using the default string literal recognition mechanism binds us to have 
>> to ‘wait’ a bit in order to figure which kind of string literal we are 
>> dealing with (single/multi line)
> 
> Part of the idea of the continuation quotes proposal is that there *is* no 
> distinction between a single-line literal and a multi-line literal. There are 
> just string literals, which may include one line or many.
> 
> And in general, part of the advantage of this proposal is precisely that it 
> has such low impact on the parser and lexer, and the grammar more generally. 
> It is currently illegal to open a string and fail to close it on the same 
> line, so we are just giving that obviously illegal construct an 
> interpretation. By extending the existing feature, we get a whole lot of 
> stuff for free:
> 

I appreciate how easy it is to retrofit some multiline literal behavior without 
touching much as demonstrated by John's code (I also implemented a different 
patch that isolates all code changes inside a couple new methods and generates 
the existing string_literal token).

The problem I am facing is that I also want to support "ZERO massaging" schemes 
(direct past without editing the lines), and so far I have not seen how to do 
it without opening a wider whole through the parser/lexer. I chose to make a 
parallel route simply to avoid risking making my code a merge nightmare as soon 
as the core team touches anything in the vicinity.


> * We don't have to worry about whether `|>` or `@|` or whatever construct you 
> end up using might, in some place where you could otherwise use a string 
> literal, be confusable with some other construct.
> * We don't have to worry about whether obscure corners of the language, like 
> the string parameters to `@available`, support multiline string literals 
> (they do, automatically).
> * We don't have to do a huge amount of redesigning in the lexer, and I doubt 
> we'll have to touch the parser at all (the prototype doesn't).
> 
> It seems a bit backwards to propose we introduce a separate path for lexing 
> multiline strings, and then complain that one of the proposals on the table 
> makes it difficult to tell which path you should take, when the proposal in 
> question is specifically designed to make having a separate path unnecessary.

Just to be sure, I am complaining about anything, but merely referencing an 
argument I read in one of John Holdsworth's recent contribution. Regarding the 
"unnecessary separate path", IMHO it depends on what the end game is supposed 
to look like (as previously stated, I want to try tagging the contents of 
multine literals, which makes them different from single line ones), and at 
what horizon.

No matter what, you are the experts... I just appreciate how easy the quality 
of the codebase makes prototyping some of these ideas.

King regards
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] multi-line string literals.

[Brent Royal-Gordon via swift-evolution]

>   • using the default string literal recognition mechanism binds us to 
> have to ‘wait’ a bit in order to figure which kind of string literal we are 
> dealing with (single/multi line)

Part of the idea of the continuation quotes proposal is that there *is* no 
distinction between a single-line literal and a multi-line literal. There are 
just string literals, which may include one line or many.

And in general, part of the advantage of this proposal is precisely that it has 
such low impact on the parser and lexer, and the grammar more generally. It is 
currently illegal to open a string and fail to close it on the same line, so we 
are just giving that obviously illegal construct an interpretation. By 
extending the existing feature, we get a whole lot of stuff for free:

* We don't have to worry about whether `|>` or `@|` or whatever construct you 
end up using might, in some place where you could otherwise use a string 
literal, be confusable with some other construct.
* We don't have to worry about whether obscure corners of the language, like 
the string parameters to `@available`, support multiline string literals (they 
do, automatically).
* We don't have to do a huge amount of redesigning in the lexer, and I doubt 
we'll have to touch the parser at all (the prototype doesn't).

It seems a bit backwards to propose we introduce a separate path for lexing 
multiline strings, and then complain that one of the proposals on the table 
makes it difficult to tell which path you should take, when the proposal in 
question is specifically designed to make having a separate path unnecessary.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] multi-line string literals.

[L Mihalkovic via swift-evolution]

Hi John,

in truth, your work is what gave me the idea of creating a separate parsing 
path now (what I called lexStringMultilineLiteral() )exactly for the two points 
you make:

it is possible/straightforward to ‘tweak’ the current lexing code to get 
something going as you proved it
using the default string literal recognition mechanism binds us to have to 
‘wait’ a bit in order to figure which kind of string literal we are dealing 
with (single/multi line)

I poorly described that and apologize for it. So there is now doubt that with 
enough small alterations, the current parser will be made better, smarter, … my 
point is that this may not be desirable, and in fact be like the song of a 
siren calling in the wrong direction?!

Taking today the step to split the parsing into 2 separate paths has some 
implication on the features that can be devised in the future, without IMO ever 
having to revisit this fundamental split. However, I will also be the first to 
recognize that if there is no long term appeal for content type tagging or 
macros or custom formatters/verifiers, then there is indeed no need to split 
the path today, or ever for that matter.

But if these make sense for 3 and more likely past 3, then one can easily see 
today that a split is likely going to make these features a lot easier to 
implement then, and if it is the right path then and we can see it today, then 
IMO it stands to reason to build it in today (per the team’s development 
doctrine that features be as much as possible split between the preliminary 
enablement steps and the specifics of the features) provided that it does not 
commit us to anything today that has not and cannot yet be decided, and 
considering how it will on the other hand facilitate more exploratory work in 
the community with minimal burden to the core team. Considering the length of 
this thread and sophistication of some of the interventions, there is little 
doubt in my mind that this will not be a simple consensus builder, which will 
IMO only increase the value of having a common extension ground for prototypes.

The names I proposed are only the result of trying to make the additions simple 
by reference to the surrounding code, while trying to minimize the intersection 
between current and new code.  To that effect my ongoing implementation is 
based on a couple of changes in lexImpl(), the rest being isolated inside new 
methods. But fundamentally the question I am presenting is about the

long term usability of a contents tagging possibility (does not have to be done 
now, but will IMO be easier that way)
workload management utilitarian aspect of a simple base split today for 
parallel explorations and easier merges along the way

The short term how is only one of the possible ways, which only makes sense 
based on the long term term direction string literals will take.

Best regards, and thank you John for showing me where to start.

LM/


> On May 1, 2016, at 7:15 PM, John Holdsworth  wrote:
> 
> Thanks Brent for pulling together the proposal and summarising this thread.
> 
> I have to say I still feel most drawn to your “continuation quotes” idea and 
> after
> some thought the “_” modifier for _”strings”with”quotes”_ also seems sensible.
> Most of all, for me the appeal of these approaches is their absolute 
> simplicity.
> My only reservation is what external editors will make of these strings as 
> there
> is no precedent in another programming language I am aware of.
> 
> I’ve updated the "reference toolchain" and PR for testing and review.
> 
> http://johnholdsworth.com/swift-LOCAL-2016-05-01-a-osx.tar.gz 
> 
> https://github.com/apple/swift/pull/2275 
> 
> 
> This implementation still contains the “e” modifier as an example of how they
> would be lexed (which I’ll remove before submission as it is outside the 
> scope 
> of this proposal) and one new feature that \ before a newline ignores the 
> newline.
> In this implementation modifiers can only be applied to the first segment of 
> the literal.
> 
> This makes the following strings valid to my mind:
> 
> let xml = "\
> "
> "
> "   
> "   \(author)
> "   XML Developer's Guide
> "   Computer
> "   44.95
> "   2000-10-01
> "   An in-depth look at creating \
> "applications with XML.
> "   
> "
> ""
> print(xml)
> 
> assert( xml == _"
> "
> "   
> "   \(author)
> "   XML Developer's Guide
> "   Computer
> "   44.95
> "   2000-10-01
> "   An in-depth look at creating applications 
> with XML.
> "   
> "
>   

Re: [swift-evolution] multi-line string literals.

[John Holdsworth via swift-evolution]

Thanks Brent for pulling together the proposal and summarising this thread.

I have to say I still feel most drawn to your “continuation quotes” idea and 
after
some thought the “_” modifier for _”strings”with”quotes”_ also seems sensible.
Most of all, for me the appeal of these approaches is their absolute simplicity.
My only reservation is what external editors will make of these strings as there
is no precedent in another programming language I am aware of.

I’ve updated the "reference toolchain" and PR for testing and review.

http://johnholdsworth.com/swift-LOCAL-2016-05-01-a-osx.tar.gz
https://github.com/apple/swift/pull/2275

This implementation still contains the “e” modifier as an example of how they
would be lexed (which I’ll remove before submission as it is outside the scope 
of this proposal) and one new feature that \ before a newline ignores the 
newline.
In this implementation modifiers can only be applied to the first segment of 
the literal.

This makes the following strings valid to my mind:

let xml = "\
"
"
"   
"   \(author)
"   XML Developer's Guide
"   Computer
"   44.95
"   2000-10-01
"   An in-depth look at creating \
"applications with XML.
"   
"
""
print(xml)

assert( xml == _"
"
"   
"   \(author)
"   XML Developer's Guide
"   Computer
"   44.95
"   2000-10-01
"   An in-depth look at creating applications with 
XML.
"   
"
""_ )

try! NSRegularExpression(pattern: e"<([a-zA-Z][\w]*)", options: [])
.enumerateMatches(in: xml, options: [], range: NSMakeRange(0, 
xml.utf16.count)) {
(result, flags, stop) in
print((xml as NSString).substring( with:result!.range(at: 1)))
}

I’d not create a lexStringMultilineLiteral() function just yet as the changes 
are still minor as you
can see from the PR and due to the fact you can’t determine if a string is 
multiline until you
are half way through it. Excuse the “bottom up" approach but the reasoning is 
it would be no
accident that if the lexer and any changes to it are minimal, it will be easy 
to document and use.

John


> On 1 May 2016, at 13:04, L Mihalkovic  wrote:
> 
> [couple minutes read]
> 
> I read with great attention this thread, trying to see it from the 
> implementation viewpoint (I know that the compiler structure should not drive 
> the language features). I also revisited the how-to-contribute notes as well 
> as the dev-process description. One of the ideas that stood out in my mind 
> was that when looking at an implementation, enablement changes should be 
> separated from the bulk of the feature, such that reviews can be easier.
> 
> So I tried to elevate this to the rank of a hidden-mandatory-requirement for 
> anything related to this feature. It lead me to a staged approach to this 
> feature that would allow a lot of things to be done, OVER TIME.
> 
> When distilling this feature to the smallest part enabler that would have to 
> be added to the compiler I came to the following short list
> 
> add a string_multiline_token  to the lexer
> I realize that the current lexer can be tweaked to work (as per John’s PR), 
> but IMO adding a dedicated "hole" in the parsing code is what will give 
> something working today (no difference with current compiler behavior) while 
> allowing all future changes to be cleanly isolated from anything around
> if one accepts the idea of a hole created by the token, then it stands to 
> reason to have delimiters around it. I looking at the structure of the 
> grammar, I came to the conclusion that  _” and “_ where an easy, unambiguous 
> choice (I believe “”” and “”” looked like an equally easy an unambiguous 
> choice)
> the next choice should be the creation of a lexStringMultilineLiteral() and 
> lexMultilineCharacter() method in the Lexer. Again… bare with me, I do 
> believe it is relevant to what everyone wants this feature to be… The latter 
> method should contain only extensions specific to multiline literals 
> delegating common use cases to lexCharacter()
> 
> The main point of following this route (or any equivalent) is that 
> it represents a very clear commitment to multiline string literals
> it ensures that there is no strong commitment to feature details, while 
> allowing many future scenarios
> it will remain backward compatible with enhancements to the current string 
> literal syntax (translation?)
> external contributors will be able to prototype while making sure we stay 
> within strict boundaries for integration with the compiler
> 
> The next equally small step would be to describe the required minimal 

Re: [swift-evolution] multi-line string literals.

[L Mihalkovic via swift-evolution]

[couple minutes read]

I read with great attention this thread, trying to see it from the 
implementation viewpoint (I know that the compiler structure should not drive 
the language features). I also revisited the how-to-contribute notes as well as 
the dev-process description. One of the ideas that stood out in my mind was 
that when looking at an implementation, enablement changes should be separated 
from the bulk of the feature, such that reviews can be easier.

So I tried to elevate this to the rank of a hidden-mandatory-requirement for 
anything related to this feature. It lead me to a staged approach to this 
feature that would allow a lot of things to be done, OVER TIME.

When distilling this feature to the smallest part enabler that would have to be 
added to the compiler I came to the following short list

add a string_multiline_token  to the lexer
I realize that the current lexer can be tweaked to work (as per John’s PR), but 
IMO adding a dedicated "hole" in the parsing code is what will give something 
working today (no difference with current compiler behavior) while allowing all 
future changes to be cleanly isolated from anything around
if one accepts the idea of a hole created by the token, then it stands to 
reason to have delimiters around it. I looking at the structure of the grammar, 
I came to the conclusion that  _” and “_ where an easy, unambiguous choice (I 
believe “”” and “”” looked like an equally easy an unambiguous choice)
the next choice should be the creation of a lexStringMultilineLiteral() and 
lexMultilineCharacter() method in the Lexer. Again… bare with me, I do believe 
it is relevant to what everyone wants this feature to be… The latter method 
should contain only extensions specific to multiline literals delegating common 
use cases to lexCharacter()

The main point of following this route (or any equivalent) is that 
it represents a very clear commitment to multiline string literals
it ensures that there is no strong commitment to feature details, while 
allowing many future scenarios
it will remain backward compatible with enhancements to the current string 
literal syntax (translation?)
external contributors will be able to prototype while making sure we stay 
within strict boundaries for integration with the compiler

The next equally small step would be to describe the required minimal changes 
to Parser, a step I do not want to take now if the compiler experts  view no 
merit at all to the proposed staged approach.



A thought experiment pushing further down this path, shows how the following 
would be equally possible language features (with roughly equivalent 
implementation cost):

let whyOwhy = “”"\
!!Can't understand what improvements it truly delivers 
!!It basically removes a handful of characters
!!It works today
!!But I don't see it as a likable foundations for adding in future 
enhancements
!!\
!!I don't envy the people who will have to support it outside of xcode
!!Or even in xcode (considering how it currently struggles with 
indents/formatting
!!As for elegance, beauty is in the eye of the beholder, they say.
“”"

var json1 = _"[json]\
!!{
!!  "file" : "\(wishIhadPlaceholders)_000.md"
!!  "desc" : "and why are all examples in xml, i thought it died a while 
ago ;-)"
!!  "rational" : [
!!  "Here we go again"
!!  "How will xcode help make these workable"
!!   ]
!!}
“_
var json2 = _"[json]\
{
  "file" : "\(wishIhadPlaceholders)_000.md"
  "desc" : "and why are all examples in xml, i thought it died a while ago ;-)"
  "rational" : [
  "Here we go again"
  "How will xcode help make these workable"
   ]
}
“_

 [_"]  --> start string
 [_"\] --> start line + ignore spaces until eol (basically swallow \r\n)
 [!!\] --> ignore everything until eol... basically the gap does not exits
 ["_]  --> terminate string
 [_"[TYPEID]\] --> start string knowing that it a verifyer or a formatter (or a 
chain of) understanding TYPEID can syntax check or format or or or


IMO splitting these expression from the current lexing/parsing has another long 
term benefits when coupled with the aforementioned idea of contents tagging:
allow external dedicated formatter to be created in any editor supporting swift
allow external validators (including in the form of compiler plugins)
open a door for an equivalent to the scala's macros for contents marked as  
[swift]

Once again I fully appreciate that implementation should not drive language 
design, but considering the flurry of great ideas, I thought it might in this 
instance be useful to identify a minimal, noncommittal, direction common to 
many scenarios, such that a step can be taken that will neither favor nor 
prohibit any of the proposals, but simply enable them all.

Thank you for your patience
Regards

PS: I am working on a rudimentary implementation that I hope could help 

Re: [swift-evolution] multi-line string literals.

[David Waite via swift-evolution]

In my opinion, one problem is that we don’t have a reference to a laundry or 
wish list of what features we would like around string literals in the 
language. Without evaluating a proposal against all of those features (moves 
forward, doesn’t impact, creates later issues for) it is hard to evaluate.

My guess here at an exhaustive list:

Main goals:
- reduce the impact on readability when dealing with certain kinds of string 
literals
- reduce the amount of editing needed when inserting/referencing text from an 
external source to be used as a string literal

Specific tasks/asks:
- for large string literals, reduce the amount of editing needed to span 
multiple lines
- for strings literals meant to represent multi-line text, allow the visual 
newline to be used rather than an encoding
(note: this may mean in the first case newlines are considered 
formatting of the literal, while in the second they are considered part of the 
represented text)
- with string literals spanning multiple lines, allow for the author to indent 
the literal to match flow with surrounding code without impacting the 
represented text
- allow for text with double quotes to be represented in a string literal 
without requiring those quotes to be escaped
- have the ability to disable all/most escape interpretation to reduce impact 
on readability of certain text
- take into account that regular expressions, when added, will likely require 
different escaping rules than text string literals

Approach-specific
- if allowing for inline blocks of strings delimited by start/end points e.g. 
here docs, data segments
- if the block end is on its own line, control whether that newline is 
part of the represented text

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

Re: [swift-evolution] multi-line string literals.

[Brent Royal-Gordon via swift-evolution]

> Second, this proposal should explain why it's reinventing the wheel
> instead of standardizing existing, very successful, prior art.  Answer
> the question: “what compelling advantages does this syntax have over
> Python's?”

Sure.

First of all, I will admit up front that I have not written much Python (a 
couple weeks ago, "much" would have been "any") and I may not fully understand 
their string literals. So I'll start by describing my understanding of the 
design in question; then I'll critique the design as I understand it. So if 
something in this section is wrong, please forgive any related mistakes in the 
critique.

Python offers a `"""` string which is almost the same as the `"` string:

* Every character between the first `"""` and the second `"""` is part 
of its contents.
* Escapes are processed normally.
* There is no special behavior with regards to whitespace.

The only difference is that a `"""` string allows real, unescaped newlines in 
it, while a `"` string forbids them. (And, of course, since the delimiter is 
`"""`, the strings `"` and `""` are interpreted literally.)

This approach is really simple, which is a plus, but it has a number of issues.



CONTENT FORMATTING

A number of aspects of the design combine to make `"""` strings harder to read 
than they should be:

* You can't indent the contents of a `"""` string to match the code 
it's in. This is actually pretty shocking considering how sensitive Python is 
to indentation, and it necessitates a number of strange hacks (for instance, 
Python's `help()` function unindents all but the first line of doc strings).
* You can't put all of the contents against the left margin, either, 
because a newline right after the `"""` is counted as part of the string's 
contents. (You can use a backslash to work around this.)
* The last line of the string also has to have the delimiter in it, 
because again, a newline right before the `"""`is counted as part of the 
string's contents. (You can use a backslash to work around this, but the 
backslash is *not* in the mirror position of the start of the string, so good 
luck remembering it.)

In other words, the first and last lines have to be adulterated by adding a 
`"""`, and the middle lines can't be indented to line up with either the 
surrounding code or the beginning of the first line. If one of the selling 
points of this feature is that you just stick your contents in verbatim without 
alteration, that isn't great.

This is such a problem that, in researching `"""` to be sure I understood how 
it works, I came across a Stack Overflow question whose answers are full of 
people recommending a different, more highly punctuated, feature instead: 


(There is an alternate design which would fix the beginning and end problems: 
make a newline after the opening delimiter and before the closing delimiter 
mandatory and part of the delimiter. You might then choose to fix the 
indentation problem by taking the whitespace between the closing delimiter and 
the newline before it as the amount of indentation for the entire string, and 
removing that much indentation from each line. But that's not what Python does, 
and it's not what you seem to be proposing.)



BREAKING UP EXPRESSIONS

String literals are expressions, and in fact, they are expressions with no side 
effects. To do anything useful, they *must* be put into a larger expression. 
Often this expression is an assignment, but it could be anything—concatenation, 
method call, function parameter, you name it.

This creates a challenge for multiline strings, because they can become very 
large and effectively break up the expression they're in. The 
continuation-quote-based multiline strings I'm proposing are aimed primarily at 
relatively short strings*, where this is less of a concern. But `"""` aims to 
be used not only for short strings, but for ones which may be many dozens or 
even hundreds of lines long. You're going to end up with code like:

print("""


...
...
...a hundred more lines of XML with interpolations in 
it...
...
...

""")

What does that `)` mean? Who knows? We saw the beginning of the expression an 
hour and a half ago. (It's common to avoid this issue by assigning the string 
to a constant even if it's only going to be used once, but that just changes 
the problem a little—now you're trying to remember the name of a local variable 
declared a hundred lines ago.)

Heredocs cleverly avoid this issue by not trying to put the literal's contents 
in the middle of the expression. Instead, they put a short placeholder in the 
expression, then start the contents on the next line. The expression is 
readable as an 

Re: [swift-evolution] multi-line string literals.

[Dave Abrahams via swift-evolution]

on Thu Apr 28 2016, Brent Royal-Gordon  wrote:

> Awesome. Some specific suggestions below, but feel free to iterate in a 
> pull
> request if you prefer that.
>
> I've adopted these suggestions in some form, though I also ended up rewriting
> the explanation of why the feature was designed as it is and fusing it with
> material from "Alternatives considered".
>
> (Still not sure who I should list as a co-author. I'm currently thinking John,
> Tyler, and maybe Chris? Who's supposed to go there?)

A couple of remarks:

First, this passage is wrong about the reliability of the triple-quote syntax:

>   (like Python's """ strings) which trick some syntax
>   highlighters into working some of the time with some contents, we don't 
> think
>   this occasional, accidental compatibility is a big enough gain to justify
>   changing the design.

I've never seen a syntax highlighter have problems with it, I don't see
how it *could* ever cause a problem, and lastly I think it's both naïve
and presumptuous to call these effects accidental.

Second, this proposal should explain why it's reinventing the wheel
instead of standardizing existing, very successful, prior art.  Answer
the question: “what compelling advantages does this syntax have over
Python's?”

-- 
Dave

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

Re: [swift-evolution] multi-line string literals.

[Dave Abrahams via swift-evolution]

on Sat Apr 30 2016, "Ted F.A. van Gaalen via swift-evolution" 
 wrote:

> @Dave  also
> what do you think about this? 
> I am trying to avoid the conclusion that most Swift-evolution
> participants are very much FP biased.  is this the case?

I don't believe so.

> (some have ventilated this before in different tunes) 
> That wouldn’t be too much of a problem where it not for the (hopefully
> wrong) impressions that:
>
> - Functional Programmers think (like the LISP-ers did in the
> seventies) that they are superior and Mathematically Correct, there is
> no other way, and therefore all else is hopelessly wrong and should be
> recklessly removed (from Swift in this case) like removing language
> elements that are not in line with FP?

The things we've removed from the language, and the reasons we've
removed them, don't have anything to do with FP.  Personally I'm
ambivalent about many of the removals, but as I understand the rationale it is
mostly about eliminating some error-prone `C' heritage, and that makes
sense to me.

> Consider for a moment that Swift-Evolution was OOP-dominated
> and therefore happily removing closures/lambdas protocols, 
> because they have never used it or even do not understand it?
> would you accept that?
>
> (protocols in Swift are cool btw, as for me, 
> I take the best of both worlds whether FP and/or OOP) 

Protocols have nothing in particular to do with FP either.

-- 
Dave

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

Re: [swift-evolution] multi-line string literals.

[Ted F.A. van Gaalen via swift-evolution]

Hi Brent,

@Dave - Hi Dave, please see at the end of this email. 

Thanks for your energetic reply, Brent.
First of all, I think there is a place in Swift for “your” and “mine” proposing 
solutions 
together. I will reply further inline -> 
> On 30.04.2016, at 09:43, Brent Royal-Gordon  wrote:
> 
>> Example 1. The \@ operator: 
>> 
>>   // 1.  multi-line string literal with data lines as is. 
>> // It loads each line (part) up to and including the 
>> source-file-line- end:
>> // you can use all available characters without problems, 
>> // even \\ and \@  thus allowing you to nest e.g. Swift 
>> statements...  
>> 
>> let xml =
>> \@
>>   \@  
>>   \@  // this is not 
>> regarded as a comment.
>>   \@   //¯\"_(ツ)_//
>>   \@
>> \@   
>> 
>> 
>>   Example 2, The \\ operator: 
>>   // Multi-line string literal with data lines with \n \t etc. respected: 
>> 
>> var str =
>> \\This is line one.\nThis is line two, with a few \t\t\t 
>> tabs in it...
>> \\
>> \\This is line three: there are \(cars) 
>> // this is a comment.
>> \\ waiting in the garage. This is still line three
> 
> There are a lot of reasons why I don't like these.
> 
> The first is simply that I think they're ugly
To me, that is not relevant: 
If something is “ugly”  or not is tied to different and unique 
personal reference, accumulated by experience and 
human instinct and are thus not comparable because no two 
beings are the same. Ergo: This voids a discussion between 
you and me about this subjective aspect “ugliness” 
Still, this aspect should be subordinate to functionality
 (in this case the functionality of a programming language).


> and don't look like they have anything to do with string literals,
You’re right about that:  they are not *string literals* but *data lines*.

 
> but that's solvable. For instance, we could modify my proposal so that, if 
> you were using continuation quotes, you wouldn't have to specify an end quote:
> 
> let xml =
> "
>"  
>"  // this is not 
> regarded as a comment.
>"   //¯\"_(ツ)_//
>"
> "   

Essentially the above is similar to what I propose with “my” data line,
that is, starting each line with a special character/token. But that is where 
the
similarity ends: It does not offer processing for *both*:
- "as-is" character data
-  character data where escaped characters need to be processed.
   
> 
> So let's set the bikeshed color aside and think about the deeper problem, 
> which is that line-oriented constructs like these are a poor fit for string 
> literals.

> 
> A string literal in Swift is an expression, and the defining feature of 
> expressions is that they can be nested within other expressions.
That is logically correct, (but desirable in all cases? (readability)) however: 
   
As said before, these \@…..  and \\…..   are data lines, not string literals. 
They are not intended to replace string literals.  A slightly different concept.

Data lines are just that and -apart from assignment, that is to be loaded in a 
String variable or constant- 
not really intended to take further part in expressions. 
however you can still do that, as shown further below.  


> We've been using examples where we simply assign them to variables, but quite 
> often you don't really want to do that—you want to pass it to a function, or 
> use an operator, or do something else with it. With an ending delimiter, 
> that's doable:
> 
>   let xmlData = 
> "
>"  
>"  // this is not 
> regarded as a comment.
>"   //¯\"_(ツ)_//
>"
> "  ".encoded(as: UTF8)
I do experience this as being “ugly”, but again, this is personal.
> 
> But what if there isn't a delimiter? You would't be able to write the rest of 
> the expression on the same line. In a semicolon-based language, that would 
> merely lead to ugly code:
> 
>   let xmlData = 
> "
>"  
>"  // this is not 
> regarded as a comment.
>"   //¯\"_(ツ)_//
>"
> "  
>.encoded(as: UTF8);
> 



In “my” case this would be:

   let xml =
 \@
 \@  
 \@  // this is not 
regarded as a comment.