My Language Feature Requests

[Craig Black]

"Christopher Wright" <dhasenan at gmail.com> wrote in message 
news:fklr1g$1uat$1 at digitalmars.com...
> This is to fix the stuff I botched with my other reply.
>
> Craig Black wrote:
>> a) Disallow overloading new and delete for classes, and make classes 
>> strictly for GC, perhaps with an exception for classes instantiated on 
>> the stack using scope.
>
> You are just making sure that the garbage collector is handling all memory 
> that is associated with objects. I don't see a point to this. The 
> collector won't try to move memory that it doesn't control.

It has nothing to do with the garbage collector run-time stuff.  It is 
giving the compiler more information so that compile-time checks can be 
done.

>
> You could do bad things with overloading new/delete, but those are hardly 
> unique situations.
>

Granted.  There are so many ways to mess things up with pointers.  It's hard 
to make a systems language "safe".  I guess my approach would be to make it 
"safer".

> > Then the compiler could disallow taking the address of a class field,
> > since we know the resulting pointer would pointer to the GC heap.
> > Note that this would be a compile-time check, and so would not degrade
> > run-time performance.
>
> That's not necessary, since you can map a source range to a destination 
> range. It would be a simplifying assumption that improves performance, by 
> changing two comparisons and an addition for each pointer (plus one 
> subtraction per move) to one comparison and one assignment for each 
> pointer. But you're going through a large amount of memory, so that's not 
> a serious concern, I think.
>
>> a) Preceding a pointer declaration with fixed would allow that pointer to 
>> take the address in the GC heap.
>
> It'd be undefined behavior to do otherwise. But safe as long as no 
> collections happen before you use the pointer.
>

Unless I am missing something, this would require a run-time check for each 
pointer assignment or pointer arithmetic operation.  Personally, I would 
make every effort to avoid this overhead.  Pointers should be lightweight 
and fast.