Bug in the spec or implementation?

[simendsjo]

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