[swift-evolution] [Proposal] Refining Identifier and Operator Symbology
xiaodi.wu at gmail.com
Sat Oct 22 17:59:42 CDT 2016
That, I think, is where we're headed. Take a look at Jonathan Shapiro's
latest draft and see what you think :)
On Sat, Oct 22, 2016 at 17:46 Matt Whiteside via swift-evolution <
swift-evolution at swift.org> wrote:
> 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.
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution