On Wednesday, September 28, 2016 21:15:32 Walter Bright via Digitalmars-d wrote: > Because then something other than comparison is happening with <=, <, >, >= > and there'll be nothing in the code to give the user a hint. [snip] > D has many very powerful modeling abilities, but so far we've tried to stay > away from things that make context-free user understanding of code unduly > difficult. It should not be necessary to use an IDE to understand code.
A related issue is generic code. Having the same operator or function name mean essentially the same thing for every type that has it is required for generic code to work. To some extent, that's also checked by having the semantics of the code checked (e.g. that front returns something as opposed to being void or that popFront takes no arguments), but there's only so much that can be done there. And no, even then, you can't guarantee that the function in question operates the way that the generic code expects. But if common function names mean the same thing and act the same way for types in general, then they play well with generic code, whereas as soon as someone takes a common function and makes it do something different from what's normal, it does not play well with generic code at all. Overloaded operators are the prime example of this, because there is a clear expectation for what their basic behaviors are, and they're functions that are built into the language. Next in line would be extremely common idioms such as the range-based functions. Once you start getting to less common stuff, then the issue of whether a function with a particular name acts the same way in one library as another is significantly diminished, but for the common stuff, it's critical for generic code that folks don't go and make common functions operate in a way that is inconsistent with how they would function on most every other type out there and how everyone is going to expect them to behave when they see them. Having a type implement something like expression templates is an utter disaster for generic code, just like it's a disaster if front does something like call popFront every time that it's called. Consistent semantics for common functions is very important for generic code as well as for code legibility and maintainability. - Jonathan M Davis