How will we fix opEquals?

[Don]

Steven Schveighoffer wrote:
> On Thu, 10 Feb 2011 15:22:48 -0500, Don <nospam at nospam.com> wrote:
> 
>> A tiny compromise which could be made, is to silently add 'const' to 
>> any class opEquals declaration, even if not present in the source. 
>> That way, simple use cases would still compile without complaint.
>> (As long as only a single, precisely defined opEquals signature is 
>> permitted, I think any other signature should be flagged as an error 
>> -- but it could be converted to the correct signature, instead).
>>
>> Dunno if this would be worth it, though.
> 
> I think then we get back to 
> http://d.puremagic.com/issues/show_bug.cgi?id=3659

No, we don't, because that issue applies to structs, not classes. For 
classes, it has to go in the vtable, so the precise signature must be known.

> Would it be possible to define a construct that says "you can override 
> this function, but you cannot add any new overloads"?  like a @precise 
> or something like that?  Then we can have a real feature to use for 
> things like this.  Sort of like final, but you're not cutting off the 
> virtual function path, just restricting the API to be exactly what you 
> specify.  That way someone cannot accidentally create a non-const 
> opEquals and generate a hidden function exception.  Although, anyone 
> worth his salt will test the opEquals, which dmd forces through 
> .opEquals(const(Object), const(Object)).

For sure that could be done. But again -- does it add much value?