Proposal : allocations made easier with non nullable types.

[Andrei Alexandrescu]

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