[Issue 323] New: Error: need opCmp for class Bar

[Sean Kelly]

xs0 wrote:
> Sean Kelly wrote:
>> Since D's associative arrays use opCmp to resolve collisions, any 
>> class that has opEquals defined should probably have opCmp defined 
>> also.  The old default implementation of Object.opCmp in Phobos was 
>> not compatible with compacting GCs so it was replaced with a version 
>> that throws an exception on use.  However, there is a default 
>> implementation that actually works and is compatible with compacting GCs:
>>
>>     int opCmp(Object o)
>>     {
>>     return this !is o;
>>     }
> 
> That's not a really good solution, as no usable ordering is defined (a>b 
> and b>a will always be true whenever a !is b). While it may work for 
> (degenerate) insertion into a binary tree, it's (imho) worse than 
> throwing an exception in practically all other cases. For example, a 
> quick sort will not only run really slow in O(n^2) time but also produce 
> an unsorted result without any indication of error.

Ah good point.  So any ideas?  Personally, I'd be happy if the default 
AA used a linked-list for chaining and opEquals for comparison so this 
wasn't an issue, but that seems a foregone conclusion.  I'm mostly 
concerned about providing default behavior that makes sense for the 
common case.  The problem I've run into is that I have objects which 
need to be used as keys in an AA but are not inherently sortable.