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