ProtoObject and comparison for equality and ordering

[Steven Schveighoffer]

On 5/16/19 5:24 PM, H. S. Teoh wrote:
> On Thu, May 16, 2019 at 09:11:48AM -0600, Jonathan M Davis via Digitalmars-d wrote:
>> On Thursday, May 16, 2019 8:41:09 AM MDT Steven Schveighoffer via
>> Digitalmars-d wrote:
> [...]
>>> For most intents and purposes, I think it should be fine to use
>>> non-const keys, as long as the keys are not modified while they are
>>> used as keys. You could, for instance, have a key that has some
>>> mutable data that doesn't affect the hash/equality. The language
>>> shouldn't impose restrictions that don't make sense for some cases,
>>> it just reduces the code you can write, even if that code would be
>>> perfectly valid.
> 
> That's a good point.  So really, what matters is that once a key is
> inserted into the AA, there must be no changes visible through .opEquals
> (and possibly .opCmp) and .toHash.

Since we went to non-tree-based buckets, we have not required opCmp 
anymore. That requirement is not going to come back.

> Although TBH, that smells like bending over backwards to do something
> that's ill-advised to begin with. If you're writing a custom type as an
> AA key, why would you deliberately write it so that it has external
> mutators and extra state?  If only part of the object is actually the
> effective key, then it should be factored out into an immutable object
> and *that* should be used as key instead of the entire object.

Sometimes the custom type isn't really meant ONLY to be a hash key. 
Sometimes you use an object as one thing somewhere, and a key somewhere 
else. Having to painstakingly separate the immutable and mutable parts 
makes things unpleasant. Especially if the immutable parts are 
semantically immutable, and not actually marked immutable (for obvious 
reasons). In other words, we live in the real world ;)

I'm pretty sure in the past I had a good use case for this, but it was 
way in the past (like over 10 years ago), and it was with Tango. And 
dcollections.

In any case, I agree requiring const does zero to guarantee anything. My 
solution just differs from yours in that I think you should not require 
any modifiers to make it work. Don't restrict the developer, you don't 
know what he is doing, or why he needs to do it that way. Sometimes the 
contract between the library and user code cannot be expressed in the 
type system.

-Steve