How will we fix opEquals?

[Steven Schveighoffer]

On Thu, 10 Feb 2011 16:34:57 -0500, Don <nospam at nospam.com> wrote:

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

What I meant was, if the compiler complains that some specific function x  
has the wrong signature, you have assumptions the compiler is making that  
may not be correct.  To me, opEquals is special, but it's still a regular  
function, and putting extra limitations is sure to ferret out some use  
case where the limitation is invalid.

I consider

bool opEquals(int x) const

to be a perfectly valid signature in a class.

>
>> 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?

Not really, I don't think it's that big a problem to begin with.  If you  
try comparing two objects and you didn't define your signature right, then  
you get a hidden func error, since they all go through .opEquals(...)  
which casts everything to Object (should be const(Object) ).  So the only  
way this gets out is if you never test the code you wrote.

-Steve