Proposal : allocations made easier with non nullable types.

[grauzone]

Leandro Lucarella wrote:
> Andrei Alexandrescu, el  9 de febrero a las 22:20 me escribiste:
>> Chad J wrote:
>>> Andrei Alexandrescu wrote:
>>>> Chad J wrote:
>>>>> Besides safety concerns, what does forbidding manual deletion enable GC
>>>>> implementations to do?
>>>> Foregoing delete affords the GC more implementation options.
>>>>
>>>> Andrei
>>> Such as?
>>> I'm not trying to be antagonistic--manual deletion is a nifty feature to
>>> me, so if it gets designed away I'd appreciate knowing what great
>>> advantages justified such a sacrifice.
>> You need to simply go through a good tutorial on GC implementations, and consider 
>> the added costs of offering a manual delete primitive.
> 
> I did read "Garbage Collection: Algorithms for Automatic Dynamic Memory
> Management"[1] (several times =P) and some papers on the subject and
> I honestly don't recall any big issues about it. The only case I can think
> of if copy/compacting collectors that use the heap as a stack when
> allocating, where freeing a cell in the middle clearly breaks the stack
> allocation.

The only issue I see is with copying garbage collectors. But even then, 
it would be possible to introduce a "force garbage" flag, which causes 
the collector to ignore a mark bit.

Also, D will never ever get a copying garbage collector (except if it's 
ported to .net, which would break everything else too), so why care 
about it?

> But in such cases I think delete could be a NOP, just like for now
> genCollect() really do a fullCollect() because no generational collection
> is present at the moment, the interface is there.
> 
> [1] http://www.cs.kent.ac.uk/people/staff/rej/gcbook/gcbook.html
>