Denis Koroskin wrote: > Andrei Alexandrescu Wrote: > >> Denis Koroskin wrote: >>> On Mon, 09 Feb 2009 13:48:39 +0300, Alex Burton <alex...@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
