WAT: opCmp and opEquals woes

[Ali Çehreli via Digitalmars-d]

On 07/23/2014 11:26 AM, David Gileadi wrote:
> On 7/23/14, 11:09 AM, Dicebot wrote:
>> On Wednesday, 23 July 2014 at 17:15:12 UTC, Ary Borenszweig wrote:
>>> Imagine you have a list of integers and strings denoting integers: [1,
>>> "2", 100, "38"]. Now you want to sort them according to their numeric
>>> value. Of course, 1 and "1" would have the same order. However, 1 and
>>> "1" are different, so "==" would give false, while 1.opCmp("1") would
>>> give 0.
>>>
>>> Equality and comparison are different. opCmp is used for sorting
>>> objects, which has nothing to do with equality. Inferring equality
>>> from opCmp is wrong in my opinion.
>>
>> Well this is why you can actually override those :) I think automatic
>> opCmd -> opEqual generation covers vast majority of use cases and as
>> such will have a vary good effort / decreased annoyance ratio.
>
> I agree. In fact I think if you've implemented opCmp to sort 1 and "1"
> as equal that in most cases you'd expect "1" and 1 to compare as
> logically equal. Automatic opCmp -> opEquals seems like a very sane
> default to me.

To add, C++ is getting "= default" versions:

   http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3950.html

Ali