RFC, ensureHeaped

Jonathan M Davis jmdavisProg at gmx.com
Tue Nov 16 11:10:16 PST 2010


On Tuesday, November 16, 2010 10:31:43 Steven Schveighoffer wrote:
> On Tue, 16 Nov 2010 13:04:32 -0500, Andrei Alexandrescu
> 
> <SeeWebsiteForEmail at erdani.org> wrote:
> > On 11/16/10 4:40 AM, Steven Schveighoffer wrote:
> >> On Mon, 15 Nov 2010 17:02:27 -0500, bearophile
> >> 
> >> <bearophileHUGS at lycos.com> wrote:
> >>> 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.
> > 
> > Hm, interestingly a data qualifier @noheap would not need to be
> > transitive as data on the stack may refer to data on the heap.
> 
> I think he means transitive the same way pure is transitive.  Not sure
> what the term would be, functionally transitive?
> 
> in other words, if your function is marked @noheap, it cannot allocate any
> memory, which means it cannot call any *other* functions that allocate
> memory.

Pure is hard enough to deal with (especially since it we probably have made it 
the default, but it's too late for that now). We shouldn't even consider adding 
anything more like that without a _really_ good reason.

- Jonathan M Davis


More information about the Digitalmars-d mailing list