Array types not treated uniformly when passed as ranges

Jonathan M Davis jmdavisProg at gmx.com
Tue Feb 15 11:43:38 PST 2011


On Tuesday, February 15, 2011 06:10:57 Steven Schveighoffer wrote:
> On Mon, 14 Feb 2011 22:59:52 -0500, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> wrote:
> > It's because an Array is not a range. Dynamic arrays are a bit special
> > in that
> > they're both a container and a range. An Array is just a container. But
> > honestly, you wouldn't really want it to work.
> 
> Dynamic arrays are not containers.  They do not own the data they
> reference, they just reference that data.  In fact, the owner of the data
> is really the runtime.
> 
> The naming of Array makes this a difficult thing to understand.  An Array
> owns its data, it manages the data, creates it, destroys it, and there is
> no way to "slice" the Array into a smaller Array.  It's a true reference
> type.  A builtin array is not really a container, so it really should be
> named differently.  But there's no way to change that.
> 
> > However, this won't work for containers in general. If you pass an
> > Array, you're
> > passing the container. The passed in Array is identical to the original
> > (currently, Array is a struct with reference semantics thanks to internal
> > reference counting, but soon it will become a class and more obviously
> > have
> > reference semantics). As such, if you alter the passed in Array, you
> > alter the
> > original. So, if you were to continuously pop the front off of the
> > passed in
> > Array, you would be continually popping the front off of the original
> > Array. So,
> > a function like find would actually remove the front part of your Array
> > as it
> > processed it, and if what you were trying to find wasn't there, you'd
> > have an
> > empty Array. The way to fix this is to not have Array be a range.
> > Instead, you
> > have a helper type which is a range over it. You get that with the slice
> > operator.
> 
> This is a good way to explain it.
> 
> > You don't have the problem with arrays that you'd have with user-defined
> > container types, because the semantics of arrays are a bit odd when you
> > copy
> > them. So, if anything were faulty, it would be the built in arrays, not
> > user-
> > defined container types like Array. It is quite handy to have arrays
> > work how
> > they work, however, so that's not likely to change.
> 
> What is faulty is that they are called arrays.  They are slices.

Yeah. I guess that arrays aren't really technically containers in that they 
don't actually own the memory that they refer to. Arrays are just a bit weird 
overall (not necessarily badly designed, just a bit weird). And there really is 
no difference in D between a slice and an array as far as arrays go, which may 
not be clear to everyone...

The overal result is that arrays are actually pretty easy to use and definitely 
very powerful, but discussing and explaining them can get a bit entertaining.

- Jonathan M Davis


More information about the Digitalmars-d-learn mailing list