Eliminate class allocators and deallocators?

[Leandro Lucarella]

Andrei Alexandrescu, el  6 de octubre a las 21:42 me escribiste:
> >>>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.

But when using delete that's exactly what it should happen. You are hiding
a bug if you let that happen on purpose.

> >>>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.

Why is a bad idea? If you are destroying an object, the object will be in
an inconsistent state. What's the point of keeping it alive. Again, you're
just hiding a bug; letting the bug live longer. The language should try to
expose bugs ASAP, not delay the detection.

I think is a good idea not to force the GC to free the memory immediately
with a delete, but it should if it's easy. Other protection methods as
using mprotect to protect the objects pages it's very desirable too,
because you can spot an access to a inconsistent (destroyed) object as
soon as it first happen.

> >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 want to introduce a new semantic, I think you should provide a new
method, not change the semantic of an existent one.

And BTW, is there any reason why this can't be implemented in the library
instead of using an operator? Why don't you provide a "destroy()" function
for that in Phobos?

Really, I can't see any advantages on changing the delete operator
semantics, only problems.

> >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.

Why it's broken? Why it's undesired?

> In fact i'd love to simply make delete disappear as a keyword and make
> it a function.

I agree on this one, no need for an operator (AFAIK). But again, I don't
see how letting the user to use a destroyed object is any safer. It's
really bad in fact.

> >>>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.

Why? Using malloc and free is a lot more trouble, you have to register the
roots yourself for example. It's not like you do malloc() and free() and
everything works magically. You have to have more knowledge of the GC to
use them. Being able to manually manage the *GC* heap (if the GC support
that, if not it can make it a NOP) is good IMHO.

> >>>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.

Why it's bad for D? (I don't care that much about C++ reasons :)

-- 
Leandro Lucarella (AKA luca)                      http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Debemos creer en los sueños del niño. Cuando el niño sueña con tetas, se
toca.
	-- Ricardo Vaporeso. Toulouse, 1915.