• What is your evaluation of the proposal?
-1, for two reasons: (from https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/034897.html 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 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034472.html ) • 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 www.synopsys.com/software
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
