Feature suggestion: in-place append to array

Steven Schveighoffer schveiguy at yahoo.com
Thu Mar 4 10:58:23 PST 2010


On Thu, 04 Mar 2010 13:38:30 -0500, grauzone <none at example.net> 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



More information about the Digitalmars-d mailing list