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

Evolution Discussion
1

• What is your evaluation of the proposal?

-0.1

• Is the problem being addressed significant enough to warrant a change to Swift?

Yes

• Does this proposal fit well with the feel and direction of Swift?

I don't think so. While Python's way of doing multiline strings may work for Python, I don't think it's an aesthetic fit for Swift, both because of the somewhat nebulous treatment of newlines and the magical-feeling indentation. Magic is a core component of Python, but has no place in Swift.

The alternative, continuation quotes, is my preferred solution to this problem. However I think it would be improved if lines began with a single quote or pipe or some other character, basically anything other than double quotes.

Advantages of continuation characters are that it is immediately clear how much leading whitespace a line actually has and that the string's value is insensitive to the indentation of the individual lines. The second point will be very useful when copying and pasting multiline strings, as the value of the string cannot change unless whitespace is explicitly inserted after the leading character. How many times have we copy-pasted code in Python, only to be stung by improper indentation of the pasted code? With a leading character on continuation lines, you can highlight and auto-indent — that's the only kind of magic that Swift should support.

If we want to make copying and pasting text from elsewhere (e.g., SQL queries) simple, then the compiler can provide a fix-it for multiline strings lacking continuation characters, offering to place the continuation character at the start of each line at the position determined by the start of the least indented offending line.

However, if we decide not to go with continuation quotes, then I largely agree with what Haravikk said here: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I don't like stealing from Python because Swift's and Python's styles are very different. Swift should steer clear of Python's magic.

Aside from Python, no.

• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick read, and followed the discussion.

2

• What is your evaluation of the proposal?

-1, for two reasons:

(from [swift-evolution] multi-line string literals. and follow-up)

First, having the same beginning and ending delimiter, with no continuation character, makes it very easy for a syntax highlighter or tokenizer to get "inverted" in what it believes is string content and what it believes is code. I have seen this happen due to a subtle bug in a Python syntax highlighter, and it's incredibly frustrating that a single misinterpretation can "invert" the highlighting of the rest of the file. It's also possible that future syntactic enhancements to Swift could lead to inversion in a correct highlighter for an older version of Swift reading a newer Swift file.

When working with an online tokenizer / highlighter while editing your code, the proposed design maximizes what needs to get re-parsed as """ are added and removed. Sure, automatic insertion of close-""" helps, but not fully.

Under this proposal, you might say, "you can assume it's code again if the indentation decreases too much." There are two problems with that. First, the required indentation is determined by the line with the close """, so there's no way to detect a violation until you get there. Second, the user might have intended that as part of the quoted text but messed up the formatting. In that case, if you assume resumption of code, the actual close """ will be interpreted as an open """ and you have inversion anyway. So it's not clear that you've decreased the likelihood of inversion.

Second, as others have pointed out, the proposal is quite lacking in specifics. For example, it's not clear if characters are allowed on the same line after an open """. If not allowed, a syntax highlighter could heuristically distinguish open and close """ based on non-whitespace on the same line (just not the case of """ on a line with only whitespace - perhaps that should be disallowed). This could be helpful for recovery in tokenization/highlighting, but this proposal is unclear.

• Is the problem being addressed significant enough to warrant a change to Swift?

Yes. Especially since unused string expressions are not a compilation error, using + to construct long strings spanning multiple lines is hazardous.

(See [swift-evolution] Disallowing many expressions with unused result (@error_unused_result?) )

• Does this proposal fit well with the feel and direction of Swift?

I'm not satisfied this proposal has sufficiently addressed issues in the language feature being mostly inherited here.

• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I have experience with some tools supporting Python and we had issues with syntax highlighting ending up "inverted" because """ strings have the same beginning and ending delimiter.

• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick read, and participation in the discussion. I don't see any evidence the proposal took into account recent discussion:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/034856.html

···

--
Peter Dillinger, Ph.D.
Software Engineering Manager, Coverity Analysis, Software Integrity Group | Synopsys

3

+0.5

Positive on multi-line string literal
Negative on the delimiter.

I don’t like continuation character, but would like to have something similar to classic C comments: distinct, symmetrical opening and closing delimiters. But I don’t have any specific suggestion.

···

On Apr 7, 2017, at 11:32 AM, Peter Dillinger via swift-evolution <swift-evolution@swift.org> wrote:

• What is your evaluation of the proposal?

-1, for two reasons:

(from [swift-evolution] multi-line string literals. and follow-up)
First, having the same beginning and ending delimiter, with no continuation character, makes it very easy for a syntax highlighter or tokenizer to get "inverted" in what it believes is string content and what it believes is code. I have seen this happen due to a subtle bug in a Python syntax highlighter, and it's incredibly frustrating that a single misinterpretation can "invert" the highlighting of the rest of the file. It's also possible that future syntactic enhancements to Swift could lead to inversion in a correct highlighter for an older version of Swift reading a newer Swift file.

When working with an online tokenizer / highlighter while editing your code, the proposed design maximizes what needs to get re-parsed as """ are added and removed. Sure, automatic insertion of close-""" helps, but not fully.

Under this proposal, you might say, "you can assume it's code again if the indentation decreases too much." There are two problems with that. First, the required indentation is determined by the line with the close """, so there's no way to detect a violation until you get there. Second, the user might have intended that as part of the quoted text but messed up the formatting. In that case, if you assume resumption of code, the actual close """ will be interpreted as an open """ and you have inversion anyway. So it's not clear that you've decreased the likelihood of inversion.

Second, as others have pointed out, the proposal is quite lacking in specifics. For example, it's not clear if characters are allowed on the same line after an open """. If not allowed, a syntax highlighter could heuristically distinguish open and close """ based on non-whitespace on the same line (just not the case of """ on a line with only whitespace - perhaps that should be disallowed). This could be helpful for recovery in tokenization/highlighting, but this proposal is unclear.

• Is the problem being addressed significant enough to warrant a change to Swift?

Yes. Especially since unused string expressions are not a compilation error, using + to construct long strings spanning multiple lines is hazardous.
(See [swift-evolution] Disallowing many expressions with unused result (@error_unused_result?) )

• Does this proposal fit well with the feel and direction of Swift?

I'm not satisfied this proposal has sufficiently addressed issues in the language feature being mostly inherited here.

• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I have experience with some tools supporting Python and we had issues with syntax highlighting ending up "inverted" because """ strings have the same beginning and ending delimiter.

• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick read, and participation in the discussion. I don't see any evidence the proposal took into account recent discussion:

[swift-evolution] multi-line string literals.

--
Peter Dillinger, Ph.D.
Software Engineering Manager, Coverity Analysis, Software Integrity Group | Synopsys
Synopsys Software Security | Software Integrity Group <http://www.synopsys.com/software&gt;

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution