[swift-evolution] [Proposal] Refining Identifier and Operator Symbology
mwhiteside.dev at gmail.com
Sat Oct 22 17:45:44 CDT 2016
> On Oct 19, 2016, at 19:07, Jonathan Hull via swift-evolution <swift-evolution at swift.org> wrote:
> There are a bunch of symbols in unicode which are hard to tell apart, and those are bad for recognition, and we should deal with that, but this proposal is throwing the baby out with the bathwater, then lighting the baby on fire. Honestly, I would propose we find a way to have Swift see certain classes of characters as identical. Can’t decide which of the thousand + symbols should be the one true + symbol? Have them all map to one of them. That emoji X symbol looks like X, so map it to X.
I really like the option of using unicode operators in swift. Removing them would be disappointing. But I do see the problem that there are a lot of redundancies and sources of confusion if there are no restrictions. Aside from the redundancies, some other cases that I find sub-optimal are: 'top-half of integral' ⌠, and 'left parenthesis upper hook’ ⎛ ; these don’t really seem like symbols we want to allow as operators. Perhaps *one* general rule here, is that symbols specifically meant for 2d math expressions aren't good candidates for inclusion, at least at the present. Another difficult one, I think, are the bracket-like glyphs. While these would be useful in certain math and physics related code, it’s not clear at the moment how these could be used in swift, until and unless some kind of ‘bracket overloading’ is made possible.
I’m in favor of what Johnathan Hull has suggested above. I’m also in favor of what some others have suggested, i.e., restricting the allowed operator symbols to some uncontroversial subset, mainly from the unicode ‘math’ category of symbols, and then possibly adding more as needed.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution