Timon Gehr wrote:
Andrei Alexandrescu wrote:
Allocation and deallocation are not symmetric and as such handling them
in a uniform way would be a mistake that perpetuates a poor
understanding of the underlying realities of memory allocation and
object creation. I suggest you reconsider.
'char' is completely orthogonal to memory allocation and it still gets handled
uniformly to it syntactically. So I do not really get the point here.
And it discourages people to get informed about
custom allocators etc.
I don't see the relationship here.
I cannot imagine that the syntax for them will be particularly nice after the
removal of 'delete'. Who likes features with unnecessarily clumsy syntax?
The cost of keeping "delete" in the language is making a rarely-used,
dangerous facility with loosely-defined semantics straight inside the
language. It reflects poor language design for many reasons.
Andrei
I think we are talking about different things. I do _not_ want to use the
keyword
to somehow try to deallocate GC allocated memory. (who would actually want to do
this anyways?) I want it for custom allocators as in
http://www.digitalmars.com/d/2.0/memory.html. In that case, the semantics would
be
completely specified by me. Removing the keyword means ruining that use case.
You
can also find a nice, clean and strict semantic specification for delete when
called on GC memory that works on all platforms and with all GC implementations:
"do nothing, GC memory is managed automatically." As it is done now, I agree it
is
not particularly nice.
Timon
Why not allow "delete" only in classes with custom allocators? AFAIK
they could be determined at compile time. Please let me know if I'm wrong.
