DIP60: @nogc attribute

[monarch_dodra via Digitalmars-d]

On Saturday, 19 April 2014 at 18:05:48 UTC, Dicebot wrote:
> I feel like the origin of the discussion has been completely 
> lost here and we don't speak the same language right now. The 
> very point I have made initially is that @nogc in a way it is 
> defined in your DIP is too restrictive to be effectively used 
> in Phobos.
>
> 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.
>
> The fact that you propose me to use unit tests to verify same 
> guarantees hints that I have completely failed to explain my 
> proposal but I can't really rephrase it any better without some 
> help from your side to identify the point of confusion.

I feel what you are asking for is that something that is part of 
the interface (qualifier), make no actual promises about the 
function itself, but rather only help you with your 
implementation? That feels wrong.

I see little value in doing:

void fun(T)(ref T t) @nogc
{
     t.allocateOnGc(); //"This is fine because T does it?"
}

This is what you are asking for? Am I correct?

I also still don't see why @nogc would behave any different from 
nothrow, pure or @safe.

***THAT SAID***, unless I'm mistaken, wouldn't your requirements 
be better answered by the "qualified block" proposal? Remember 
that proposal that (would) have allowed us to do:

void fun() @safe
{
   @trusted { //doesn't create scope.
     T t = someUnsafeFunctionITrust();
   }

     t.doIt(); //doIt must be safe
}

By the same standard, you could use it to enforce no GC. But only 
in certain areas.

EG:
void fun(T)(ref T t) //inferred
{
     t.allocate(); //I'm fine with this using GC

   @nogc : //But as of this line, I want the compiler to ban the 
GC altogether
     doThings(); //I can rest assured this won't allocate on the 
GC.
}

Personally, I still feel this would be a *much* more natural, 
idiomatic, and more transparent approach to doing things, than 
the current trusted lambda *crap* we've been doing. And it would 
indeed help with writing things correctly.
...

...or I misunderstood you, in which case I apologize.