Final by default?

[Steven Schveighoffer]

On Thu, 13 Mar 2014 09:59:41 -0400, Daniel Murphy  
<yebbliesnospam at gmail.com> wrote:

> "Steven Schveighoffer"  wrote in message  
> news:op.xcnxwzc8eav7ka at stevens-macbook-pro.local...
>
>> I would also mention that a "band-aid" fix, if you are always using  
>> x.length = 0, is to special case that in the runtime to automatically  
>> reset the used size to 0 as well. This is a specialized application, I  
>> would think tweaking the runtime is a possibility, and a temporary fix  
>> like this until you can update your code would at least provide an  
>> intermediate solution.
>
> That would risk breaking code in druntime/phobos.

I think it would be highly unlikely. Consider the use case:

arr contains some number of elements;
someOtherArr = arr;
arr.length = 0;

...

arr ~= ...;

use someOtherArr, which now has stomped data.

Now, if the code means to reuse the buffer, it will call assumeSafeAppend,  
which in this case would be a noop, and things will continue to work as  
expected. If it just relies on the runtime re-allocating arr on the next  
append, why not just do arr = null? If the code doesn't have someOtherArr,  
then it will still work just fine. I can't see a reason to reset the  
length to 0 if you aren't going to reuse the array bytes, instead of  
setting it to null.

If the code doesn't always reset to length 0, and then tries appending,  
then Sociomantic's code will still be poorly performing. But I'm assuming  
it's always length = 0. I would ONLY trigger on that condition (and the  
array has to be starting at the beginning of the block, I should have  
mentioned that).

I think it would work without issue. In fact, I wonder if that shouldn't  
be a "feature" of the array runtime anyway.

-Steve