<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><br><div>On Oct 2, 2017, at 5:45 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div><div><div class="gmail_quote"><div dir="auto">On Mon, Oct 2, 2017 at 19:28 Ethan Tira-Thompson via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div>I’m all for fixing pressing issues requested by Xiaodi, but beyond that I request we give a little more thought to the long term direction.</div><div><br></div>My 2¢ is I’ve been convinced that very few characters are “obviously” either a operator or identifier across all contexts where they might be used. Thus relegating the vast majority of thousands of ambiguous characters to committee to decide a single global usage. But that is both a huge time sink and fundamentally flawed in approach due to the contextual dependency of who is using them.<div><br></div><div>For example, if a developer finds a set of symbols which perfectly denote some niche concept, do you really expect the developer to submit a proposal and wait months/years to get the characters classified and then a new compiler version to be distributed, all so that developer can adopt his/her own notation?</div></div></blockquote><div dir="auto"><br></div></div></div></div><div><div><div class="gmail_quote"><div dir="auto">The Unicode Consortium already has a document describing which Unicode characters are suitable identifiers in programming languages, with guidance as to how to customize that list around the edges. This is already adopted by other programming languages. So, with little design effort, that task is not only doable but largely done.</div><div dir="auto"><br></div><div dir="auto">As to operators, again, I am of the strong opinion that making it possible for developers to adopt any preferred notation for any purpose (a) is fundamentally incompatible with the division between operators and identifiers, as I believe you’re saying here; and (b) should be a non-goal from the outset. The only task, so far as I can tell, left to do is to identify what pragmatic set of (mostly mathematical) symbols are used as operators in the wider world and are likely to be already used in Swift code or part of common use cases where an operator is clearly superior to alternative spellings. In my view, the set of valid operator characters not only shouldn’t require parsing or import directives, but should be small enough to be knowable by memory.</div></div></div></div></div></blockquote><br><div>The set notation operators should be identifiers, then? Because the impression I got from the Set Algebra proposal a few months ago is that there are a lot of people who’ve never even seen those operators, let alone memorized them.</div></div><div><br></div><div>- Dave Sweeris</div></body></html>