Proposal : allocations made easier with non nullable types.

[dsimcha]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> Daniel Keep wrote:
> >
> > Denis Koroskin wrote:
> >> Andrei Alexandrescu Wrote:
> >>
> >>> Denis Koroskin wrote:
> >>>> On Mon, 09 Feb 2009 13:48:39 +0300, Alex Burton <alexibu at mac.com> wrote:
> >>>>
> >>>>> I think it makes no sense to have nullable pointers in a high level
> >>>>> language like D.
> >>>>>
> >>>>> In D :
> >>>>>
> >>>>> X x = new X;
> >>>>> This is a bit redundant, if we take away the ability to write X x; to
> >>>>> mean X x = 0; then we can have X x; mean X x = new X;
> >>>>> If the class has a ctor then we can write X x(32); instead of X x =
> >>>>> new X(32);
> >>>>> Only when the types of the pointer and class are different do we need
> >>>>> to write X x = new Y;
> >>>>> We can do this syntactically in D because classes cannot be
> >>>>> instantiated on the stack (unless scope is used, which I have found a
> >>>>> bit pointless, as members are not scope so no deterministic dtor)
> >>>>>
> >>>>> This makes the code much less verbose and allows code to change from X
> >>>>> being a struct to X being a class without having to go around and
> >>>>> change all the X x; to X = new X;
> >>>>>
> >>>>> As I said in the nullable types thread:
> >>>>> Passing 0 or 0x012345A or anything else that is not a pointer to an
> >>>>> instance of X to a variable declared as X x is the same as mixing in a
> >>>>> bicycle when a recipe asks for a cup of olive oil.
> >>>>>
> >>>>> There are much better, and less error prone ways to write code in a
> >>>>> high level language than allowing null pointers.
> >>>>>
> >>>>> Alex
> >>>> I remember Andrei has showed interest in unification of the way value
> >>>> and reference types are instantiated:
> >>>>
> >>>> Foo foo(arg1, arg2); // valid instance, be it reference of value type
> >>>> Bar bar; // same here (default ctor is called)
> >>>>
> >>>> and ditch 'new' keyword altogether.
> >>> That would be nice but Walter says he dislikes a dynamic allocation
> >>> going under the covers.
> >>>
> >> How about dynamic closures? It's way much harder to /properly/ determine
whether a closure allocates that to determine if Foo foo; allocates But it reduces
syntax complexity (by removing one syntax construct) and make structs and classes
a little bit more intechangeble, which is a plus, I think.
> >>
> >>>> Note that you can't delete
> >>>> non-nullable reference so 'delete' keyword is not needed, too (use scope
> >>>> instead). Nullable types, however, may be recycled with e.g.
> >>>> GC.delete(foo);
> >>> Delete-ing either non- or yes-nullable references is just as dangerous.
> >>> IMHO the delete facility of the GC should be eliminated. (Long story.)
> >>>
> >> I competely agree. Don't remember last time I used delete in D.
> >>
> >>> Andrei
> >
> > I've used it for managing very large chunks of memory that I don't want
> > hanging around.  Access to this memory is generally mediated by small
> > proxy object using reference counting so I know when it's OK to nuke
> > that big chunk.
> >
> > GC is wonderful, but there are times where you just can't trust it.
> >
> >   -- Daniel
> Sure. My suggested framework is one in which you'd use malloc for those
> allocations. Then you can free. But plopping delete in the midst of a GC
> system... that's just uncalled for.
> Andrei

But then, you can't delete, for example, builtin arrays.  Furthermore, if you use
C's malloc/free, you have to be really anal about making sure all code paths free
the memory.  With the ability to manually free GC managed memory, it becomes ok to
miss an infrequently taken code path, like an exception, because it's just a
performance optimization.  Lastly, using multiple heaps like this seems kind of
inefficient.  There could be tons of free space on the GC heap, and you'd still be
allocating on the C heap.

I think it's fine to remove the delete keyword, but at least keep the GC.free
library function.