On Tue, 09 Nov 2010 08:14:40 -0500, Pillsy <pillsb...@gmail.com> wrote:
Steven Schveighoffer Wrote:
On Mon, 08 Nov 2010 18:29:27 -0500, Ali Çehreli <acehr...@yahoo.com>
wrote:
[...]
> I must be remembering an old behavior. I think appending could
> affect the original if it had enough capacity.
Before the array append changes were introduced (somewhere around
2.040 I think?), appending to a slice that started at the beginning of
the memory block could affect the other data in the array. But that
was a memory corruption issue, somewhat different than what we
are talking about.
Ah! This is a lot of what was confusing me about arrays; I still thought
they had this behavior. The fact that they don't makes me a good deal
more comfortable with them, though I still don't like the
non-deterministic way that they may copy their elements or they may
share structure after you append stuff to them.
As I said before, this rarely affects code. The common cases I've seen:
1. You append to an array and return it.
2. You modify data in the array.
3. You use a passed in array as a buffer, which means you overwrite the
array, and then start appending when it runs out of space.
I don't ever remember seeing:
You append to an array, then go back and modify the first few bytes of the
array.
Let's assume this is a very common thing and absolutely needs to be
addressed. What would you like the behavior to be? How can anything
different than the current behavior be reasonable?
IMO, the benefits of just being able to append to an array any time you
want without having to set up some special type far outweighs this little
quirk that almost nobody encounters. You can append to *any* array, no
matter where the data is located, or whether the data is a slice, and it
just works. I can't see how anyone would prefer another solution!
-Steve
