<div dir="ltr">On Mon, Oct 2, 2017 at 12:58 PM, David Sweeris <span dir="ltr">&lt;<a href="mailto:davesweeris@mac.com" target="_blank">davesweeris@mac.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><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 dir="auto"><span class=""><br><div>On Oct 2, 2017, at 09:14, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:<br><br></div><blockquote type="cite">What is your use case for this?<br><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 2, 2017 at 10:56 David Sweeris 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><br><div>On Oct 1, 2017, at 22:01, Chris Lattner 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"><br><div><blockquote type="cite"><div>On Oct 1, 2017, at 9:26 PM, Kenny Leung via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_5987115338413293819m_8138847825612054131Apple-interchange-newline"><div><div style="word-wrap:break-word"><div>Hi All.</div><div><br></div><div>I’d like to help as well. I have fun with operators.</div><div><br></div><div>There is also the issue of code security with invisible unicode characters and characters that look exactly alike.</div></div></div></blockquote><div><br></div><div>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></div><div dir="auto"><div>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><br></div></span><div>Off the top of my head...</div><div>In calculus, “𝖽” (MATHEMATICAL SANS-SERIF SMALL D) would be a fine substitute for &quot;d&quot; in “𝖽y/𝖽x” (&quot;the derivative of y(x) with respect to x&quot;).</div><div>In statistics, we could use &quot;𝖢&quot; (MATHEMATICAL SANS-SERIF CAPITAL C), as in &quot;5𝖢3&quot; to mimic the &quot;<span style="font-size:8px;vertical-align:-1px"><sub>5</sub></span><span style="line-height:normal">C</span><span style="font-size:8px;vertical-align:-1px"><sub>3</sub></span>&quot; notation (&quot;5 choose 3&quot;). 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 &quot;!&quot; in “4!” (&quot;4 factorial&quot;).</div><div><br></div><div>I&#39;m sure there are other examples from math/science/&lt;insert any &quot;symbology&quot;-heavy DSL here&gt;, but “d” in particular is one that I’ve wanted for a while since Swift classifies &quot;∂&quot; (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 &quot;d(y)/d(x)&quot;, whereas partial derivatives get to drop the parens &quot;∂y/∂x&quot;)</div></div></div></blockquote><div><br></div><div>Allowing a custom operator that looks like `!` to be anything other than the force-unwrap operator would be unwise, IMO, and not a desirable goal. Likewise characters that look like `d` not being the character `d`, etc. In the previous PR, the authors deliberately created a system where these will not be possible.</div><div><br></div><div>I think we should specify from the outset of re-examining this topic that supporting arbitrary math/science notation without demonstrable improvement in code clarity for actual, Swift code is a non-goal. Since manipulating matrices is a common programming task, and the current BLAS syntax is terribly cumbersome, being able to use operators for matrix multiplication, inversion, etc. is imminently reasonable. Having a way of writing `4.factorial()` that looks like an equation in a math textbook, however, wouldn&#39;t pass that bar.</div><div><br></div></div></div></div>