Andrei Alexandrescu, el 19 de octubre a las 17:24 me escribiste: > dsimcha wrote: > >== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article > >>Making ~= work well for slices does not preclude creating a distinct > >>library type. > >>Andrei > > > >Yes, I see LRU/MRU/whatever as a kludge to allow convenience without being > >unsafe > >egregiously inefficient. The fact that it is a kludge is not a criticism > >because > >there is clearly no easy answer, and thus a kludge is genuinely necessary. > >However, I think there needs to be a separate array builder type for "heavy > >duty" > >appending operations. In TDPL I would just say that concatenating slices > >can be > >inefficient and that people should use array builder for heavy duty > >appending, > >length changing, etc., w/o getting into the details. > > But how about the opposite view. What if the *previous* > implementation of GC and ~= were a kludge that led to egregious > inefficiency and revolting unsafety, kludge that that now is getting > fixed. > > What I'm saying is that with the cache in place we'll have slices > that are safe and efficient. Right now they are not safe and not > efficient. I can hardly find reasons to characterize the new state > of affairs as kludgey. > > One surprising (but safe) behavior that remains with slices is this: > > void fun(int[] a) { > a[0] = 0; > a ~= 42; > a[0] = 42; > } > > The caller may or may not see 42 in the first slot after the call.
And for me this is enough to remove appending from slicing and having a proper array type. There is no reason to keep that buggy behaviour. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- DONAN UN PENE EN NICARAGUA -- Crónica TV