On Tuesday, 23 April 2013 at 05:28:54 UTC, Mehrdad wrote:
If when you see a == b you think,
Hey, that's equivalent to (a.d is b.d)
I suppose that when you see (a is b) you think,
Hey, that's equivalent to a.d == b.d
?
Incorrect. When I see a == b, I don't think anything. Thanks to
encapsulation, typeof(a) and typeof(b) gets to decide what "=="
means. If they happen to be structs, then if the author defined
opEquals, then that's what it means. Otherwise, it's just a
simple bitwise comparison (or should be).
If it doesn't make sense, it's broken.
Implementing == as 'is' by default doesn't make sense when
there is already an 'is' operator that could do the same, hence
it's broken.
It doesn't make sense to _you_. It's a purely subjective matter.
And considering I've explained the way to think about it so it
should be cleared up now. It's a minor stumbling block at best.
Define opEquals and everything will work how you want. Very
simple solution to a problem you seem to be blowing out of
proportion. My very first post fixed your bug.
Is there something stopping you from defining opEquals for the
behavior you want?
