class Foo
{
@safe nothrow:
void method_is_nothrow(){}
void method_is_also_nothrow(){}
}
or
class Foo
{
@safe nothrow
{
void method_is_nothrow(){}
void method_is_also_nothrow(){}
}
}
no need to append it to every single method by hand...
Am 12.09.2012, 04:38 Uhr, schrieb SomeDude :
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.
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
