<div><br><div class="gmail_quote"><div dir="auto">On Mon, Oct 2, 2017 at 23:11 David Sweeris &lt;<a href="mailto:davesweeris@mac.com">davesweeris@mac.com</a>&gt; 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"><div><blockquote type="cite"><div>On Oct 2, 2017, at 7:57 PM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:</div><br class="m_1718387483571887071Apple-interchange-newline"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Mon, Oct 2, 2017 at 9:04 PM, David Sweeris<span class="m_1718387483571887071Apple-converted-space"> </span><span>&lt;<a href="mailto:davesweeris@mac.com" target="_blank">davesweeris@mac.com</a>&gt;</span><span class="m_1718387483571887071Apple-converted-space"> </span>wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><span></span></div><div><span class="m_1718387483571887071gmail-"><br><div>On Oct 2, 2017, at 5:45 PM, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; 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 &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><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></span><div>The set notation operators should be identifiers, then?</div></div></div></blockquote><div><br></div><div>Set notation operators aren&#39;t valid identifier characters; to be clear, the alternative to being a valid operator character would be simply not listing that character among valid operator or identifier characters.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div>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></blockquote><div><br></div><div>That&#39;s not the impression I got; the argument was that these symbols are hard to type and _not more recognizable that the English text_, which is certainly a plausible argument and the appropriate bar for deciding on a standard library API name.</div><div><br></div><div>MHO is that the bar for a potentially valid operator character _for potential use in third-party APIs_ needn&#39;t be so high that we demand the character to be more recognizable to most people than alternative notations. Instead, we can probably justify including a character if it is (a) plausibly useful for some relatively common Swift use case and (b) at least somewhat recognizable for many people. Since set algebra has a well-accepted mathematical notation that&#39;s taught (afaict) at the _high school_ level if not earlier, and since set algebra functions are a part of the standard library, that surely meets those bars of usefulness and recognizability.</div></div></div></div></div></blockquote></div></div><div style="word-wrap:break-word"><div><div>Maybe they&#39;ve started teaching it earlier than when I went through school... I don&#39;t think I learned it until Discrete Math, which IIRC was a 2nd or 3rd year course at my college and only required for Math, CS, and maybe EE majors. Anyway, WRT a), if Swift achieves its &quot;take over the world&quot; goal, <i>all</i> use cases will be Swift use cases. WRT b), &quot;many&quot; as in the numerical quantity or &quot;many&quot; as in the percentage? There are probably millions of people who recognize calculus&#39;s operators, but there are 7.5 <i>billion</i> people in the world.</div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div>Keep in mind that Swift already goes far above and beyond in terms of operators</div></div></div></div></div></blockquote></div></div><div style="word-wrap:break-word"><div>Yep, that&#39;s is a large part of why I&#39;m such a Swift fan :-D</div><div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div>in that: (a) it allows overloading of almost all standard operators; (b) it permits the definition of effectively an infinite number of custom operators using characters found in standard operators; (c) it permits the definition of custom precedences for custom operators; and (d) it additionally permits the use of a wide number of Unicode characters for custom operators. Most systems programming languages don&#39;t even allow (a), let alone (b) or (c). Even dramatically curtailing (d) leaves Swift with an unusually expansive support for custom operators.</div></div></div></div></div></blockquote></div></div><div style="word-wrap:break-word"><div><div>Yes, but many of those custom operators won&#39;t have a clear meaning because operators are rarely limited to pre-existing symbols like &quot;++++++++&quot; (which doesn&#39;t mean anything at all AFAIK), so operators that are widely known <i>within some field</i> probably won&#39;t be widely known to the general public, which, IIUC, seems to be your standard for inclusion(?). Please let me know if that&#39;s not your position... I hate being misunderstood probably more than the next person, and I wouldn&#39;t want to be guilty of that myself.</div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div>What it does conclusively foreclose is something which ought to be stated firmly as a non-goal, which is the typesetting of arbitrary mathematical equations as valid Swift code.</div></div></div></div></div></blockquote></div></div><div style="word-wrap:break-word"><div><div>I&#39;m not arguing for adding arbitrary <i>typesetting</i> (not now anyway... maybe in a decade or so when more important things have been dealt with). What I <i>am</i> arguing for is the ability to treat operators from &lt;pick your field&gt; as operators within Swift. As much as possible, anyway.</div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">Yes, and to be clear, I am arguing that this should be an explicit non-goal at the moment for arbitrary &quot;pick your fields&quot;; instead, work for Swift 5 should address some pragmatic, fixed, and limited set of plausible use cases for Swift.</div><div dir="auto"><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"><div><div></div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div>Quite simply, Swift is not math; simple addition doesn&#39;t even behave as it does in grade-school arithmetic,</div></div></div></div></div></blockquote></div></div><div style="word-wrap:break-word"><div>Perhaps not for the built-in numeric types, but how do you know somebody won&#39;t create a type which does behave that way?</div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div> so there is no sense in attempting to shoehorn calculus into the language.</div></div></div></div></div></blockquote></div></div><div style="word-wrap:break-word">(I&#39;m assuming you mean calculus&#39;s syntax, not calculus itself, right?)<i> </i>What&#39;s the point of having unicode support if half the symbols will get rejected because they aren&#39;t well-known enough? Sometimes only having token support for something can be worse than no support at all from the PoV of someone trying to do something that relies on it.<div><br></div><div><br></div><div><br></div><div>In any case, I only meant to point out a use-case for lookalikes, not spark a debate about whether we should support more than a handful of operators... shall we consider the idea withdrawn?<br><div><br></div><div>- Dave Sweeris</div></div></div></blockquote></div></div>