Destructor semantics

[Michel Fortin]

On 2010-08-11 09:03:53 -0400, "Steven Schveighoffer" 
<schveiguy at yahoo.com> said:

> The problem is, you don't know from the type system that  they are 
> heap-allocated, and the compiler cannot know what is owned and  what is 
> not owned, so it can't make the call to restrict you.

Indeed, that's a real problem.

And I'm beginning to be amazed by the number of issues just begging for 
including owner information in the type system.

1. Destructor and GC-allocated data
2. Synchronized classes members with one or more levels of indirection
3. Safe creation of immutable data through a unique reference
4. Safe moving of mutable data between threads through a unique reference

Am I missing any other?

In all these cases (except the first), the compiler makes the 
conservative assumption and when that assumption is too conservative 
the "solution" is always to cast. I've always found that "solution" 
ridiculous because, unless it's going to be very rare, adding casts 
everywhere is just going to make things worse. And at this point, given 
all the use cases that needs casts, I don't think anyone is going to 
say it's going to be rare.

So I'm not really sure what to do about destructors. If we want it to 
be consistent with the rest, the compiler should take the conservative 
approach and disallow dereferencing members (and also calling any 
function that might dereference a member, ouch!). But once again, this 
is a fake solution to the problem: if we require casts everywhere, 
it'll be worse. So where do we draw the line?

Well, at the very least SafeD should take the conservative route.

The only "correct" solution in the end is to have owner information in 
the type system. But this has other issues...

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/