Flexibly sized arrays (was Re: in-parameter)

[Jonathan M Davis]

On Monday, November 08, 2010 10:46:52 Pillsy wrote:
> 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? [...]

It's perfectly legal. You just can't alter any of the elements in the array. 
Appending or concatenating to an arry alters the array, not its elements. And in 
a string, it's its elements which are immutable, not the array itself.

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

It's certainly true that if you want to be altering mutable arrays and you want 
guarantees that two arrays don't refer to the same memory, you're going to have 
to take extra steps - such as using dup. However, a container class such as 
Array isn't necessarily going to help with that. The main change there would be 
that a range over the container and the container would no longer be the same 
type, but that can be detrimental as well depending on what you're doing.

A container solution would result in extraneous dups in many situations and 
could be detrimental to performance. The current situation does not disallow a 
container solution, but it doesn't force it either, so you're free to use 
containers such as Array, if you'd prefer.

Really, I think that using dynamic arrays safely comes down to four rules:

1. Don't resize an array if you want a guarantee that any references to it or a 
portion of it continue to point to the same memory.

2. dup or idup an array if you want a gurantee that it points to the same 
memory.

3. If you don't care whether two arrays point to the same memory or not, then 
feel free to resize them. They may or may not end up pointing to the same 
memory, but since you don't care if they do, it doesn't matter.

4. If you want guarantees that the elements of an array aren't altered but don't 
want to any reallocations to take place if they don't need to, then use arrays 
with const or immutable elements. That way, the arrays themselves can be messed 
with as much as you like, but the elements won't be changed, and so it doesn't 
matter one whit whether two arrays point to the same memory.

True, the situation is not as straightforward as it would be if resizing arrays 
wasn't legal, but it would sure be limiting to disallow the resizing of arrays 
(I think that it's a great feature and a definite improvement over C). It really 
isn't all that hard to avoid problems with it, and of course, there's nothing 
stopping anyone from using library solutions instead if they'd prefer.

- Jonathan M Davis