How will we fix opEquals?

[Steven Schveighoffer]

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

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)).

-Steve