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.
Andrei
