Eliminate class allocators and deallocators?

[Leandro Lucarella]

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?

> >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. If you wrote delete x; the
language should assume you know what you're doing. 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 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.

> >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 :)

-- 
Leandro Lucarella (AKA luca)                      http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Never let a fool kiss you, or let a kiss fool you