July 31, 2005
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
July 31, 2005
> -- 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.
July 31, 2005
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.


August 02, 2005
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
August 02, 2005
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 found this ambiguity to be a real source of bugs in C#, which does make your distinction.) Gripping hand is, I can't see any semantic difference between the two anyway.

cheers
Mike


Top | Discussion index | About this forum | D home