Proposal : allocations made easier with non nullable types.

[grauzone]

Andrei Alexandrescu wrote:
> 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

Using malloc would probably force us to overwrite a class' new operator. 
Then you no longer had the choice between automatic and manual freeing, 
because the new operator implementation is fixed. Basically, using 
malloc would add a load of crap to the program. Having delete (or a 
function like GC.delete()) is a so much simpler and nicer solution. Why 
would you remove that?