July 29, 2005
On Fri, 29 Jul 2005 14:19:06 +0000 (UTC), AJG wrote:

> Hi Derek,
> 
>>I know I'm not the big W. but here's my take this anyhow ;-)
>>
>>> This is something that's confused me quite a bit and I think you are the only one that can settle it for good. The question is whether we should be using null as a special array value. Maybe it can be broken down to pieces:
>>> 
>>> 1) Why can objects be null but arrays can't (given that _both_ are by-ref)?
>>> 
>>> # // Example:
>>> # Object obj  = null; // This is a "proper" null.
>>> # int[] array = null; // This is not. Only via array.ptr.
>>
>>I don't understand your concern. Both these are allowed and both work as expected; that is to say in both cases, after the assignment, the variable does not reference anything. What more than this are you expecting?
> 
> Sure, they both "work" to a certain extent. But if you try to access a property on a null object -that's illegal. On a null array, it's not. That's not a null array. That's a pseudo-null reference that never goes away.

Yes ... but so what? Is that behavior hurting anyone?

Object properties are user-defined and all take 'this' as an automatic argument, thus they require an instance. Array properties are built-in to D. The 'array' is the instance. Don't confuse its elements as being instances of the array.

Thus 'int[] array;' creates an instance of the array even though it has no data yet. And because the instance exists, you can use its properties. There is no inconsistency here. I think you have merged object nullness and array nullness into the same meaning. But they are not the same thing. A null object is a placeholder into which you can later store a reference to an object instance. A null array is an instance of an array that has no data.

>>> IMHO this is inconsistent. The former makes sense, the latter is weird. Another way of looking at it is: why dumb-down arrays but not objects?
>>
>>Huh? I still can't see what you are worried about.
> 
> Arrays are dumbed-down so that you can do things like:
> 
> foreach (char c; null) { // do something }
> 
> NULL, in my opinion, is _not_ the same as empty. BUT, the above operation makes it so. Instead, it should throw an exception at the very least, or even better, it could be detected at compile-time.

You use the phrase 'dumbed-down' where as I see this as a smart thing. And just because the coder does some weirdo foreach() statement, doesn't mean the language is wrong. And by the way, you code example does produce a compiler error - " foreach: void* is not an aggregate type". To get it to compile you have to use 'foreach(char c; cast(char[])null) {};' which shows to me that somebody with a big stick needs to chat with the coder.

>>> 2) Is it a technical limitation (for now)?
>>Is *what* a limitation?
> 
> The distinction I made before between the nullness of objects (which is
> complete), and that of arrays (which is incomplete). I asked this because
> perhaps it was due to the way D properties worked (more like functions), or
> somesuch, meaning, it was not _intended_ to be that way.

But arrays are not classes or objects. So what if they are both reference types. They are still not the same beasties.

>>> 3) Is support for "proper" null arrays planned?
>>> 
>>> I, for one, would _like_ to see support for both null arrays and continued support for null objects.
>>
>>Who says that this support is going away?
> 
> If Walter decides emptiness and existence should be one. This already happens in the language. Maybe it's due to bugs, maybe not. That's why I asked Walter for his "vision," if you will, regarding arrays and nulls. If array null disappears, it's likely object null will also disappear. Both of these worry me. But if indeed they are just bugs, then why doesn't Walter say so?

That could be said about lots of things ;-)

