Flexibly sized arrays (was Re: in-parameter)

Pillsy pillsbury at gmail.com
Mon Nov 8 10:46:52 PST 2010


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


More information about the Digitalmars-d mailing list