On Thursday, 17 April 2014 at 19:51:38 UTC, Walter Bright wrote:
On 4/17/2014 10:41 AM, Dicebot wrote:
On Thursday, 17 April 2014 at 16:57:32 UTC, Walter Bright
wrote:
With current limitations @nogc is only useful to verify that
embedded code which
does not have GC at all does not use any GC-triggering
language features before
it comes to weird linker errors / rt-asserts. But that does
not work good either
because of next problem:
Remember that @nogc will be inferred for template functions.
That means that
whether it is @nogc or not will depend on its arguments being
@nogc, which is
just what is needed.
No, it looks like I have stated that very wrong because
everyone understood it
in completely opposite way. What I mean is that `put()` is NOT
@nogc and it
still should work. Same as weakly pure is kind of pure but
allowed to mutate its
arguments, proposed "weakly @nogc" can only call GC via
functions directly
accessible from its arguments.
I don't see value for this behavior.
It's a formal promise that the function won't do any GC work
*itself*, only indirectly if you pass it something that
implicitly does heap allocation.
E.g. you can implement some complicated function foo that writes
to a user-provided output range and guarantee that all GC usage
is in the control of the caller and his output range.
The advantage of having this as language instead of documentation
is the turtles-all-the-way-down principle: if some function deep
inside the call chain under foo decides to use a GC buffer then
it's a compile-time-error.
