RFC, ensureHeaped

[bearophile]

Steven Schveighoffer:

> > The experienced programmers may write "scope int[] a...", and have no  
> > heap allocations.
> 
> This is a good idea.  This isn't what I thought spir was saying, I thought  
> he wanted the function to always allocate.

I have also suggested that when "scope" is not present, DMD may automatically add a runtime test similar to the one done by ensureHeaped and dup the array data only if it's on the stack. So even when you don't use "scope" it doesn't always copy.


> The only issue I see here is that scope should really be the default,  
> because that is what you want most of the time.

If the variadics is in the signature of a free function then I agree with you. But if it's inside the this() of a class, then often you want that data on the heap.


> However, the compiler  
> cannot prove that the data doesn't escape so it can't really enforce that  
> as the default.

If you look at my original answer I have suggested something like @heaped, that's attached to an array and makes sure its data is on the heap. This is done with a mix (when possible) of static analysis and runtime tests (in the other cases). But I have not added this idea to the enhancement request of scoped variadics because it looks too much hard to implement in D/DMD.


> I believe the compiler cannot really be made to enforce that all passed-in  
> data will be heap-allocated when passed to foo.  A runtime check would be  
> a very good safety net.

Static analysis is able to do this and more, but it requires some logic added to the compiler (and such logic probably doesn't work in all cases).



> > I have even suggested a transitive @noheap annotation, similar to  
> > @nothrow, that makes sure a function contains no heap allocations and  
> > doesn't call other things that perform heap allocations:
> > http://d.puremagic.com/issues/show_bug.cgi?id=5219
> > The proliferation of function attributes produces "interesting" results:
> > @noheap @safe nothrow pure real sin(in real x) { ... }
> 
> This is a bit much.  Introducing these attributes is viral -- once you go  
> @noheap, anything you call must be @noheap, and the majority of functions  
> will need to be marked @noheap.  The gain is marginal at best anyways.

Indeed, it's a lot, and I am not sure it's a good idea.

I have had this idea reading one or two articles written by people that write high performance games in C++. They need to keep the frame rate constantly higher than a minimum, like 30/s or 60/s. To do this they have to avoid C heap allocations inside certain large loops (D GC heap allocations may be even worse). Using @noheap is a burden, but it may help you write code with a more deterministic performance.

Maybe someday it will be possible to implement @noheap with user-defined attributes plus static reflection, in D. But then the standard library will not use that user-defined @noheap attribute, making it not so useful. So if you want it to be transitive, Phobos needs to be aware of it.

Bye,
bearophile