>>>As Regan has argued (and now I'm a believer), the null
>>> special value is very useful, and we should keep this distinction (vs. empty).
>>
>>Absolutely! Both are good and distinct concepts.
> 
> In theory, yes. In D, not entirely. Please see below:

I distinctly remember reading a note from Walter saying that he was
surprised that setting the length to zero also nulled the pointer. He has
code in Phobos that assumes that this is not the right behavior.

>>> Perhaps you can clarify whether this is going to happen properly or not.
>>> 
>>> In my view, proper array nulls do _not_ exist.
>>
>>But they do. If array.ptr is null, then array is a null array.
> 
> Why should be have to resort to array.ptr for nullness? Why can't the _array itself_ be null?

Because its like saying, why can't an object instance be null. The array IS an instance. A null array means something different to a null object.

>An object _can_ be null by itself, no need to check an
> "object.ptr". In fact, on a null object .ptr would throw. You have to acknowledge this is a significant difference.

Yes it is a difference. So what? Learn it and move on. This is D, not C/C++.

>>>What we have right now is very
>>> confusing because sometimes we can use the null value and sometimes we can't.
>>
>>Huh? When can't you use it?
> 
> I can't use it when the "bugs" get in my way. And they just so happen to get in the way a lot. I'm working with databases right not, and essentially there's no way to have a string represent a DBNULL, because when I dup an empty string, it _too_ becomes NULL.

Yep. Been there, done that. I just wish he'd fix this bug. Its very easy to fix.

>>> It is also fickle because the null value is tied to the pointer.
>>
>>Huh? Of course it is. What else could it be?
> 
> It could be, say, a simple boolean. Or, it could be, say, like objects. Objects don't rely on object.ptr, why should arrays?

Because they are arrays and not class instances.

>>> Regan thinks that
>>> you are planning on merging emptiness and existence into one (a bad thing).
>>
>>I don't think that Walter is planning on this.
> 
> I certainly hope not, but how can we be sure? This is why I asked.
> 
>>> Some of the problems (not technically "bugs"):
>>> - array.length = 0 sets the pointer to null.
>>
>>This is a bug and Walter has said so. He will fix this.
> 
> Just out of curiosity, is there a post that I could read regarding this? I'd really like to see what he said.

Yes, but I don't know how to search for it.

>>> - static int[0] is not null, but new int[0] is.
>>
>>static arrays cannot be null (not reference anything) by their very nature.
> 
> Their very nature says nothing of nullness. It just means allocate in a different area of memory.

By 'static' are you meaning non-dynamic arrays or single-instance arrays. For example, which of these lines are static to you?

void func()
{
  int[] a;
  int[1] b;
  static int[1] c;
}

To me, I only call array 'c' a static array. The array 'a' is a dynamic(-length) array and array 'b' is a fixed-length array. But array 'a' and 'b' are not single-instance arrays. After checking with the usage in D itself, it seems that D uses static ambiguously when it comes to arrays.

>>A static array must always reference some RAM somewhere.
> 
> Why? Why can't it reference null? Conceptually, I don't see a problem. But maybe this is one of the "technical limitations" I was talking about.

Because static arrays are allocated RAM at compile time and they reference themselves. Because they exist they can't be null. Given ...

  static int[1] x;

You will find that ...

  x.ptr == &x

And because &x will always return a non-null, then x.ptr is always
non-null.


-- 
Derek Parnell
Melbourne, Australia
30/07/2005 2:09:05 AM
July 29, 2005
Hi Derek,

>> Sure, they both "work" to a certain extent. But if you try to access a property on a null object -that's illegal. On a null array, it's not. That's not a null array. That's a pseudo-null reference that never goes away.
>
>Yes ... but so what? Is that behavior hurting anyone?

Well, if we look at it that way, then everything becomes a lot easier, doesn't it? Whether it hurts anyone or not is not the way to build a language. There are things that are correct, and those that are not. Arrays, as it stands, _break_ reference semantics. I don't know whether this hurts anyone or not, but it is certainly inconsistent, and it is my view simply incorrect.

>Object properties are user-defined and all take 'this' as an automatic argument, thus they require an instance. Array properties are built-in to D. The 'array' is the instance.

Technically speaking, this is half-right:

# char[] a = "hello"; // whatever.
# char[] b = a; // This is a reference to a.
# b.length = 2; // Now b became its own instance.

Semantically speaking, I think this is wrong.

int[] arr    // This is the reference.
= new int[0] // _This_ is the array.

>Don't confuse its elements as being
>instances of the array.

I never did. Elements are fine the way they are. But by your logic, perhaps we should be able to do this:

# char[] nullArray = null;
# nullArray[5]; // valid, but returns null, since there is no item.

Or wouldn't you say this is wrong? Does it "hurt" anyone? Nah. In fact, it will help by preventing those annoying ArrayOutOfBounds thingamajjigs.

>Thus 'int[] array;' creates an instance of the array even though it has no data yet. And because the instance exists, you can use its properties.

This just doesn't make sense. int[] array creates a _reference_. That's the very definition of a reference. That's why arrays are reference-types. It's essentially a nicer version of a pointer.

>There is no inconsistency here. I think you have merged object nullness and array nullness into the same meaning. But they are not the same thing. A null object is a placeholder into which you can later store a reference to an object instance. A null array is an instance of an array that has no data.

If this is so, then arrays can't be called reference types. That's not what references do. Frankly, I wouldn't know what the heck to call arrays if these are the semantics we're supposed to follow.

>You use the phrase 'dumbed-down' where as I see this as a smart thing. And just because the coder does some weirdo foreach() statement, doesn't mean the language is wrong.

It's not whether it's a smart-thing or a dumb thing. I see it as being a dumbing down, but that's not the point. The point is that it muddies the distinction between _empty_ and _non-existant_. Conceptually, you can't iterate thru a non-existant array. It doesn't exist. It should be a bug.

Conceptually, you _can_ iterate thru an empty array. It exists and has no elements, thus no iteration would happen, but the construct is valid.

With this "smart" feature, the two are fused into one. Empty and Non-existant can _both_ be iterated thru. They both produce the same result: 0 iterations. This I think is incorrect.

0 iterations == 0 elements // correct
0 iterations == null       // incorrect

>And by the way, you code example does produce a
>compiler error - " foreach: void* is not an aggregate type". To get it to
>compile you have to use 'foreach(char c; cast(char[])null) {};' which shows
>to me that somebody with a big stick needs to chat with the coder.

Sorry, my bad. I don't have access to DMD. But you know what I meant:

char[] nullArray = null;
foreach (char c; nullArray) { /* do something */ }

>>>> 2) Is it a technical limitation (for now)?
>>>Is *what* a limitation?
>> 
>> The distinction I made before between the nullness of objects (which is
>> complete), and that of arrays (which is incomplete). I asked this because
>> perhaps it was due to the way D properties worked (more like functions), or
>> somesuch, meaning, it was not _intended_ to be that way.
>
>But arrays are not classes or objects. So what if they are both reference types. They are still not the same beasties.

