Kagamin wrote:
Andrei Alexandrescu Wrote:
- Most code and most coders would be dramatically helped by
distinguishing destruction from deletion, as opposed to the wrong
conflation implicitly fostered by C++ for years.
So you just want to have control what you destruct and what you
delete? For what reason?
This has been often discussed in numerous fora. Essentially destruction
can be made safe but memory reclamation cannot (with qualifications).
- D is a systems language, but it's also a language in which doing
the right thing is easy and favored. Allocating no less than a
keyword for a fundamentally unsafe operation is just too much.
The language can't guarantee it's unsafety. You can tell whether an
object's destructor was called, but you can't tell whether a memory
chunk was freed.
I'm not sure where this leaves the conversation.
- The GC can't be expected to implement manual disposal anyway.
This expectation is not easy to verify. If you want GC to not free,
why you bother if it doesn't free?
I bother about primitives that essentially can't guarantee anything.
allocating a _keyword_ for an operation that may actually end up
not doing much at all is overkill.
This seems to be the only argument that's hard to object to, and it
seems to be the main one. So is that it?
Plus all others, none of which was successfully retorted.
Honestly the top thing I'm worried right now is Walter's aversion
to breaking changes, which has turned an elbow since TDPL.
I doubt that keyword saving is a good argument for a breaking change.
btw can a function destruct object and nullify pointer for both
rvalue and lvalue?
It doesn't matter. delete nullifying its argument was a false sense of
safety anyway - like the helmet of a kamikaze.
Andrei
