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

Thorsten Seitz tseitz42 at icloud.com
Sat Apr 15 14:28:08 CDT 2017


> Am 15.04.2017 um 16:46 schrieb Ricardo Parada <rparada at mac.com>:
> 
> Reply inline. 
> 
> On Apr 15, 2017, at 8:48 AM, Thorsten Seitz via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> 
>>> Am 15.04.2017 um 09:24 schrieb Adrian Zubarev via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>>> 
>>> […]
>>> 
>>> Now it’s time to solve the puzzle in your example. The correct result should be as follows:
>>> 
>>> (a + b) == """
>>> This is line one
>>> This is line twoThis is line three
>>> This is line four
>>> """
>>> 
>>> // Or more precise
>>> (a + b) == "This is line one\nThis is line twoThis is line three\nThis is line four“
>> 
>> I disagree and think BJ Homer is right: the multiline variant contains *lines* which all end with a newline. That is a very simple mental model.
>> 
>> I do agree that the mixed modes (v1, v2, v3) should be banned.
> 
> Hi Thorsten, I think v2 would allow you to pick an alternate style to define your multiline string literal. For example, take a look at the xml string literal defined in two different ways under the Indentation Stripping section in Brent's proposal here:
> 
> https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md <https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md>
> 
> Here is another example:
> 
> 	case .isExprSameType(let from, let to):
> 		return """checking a value with optional type \(from) \
> 			  against dynamic type \(to) \
> 			  succeeds whenever the value is non-'nil'; \
> 			  did you mean to use '!= nil'?\
> 			  """
> 

This only works because the lines have been indented by hand to match correctly which would not be the case with standard indentation used in a code editor which is a fixed multiple of spaces or tabs: the example had to add 2 spaces to the 2 tabs in this example to fix the indentation (requiring 8-space-tabs). In reality the example would look like follows (assuming 4-space-indentation but the problem is the same for other indentations):

case .isExprSameType(let from, let to):
    return """checking a value with optional type \(from) \
        against dynamic type \(to) \
        succeeds whenever the value is non-'nil'; \
        did you mean to use '!= nil'?\
        """

And the alignment has gone awry… That’s why I think this form is problematic. It saves just one line for the price of a broken alignment. 
(Requiring the editor to have content sensitive indentation is a no go).

> I personally do not find this style confusing at all.

The confusion arises over the leading newline: why does text directly following the opening triple quote have a newline while an empty line after the opening triple quote does not have a newline?

Banning the mixed form eliminates that question which is a good thing IMHO.

-Thorsten


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


More information about the swift-evolution mailing list