On Friday 11 February 2011 02:43:11 spir wrote:
> 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?
structs are a different beast. The issue under discussion here is classes where
polymorphism gets involved. There, the function signatures have to match.
Now, structs are still problematic, because the compiler currently insists that
their signature for opEquals look something like
bool opEquals(const ref S s) const;
Structs shouldn't be so picky. Pretty much anything named opEquals which takes
one argument and returns bool should work. But that hasn't been fixed yet.
Regardless, it's a separate issue from classes where polymorphism puts much
stricter requirements on opEquals' signature.
- Jonathan M Davis
