Bug in the spec or implementation?

[Steven Schveighoffer]

On Thu, 05 Aug 2010 16:00:35 -0400, simendsjo <simen.endsjo at pandavre.com>  
wrote:

> On 05.08.2010 21:41, Steven Schveighoffer wrote:
>> On Thu, 05 Aug 2010 15:13:26 -0400, simendsjo
>> <simen.endsjo at pandavre.com> wrote:
>>
>> I found this line in the spec:
>>
>> "These issues also apply to concatenating arrays with the ~ and ~=
>> operators."
>>
>> Where "These issues" refer to reallocating in place (look at the section
>> for setting the length of an array).
>>
>> I think this line is in error, as it directly conflicts with the  
>> statement:
>>
>> "Concatenation always creates a copy of its operands, even if one of the
>> operands is a 0 length array"
>>
>> I think the line should read:
>>
>> "These issues also apply to appending arrays with the ~= operator. Note
>> that the concatenation operator ~ is not affected since it always
>> reallocates."
>>
>> I can assure you that the runtime does always make a copy on
>> concatenation, and always tries to append in place if possible on an
>> expanding length or an append.
>>
>> The spec needs some work, but the runtime is correct.
>>
>> I will file a bug against the spec for you.
>>
>> -Steve
>
> Thanks!
>
> Seems there are plenty of errors in the spec though...
> It will be very difficult to learn the language if the spec and  
> implementation is different. Spec or compiler bug?
>
>
> char[] a = new char[20];
> char[] b = a[0..10];
> assert(a.ptr == b.ptr); // hmm.. does slice has a offset property or  
> something?
>
> // In the spec on arrays#Setting Dynamic Array Length,
> // this is the example, but it doesn't work as in the spec...
>
> char[] c = a[10..20];
> // The spec says expanding b.length should expand
> // in place as a has enough memory and thus overlapping a, but...
> assert(b.capacity == 0); // capacity is 0, so...
> b.length = 15;
> assert(b.capacity == 15); // .. setting length removed it from a..
> assert(a.ptr == b.ptr); // fails...
> b[11] = 'x'; // Says a[11] and c[1] should also change..
> assert(a[11] == 'x'); // fails
> assert(c[1] == 'x'); // fails
>

Yep, I noticed that too when going to file the bug :)

see here: http://d.puremagic.com/issues/show_bug.cgi?id=4590

I should take responsibility for not fixing this sooner since the runtime  
used to work this way, but does not since a patch I added in 2.041 or  
2.042.

Sorry.

-Steve