Thread overview | ||||||
---|---|---|---|---|---|---|
|
November 24, 2014 opEquals unsafe? Please tell me this isnt true... | ||||
---|---|---|---|---|
| ||||
@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'? -Eric |
November 25, 2014 Re: opEquals unsafe? Please tell me this isnt true... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Eric | 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 |
November 25, 2014 Re: opEquals unsafe? Please tell me this isnt true... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | 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
|
November 25, 2014 Re: opEquals unsafe? Please tell me this isnt true... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Eric | On Tuesday, 25 November 2014 at 03:42:50 UTC, Eric wrote:
> I'm finding it really hard to write robust classes in D
> due to all the problems with Object.
I wish Object didn't have any methods. One thing I do is kinda act as if it didn't and make my own interfaces instead.
|
Copyright © 1999-2021 by the D Language Foundation