<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><br><div class="AppleOriginalContents" style="direction: ltr;"><blockquote type="cite"><div>On Oct 2, 2017, at 3:24 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div><div dir="ltr" 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="">On Mon, Oct 2, 2017 at 12:58 PM, David Sweeris<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:davesweeris@mac.com" target="_blank" class="">davesweeris@mac.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><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 style="word-wrap: break-word;" class=""><div dir="auto" class=""><span class=""><br class=""><div class="">On Oct 2, 2017, at 09:14, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" 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" target="_blank" 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_5987115338413293819m_8138847825612054131Apple-interchange-newline"><div class=""><div style="word-wrap: break-word;" class=""><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></span><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 style="font-size: 8px; vertical-align: -1px;" class=""><sub class="">5</sub></span><span style="line-height: normal;" class="">C</span><span style="font-size: 8px; vertical-align: -1px;" class=""><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></div></blockquote><div class=""><br class=""></div><div class="">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.</div></div></div></div></div></blockquote><br></div><div class="AppleOriginalContents" style="direction: ltr;">I gave up on trying to get the restrictions on the normal "!" removed a while ago... I guess we'll just have to agree to disagree on !-lookalikes.</div><div class="AppleOriginalContents" style="direction: ltr;"><br></div><div class="AppleOriginalContents" style="direction: ltr;">Supporting arbitrary math/science notation, though, is almost by definition an increase in code clarity for the people who are used to it. Is that everyone? Of course not. Is it the majority? I doubt it; the days when Computer Science was part of the Math department are long gone, and it's common for people to become developers without getting any formal education in the field at all (which is great, IMHO... that means we're successfully making computing more accessible). That doesn't seem to me like a good reason not to support such symbolic notations, though. I'm not suggesting a change to the standard library here, to be forced on everyone -- I'm merely suggesting a way to help people who prefer the more symbol-heavy notations to use them if they and their teams (and their clients, if they're a library vendor) want to.</div><div class="AppleOriginalContents" style="direction: ltr;"><br></div><div class="AppleOriginalContents" style="direction: ltr;">I would never claim that the particular cases I raised are “critical to Swift's long-term success” or anything (I think the # of people who care about "𝖽y" vs "d(y)" enough to let it dictate their language choice is probably zero), but I would like to point out that a few of the threads here have demonstrated just how differing the opinions are on this matter even within the relatively small group of people who participate on this list. I<span style="background-color: rgba(255, 255, 255, 0);">f Swift’s long-term goal is to take over the world, that means the language needs to “work” for <i>very</i> diverse groups of people... We probably shouldn’t be restricting syntax at the <i>language</i> level unless we actually have to.</span></div></div><div class="AppleOriginalContents" style="direction: ltr;"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div class="AppleOriginalContents" style="direction: ltr;"><span style="background-color: rgba(255, 255, 255, 0);">- Dave Sweeris</span></div></body></html>