@Araq, regarding my thinking on the treatment of raw pointers to do with "owned":
> The only complication on automatic application of the "simple rule" is what > to do with the raw pointers pointer and ptr T which might reference the heap > but can reference any memory location anywhere including the code as for > literals or the stack as for local bindings... I've done more thinking about this, and I think the right answer is to deallocate these raw pointers just as we do ref's at the end of the scope of their "owned". There is no overhead complications necessary, or shouldn't be if there currently are, as when the Allocator is asked to deallocate a pointer to some memory address, it will try to look up that memory address in some way to find the memory control block, which it won't find for literals or for stack bindings as they were never allocated. In that case, it should just no-op and make no changes if that isn't what it does now. By deallocating all forms of pointer when they are inside an "owned", we can have no forms of memory leak when the memory pointers are inside a "owned" data type structure. The only way to get memory leaks is to allocate manually and not manually deallocate for a pointer that is not part of a data structure and thus not automatically "deepDestroy"'ed, and even that would not be possible if we also made normally allocated pointers "owned". Then the final consideration is what to do with pointers that come about as a result of addr and unsafeAddr: we need these in order to bypass copy/move semantics so these need to remain as truly "raw", but as the documentation says, these are "unsafe" and "really really unsafe", so only to be used internally and by people who know what they are doing for reasons of performance.
