Setting array length to 0 discards reserved allocation?

[Andrew Godfrey via Digitalmars-d]

On Friday, 1 August 2014 at 21:36:14 UTC, Chris Cain wrote:
> On Friday, 1 August 2014 at 07:51:32 UTC, Andrew Godfrey wrote:
>> Going through other .dd files, I found an error in 
>> expression.dd.
>> It says "For static or dynamic arrays, identity is defined as 
>> referring
>> to the same array elements and the same number of elements."
>>
>> Well, in fact:
>>
>> unittest {
>>    // expression.dd says that equality AND IDENTITY compare 
>> elements and sizes, for both "static and dynamic arrays". Gaah!
>>
>>    int[] a = new int[3];
>>    int[] b = new int[3];
>>    assert(a == b);
>>    assert(a !is b); // Nope! The doc is wrong!
>>
>>    // So then:
>>
>>    b = a;
>>    assert(b is a); // Now b points to a, and 'is' does what 
>> I'd expect.
>>    // But evidently it's because it compared the array 
>> references - not
>>    // the elements and sizes!
>> }
>>
>> I would NOT recommend updating the compiler to match what the 
>> doc says.
>> The current behavior is consistent with how assignment to an 
>> array reference behaves.
>
> I think the docs might can be cleared up in this regard, but 
> from my reading, the docs are correct on this.
>
>     int[] a = new int[3];
> and
>     int[] b = new int[3];
>
> Do not refer to the same elements. They are two different 
> allocations that happen to look alike and compare equal, but 
> they aren't referring to the same point in memory.
>
> To prove this, you can simply do `a[0] = 1;` ... did `b[0]` 
> "change" as well? (No). Then they couldn't possibly have been 
> referring to the same thing.
>
> What the docs are saying by "referring to the same array 
> elements and the same number of elements": basically, an array 
> in D is simply a pointer + length struct. The `is` operator 
> essentially does a bitwise compare, so naturally `a is b` only 
> returns true when they are bitwise identical structs, which 
> must mean they are the same in both pointer and in length, 
> which naturally means that `a == b` as well. There's no need to 
> compare elements since there's no way something doesn't equal 
> itself unless some weird trickery is going on (concurrent 
> modification?).
>
> You can imagine `is` to mean `a.ptr == b.ptr && a.length == 
> b.length` (or that they refer to the same array and they have 
> the same number of elements), but implemented in what is 
> probably a more efficient manner.

Yes, I was a bit terse in my previous retraction (was low on 
time). I realized this is what the doc was actually saying. The 
edit in the PR stands, but my description of it as fixing an 
"error" is incorrect.
The language was just a bit confusing, perhaps.
I am unable to fix the PR description at the moment but that 
shouldn't prevent review of the PR itself.