On Thu, 04 Mar 2010 13:38:30 -0500, grauzone <[email protected]> wrote:
Steven Schveighoffer wrote:
So it probably should be marked as unsafe.
Doesn't it conform to Andrei's ideas about memory safety? It can stomp
over other data, but it can't be used to subvert the type system.
I think the idea is that anything that *could* result in undefined
behavior is marked as unsafe. It just means it's not available from safe
functions. It still can be called from safe functions via a trusted
wrapper. I'd call it undefined behavior, because the memory is
effectively released. Future GCs may make assumptions about that
unallocated space that would cause problems. I feel like safeD has a
slight lean towards sacrificing performance for the sake of memory
safety. This is not a bad thing, and in most cases inconsequential.
Also, it's not the default behavior: if you don't use this function,
stomping can never happen.
What's nice about capturing it into a function is you *can* classify it as
unsafe, versus the current method which is harder to detect. I'd
categorize it like casting.
But it must be disabled for arrays of immutable types (i.e. strings).
This is tricky, you could have partially immutable types. The function
would have to examine the type of all the contained items and make sure
there were no immutable bytes in the element.
Plus, it's not truly unsafe to use on immutable types if the given array
is the only reference to that data. You could potentially implement a
stack using builtin array appending and shrinkToFit, even on immutable
elements (although I'd advise against it :)
Again, the name shrinkToFit isn't my favorite, ideas welcome.
stompOnAppend()? uniqueSlice()? trashRemainder()?
I don't know either, all sound a bit silly.
I think I like shrinkToFit better than all those :) I still like minimize
the best, but the objection was that it has mathematical connotations.
-Steve
