Guillaume Piolat wrote:
On Saturday, 17 June 2017 at 13:05:50 UTC, Adam D. Ruppe wrote:
This is why I consider @nogc to be an *extremely* niche feature and
generally harmful. It makes things look a lot harder than it really is -
people confuse `@nogc` with "no gc". Instead, I suggest just minding the
list and using runtime profiling and debugging to ensure your needs are
met in actual practice.
As a counterpoint: It's true that it's a bit niche, but when you have "no
gc" then @nogc really helps with peace of mind (only one allocation and
you may crash).
yeah, it helps a little... in (let's be honest) rare situations where you
really want to be *completely* free of any possible gc allocation. in most
real-life scenarios you're ok with "mostly gc-free, except for exceptional
cases" (like writeln, for example), and you have no way to express it. i
end up not using @nogc at all (except on simple `return a` getters),
despite the fact that many of my code rarely allocates.
there should be a way to say "i don't want gc on this code path, but it is
ok for this one" (like throwing), without resorting to dirty tricks with
casting and lambdas. something like `@raregc` ;-).
but then, how we should define "rare"? that attribute will quickly become
useless, as people will mark arbitrary code with it.
so, `@nogc` is mostly useless IRL (you can't even `enforce` with it), and
`@raregc` will become useless if introduced. and the sole reason (as i see
it) of introducing `@nogc` was to please people complaining about gc
allocations, no matter how often they're done, and on which code path. i
myself see it as "PR design", which attracts people only to make them find
that using D with `@nogc` is a PITA, due to `@nogc` being too restrictive.
what `@nogc` *really* does now is dividing codebases into "i will do all
kind of dirty tricks to avoid GC at all costs, even if it is not really
necessary", and into "ah, screw it, i don't care". to me, it looks like
`@nogc` does more bad than good now.