On Tuesday, 25 November 2014 at 02:48:43 UTC, Jonathan M Davis
via Digitalmars-d-learn wrote:
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
Thanks for reminding me about @trusted. I'm finding it really
hard
to write robust classes in D due to all the problems with Object.
-Eric
