Cannot compare object.opEquals is not nogc

[Steven Schveighoffer via Digitalmars-d-learn]

On 7/23/16 10:53 AM, Rufus Smith wrote:
> On Saturday, 23 July 2016 at 14:15:03 UTC, Lodovico Giaretta wrote:
>> On Saturday, 23 July 2016 at 13:18:03 UTC, Rufus Smith wrote:
>>> Trying to compare a *ptr value with a value in nogc code results in
>>> the error:
>>>
>>> Error: @nogc function '...' cannot call non- at nogc function
>>> 'object.opEquals'
>>>
>>> Shouldn't object opEquals be marked?
>>
>> If object.opEquals is marked @nogc, than all D classes must implement
>> it as @nogc, because (of course) you cannot override a @nogc method
>> with a not- at nogc one (while the opposite is possible, of course).
>> So marking it @nogc is not only a big breaking change, but also very
>> limiting.
>
> Um, this isn't right. GC code can always call non-gc code.

The issue is that for *classes*, the proper way to add an opEquals is to 
override the base version. The base version existed LONG before @nogc 
did, and so it's not appropriately marked.

Not only that, but @nogc is too limiting (if I want to use GC in 
opEquals, I should be able to).

The real problem here is that there is a base method at all. We have 
been striving to remove it at some point, but it is very difficult due 
to all the legacy code which is written.

Almost all the Object base methods need to be removed IMO. You can add 
them at a higher level if you need them, and then specify your 
requirements for derived classes.

Including opHash, opCmp, toString, etc.

> If you mark opEquals nogc, it breaks nothing except implementations of
> opEquals that use the GC. GC code can still call it nogc opequals, it
> only enforces opEquals code to avoid the GC itself, which isn't a
> terrible thing.

It breaks all classes which use GC in opEquals. Note that you can't 
really compare two immutable or const objects either! (well, actually 
you can, but that's because the runtime just casts away const and lets 
you have undefined behavior).

> What is terrible is that nogc code can never have any equality
> comparisons! It is impossible unless one manually tests them, but how?
> Every method would be brittle. Do a memory test? compare element by
> element? One can't predict what to do.

It is unfortunate. I hope we can fix it. I'd rather not add another 
exception like we have for comparing const objects.

> So, you are trying off laziness to break nogc. As it stands, if nogc
> code can't compare equality, it is broken and useless. Why put it in the
> language then?

@nogc is not useless, it just cannot handle Objects at the moment.

> Broke! Even if opEquals of T does not use any GC we can't write test to
> be nogc, which means we can't have S be nogc or anything that depends on
> S that is nogc. This must be a dirty trick played by the implementors of
> nogc to keep everyone on the gc nipple?

I assure you, it's not a trick. It's legacy. It needs fixing, but the 
fix isn't painless or easy.

-Steve