[swift-evolution] [Review] SE-0168: Multi-Line String Literals
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution