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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
