[swift-evolution] A path forward on rationalizing unicode identifiers and operators

[David Sweeris]

> On Oct 2, 2017, at 3:24 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
>> On Mon, Oct 2, 2017 at 12:58 PM, David Sweeris <davesweeris at mac.com> wrote:
>> 
>>> On Oct 2, 2017, at 09:14, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>> 
>>> What is your use case for this?
>>> 
>>>> On Mon, Oct 2, 2017 at 10:56 David Sweeris via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>>> On Oct 1, 2017, at 22:01, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>>>>> 
>>>>> 
>>>>>> On Oct 1, 2017, at 9:26 PM, Kenny Leung via swift-evolution <swift-evolution at swift.org> wrote:
>>>>>> 
>>>>>> Hi All.
>>>>>> 
>>>>>> I’d like to help as well. I have fun with operators.
>>>>>> 
>>>>>> There is also the issue of code security with invisible unicode characters and characters that look exactly alike.
>>>>> 
>>>>> 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?
>>>> 
>>>> 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).
>> 
>> Off the top of my head...
>> 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").
>> In statistics, we could use "𝖢" (MATHEMATICAL SANS-SERIF CAPITAL C), as in "5𝖢3" to mimic the "5C3" 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").
>> 
>> 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")
> 
> 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.

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.

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.

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. If Swift’s long-term goal is to take over the world, that means the language needs to “work” for very diverse groups of people... We probably shouldn’t be restricting syntax at the language level unless we actually have to.

- Dave Sweeris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171002/07c897a9/attachment.html>