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

[Chris Lattner]

On Oct 2, 2017, at 3:24 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>> 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")
> 
> 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.

I completely agree with Xiaodi here.  Even if this were technically possible by the rules that are defined, it would still be very poor form to do this.  It would violate the swift goal of clarity of code.  If these operations need to be an operator, it would be better to define a *new* operator for these operations, so that a human at least knows that they don’t know what the operation does - rather than being misled into thinking they are a familiar construct.

> 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.

+100.  Clarity is the important thing, and sometimes operators are the right way to get that.  Emulating math syntax exactly is a non-goal.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171002/055a6840/attachment.html>