TDPL: Manual invocation of destructor

[Andrei Alexandrescu]

awishformore wrote:
> On 09/08/2010 22:52, Andrei Alexandrescu wrote:
>> awishformore wrote:
>>> Quite frankly, I can't imagine any situation where I would ever want
>>> to use the clear the way you currently intend to implement it, and if
>>> you're unclear, you will probably agree that you don't really see a
>>> good way to implement it as things stand.
>>>
>>> Rather than removing delete and implementing a completely useless
>>> clear, I would like to see an improved version of the GC that can
>>> correctly handle delete. Maybe you are approaching the issue from the
>>> wrong perspective.
>>
>> If it's not easy to decide between two alternatives, choosing a third
>> that's worse than either is probably not a good idea.
>>
>> Regarding "correct" handling of delete by the GC - what does that mean?
>> Once you define that, I'll be glad to put that behavior in clear() :o).
>>
>>
>> Andrei
> 
> In the sense of the word, I want "delete" to delete the object.
> 
> That means:
> 
> - all references to the object are invalid
> - the memory is freed
> 
> As has been argued before, this obviously wouldn't belong in the SafeD 
> subset of the language. As far the SafeD subset, there shouldn't be any 
> such instrument at all.

First off, allocating a keyword for the unsafe subset of the language is 
wrong in more than one way. I think we should eliminate delete as a 
keyword as quickly as possible. It is an embarrassment.

Second, there is already a means to manually free memory in druntime's 
current GC: call GC.free() defined in memory.d. It is trivial to add a 
two-liner on top of it (call that nuke()) that invokes the destructor. 
clear() does not attempt to replace that function. This discussion is 
about clear(), so we shouldn't put it in competition with delete.

I personally do not condone adding nuke() to Phobos. It's not reasonable 
to expect that modern GCs support manual deallocation. This is a quirk 
of dmd's current GC, which I think we all agree is run-of-the-mill and 
leaves room for improvement. Adding improvements to the GC would most 
likely render GC.free() inoperant.

A much better possibility is to allow GC to focus on garbage collection 
and use manual deallocation schemes in conjunction with malloc() and free().


Andrei