LRU cache for ~=

[Leandro Lucarella]

Andrei Alexandrescu, el 19 de octubre a las 17:24 me escribiste:
> dsimcha wrote:
> >== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at 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