• 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

Reply via email to