www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Arrays and the recent (or recently uncovered) confusion.

reply "Regan Heath" <regan netwin.co.nz> writes:
I have to take some responsibility for some of the recent confusion over  
arrays. While arguing against a proposal to change the behaviour of  
"if(x)" WRT arrays I made the assertion that arrays have reference  
semantics, when, in fact they have both reference and value type  
semantics, take for example:

char[] p = null;       //reference
if (p is null) {}      //reference
if (p) {}              //reference

Try doing any of those with a value-type like a struct.

void foo(char[] s) {}
foo(p);                //struct, pass-by-value, 's' is a bitwise copy of  
'p'

char[] s = p;          //struct, bitwise copy
char[] s = p[0..5];    //struct, bitwise copy, new length

Try doing any of these with a reference type (and get the same results).

Some of the behaviour above would be possible with operator overloads and  
some could be made possible with additional operator overloads but that's  
not really important. What is important is that we have a type that  
exhibits both types of semantic behaviour.

It's important for me to make clear here that I _like_ arrays, I _like_  
how they operate, I _like_ that they're a fast, efficient stack based type  
that can represent non-existance (via null). At the same time I can see  
where confusion might arise.

Take the phrase "array reference". To me calling "char[] p" an array  
reference is saying that 'p' is a reference, when in fact it's not. 'p' is  
an 'array' and an 'array' is a reference to some 'data'. I think this  
distinction needs to be made and kept very clear in the docs, take these  
examples from this page:

http://www.digitalmars.com/d/arrays.html

(1) "Slicing an array means to specify a subarray of it. An array slice  
does not copy the data, it is only another reference to it."

-- good, arrays are references to data

(2) "When the slice operator appears as the lvalue of an assignment  
expression, it means that the contents of the array are the target of the  
assignment rather than a reference to the array."

-- "reference to the array" seems wrong, how about replacing that with  
simply "the array"?

(3) "Returns the size of the dynamic array reference, which is 8 on 32 bit  
machines."

-- "dynamic array reference"? replace with just "dynamic array"?

(4) "Returns the size of the reference to the associative array; it is  
typically 8"

-- "reference to the associative array"?

(5) "error, since s is a compiled in static reference to an array."

-- "reference to an array"?

Thoughts?

Regan
Jul 31 2005
next sibling parent reply Vathix <chris dprogramming.com> writes:
 -- good, arrays are references to data


So it sounds like you want to use the names "array" and "array data"; an  
array is a reference to array data. When I explain arrays to people I use  
"elements" rather than data and it seems to be easier to make sense of.

Another array confusion is "static array", the one that has little to do  
with the static keyword. I think it should be renamed, possibly to  
fixed-length array. Might want to rename "dynamic array" to keep it  
consistent, to variable-length array or slice.

By the way, I also very much like D's dynamic arrays. That and  
delegates/closures are probably my favorite things. My beef with dynamic  
arrays is just the bugs with zero length non-null arrays being set to null.
Jul 31 2005
parent Shammah Chancellor <Shammah_member pathlink.com> writes:
In article <op.sur6870ql2lsvj esi>, Vathix says...

 -- good, arrays are references to data


So it sounds like you want to use the names "array" and "array data"; an  
array is a reference to array data. When I explain arrays to people I use  
"elements" rather than data and it seems to be easier to make sense of.

Another array confusion is "static array", the one that has little to do  
with the static keyword. I think it should be renamed, possibly to  
fixed-length array. Might want to rename "dynamic array" to keep it  
consistent, to variable-length array or slice.


I second this renaming.  I was very confused when I first read the language
specification.


By the way, I also very much like D's dynamic arrays. That and  
delegates/closures are probably my favorite things. My beef with dynamic  
arrays is just the bugs with zero length non-null arrays being set to null.


Ditto.  I think they're exactly the improvement needed over C arrays.  They
obviate all the issues I had 
with arrays in C, without adding alot of fluff.  And they're fast for slicing.
D style array slicing is 
something I did alot of in various parsers I wrote in C, for the sake of speed.
(IE load a file into memory, 
and then store pointers and lengths to various parts in a DOM style tree.)
Expect D arrays and D array 
slicing makes this taste about a billion times more convenient.
Jul 31 2005
prev sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
I've just recently been fully learning D (by reading the D spec) so only 
now did I finish reading about arrays, curious to know more and figure 
out what I could related to that other big dyn-array discussion.
And actually it semeed to me that people spent a lot of posts 
misunderstanding each other or not speaking clearly (if they were 
actully wrong I could not tell). What are dyn-arrays *should* be (in 
terms of semantics of course) is open to discussion, but what they 
currently are in D is well-defined (and I'm not sure if the following 
was understood by some participants in the other thread), namely :

Dyn-arrays have mostly reference semantics but not totally, and not 
because besides the pointer they have an extra .length struct-like 
member. It's because dynarrays cannot be null, and I mean proper null, 
that is, non-existant. From the D spec :

"Nulls are also used for empty arrays." in Expressions

So setting a dynarray to null makes it an empty array, not a null 
(non-existant) array. This is clear.

Now for the debattable part: I definitely think null should NEVER mean 
empty array. So either allow non-existant arrays, or disallow assignment 
of nulls to arrays.


-- 
Bruno Medeiros
Computer Science/Engineering student
Aug 02 2005
parent Mike Capp <mike.capp gmail.com> writes:
In article <dcor6m$2ph8$1 digitaldaemon.com>, Bruno Medeiros says...

Now for the debattable part: I definitely think null should NEVER mean 
empty array. So either allow non-existant arrays, or disallow assignment 
of nulls to arrays.


As you say, it's debateable. I much prefer the current rule. For one thing, you
don't need an explicit null check before a foreach. For another, you don't have
to worry about whether some API call returns null or an empty array. (We've

distinction.) Gripping hand is, I can't see any semantic difference between the
two anyway.

cheers
Mike
Aug 02 2005