<div dir="ltr">On Mon, Oct 2, 2017 at 12:58 PM, David Sweeris <span dir="ltr"><<a href="mailto:davesweeris@mac.com" target="_blank">davesweeris@mac.com</a>></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 <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> 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 <<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 dir="auto"><br><div>On Oct 1, 2017, at 22:01, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> 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 <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> 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 "d" in “𝖽y/𝖽x” ("the derivative of y(x) with respect to x").</div><div>In statistics, we could use "𝖢" (MATHEMATICAL SANS-SERIF CAPITAL C), as in "5𝖢3" to mimic the "<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>" 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><br></div><div>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></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't pass that bar.</div><div><br></div></div></div></div>