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 < [email protected]> wrote:
> > On Oct 19, 2016, at 19:07, Jonathan Hull via swift-evolution < > [email protected]> wrote: > > <snip> > > 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. > > > > Agreed. > > 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. > > -Matt > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
