On Saturday, 19 April 2014 at 18:12:32 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 19 April 2014 at 18:05:48 UTC, Dicebot wrote:
In lot of standard library functions you may actually need to
allocate as part of algorithm, strict @nogc is not applicable
there. However, it is still extremely useful that no _hidden_
allocations happen outside of weel-defined user API and this
is something that less restrictive version of @nogc could help
with.
What you want is to mark some functions with @allow_gc ? So
that you only get GC where specified as a "contract"?
But isn't this more suitable for dynamic tracing/logging?
Because what you want is probably the frequency of GC
allocations in a particular call tree?
Original proposal, updated and re-worded as formal as possible.
"weak @nogc" functions / methods are identical to normal @nogc
function but are allowed to trigger GC via functions / methods
directly accessible via its arguments. Such weak @nogc functions
can only call strict @nogc functions in any other context.
Exact details get tricky rather quick and this is something that
needs thorough examination but rationale behind this is to move
all allocation decisions exclusively to caller side. Frequency
does not matter here, only the fact that function does not cause
allocations of its own.
Again, example of a pattern that should be common in Phobos:
void foo(ref OutputBuffer buffer) @nogc
{
buffer.put(42); // buffer.put may be not @nogc, this turns
foo into "weak @nogc"
throw new Exception(); // put this is prohibited anyway
someGCFunction(); // as well as this..
int[] arr; arr ~= 42; // ..and this
}
User of such functions will be 100% sure that if any allocations
happen, he is the one to blame and can tweak it in his own code,
possibly using OutputBuffer implementation that does not use GC
or allocations at all.
