+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 > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/034897.html > > <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 > > <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 > > <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 <http://www.synopsys.com/software> > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
