'delete' keyword

[Jonathan M Davis]

On Tuesday, January 04, 2011 18:31:25 %u wrote:
> Hi,
> 
> I just found out that the 'delete' keyword is intended to be deprecated,
> and I wanted to share several opinions about it and make a couple of
> suggestions:
> 
> - Please don't remove it, at least not in D version 2. The *main* reason
> I've used D is its flexibility with regard to garbage collection -- it
> lets the programmer optimize his programs in ways that are not possible
> otherwise.
> 
> - If you remove it, you'll also be forced to remove scope(), because of the
> same "dangers" -- and hence lots of optimizations when using the stack
> simply won't be possible, and D will just become a glorified C# in terms
> of memory management. (I quit C# precisely because of D's greater
> flexibility in memory management.)
> 
> - If you *MUST* remove it, do something else instead: Change it so it
> simply redirects to a GC method, and have that GC method add the object to
> a list of objects that should be analyzed before anything else for garbage
> collection (effectively making the object become generation negative one).
> This will fix safety issues (because there's no requirement for the object
> to be actually freed, if there's references to it), it'll be efficient
> (since no collection necessarily takes place at that moment), but it'll
> still give the programmer control over object lifetimes, and prevent
> issues like midlife crisis. (I'll still cry over the fact that the old
> 'delete' will be gone, but less than if this feature wasn't present.) :)
> 
> - An alternative solution to removing 'delete' (which I would highly
> advocate) is for it to still delete the object, but call a logging
> function (which can be activated at run time) to write down which exact
> chunks of memory were collected. That way, if an access violation later
> happens, the programmer can simply look at the address and notice that it
> was previously allocated by objects X, Y, and Z, and then he can look for
> where the problems were. I'd personally say that this is probably better
> than any other solution, because (a) the programmer can activate or
> deactivate the logging at will, and (b) it'll facilitate debugging but
> still make D be the powerful language it is.
> 
> Again, PLEASE continue supporting the keyword, even if it means the program
> has to be given a big red "COMPUTER HAZARD" stamp or something... :)
> otherwise D will just no longer be the powerful language it is.
> 
> (I'm curious to see what people think of the debugging feature? Opinions
> are very welcome!)
> 
> 
> And thank you for making D the great language it is! :)

This has been discussed at length before. Andrei is against delete, and actually 
deleting stuff on the GC heap can cause problems. I believe that there is a 
gc_malloc() and gc_free() that will allow you to do that if you really want to. 
I believe that there are other functions for disabling the garbage collector and 
telling it to collect garbage if you want to do that. However, I'm not all that 
well-versed in what functions exist to manipulate the GC. Really, the idea is 
that normally, you'd just use the GC and not worry about it unless profiling 
shows that you have an issue somewhere, and then you tweak that one spot.

clear() is intended to be used when you want to call the destructor on an object 
on the heap so that it can clean up its resources which aren't memory resources. 
The object is then supposed to have its vtable nulled-out so that you get a 
segfault if your code tries to use that object, but I'm not sure that it's 
currently implemented to do that yet (it at least used to put the object in the 
state that its in just prior to a constructor being called on it).

Because it is unsafe, scope is going away as a modifier on a local variable 
(though scope statements are remaining and scope on function parameters is 
staying - though I don't recall what that really does, since it's not the same 
as marking a local variable with scope). However, I believe that there is a 
scoped template which has been added to std.typecons to take its place. So, if 
you _really_ want to use it, it's there. If you're doing that a lot though, you 
might want to rethink things so that you're using structs instead of classes. 
Using structs and templates goes a long way without needing classes and the 
polymorphism that they have, so a lot of D programs don't need the heap all that 
much. Use classes only if you actually need them.

I'm sure that someone else will chime in with better info, but delete is 
definitely going away. It's been argued before, and I really don't think that the 
folks who want delete to stay are going to convince Andrei.

- Jonathan M Davis