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