Swift should treat common Unicode substitutions as their ASCII equivalents
| Originator: | brent | ||
| Number: | rdar://17297117 | Date Originated: | 12-Jun-2014 08:40 PM |
| Status: | Open | Resolved: | |
| Product: | Developer Tools | Product Version: | Xcode6-Beta (6A215l) |
| Classification: | Enhancement | Reproducible: | Always |
Summary:
In 2014, a lot of our software tries to “cleverly” fix our text as we type it: swapping dumb quotes for smart quotes, turning runs of dots into ellipsis characters, converting two dashes into an em-dash, and so on. Swift should recognize these common conversions and transparently undo them, treating them as their ASCII equivalents.
Steps to Reproduce:
1. Open an Xcode window.
2. Paste in the following (note the character at the end of the signature is an ellipsis, not three periods):
func sum(xs: Int…) -> Int { return reduce(xs, 0) { sum, num in sum + num } }
Expected Results:
Swift compiles the code without trouble.
Actual Results:
Swift emits a compiler error, indicating a comma was expected before the ellipsis. (Curiously, it keeps emitting this error no matter how many commas you insert.)
Notes:
The quotation marks around “cleverly” in the first paragraph are smart quotes. Did you notice?
Ideally, this would not be a matter of defining aliases for operators; Swift would simply transparently replace these characters during lexing, unless they’re found in a string literal. A good starting point to come up with a list of characters to treat this way would be OS X’s own Text tab in the Keyboard preference pane.
You might be tempted to try to make string parsing require matching smart quotes—left quote at the beginning, right quote at the end—but I wouldn’t bother. Automatic smart quote algorithms are fairly mistake-prone, particularly when combined with the ungrammatical punctuation seen in code.
Comments
Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!
I must say I disagree with this one. I 100% agree that Xcode should strive to faithfully translate our keystrokes into our intended characters (rather than weird guesses at Unicode character substitutions).
But it seems like a mistake to me to clog up the language itself with guesswork that distorts predictable string parsing in order to try to reverse other string parsing guesswork.