Proposal : allocations made easier with non nullable types.

[Daniel Keep]

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