My Language Feature Requests

[Christopher Wright]

Craig Black wrote:
> 
> "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.

The point of overloading new and delete is to work around the garbage 
collector. It's not smart enough, it doesn't have the knowledge about my 
specific problem, so I'm going to fix the problem myself.

The most common situation is, I want to manually allocate the memory for 
the variable, and I don't want the garbage collector to know about this 
object.

>> 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".

I don't see that. I mean, if D didn't have arrays, you couldn't ever get 
an array bounds error; if it didn't have pointers, you would have 
trouble segfaulting; but those are too useful.

I've manually created objects without using the new operator or the 
constructor. It's ugly. It's error-prone. Overloading new is safer, when 
you just want to control how the memory is allocated. (I couldn't avoid 
it because I didn't want to use a constructor.)

>> > 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. 

Undefined behavior means there are no checks preventing it, but bad 
things can happen if you do it, so be careful, and it isn't Walter's 
fault if it explodes in your face.

The point is, it might be a useful thing, in which case you wouldn't 
want to disallow it. But either way, checking it is too expensive, so 
calling it undefined behavior should suffice.