F. Almeida wrote:
About a week ago (or more), I posted a poll to gather the community
opinion on how memory management in D should evolve. Link is
http://www.micropoll.com/akira/mpview/979834-265542
Last I saw, more than half of the D users who voted in it would prefer
that the delete keyword would remain in the language, instead of being
removed. Some of those don't even see a need for a clear() function,
but I disagree with them, I think it will be useful.
On the other hand, just because new safe memory management functions
are to be added to the standard library, that is no justification to
turn D into less of a systems programming language. Which is what will
happen if we give preference to the GC instead of making both styles
(managed or not managed, safe or unsafe) equally easy to adopt to any
programmer. This is the most attractive aspect of D and shouldn't be
discarded.
It's difficult to take a meaningful poll without clearly informing the
voters about the context of the vote and the arguments brought about.
I apologize for my hard stance on the matter but I really think there is
no case in favor of keeping delete.
- The operation didn't deserve a keyword in the C++ days, and carrying
that keyword along is completely gratuitous.
- 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.
- 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 GC can't be expected to implement manual disposal anyway. Again,
allocating a _keyword_ for an operation that may actually end up not
doing much at all is overkill.
Honestly the top thing I'm worried right now is Walter's aversion to
breaking changes, which has turned an elbow since TDPL. I think he is
convinced delete must be deleted as much as I am, but right now it's
possible he'd rather have it limp along a slow deprecation process
instead of outright removing it.
Many of the same arguments and considerations apply to "scope" as a
storage class.
In brief: it's best to not use the likes of "scope" (storage class) and
"delete" in new code, remove it from old code, and propose library
features that help with such unsafe use cases. I think it is a waste of
time arguing in favor of the status quo unless new strong arguments come
to the table.
Andrei
