Pop quiz [memory usage]

[Brad Roberts]

Steve Schveighoffer wrote:
> On Mon, 08 Jun 2009 00:34:10 +0400, Denis Koroskin wrote:
> 
>> On Sun, 07 Jun 2009 15:47:52 +0400, Steve Schveighoffer
>> <schveiguy at yahoo.com> wrote:
>>
>>> On Sat, 06 Jun 2009 21:59:39 -0700, Sean Kelly wrote:
>>>
>>>> Steve Schveighoffer wrote:
>>>>> On Sat, 06 Jun 2009 12:03:03 -0700, Sean Kelly wrote:
>>>>>
>>>>> void main()
>>>>> {
>>>>>   auto str1 = "hello".idup;
>>>>>   auto str2 = str1;
>>>>>   str1 ~= "world";
>>>>>   assert(str1.ptr == str2.ptr);
>>>>> }
>>>> auto str1 = "hello".idup;
>>>> auto str2 = str3 = str1;
>>>> str2 ~= " world";
>>>> str3 ~= " garbage";
>>>>
>>>> Doesn't seem terribly safe to me.
>>> Oh, I know.  It's a long-standing issue with immutability, but I think
>>> if appending gets fixed as Andrei suggests, this should be fixed as
>>> well.  I was just saying that your statement about immutable data never
>>> being appended in-place was false.
>>>
>>> -Steve
>> Your proof relies on buggy behavior.
> 
> By-design behavior.  See http://www.digitalmars.com/d/2.0/
> arrays.html#resize
> 
> poorly designed, perhaps, but it's by design.
> 
> My point was that there's no special treatment of immutable data (as was 
> suggested by Sean), it suffers from the same issues as mutable appending.
> 
> BTW, I'm not in favor of the current behavior, but I do think that if 
> something is fixed for this array allocation issue, it should cover this 
> problem as well.
> 
> -Steve

This problem was one of the main drivers behind the proposal to formally
separate arrays and slices (the T[new] vs T[] part of the D 2.0 talk).

It's kinda fallen down on the todo list, but it's a pretty key usability
problem, imho.

Later,
Brad