Bug in the spec or implementation?

[Steven Schveighoffer]

On Thu, 05 Aug 2010 15:13:26 -0400, simendsjo <simen.endsjo at pandavre.com>  
wrote:

> On 05.08.2010 20:53, Steven Schveighoffer wrote:
>> On Thu, 05 Aug 2010 14:45:18 -0400, simendsjo
>> <simen.endsjo at pandavre.com> wrote:
>>
>>> This is only tested on dmd 2.047 on win7.
>>>
>>> According to the spec at http://digitalmars.com/d/2.0/arrays.html:
>>> "Concatenation always creates a copy of its operands, even if one of
>>> the operands is a 0 length array"
>>>
>>> But this doesn't seem like the case:
>>>
>>> auto a = [0];
>>> auto oldPtr = a.ptr;
>>> assert(a.length == 1);
>>> assert(a.capacity == 3);
>>> a ~= 1;
>>> assert(a.ptr != oldPtr); // Fails - Still the same array
>>
>> Concatenation is this:
>>
>> a ~ 1
>>
>> appending is this:
>>
>> a ~= 1
>>
>> Two separate operations, two separate semantics. It might not be easy to
>> determine that from the spec, but I believe the spec is clear.
>>
>> -Steve
>
> Hmm... Doing "a = a ~ 1", and it works like specified.
> I always assumed that composite operators would mean the same..
> That "a += 1" is the same as "a = a + 1" etc.
> I cannot find this behavior explained in the spec though..
>
>  From the Expression spec, I found that "a op= b" is the same as "a = a  
> op b" - see "Assignment Operator Expressions".
> No mention of a CatAssignExpression behaving differently. Array doesn't  
> mention anything either.

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