In a well-designed library, it does what it looks like - whatever "~" means in the language of that domain. In a badly-designed library it could do anything. Just like .add().
(It's normal for the same symbol to mean different things in different domains, even in Java. If a and b are BigIntegers, a.add(b) means one thing; if a and b are Wicket components, a.add(b) means something quite different. Wicket remains a respected, well-designed library even though it "overloads" the word "add" in this way)
(Another reply points out that it has the same meaning on numeric types - bitwise negation - as in Java, but I doubt that's what you're asking about)
When dealing with arithmetic equations the cognitive burden of add vs + can be quite high. Not allowing the overriding of arithmetic operators means that all new mathematical code you right will be second class vs primitives, encouraging people to not use special types in math operations. This leads to unit mismatches and other sorts of bugs.
The ~ operator in scala is the same as in java (if it isn't overloaded)
Comments
Humans read by the word, not by the individual letters. + vs add() is not a real cognitive burden.
Btw what does the operator ~ do in scala?
In a well-designed library, it does what it looks like - whatever "~" means in the language of that domain. In a badly-designed library it could do anything. Just like .add().
(It's normal for the same symbol to mean different things in different domains, even in Java. If a and b are BigIntegers, a.add(b) means one thing; if a and b are Wicket components, a.add(b) means something quite different. Wicket remains a respected, well-designed library even though it "overloads" the word "add" in this way)
(Another reply points out that it has the same meaning on numeric types - bitwise negation - as in Java, but I doubt that's what you're asking about)
I'm not sure what you mean by word, but + vs. add() definitely have different levels of cognitive burden:
Compare: (a + (b + c)) + d vs. add(add(a, add(b, c)), d)
One is arithmetic, the other is polish notation.
Even polish notation benefits from +, IMO.
+ + a + b c d
We can also (with mainstream OO syntax) make add infix and it's still ugly:
a.add(b.add(c)).add(d)
Yuck, really? I find that much less readable than "add(add(a, add(b, c)), d)"
shrug I've probably done more rpn. A huge component of "readable" is "how similar is it to stuff I am used to reading".
I do have to read it backward and build the stack, but that's basically intuitive at this point.
When dealing with arithmetic equations the cognitive burden of add vs + can be quite high. Not allowing the overriding of arithmetic operators means that all new mathematical code you right will be second class vs primitives, encouraging people to not use special types in math operations. This leads to unit mismatches and other sorts of bugs.
The ~ operator in scala is the same as in java (if it isn't overloaded)