[swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Xiaodi Wu]

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:
>
> <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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161022/3f3241a4/attachment.html>