Eliminate class allocators and deallocators?

[Andrei Alexandrescu]

Leandro Lucarella wrote:
> Andrei Alexandrescu, el  6 de octubre a las 19:26 me escribiste:
>> Christopher Wright wrote:
>>> What exactly is your suggestion?
>>>
>>> It seems that you mean that:
>>> delete obj;
>>>
>>> should call a destructor but not call delete() or notify the GC
>>> that the memory is free.
>> That is correct. In particular, an object remains usable after delete.
> 
> Why would you do that? What is the rationale to not notify the GC?

Because there may be other live references to the object.

>>> You're saying that there is a problem, but you're not telling us
>>> what's wrong. Why the hell do you want to destroy an object
>>> without recycling its memory? Why does the inability to do so
>>> cause a problem?
>> The matter has been discussed quite a bit around here and in other
>> places. I'm not having as much time as I'd want to explain things.
>> In short, destroying without freeing memory avoids dangling
>> references and preserves memory safety without impacting on other
>> resources.
> 
> But D is a system programming language.

Well it is but there are quite a few more things at stake. First, it is 
a reality that it is often desirable to distinguish between calling the 
destructor and reclaiming memory. D's current delete continues the bad 
tradition started by C++ of conflating the two.

> If you wrote delete x; the
> language should assume you know what you're doing.

I think delete should be present in SafeD and if you want manual memory 
management you should build on malloc and free.

> If you only want to
> "deinitialize" an object, you can write a .destroy() method for example,
> and call that. I think delete have a strong established semantic to change
> it now, and without any gain.

It has a thoroughly broken and undesired semantics. It would be a step 
forward to divorce it of that. In fact i'd love to simply make delete 
disappear as a keyword and make it a function.

>>> It seems like a performance hack to me -- you've got an object
>>> that isn't valid anymore, but you want to hang on to the memory
>>> for some other purpose. And you could override new() and delete(),
>>> but you don't want to incur the performance penalty of calling the
>>> runtime to fetch the deallocator.
>> It's a safety hack, not a performance hack.
> 
> But you shouldn't provide safety where the programmer is not expecting it.
> delete is for *manual* memory management. It makes no sense to guarantee
> that the memory is *not* freed. It makes sense not guaranteeing that it
> will actually be freed either. I think that's a good idea actually,
> because it gives more flexibility to the GC implementation.

I think we should move away from the idea that delete is for manual 
memory management. We should leave that to the likes of malloc and free 
alone.

>>> The only remaining use that I see is a way to reset a shared
>>> object without explicitly passing around a reference to the new
>>> version of the object. This seems potentially dangerous, and
>>> nothing I want for default behavior.
>> Well incidentally at least as of now "delete obj" puts null in obj...
> 
> That's nice :)

I think it's a false sense of security. C++ beginners keep on suggesting 
that feature and C++ pundits keep on explaining them that it's ungainful.


Andrei