Overloading relational operators separately; thoughts?

Minty Fresh via Digitalmars-d digitalmars-d at puremagic.com
Wed Sep 28 21:39:37 PDT 2016


On Thursday, 29 September 2016 at 04:15:32 UTC, Walter Bright 
wrote:
> On 9/28/2016 1:40 PM, Timon Gehr wrote:
>> What's wrong with that usage?
>
> Because then something other than comparison is happening with 
> <=, <, >, >= and there'll be nothing in the code to give the 
> user a hint.

There's also nothing to give the user a hint that binary 
arithmetic operators may also not do what they expect them to do.
Going further, there may be nothing to give the user a hint that 
a named function doesn't to what its name suggests.

All of the above are shortcomings in documentation, or short 
comings in implementation.

Even with the current system of using `opCmp`, it's still 
possible to implement these operators such that they behave in a 
way that would confound the user (ie. have their results be 
nondeterministic, external side effects, etc.)

> 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.

No, you're right. It's not the responsibility of the IDE to 
perform such tasks. It's the responsibility of the documentation. 
D is already is such a state the language is difficult for a 
context-free user without access to documentation.

Even the standard library. Especially the standard library.
Things like `.each` in std.algorithm returning void, whereas the 
bizarrely named `.tee` in std.range actually retuning the input 
range. Things like the `SList` and `DList` types defined in 
std.container requiring explicit initialization to work. Things 
like the behavior and semantics of type tuples (or alias lists). 
Things like the differences between `.byLine` vs `.byLineCopy` in 
std.stdio.
All of these rely on the developer having documentation. There's 
no way around it. D as a language is already way too complex to 
do anything without it.

This applies to operator overloads just like everything else. 
They're just syntactic sugar for functions. Documenting their 
behavior is just as necessary.


More information about the Digitalmars-d mailing list