Certainly they are not the same. But they both have the same "nature" as you put it, -references. As it is, arrays are breaking reference behaviour too, as my example above showed. Or do you know agree that arrays are reference types either?

>I distinctly remember reading a note from Walter saying that he was surprised that setting the length to zero also nulled the pointer. He has code in Phobos that assumes that this is not the right behavior.

This is all very circumstantial, but oh well...

>>>> Perhaps you can clarify whether this is going to happen properly or not.
>>>> 
>>>> In my view, proper array nulls do _not_ exist.
>>>
>>>But they do. If array.ptr is null, then array is a null array.
>> 
>> Why should be have to resort to array.ptr for nullness? Why can't the _array itself_ be null?
>
>Because its like saying, why can't an object instance be null. The array IS an instance. A null array means something different to a null object.

Once again, this view is incorrect. An array can be both a reference and an instance.

int[] arr    // This is the reference.
= new int[0] // _This_ is the array.

>>An object _can_ be null by itself, no need to check an
>> "object.ptr". In fact, on a null object .ptr would throw. You have to acknowledge this is a significant difference.
>
>Yes it is a difference. So what? Learn it and move on. This is D, not C/C++.

Why learn and move on from something that is clearly wrong? I'd rather fix it, thank you very much ;)

>Yep. Been there, done that. I just wish he'd fix this bug. Its very easy to fix.

