Overloading relational operators separately; thoughts?

[Chris Wright via Digitalmars-d]

On Fri, 30 Sep 2016 19:33:33 +0000, pineapple wrote:
> How many people have to state it how many times in how many different
> ways before it gets through? These are stupid goals. They reflect
> intention that has no basis in reason, that has no basis in reality,
> that is a blindly-enforced dogma.

More like: this is the common use case, so let's try to make that as 
smooth as possible, both for implementors and readers. And mucking about 
in the same area can add wrinkles that confuse people.

The takeaway should be that we should exercise caution, not that we 
should refuse to change the language. But the basic idea does make sense.

I'm not sure it's straightforward to make other operators consistent in 
the same way. You could try to enforce things like: typeof(a OP b) should 
be co/contravariant with typeof(a) or typeof(b) for math operators; 
opApply and opIndex should deal with the same types (though it's valid to 
add extras); that kind of thing. It does seem inconsistent that no 
attempt was made, but the language was only Walter Bright for nearly a 
decade, and one person doesn't have that much time.

With most of the language and compiler work still being Walter Bright, he 
has much more say in the direction of the language than anyone else.

> It always would have been simpler if, in the first place, opBinary had
> caught comparison operators and opCmp and opEquals were omitted.
> Instead, those making the decisions went out of their way to impose
> these arbitrary limitations. If we can start now to untangle that
> mistake, it will make D more tenable for real-world code.

That would have been tricky, or at least unpleasant, before auto return 
types. Auto return types were introduced after 2010, and opCmp was 
introduced before 2006.