poll about delete

[Andrei Alexandrescu]

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