Proposal : allocations made easier with non nullable types.

[dsimcha]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> Chad J wrote:
> > Besides safety concerns, what does forbidding manual deletion enable GC
> > implementations to do?
> Foregoing delete affords the GC more implementation options.
> Andrei

Let's assume this is true and that these options are things that are useful to a
language like D.  Worst case scenario, a GC implementation could just ignore calls
to GC.free().  GC.free() could just be implementation defined as either frees
memory or does nothing.

As far as safety, D is a systems programming language.  If you really want to
manually delete a piece of GC-allocated memory, you should be able to.  It's good
for a systems language to make it harder to screw up _by accident_ (I'm all for
getting rid of the delete keyword to make deleting GC-allocated memory less
obvious), but if you insist on doing something, the language should assume you
have a good reason.  Deleting GC allocated memory is an advanced technique that
you do at your own risk, just like using C's malloc/free, using pointers, turning
off bounds checking, casting, using inline assembly, not initializing variables at
declaration, and all the other dangerous but sometimes useful stuff that "safe"
languages won't let you do.  Disabling this wouldn't absolutely prevent corruption
of the GC heap since D still has pointers, which in principle could be made to
point anywhere, and since one could still do something stupid like store the only
pointer to an object in a region not scanned by the GC via casting or something.
The bottom line is that I fail to see how deleting GC-allocated memory is any
different than other dangerous but useful things that can be done in D, and unless
we want to make D a completely safe language at the expense of the flexibility
that its unsafeness offers, I don't understand why you're so opposed to it.