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
