|Posted by Ali Çehreli|
in reply to frame
On 9/17/22 10:14, frame wrote:
> On Saturday, 17 September 2022 at 15:04:48 UTC, solidstate1991 wrote:
>> And then instead just decides that the `localName` and `namespaceURI` pairs are not equal, and in those cases the Visual Studio debugger doesn't detect any entering into any of the `DOMString.equals` overrides, all while the debugger shows those strings are equal.
> `opEquals` probably was not called if an operand was null. It seems that `Attr.localName` can return null.
Indeed. Copying from my /usr/include/dlang/dmd/object.d:
Implementation for class opEquals override. Calls the class-defined methods after a null check.
Please note this is not nogc right now, even if your implementation is, because of
the typeinfo name string compare. This is because of dmd's dll implementation. However,
it can infer to @safe if your class' opEquals is.
bool opEquals(LHS, RHS)(LHS lhs, RHS rhs) if (is(LHS : const Object) && is(RHS : const Object))
static if (__traits(compiles, lhs.opEquals(rhs)) && __traits(compiles, rhs.opEquals(lhs)))
// If aliased to the same object or both null => equal
if (lhs is rhs) return true;
// If either is null => non-equal
if (lhs is null || rhs is null) return false;
if (!lhs.opEquals(rhs)) return false;
// If same exact type => one call to method opEquals
if (typeid(lhs) is typeid(rhs) ||
!__ctfe && typeid(lhs).opEquals(typeid(rhs)))
/* CTFE doesn't like typeid much. 'is' works, but opEquals doesn't
(issue 7147). But CTFE also guarantees that equal TypeInfos are
always identical. So, no opEquals needed during CTFE. */
// General case => symmetric calls to method opEquals
// this is a compatibility hack for the old const cast behavior
// if none of the new overloads compile, we'll go back plain Object,
// including casting away const. It does this through the pointer
// to bypass any opCast that may be present on the original class.
return .opEquals!(Object, Object)(*cast(Object*) &lhs, *cast(Object*) &rhs);