On Wednesday, November 07, 2012 10:19:06 thedeemon wrote: > On Wednesday, 7 November 2012 at 06:44:11 UTC, Jonathan M Davis > > wrote: > > On Wednesday, November 07, 2012 04:45:04 Malte Skarupke wrote: > >> I don't anticipate that I will ever run into a situation where > >> I want to append to a range without caring about whether it > >> allocates and copies or not. If I want to append to a range, I > >> will write the extra line to create a copy manually. > >> Because of that I don't need the syntactic ambiguity of > >> treating > >> a range the same as an array. > > > > In general, you can't append to ranges. > > I assume Malte really meant slices, not ranges.
Well, there's no difference between a slice of an array and an array. There's no point in distinguishing them, and it's just going to cause confusion if you try and think of them as being any different from one another. Similarly, thinking of a dynamic array as a container is a bit mistaken, because dynamic arrays don't own or manage their own memory. The runtime does. If you want an array that is never sliced, you have to make sure of that yourself (probably by wrapping it in class - even wrapping it in a struct wouldn't work, since it would be sliced when the struct was copied), and if you want to avoid reallocating when appending in the face of removing elements from the array, you'll have to manage that yourself as well. But if you're going that far to manage your own arrays, and you're wrapping them in another type, it might make the most sense to just not use arrays but rather allocate the memory yourself with malloc, and then have the wrapper manage its length. You lose concatenation and whatnot, but it's probably more efficient that way, and you avoid the problem of potentially screwing up and ending up with reallocations that you didn't expect. Dynamic arrays are meant to be sliceable, and trying to avoid letting them be sliced or otherwise letting the runtime manage them is likely more trouble than it's worth. - Jonathan M Davis