On 07/31/2016 08:43 PM, Rufus Smith wrote:
e.g., I have a nogc container and a remove(T obj). I can't search for
obj and remove it because opEquals is not marked nogc. So I need an
alternative that is somewhat robust.
Jonathan M Davis has already mentioned his plans to templatize
object.opEquals, which would help here. In the meantime, you can make
your own comparison function and use that instead of the == operator.
Note that you can add @nogc when overriding Object.opEquals, and you can
call such a @nogc opEquals directly from @nogc code. You just can't use
the == operator which is implemented in object.opEquals.
In code:
----
class C
{
override bool opEquals(Object other) const @nogc { return false; }
}
void f(C a, C b) @nogc
{
bool x = a == b; /* doesn't compile */
bool y = a.opEquals(b); /* compiles just fine */
}
----
object.opEquals (i.e. the == operator) does a little more than just
calling a.opEquals(b). You can check the source to see what it does exactly:
https://github.com/dlang/druntime/blob/master/src/object.d#L136-L156
You'd probably want to mirror that as closely as possible in a custom
comparison function, so that the results are consistent with the ==
operator.
As far as I see, you can't do the typeid thing, though, because
TypeInfo.opEquals is not @nogc. Ugh.
