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-@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-@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.
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.
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.
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?
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!
