[swift-evolution] multi-line string literals.

Haravikk swift-evolution at haravikk.me
Mon Apr 3 08:38:58 CDT 2017


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 <swift-evolution at swift.org> 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 (daniel at crossroadlabs.xyz <mailto:daniel at 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 at swift.org <mailto:swift-evolution at 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 (charlie at charliemonroe.net <mailto:charlie at 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.zubarev at devandartist.com <mailto:adrian.zubarev at 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 (charlie at charliemonroe.net <mailto:charlie at 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 = '''
>>>>> |<?xml version="1.0"?> 
>>>>> |<catalog> 
>>>>> | <...>
>>>>> |</catalog> 
>>>>> '''
>>>>> 
>>>>> This way, if you care about the leading whitespace, you define the line beginning using "|".
>>>>> 
>>>>> Two characters aren't harmful, but in my experience when working with HTML strings, etc. the quote-escaping is extremely tedious.
>>>>> 
>>>>>> On Apr 3, 2017, at 11:06 AM, Adrian Zubarev <adrian.zubarev at devandartist.com <mailto:adrian.zubarev at devandartist.com>> wrote:
>>>>>> 
>>>>>> My main concern with this approach is that you donā€™t have any control about indent and you loose pre- and post spacing characters.
>>>>>> 
>>>>>> A concatenating approach is a little tedious but itā€™s precise. In any situation a multi-lined string is not softly wrapped string, which implies that you will have to press enter for each new line you wish to have. IMHO adding two more characters for each line isnā€™t that harmful. ;-)
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> Adrian Zubarev
>>>>>> Sent with Airmail
>>>>>> 
>>>>>> Am 3. April 2017 um 10:49:02, Charlie Monroe (charlie at charliemonroe.net <mailto:charlie at charliemonroe.net>) schrieb:
>>>>>> 
>>>>>>> While I long for multiline string literals, I'd also very like to see a different syntax as in many cases, these can be XML/HTML snippets and the use of quotes is ubiqituous. I'd very much like to see a variant where you can simply paste almost any string without escaping it.
>>>>>>> 
>>>>>>> For example, Scala uses a tripple-quote syntax... As we've gotten rid of ' for character literals, we could use it for multiline strings?
>>>>>>> 
>>>>>>> Or possibly tripple-apostrophe for multiline strings?
>>>>>>> 
>>>>>>> let xml = '''
>>>>>>> <?xml version="1.0"?> 
>>>>>>> <catalog/> 
>>>>>>> '''
>>>>>>> 
>>>>>>> 
>>>>>>>> On Apr 3, 2017, at 9:01 AM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>>>> 
>>>>>>>> Hello Swift community,
>>>>>>>> 
>>>>>>>> on Github there is a PR for this proposal, but I couldnā€™t find any up to date thread, so Iā€™m going to start by replying to the last message I found, without the last content.
>>>>>>>> 
>>>>>>>> I really like where this proposal is going, and my personal preference are *continuation quotes*. However the proposed solution is still not perfect enough for me, because it still lacks of precise control about the trailing space characters in each line of a multi-line string.
>>>>>>>> 
>>>>>>>> Proposed version looks like this:
>>>>>>>> 
>>>>>>>> let xml = "<?xml version=\"1.0\"?>
>>>>>>>>     "<catalog>
>>>>>>>>     "    <book id=\"bk101\" empty=\"\">
>>>>>>>>     "        <author>\(author)</author>
>>>>>>>>     "        <title>XML Developer's Guide</title>
>>>>>>>>     "        <genre>Computer</genre>
>>>>>>>>     "        <price>44.95</price>
>>>>>>>>     "        <publish_date>2000-10-01</publish_date>
>>>>>>>>     "        <description>An in-depth look at creating applications with XML.</description>
>>>>>>>>     "    </book>
>>>>>>>>     "</catalog>
>>>>>>>>     ""
>>>>>>>> I would like to pitch an enhancement to fix the last tiny part by adding the escaping character ā€˜' to the end of each line from 1 to (n - 1) of the n-lined string. This is similar to what Javascript allows us to do, except that we also have precise control about the leading space character through ā€™"ā€™.
>>>>>>>> 
>>>>>>>> The proposed version will become this:
>>>>>>>> 
>>>>>>>> let xml = "<?xml version=\"1.0\"?>\      
>>>>>>>>     "<catalog>\ // If you need you can comment here
>>>>>>>>     "    <book id=\"bk101\" empty=\"\">\
>>>>>>>>     "        <author>\(author)</author>\
>>>>>>>>     "        <title>XML Developer's Guide</title>\
>>>>>>>>     "        <genre>Computer</genre>\
>>>>>>>>     "        <price>44.95</price>\
>>>>>>>>     "        <publish_date>2000-10-01</publish_date>\
>>>>>>>>     "        <description>An in-depth look at creating applications with XML.</description>\
>>>>>>>>     "    </book>\
>>>>>>>>     "</catalog>\
>>>>>>>>     ""
>>>>>>>> Here is another example:
>>>>>>>> 
>>>>>>>> let multilineString: String = "123__456__\ // indicates there is another part of the string on the next line
>>>>>>>>                               "__789_____\ // aways starts with `"` and ends with either `\` or `"`
>>>>>>>>                               "_____0_" // precise control about pre- and post-space-characters
>>>>>>>> 
>>>>>>>> let otherString = "\(someInstance)\ /* only comments are allowed in between */ "text \(someOtherInstance) text"
>>>>>>>> This is simply continuation quotes combined with backslash concatenation.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -- 
>>>>>>>> Adrian Zubarev
>>>>>>>> Sent with Airmail
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> swift-evolution mailing list
>>>>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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


More information about the swift-evolution mailing list