On Wednesday, 12 September 2012 at 02:37:52 UTC, SomeDude wrote:
On Tuesday, 11 September 2012 at 10:28:29 UTC, bearophile wrote:
SomeDude:
It's a bad solution imho. Monitoring the druntime and hunting
every part that allocates until our codebase is correct like
Benjamen Thaut is a much better solution
Why do you think such hunt is better than letting the compiler
tell you what parts of your program have the side effects you
want to avoid?
Bye,
bearophile
My problem is you litter your codebase with nogc everywhere. In
similar fashion, the nothrow keyword, for instance, has to be
appended just about everywhere and I find it very ugly on its
own. Basically, with this scheme, you have to annotate every
single method you write for each and every guarantee (nothrow,
nogc, nosideeffect, noshared, whatever you fancy) you want to
ensure. This doesn't scale well at all.
I would find it okay to use a @noalloc annotation as a shortcut
for a compiler switch or a an external tool to detect
allocations in some part of code (as a digression, I tend to
think D @annotations as compiler or tooling switches. One could
imagine a general scheme where one associates a @annotation
with a compiler/tool switch whose effect is limited to the
annotated scope).
I suppose the tool has to build the full call tree starting
with the @nogc method until it reaches the leaves or finds
calls to new or malloc; you would have to do that for every
single @nogc annotation, which could be very slow, unless you
trust the developer that indeed his code doesn't allocate,
which means he effectively needs to litter his codebase with
nogc keywords.
This is partially what happens in C++/CLI and C++/CX.