It's very frustrating. I would sue this bug if I could. :p

>>>> It is also fickle because the null value is tied to the pointer.
>>>
>>>Huh? Of course it is. What else could it be?
>> 
>> It could be, say, a simple boolean. Or, it could be, say, like objects. Objects don't rely on object.ptr, why should arrays?
>
>Because they are arrays and not class instances.

Assuming the _wrong_ semantics stay in place, why couldn't we do something like: array.isNull or array.exists as a simple boolean check, instead of the more complicated array.ptr that is riddled with "bugs?"

That way we separate the implementation details (how the array.ptr is handled
internally), from the semantics (whether the array exists or not).

>>>> Regan thinks that
>>>> you are planning on merging emptiness and existence into one (a bad thing).
>>>
>>>I don't think that Walter is planning on this.
>> 
>> I certainly hope not, but how can we be sure? This is why I asked.
>> 
>>>> Some of the problems (not technically "bugs"):
>>>> - array.length = 0 sets the pointer to null.
>>>
>>>This is a bug and Walter has said so. He will fix this.
>> 
>> Just out of curiosity, is there a post that I could read regarding this? I'd really like to see what he said.
>
>Yes, but I don't know how to search for it.

Well, perhaps he can clarify his position now.

----

Re:Static
<snip>
>By 'static' are you meaning non-dynamic arrays or single-instance arrays.
<snip>

It doesn't matter. I don't understand why you bring technical implementation details to the discussion, when I am talking solely about the concept.

Conceptually, whether an array is static or not has no effect on whether the array can exist or not. Static changes allocation semantics, _not_ existance semantics. That's my point.

Now, if you tell me: We can't have that because of a technical limitation, then I would understand. However, the point in your memory argument can be fixed the way Regan and others have mentioned.

Cheers,
--AJG.


July 29, 2005
Hi Ben,

>>>Do you want all operations on a null array, such as:
>>>
>>># int[] array = null;
>>># int len = array.length; // <-- segfault
>>>
>>>to segfault (to throw a NullPointerException in managed environments parlance), like they do on a null object reference?
>>
>> For starters, yes. Why should objects be different than arrays when they
>> are
>> both reference types? This is inconsistent IMHO.
>
>I think you'll have a hard time getting lots of support for that. I much prefer the current behavior and I bet there is lots of existing D code that assumes one can test the length of an array at any time. Since an array is not an object I see no problem with the "inconistency" - an array is an array.

I agree that there won't be much support for this. I don't suppose it will change. But ideally that's what the behaviour should be. Say you had no D code written at the moment, would you support the change?

On the other hand, would you support access to object properties that don't require an instance from a null reference? It's the same thing, isn't it? Yet aren't those illegal at the moment? (don't have DMD at hand).

Cheers,
--AJG.

"What is popular is not always right; what is right is not always popular."



July 29, 2005
"AJG" <AJG_member@pathlink.com> wrote in message news:dcdqig$1us6$1@digitaldaemon.com...
> Hi Ben,
>
>>>>Do you want all operations on a null array, such as:
>>>>
>>>># int[] array = null;
>>>># int len = array.length; // <-- segfault
>>>>
>>>>to segfault (to throw a NullPointerException in managed environments parlance), like they do on a null object reference?
>>>
>>> For starters, yes. Why should objects be different than arrays when they
>>> are
>>> both reference types? This is inconsistent IMHO.
>>
>>I think you'll have a hard time getting lots of support for that. I much
>>prefer the current behavior and I bet there is lots of existing D code
>>that
>>assumes one can test the length of an array at any time. Since an array is
>>not an object I see no problem with the "inconistency" - an array is an
>>array.
>
> I agree that there won't be much support for this. I don't suppose it will
> change. But ideally that's what the behaviour should be. Say you had no D
> code
> written at the moment, would you support the change?

no

> On the other hand, would you support access to object properties that
> don't
> require an instance from a null reference?

no (assuming you aren't referring to static class properties)

> It's the same thing, isn't it?

no

>Yet aren't those illegal at the moment? (don't have DMD at hand).

yes

> Cheers,
> --AJG.
>
> "What is popular is not always right; what is right is not always popular."


July 29, 2005
Hi Ben,

Ok, I don't think I said exactly what I meant before. Let's look at this piece by piece:

1) Arrays are ("in theory") reference types.
2) Objects are reference types.
3) Arrays are not objects.
4) So, even though Arrays and Objects are different, they share (or should)
reference semantics.

