<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">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 class=""><br class=""></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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">And then after that is done, now say a member of some distant tribe complains they wanted to use one of those characters to write identifiers using their native language. Even though there may be zero intersection between these two user groups, this path forces Swift itself to pick a side of one vs. the other.</div><div class=""><br class=""></div><div class=""><div class="">Surely there is some way to enable the local developer to resolve these choices rather than putting the swift language definition on the critical path?</div><div class=""><br class=""></div><div class="">The goals I know of:</div><div class="">1. Performance: don’t require parsing all imports to get the operator set</div><div class="">2. Security: don’t let imports do surprising/obfuscated stuff</div><div class="">3. Functionality: do let users write what they want, or import/share libraries for niche domains</div><div class="">4. Well defined: resolve conflicts, e.g. between libraries</div><div class=""><div class=""><div class=""><br class=""></div><div class=""></div></div><div class=""></div></div><div class="">I’m a little out of my league, but let’s say we want to use operator ᵀ from some matrixlib, how about:</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>import matrixlib (operator: ᵀ)</div><div class=""><br class=""></div><div class="">Or if you want several operators:</div><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>import matrixlib (operators: [ᵀ,·,⊗])</div><div class=""><br class=""></div><div class="">Ideally, any local operator definitions “just work” across their own module, but if it requires a “import (operator: ×)” in each file for performance, so be it.</div><div><br class=""></div><div><div>A whitelist of “standard” operators would automatically import (i.e. initialize the operator character list) to maintain compatibility with current usage. But you can imagine additional arguments to the import call, such as “standardOperators: false” to import only the explicitly listed operators and reduce potential surprises.</div><div><br class=""></div><div>My rationale vs. the goals:</div></div><div>1. Performance: the operator character set vs. identifiers (everything else) can be determined within the file itself</div><div>2. Security: developer explicitly opts-in to the special operators they want to use, and readers can see where an operator comes from</div><div>3. Functionality: user is able to define their operators without getting committee involved</div><div>4. Well defined: potential conflict between libraries resolved by client’s choice to import or exclude the operator</div><div><br class=""></div><div>Does this have potential?</div><div><br class=""></div><div>-Ethan</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 2, 2017, at 10:59 AM, David Sweeris via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class="" 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; -webkit-text-stroke-width: 0px;"><div class=""><br class="Apple-interchange-newline">On Oct 2, 2017, at 09:14, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class="">What is your use case for this?<br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Oct 2, 2017 at 10:56 David Sweeris via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></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" class=""><br class=""><div class="">On Oct 1, 2017, at 22:01, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Oct 1, 2017, at 9:26 PM, Kenny Leung via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_8138847825612054131Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word;"><div class="">Hi All.</div><div class=""><br class=""></div><div class="">I’d like to help as well. I have fun with operators.</div><div class=""><br class=""></div><div class="">There is also the issue of code security with invisible unicode characters and characters that look exactly alike.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Unless there is a compelling reason to add them, I think we should ban invisible characters. What is the harm of characters that look alike?</div></div></blockquote><br class=""></div><div dir="auto" class=""><div class="">Especially if people want to use the character in question as both an identifier and an operator: We can make the character an identifier and its lookalike an operator (or the other way around).</div></div></blockquote></div></blockquote><div class=""><br class=""></div><div class="">Off the top of my head...</div><div class="">In calculus, “𝖽” (MATHEMATICAL SANS-SERIF SMALL D) would be a fine substitute for "d" in “𝖽y/𝖽x” ("the derivative of y(x) with respect to x").</div><div class="">In statistics, we could use "𝖢" (MATHEMATICAL SANS-SERIF CAPITAL C), as in "5𝖢3" to mimic the "<span class="" style="font-size: 8px; -webkit-text-stroke-color: rgb(0, 0, 0); -webkit-text-stroke-width: initial; vertical-align: -1px; -webkit-font-kerning: none;"><sub class="">5</sub></span><span class="" style="-webkit-text-stroke-color: rgb(0, 0, 0); -webkit-text-stroke-width: initial; line-height: normal; -webkit-font-kerning: none;">C</span><span class="" style="font-size: 8px; -webkit-text-stroke-color: rgb(0, 0, 0); -webkit-text-stroke-width: initial; vertical-align: -1px; -webkit-font-kerning: none;"><sub class="">3</sub></span>" notation ("5 choose 3"). And although not strictly an issue of identifiers vs operators, “！” (FULLWIDTH EXCLAMATION MARK) would be an ok substitution (that extra space on the right looks funny) for "!" in “4！” ("4 factorial").</div><div class=""><br class=""></div><div class="">I'm sure there are other examples from math/science/<insert any "symbology"-heavy DSL here>, but “d” in particular is one that I’ve wanted for a while since Swift classifies "∂" (the partial derivative operator) as an operator rather than an identifier, making it impossible to use a consistent syntax between normal derivatives and partial derivatives (normal derivatives are "d(y)/d(x)", whereas partial derivatives get to drop the parens "∂y/∂x")</div><div class=""><br class=""></div><div class="">- Dave Sweeris</div></div><span 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; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br 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; -webkit-text-stroke-width: 0px;" class=""><span 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; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">swift-evolution mailing list</span><br 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; -webkit-text-stroke-width: 0px;" class=""><a href="mailto:swift-evolution@swift.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">swift-evolution@swift.org</a><br 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; -webkit-text-stroke-width: 0px;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></div></div></div></body></html>