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