I believe most of us can agree up to here.

My overall point is that D is not keeping its promise regarding Arrays obeying reference semantics. Whether this is good or not is debatable, but at least it should be noted. Do you agree that D's arrays break reference semantics?

Thanks,
--AJG.







July 29, 2005
"AJG" <AJG_member@pathlink.com> wrote in message news:dcdtq5$21q6$1@digitaldaemon.com...
> Hi Ben,
>
> Ok, I don't think I said exactly what I meant before. Let's look at this
> piece
> by piece:
>
> 1) Arrays are ("in theory") reference types.

no - an array is two pieces of information: (1) a pointer to the data and (2) a length. The pointer can be considered a reference but the length information is definitely not manipulated by reference. For example

  int[] a,b;
  a.length = 10;
  b = a;
  b.length = 100;
  assert( a.length == 10 );

If arrays had "pure" reference semantics in the same way objects do then one would expect a.length == 100. In casual conversations one often says arrays have reference semantics but the unspoken assumption is that one is talking about the data pointer. This can confuse people who aren't used to D array semantics.

> 2) Objects are reference types.
> 3) Arrays are not objects.

these I agree with.

> 4) So, even though Arrays and Objects are different, they share (or
> should)
> reference semantics.

naturally I disagree given 1).

> I believe most of us can agree up to here.
>
> My overall point is that D is not keeping its promise regarding Arrays
> obeying
> reference semantics. Whether this is good or not is debatable, but at
> least it
> should be noted. Do you agree that D's arrays break reference semantics?

The length information is not manipulated with reference semantics. I think this is a good design choice that shouldn't be changed. I agree it is different than object behavior but that's well worth the benefits of the current system. If there are statements in the D doc that say "arrays have reference sematnics" I think they should be changed to be more accurate and say something like "the array data has reference semantics". It's common to ignore the length field when you are casually talking about arrays.


July 29, 2005
I've been following this, but have as of yet been unable to express my problem with this whole issue. My feelings line up with yours ben.

Arrays are not pointers, nor are they reference types.  In C, pointers happen to be able to be dereferenced with the array index operator, but that's a side effect of implementation.  If something is a true array, I think there is a reasonable expectation that the array always points to some data.

array != null; //should always be true; Especially in the case of D where the array is really a structure with a ptr and a length.


However, if for some reason you need the reference symantics, those are not denied to you.  You're free to do this:

int* array = new int[100];

My 2 cents
-Sha

