[swift-evolution] [Review] SE-0168: Multi-Line String Literals

[Vladimir.S]

On 12.04.2017 17:52, Thorsten Seitz via swift-evolution wrote:
>> Am 12.04.2017 um 15:40 schrieb Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org>:
>>
>> Hey folks,
>>
>>
>> We've revised the proposal again. The main difference: You no longer need an initial newline to enable indentation stripping, and stripping no longer removes that newline even if it is present. (Adrian Zubarev and I believe some others argued for this.) We
> 
> Hmm, not sure if I like these changes. I expect that almost all strings won't begin with a newline and a majority won’t end with a newline. The new design would require a leading backslash almost all the time and a trailing backslash often, which is ugly:
> 
> let mystring = "““\
>      text text
>      text text\
>      "““

Agree with Thorsten. This is just ugly syntax for commonly used case.
Why not simple rule that content of multi-line string is all lines *between* leading 
and trailing """ ? So, as was discussed, or you have single line """text""" or 
multiline, where opening and closing """ should be on separate lines with text, and 
text is lines strictly between.
Even more, I feel such solution will be more consistent, as trailing triple quotes 
does not inject \n symbol -> so leading """ also should not inject it. In this case 
""" is just a marker of start/end of multi-line string. Simple model, nice-looking 
code for common cases, can tune emitting of \n symbol as you wish. No?

> 
> -Thorsten
> 
> 
>> disagreed with this at first, but it made more sense as we thought about it more. There are a few things we like about it:
>>
>> 	1. The rules and algorithm are simpler.
>> 	2. It accommodates more coding styles.
>> 	3. Every non-escaped newline in the literal now creates a corresponding newline in the resulting string.
>> 	4. it's easy to get the old behavior back by backslashing the leading newline.
>>
>> Unfortunately, I think this precludes stripping the trailing newline by default, but I think this is ultimately a simpler and better approach than the previous draft.
>>
>> Other changes:
>>
>> 	* We realized we needed to make closing delimiter matching a little more complicated if we wanted to allow one or two adjacent double-quote characters that were part of the literal's contents. Oops.
>> 	* Tabs aren't actually allowed in ordinary string literals, so we now explicitly mention that as a difference between the two types.
>> 	* We wrote some tests for the prototype (though they haven't been updated for this new version yet).
>> 	* There were some other wording changes, particularly in the indentation stripping rationale, but nothing that affects the actual design.
>>
>> I understand John is working on a new version of his toolchain so people can play with the prototype. We hope to have that ready for you all soon.
>>
>> Let us know what you think of the revisions!
>>
>> -- 
>> Brent Royal-Gordon
>> Architechies
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>