Jonathan M Davis wrote: > On Monday, November 08, 2010 08:43:20 Pillsy wrote:
> > The length property of an array shouldn't be directly mutable, > > and you shouldn't be able to append onto the end of a dynamic > > array, because it can cause some surprising behavior and adds a > > lot of cruft to the interface in the form of, well, most of > > std.array. The ability to use an an array as a replacement for an > > ArrayList or std::vector clashes badly with the ability to use > > arrays as lightweight slices. [...] > Concatenation for arrays is huge, and given that strings are arrays, > it's that much more important. Well, there's catenating arrays and producing a new (and freshly allocated) array, and there's catenating arrays *in place* to reduce the allocation overhead. That's not useless by any means, but I think it can be handled by container classes or the moral equivalent of something like StringBuilder. Since D has operator overloading, you can even continue to use the same pleasant syntax. Besides, isn't catenating or appending in place impossible with D's (immutable) strings anyway? [...] > I just don't see any real benefit in trying to do so. What we have > works quite well. The way mutable arrays may or may not share structure with each other in ways that are hard to predict gives me the screaming willies, and I think container and "builder" classes are entirely sufficient for covering the other use cases. In any event, I'm pretty certain that even if there were wide-spread support for this change, it would have to wait for the largely-hypothetical D3. Cheers, Pillsy