In article <dcdur3$232d$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>"AJG" <AJG_member@pathlink.com> wrote in message news:dcdtq5$21q6$1@digitaldaemon.com...
>> Hi Ben,
>>
>> Ok, I don't think I said exactly what I meant before. Let's look at this
>> piece
>> by piece:
>>
>> 1) Arrays are ("in theory") reference types.
>
>no - an array is two pieces of information: (1) a pointer to the data and (2) a length. The pointer can be considered a reference but the length information is definitely not manipulated by reference. For example
>
>  int[] a,b;
>  a.length = 10;
>  b = a;
>  b.length = 100;
>  assert( a.length == 10 );
>
>If arrays had "pure" reference semantics in the same way objects do then one would expect a.length == 100. In casual conversations one often says arrays have reference semantics but the unspoken assumption is that one is talking about the data pointer. This can confuse people who aren't used to D array semantics.
>
>> 2) Objects are reference types.
>> 3) Arrays are not objects.
>
>these I agree with.
>
>> 4) So, even though Arrays and Objects are different, they share (or
>> should)
>> reference semantics.
>
>naturally I disagree given 1).
>
>> I believe most of us can agree up to here.
>>
>> My overall point is that D is not keeping its promise regarding Arrays
>> obeying
>> reference semantics. Whether this is good or not is debatable, but at
>> least it
>> should be noted. Do you agree that D's arrays break reference semantics?
>
>The length information is not manipulated with reference semantics. I think this is a good design choice that shouldn't be changed. I agree it is different than object behavior but that's well worth the benefits of the current system. If there are statements in the D doc that say "arrays have reference sematnics" I think they should be changed to be more accurate and say something like "the array data has reference semantics". It's common to ignore the length field when you are casually talking about arrays.



July 29, 2005
Hi,

Well, this is certainly an interesting development. So, to recap, arrays in D are not reference types. I was always under the impression that they were. This is very saddening to me.

Is this correct? Walter, could you clarify this?

>> 1) Arrays are ("in theory") reference types.
>
>no - an array is two pieces of information: (1) a pointer to the data and (2) a length. The pointer can be considered a reference but the length information is definitely not manipulated by reference. For example

What about .dup, .sort, .reverse, .sizeof?
Do those have reference semantics or not?

>If arrays had "pure" reference semantics in the same way objects do then one would expect a.length == 100. In casual conversations one often says arrays have reference semantics but the unspoken assumption is that one is talking about the data pointer. This can confuse people who aren't used to D array semantics.

Yes, arrays semantics are definitely weird. I was hoping they were references and that .length was simply buggy, but perhaps it's by design. In addition, IMO this "unspoken assumption" is not mentioned anywhere in the docs.

>> My overall point is that D is not keeping its promise regarding Arrays
>> obeying
>> reference semantics. Whether this is good or not is debatable, but at
>> least it
>> should be noted. Do you agree that D's arrays break reference semantics?
>
>The length information is not manipulated with reference semantics. I think this is a good design choice that shouldn't be changed.

Why is it a good design choice? Forget about legacy for a second. Wouldn't it be much simpler, more consistent and less confusing to make arrays pure reference types? It would eliminate a lot of the various special cases that we have to deal with given the current convoluted semantics. It would also align their behaviour to that of objects, much like a struct's behaviour is aligned to that of a primitive.

>I agree it is different than object behavior but that's well worth the benefits of the current system.

Like what? Which benefits?

>If there are statements in the D doc that say "arrays have reference sematnics" I think they should be changed to be more accurate and say something like "the array data has reference semantics". It's common to ignore the length field when you are casually talking about arrays.

Or perhaps the arrays themselves could be changed to reference types? ;)

Cheers,
--AJG



July 29, 2005
Hi,

>I've been following this, but have as of yet been unable to express my problem with this whole issue. My feelings line up with yours ben.
>
>Arrays [...] are not reference types.

If this is so, it is unfortunate. I'm asking Walter to clarify this, that is all.

>In C, pointers happen to
>be able to be dereferenced with the array index operator, but that's a side
>effect of implementation.  If something is a true array, I think there is a
>reasonable expectation that the array always points to some data.

This is not a reasonable expectation. We are talking about two things here:
a) Existance.
b) Emptiness.

Even in C, you can express both. I'm asking whether Walter thinks we should do that in D or not.

Some examples (of the 3 possible cases):

char[] string = "hi"; // non-null non-empty array.
char[] empty  = "";   // non-null empty array.
char[] cnull  = null; // null array.

>array != null; //should always be true; Especially in the case of D where the array is really a structure with a ptr and a length.

