Cannot compare object.opEquals is not nogc

[Lodovico Giaretta via Digitalmars-d-learn]

On Saturday, 23 July 2016 at 14:53:49 UTC, Rufus Smith wrote:
> Um, this isn't right. GC code can always call non-gc code.
>
> 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.

That's what I meant. Sorry for being not clear. IMHO, it is very 
limiting to forbid the use of the GC in opEquals. And it would 
definitely break a lot of code.

> 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.

@nogc code can have @nogc comparisons, as long as it does not use 
other objects whose comparison requires the GC. See more below.

> 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?
>
> struct S(T)
> {
>    @nogc void test(T t1, T t2)
>    {
>       if (t1 == t2) return true;
>       return false;
>    }
> }
>
> 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?

If opEquals of T does not use the GC, then the compiler will 
infer the attribute @nogc for your test function. Remember: 
templated functions will be inferred @nogc whenever possible. 
Just, don't put @nogc explicitly, so the code will be @nogc if 
T.opEquals is @nogc and otherwise it will be not- at nogc.

> Equality comparison is more fundamental than the GC in 
> programming. There is no fundamental reason why equality 
> comparison depends on the GC.
>
> All I can hope for now is that there is a robust way to compare 
> that I can use that is marked nogc. Else all my nogc code is 
> broke. I guess one has this problem with all opOp's!

With templates (as you show in your code) you have no problem, 
just let the compiler infer the attributes, as I said.
With runtime OOP it is more of a trouble, but in D runtime OOP is 
not used that much, and it is rarely used in critical @nogc code.