On 2010-08-11 09:03:53 -0400, "Steven Schveighoffer"
<[email protected]> 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
[email protected]
http://michelf.com/
