On Saturday, 23 July 2016 at 21:44:05 UTC, Rufus Smith wrote:
On Saturday, 23 July 2016 at 17:27:24 UTC, Lodovico Giaretta
wrote:
- we trust what we are doing: e.g. we cannot mark a thing
@nogc, but we know it is and the profiler confirms that no
allocation happens, so we are happy; our aim is having code
that doesn't freeze because of collections, and not marking
code @nogc.
This is bad. It only creates a faulty foundation. The whole
point of nogc is to enforce nogc behavior. If you don't use it
your not enforcing anything and then things slip by only to
create problems later. This mentality is completely wrong and
leads to decay.
While you are right on this, we must be pragmatical: we currently
do not enforce that pointers point to valid memory locations,
that private members are not accessed outside the module with
tricky arithmetics, we have tons of things that work by
convention, because the compiler simply can't check them all and
some are even intrinsically uncheckable. In this environment of
"code by trust", @nogc is the least of the problems, also
because, I insist, it can be checked with the profiler, or you
can plug a custom GC to druntime that asserts every time you try
to call its functions (work is being made to make the GC
independent and pluggable).
This is exactly why we are discussing this right now, because
someone decided that it was ok to ignore other use cases which
eventually turn out to be quite important.
Well, I think that deciding that opXXX must always be @nogc,
ignoring other use cases that may need the GC, is blatantly
wrong. By asking that Object.opXXX be @nogc, you are making the
error the error you said others made.