This is not the case in D. array != null is sometimes false, because it's comparing the pointer. This is the very thing that allows an array to be non-existant (a true, NULL array). Thus, that was my original question to Walter, whether we should rely on this behaviour or if he's planning on phasing it out.

>However, if for some reason you need the reference symantics, those are not denied to you.  You're free to do this:
>
>int* array = new int[100];

Yes, there's nothing like regressing a couple of decades ;) I think one of D's design goals was to make pointer use unnecessary. Using a pointer you lose safety, lose info (.length, etc.) and lose functionality. This is not a valid solution, IMHO.

Cheers,
--AJG.


July 29, 2005
"AJG" <AJG_member@pathlink.com> wrote in message news:dce24h$272t$1@digitaldaemon.com...
> Hi,
>
> Well, this is certainly an interesting development. So, to recap, arrays
> in D
> are not reference types. I was always under the impression that they were.
> This
> is very saddening to me.
>
> Is this correct? Walter, could you clarify this?
>
>>> 1) Arrays are ("in theory") reference types.
>>
>>no - an array is two pieces of information: (1) a pointer to the data and (2) a length. The pointer can be considered a reference but the length information is definitely not manipulated by reference. For example
>
> What about .dup, .sort, .reverse, .sizeof?
> Do those have reference semantics or not?

Yes - they "have reference semantics" in the sense that they act on the data (though in the case of .dup and .sizeof the reference/value semantics is irrelevant).

>>If arrays had "pure" reference semantics in the same way objects do then
>>one
>>would expect a.length == 100. In casual conversations one often says
>>arrays
>>have reference semantics but the unspoken assumption is that one is
>>talking
>>about the data pointer. This can confuse people who aren't used to D array
>>semantics.
>
> Yes, arrays semantics are definitely weird. I was hoping they were
> references
> and that .length was simply buggy, but perhaps it's by design. In
> addition, IMO
> this "unspoken assumption" is not mentioned anywhere in the docs.

The first sentance of http://www.digitalmars.com/d/arrays.html section Dynamic Arrays says "Dynamic arrays consist of a length and a pointer to the array data." I agree, though, that the doc needs to emphasize this more. I added some feedback to the Wiki about arrays asking for examples illustrating how array assignment works.

>>> My overall point is that D is not keeping its promise regarding Arrays
>>> obeying
>>> reference semantics. Whether this is good or not is debatable, but at
>>> least it
>>> should be noted. Do you agree that D's arrays break reference semantics?
>>
>>The length information is not manipulated with reference semantics. I
>>think
>>this is a good design choice that shouldn't be changed.
>
> Why is it a good design choice? Forget about legacy for a second. Wouldn't
> it be
> much simpler, more consistent and less confusing to make arrays pure
> reference
> types? It would eliminate a lot of the various special cases that we have
> to
> deal with given the current convoluted semantics. It would also align
> their
> behaviour to that of objects, much like a struct's behaviour is aligned to
> that
> of a primitive.

It would be very annoying to have to check for null before asking if an array length is zero. Plus the whole design of slicing would need to be redone and probably would lose much of the efficiency it has today. I view an array as much closer to a struct than an object: an array is just like a struct with a pointer field and a length field. That's the simplest description of what an array is. Comparing them to objects is the wrong analogy.

>>I agree it is
>>different than object behavior but that's well worth the benefits of the
>>current system.
>
> Like what? Which benefits?

see above - checking all the time for null would be very annoying. Almost all the time with arrays one cares if the length is zero and making people check for null before asking that question is error-prone. See Java for examples of making people check for null before asking for the length.

>>If there are statements in the D doc that say "arrays have
>>reference sematnics" I think they should be changed to be more accurate
>>and
>>say something like "the array data has reference semantics". It's common
>>to
>>ignore the length field when you are casually talking about arrays.
>
> Or perhaps the arrays themselves could be changed to reference types? ;)

Sure - one can change anything in D if the tradeoffs are worth it. I happen to believe D's dynamic array semantics are an excellent balance of tradeoffs.