Proposal : allocations made easier with non nullable types.

[Andrei Alexandrescu]

dsimcha wrote:
> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
>> Sure. My suggested framework is one in which you'd use malloc for those
>> allocations. Then you can free. But plopping delete in the midst of a GC
>> system... that's just uncalled for.
>> Andrei
> 
> But then, you can't delete, for example, builtin arrays.

You oughtn't.

> Furthermore, if you use
> C's malloc/free, you have to be really anal about making sure all code paths free
> the memory.

I agree. But the underlying idea is that those places are few and far apart.

> With the ability to manually free GC managed memory, it becomes ok to
> miss an infrequently taken code path, like an exception, because it's just a
> performance optimization.

The problem is, many (most?) GCs don't support manual deletion. That's a 
quirk rather endemic to D's implementation. Relying on it is not wise 
because other allocators will implement it as a do-nothing.

But the real problem is that delete creates a safety hole. I'd rather 
keep at least the GC heap as free from corruption as possible.

> Lastly, using multiple heaps like this seems kind of
> inefficient.  There could be tons of free space on the GC heap, and you'd still be
> allocating on the C heap.
> 
> I think it's fine to remove the delete keyword, but at least keep the GC.free
> library function.

IMHO that is too unsafe for any of these arguments to convince me.


Andrei