On Thursday, 28 July 2016 at 20:32:18 UTC, bitwise wrote:
On Thursday, 28 July 2016 at 18:53:35 UTC, Meta wrote:
On Thursday, 28 July 2016 at 00:23:57 UTC, bitwise wrote:
While working on a past project(C++), I found this little gem:
void draw() {
Font* f = new Font("arial.ttf", 16);
drawText(f, "hello world");
}
It sounds like -vgc and --profile=gc are exactly what you
want. @nogc is meant to *guarantee* that the GC will not be
called within a function or any other functions called by that
function. Taking that guarantee away makes it effectively
useless.
I understand that @assumenogc may not be exactly the right
approach, but the underlying idea is sound, which is to have
the compiler to disallow all GC allocations in some annotated
scope, just like @nogc, but to allow the programmer to override
the @nogc restriction in certain cases.
There may be alternative approaches, and the @warngc idea was
just one random suggestion.
The point is, a mixture of @nogc and @assumenogc would achieve
exactly what I'm looking for. The only problem is that it may
cause issues for people that are using @nogc under a different
set of assumptions.
Also, @assumenogc or whatever does not play well with public
APIs: if a library function is marked @nogc, its user can no
longer know if it is really @nogc or if it does allocate via
@assumenogc. This is not a good thing, as the user may want
*absolutely* no GC allocation in his program, and may even have
disabled the GC at program startup. Also, the code of that
maybe-not-@nogc library may not be available to check for this
thing. Maybe the user doesn't want to trust the library writer,
and so wants the compiler to guarantee no allocations at all.
