downs wrote:
Andrei Alexandrescu wrote:
downs wrote:
Andrei Alexandrescu wrote:
downs wrote:
Andrei Alexandrescu wrote:
Hello,
D currently allows defining class allocators and deallocators. They
have
a number of problems that make them unsuitable for D 2.0. The most
obvious issue is that D 2.0 will _not_ conflate destruction with
deallocation anymore: invoking delete against an object will call
~this() against it but will not recycle its memory. In contrast, class
deallocators are designed around the idea that invoking delete
calls the
destructor and also deallocates memory.
So I'm thinking of removing at least class deallocators from the
language. Class allocators may be marginally and occasionally
useful if
the user takes the matter of deallocation in her own hands.
A much better way to handle custom allocation of classes would be
in the
standard library.
What do you think?
Andrei
Do you trust the D GC to be good enough to always free everything
you've allocated, without error?
If your answer was 'ye- maaybe ... no actually', please rethink this.
People will always be able to call functions in the garbage collector
manually. The discussion on class allocators and deallocators has
nothing to do with that.
Andrei
So you can still deallocate a class by hand, only it's not called
delete anymore?
That is correct.
Andrei
Isn't that a pretty big violation of Least Surprise?
http://en.wikipedia.org/wiki/Principle_of_least_astonishment :
"In user interface design, programming language design, and ergonomics, the
principle (or rule or law) of least astonishment (or surprise) states that, when two
elements of an interface conflict, or are ambiguous, the behaviour should be that which
will *least surprise* the human user or programmer at the time the conflict arises."
I think the basic rule being introduced is:
that every object can be managed by the gc, or manually managed. But not
both. That seems reasonable to me. But if delete no longer deletes, it
needs a name change.
