TDPL: Manual invocation of destructor

[Jacob Carlborg]

On 2010-08-09 23:14, Andrei Alexandrescu wrote:
> 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.

The I suggest you start discussing about what should replace delete if 
clear isn't going to.

> 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


-- 
/Jacob Carlborg