It’s not really about scary so much as readable.
I would not tend to agree with that beyond the trivial idea that you can just use meaningless method names like “dog” to mean “cross product”. I would tend to always find the following:
let a = b.cross( c )
more readable and more easily recognized than some combination of punctuation characters as an operator:
let a = b ~*~ c
for example.
That is why, rather than focusing on introducing more punctuation-style operators into the language I would prefer that we introduce an in-fix function calling convention. For example, if you have a method “foo” that takes two arguments, you can call it like this:
let a = BType::foo( b, c );
or you can also currently call it like this:
let a = b.foo(c);
I would like to also allow (something like):
let a = b ~foo~ c
or possibly
let a = b :foo: c
So instead of having the methods of special Operator Traits map to punctuation (aka operators), just be able to call the method in an in-fix style. Then if you had, for example, cadd (checked_add), csub (checked subtract), cmul (checked multiply), and cdiv (checked divide) methods on a type that did add/sub/mul/divide with checks for overflow on a type, you could write expressions like:
let a = d ~cmul~ ( b ~cadd~ c ) ~cdiv~ e
Instead of:
let a = d.cmul( b.cadd( c ) ).cdiv( e )
Now, for this example, because it is add, subtract, multiply, and divide, you could make the argument that some punctuation would be more appropriate, but, once you get away from basic operations like this, unless you are going to allow unicode characters as operators in the source, the random streaming together of the few available punctuation characters to try to create “operators” seems counter-productive (to me) when you could just allow an in-fix style method call syntax and then you can create meaningful and clear names for all your interesting operations. Really, at the end of the day, that is all operators are - alternative names for an arity-2 method called using in-fix syntax. Why not just allow the method name instead? Why have garbled punctuation trying to map to a bunch of different concepts?
Maybe (and here I think is a BIG MAYBE) if you allowed operators to be defined using Unicode operator characters it might actually be worth it, but, that presents a whole bag of problems with editors, IDE’s, etc. that makes it feel like the juice isn’t worth the squeeze.
If Rust did decide to allow for definition of lots of different operators, I would think the approach should be:
- figure out how to allow unicode characters as operators and understand how that will be supported by the editor/ide ecosystem
- create Traits for all the Mathematical or Operator-Like characters in Unicode (NOT things like Emojis, Wing-Nuts, Bat-Shits, or random Klingon characters) with clear explanation and documentation on the trait as to the expected behavior of trait implementations (for example, if you had a trait for the square-root character, the trait would require that implementations must also implement the trait for multiply and the implementation constraint would be that whatever the result of square root on t:T is, then that result r multiplied by itself (using the implementation of the multiply operator for that type) must be equal to t:T (so, square-root( t:T ) * square-root( t:T ) = t ) where “square-root” is a stand-in for the unicode square root character in this explanation.
Anything short of this involving using various combinations of ascii punctuation characters to create complex operators seems like a fools errand to create unreadable code.
