http://d.puremagic.com/issues/show_bug.cgi?id=2093
[EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Comment #8 from [EMAIL PROTECTED] 2008-11-22 09:44 ------- Note that this behavior is defined in the spec. See http://www.digitalmars.com/d/2.0/arrays.html#resize "To maximize efficiency, the runtime always tries to resize the array in place to avoid extra copying. It will always do a copy if the new size is larger and the array was not allocated via the new operator or a previous resize operation. This means that if there is an array slice immediately following the array being resized, the resized array could overlap the slice" The fact that it violates invariantness is a side effect that Walter has not yet dealt with. There have been proposals to fix this, two of which I have proposed: 1. As you said, store the requested length along with the block length in the GC. Only appending to an array that ends at the end of the allocated memory will realloc in place. Original proposal: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=63146 Note nobody responded to this one 2. Store the length of the allocated array in the first element of the array. Then modify the meaning of the length member of the array struct to flag whether it is pointing to the beginning of the array or not. Original proposal: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=77437 Some people had questions, but nobody proved the proposal wouldn't work. I don't think Walter is interested in fixing this issue, as it has been a 'feature' for a while, and he never has responded positively to any decent proposals to fix this. --