[swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Benjamin Spratling]

Howdy,
Some good points about standardizing identifiers.
Some extremely short-sighted points about deleting my formal operators that are widely recognized as operators, and that I’ve spent months adding into my code.  Frankly, I just couldn’t upgrade until you put them back in.
> Operators
> 
> Swift operator characters will be limited to only the following ASCII characters:
> 
> ! % & * + - . / < = > ? ^ | ~
> 

For a mathematician / scientist / engineer, they have an easier time catching errors when the code on their screen look more like what they write on paper.  Hence the only good reasons to leave sin() as a global function instead of a computed property.  Obviously, we don’t have 2D layout in Swift, but finally using the right operator characters instead of the ridiculous ascii hacks was a breath of fresh air Swift breathed into my code.  The state of operators in C languages was abysmal, and its legacy is still here.  Take the blinders off for a moment and realize that “repetition” isn’t a great semantic: “&&” and “===“.  They're a side effect of the hardware & character encoding sets available to developers in past decades, not a goal for the future.  Sure, we don’t have screens on every key so I can set up my own domain specific operator character sets without having to scroll through a giant list of unused characters, but finally the second barrier had fallen.  And at least there are prototypes and rumors of those keyboards out in the wild.

There’s just no good reason to make
≤ ≥ ≠ ± 
not valid operators.

“in homage to Swift's origins, we permit 🐶 and 🐮 in identifiers."

That’s a blatant attempt at a cheat.  Wrong answer.

It’s true there are inconsistencies of the choice of whether a particular symbol is an operator or identifier, but I’d rather resolve that instead of blow everything away.

- - From me

-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161019/8929b7b3/attachment.html>