On 07/14/2014 05:29 PM, Dicebot wrote:
On Monday, 14 July 2014 at 15:13:21 UTC, Timon Gehr wrote:
On 07/14/2014 11:55 AM, Dicebot wrote:
I must admit D is far from perfect in that regard because operator
overloading is still not limited enough
There is no real point in limiting it at all. It is just a matter of
naming your functions properly.
auto subtract(int a, int b){ return a+b; }
Same principle of surprise minimization. Reader expects arbitrary
actions done by function call.
No way.
Reader expects arithmetical semantics
Right, arithmetical semantics, which for built-in '+' can reach from
wrap-around behaviour to saturated behaviour which is not even
associative. Knowing what '+' does without being very aware what types
its operands are is a pipe dream.
from arithmetical operations.
'+' is opBinary!"+" and it is just another function name. There don't
need to be 'anti-abuse' mechanics in place for this name and not for others.
I don't see "you can change anything"
D does not allow you to e.g. redefine what the built-in operators do on
built-in types, so where is this complaint coming from?
language working for any large team production.
Languages that do not make built-in operators syntactically special are
way better off regarding this issue because this way the question of
automatically limiting implementations to match naming is even more
obviously pointless. In any case, what are you arguing against here?
Lexical scoping? Named definitions? Module systems? :o)
