WAT: opCmp and opEquals woes

[Andrei Alexandrescu via Digitalmars-d]

On 7/24/14, 11:30 AM, Jonathan M Davis wrote:
> On Thursday, 24 July 2014 at 01:39:01 UTC, H. S. Teoh via Digitalmars-d
> wrote:
>
>> Keep in mind, though, that due to current AA changes in 2.066 beta,
>> existing code WILL break unless we autogenerate opEquals to be
>> opCmp()=0. In fact, issue 13179 was originally filed because 2.066 beta
>> broke Tango. My current stance is that these AA changes are an
>> improvement that we should keep, so then the question becomes, should we
>> break code over it, or should we introduce opEquals = (opCmp()==0),
>> which would allow existing code *not* to break?
>
> Can we just adjust the AA implementation so that it uses lhs.opCmp(rhs)
> == 0 if opEquals isn't defined and produces a deprecation warning about
> that? That way, we avoid immediately breaking folks, but we still move
> towards requiring that they define opEquals.

I like Daniel's idea to auto-define opEquals as a field-for-field 
comparison. -- Andrei