WAT: opCmp and opEquals woes

[Walter Bright via Digitalmars-d]

On 7/25/2014 1:47 PM, H. S. Teoh via Digitalmars-d wrote:
> On Fri, Jul 25, 2014 at 06:56:40PM +0000, Jonathan M Davis via Digitalmars-d wrote:
> [...]
>> So, if we remove the new check for a user-defined opEquals when opCmp
>> is defined, then you don't have to define opEquals.
>
> This is even worse, since it may silently introduce runtime breakage.
> The original type may have had opCmp defined just so it can be used with
> AA's, and now after the upgrade to 2.066, suddenly the custom opCmp code
> they wrote specifically to work with AA's doesn't get used anymore, yet
> the compiler silently accepts the code, and the problem won't be found
> until runtime.

Once again,

"The thing is, either this suffers from == behaving differently than AAs, or 
you've made opEquals superfluous by defining it to be opCmp==0. The latter is a 
mistake, as Andrei has pointed out, as opCmp may not have a concept of equality, 
and opEquals may not have a concept of ordering.
I.e. it's not just about AAs."

What you're defending is code of this sort running without error:

   S[T] aa;
   S s;
   aa[t] = s;
   assert(s != aa[t]);



> Which IMO fits the D motto of being correct first, and performant if you
> ask for it.

See the above snippet.