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 >> <[email protected]> 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
