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.

Reply via email to