opEquals unsafe? Please tell me this isnt true...

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, November 24, 2014 22:12:08 Eric via Digitalmars-d-learn wrote:
>
> @safe
> class Y { }
>
> @safe
> class X { }
>
> @safe
> class Z
> {
>      int x;
>
>      this()
>      {
>          if (typeid(X) == typeid(Y)) x = 1; // Compile Error
>          else x = 2;
>      }
> }
>
> void main() { new Z; }
>
> // test.d(19): Error: safe function 'test.Z.this'
> // cannot call system function 'object.opEquals'
>
> Isn't this analagous to saying that the "instanceof" operator
> in java endangers the GC?
>
> Is it correct to replace '==' with 'is'?

It's not that it's inherently unsafe. The problem is a combination of the
fact that stuff in druntime that pre-existed @safe hasn't been made @safe
yet (particularly, stuff in TypeInfo) and the fact that Object shouldn't
even have opEquals, opCmp, toHash, or toString on it, because that restricts
which attributes can be used
( https://issues.dlang.org/show_bug.cgi?id=9769 ), though I think that with
@safe, we can work around that (unlike with const). However, for whatever
reason, TypeInfo's opEquals function hasn't been marked with @safe or
@trusted, so it's considered @system. That will need to be fixed, but I
don't know if there are any implementation issues preventing it. It _looks_
like it could probably be marked @trusted, but I haven't actually dug into
it in detail.

In any case, you should be able to just mark the constructor as @trusted for
now to work around the issue, and at some point in the future opEqualso or
TypeInfo should be @trusted or @safe.

- Jonathan M Davis