How will we fix opEquals?

[spir]

On 02/11/2011 07:13 AM, Jonathan M Davis wrote:
>>> We _must_ have it there, so anyone overriding those functions _must_
>>> >  >  use it for those functions. They could create non-const versions in
>>> >  >  addition to
>>> >  >  the const ones,
>> >
>> >  It is the whole point, they can't.
> Hmm. You're right (I just tried it).

In the worst case, people who really, really, want it it non-const are left with:

     struct S {
         ...
         bool equals (ref S s) {...}
     }
     ...
     if (s1.equals(s2)) {...}

I do not find it /that/ terrible (esp.compared to many other wrokarounds we 
commonly are forced to use for various reasons). The one bad case is if S 
belongs to the interface to client code. In other words, this is not an 
acceptable solution for library public types. But since const opEquals (and 
same reasoning for other methods) is only annoying for structs that (1) need 
custom equality predicate (2) call other funcs, else as member opEquals, (3) 
which themselves may be called by yet other funcs (else virality does not 
spread), then I guess very few cases remain.
What do you think?

Denis
-- 
_________________
vita es estrany
spir.wikidot.com