@gc attribute for bypassign @nogc

[Lodovico Giaretta via Digitalmars-d]

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- at 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.