at last I actually found a good reason why non null zero length arrays should exist (and a way to make them).

currently
Obj[] foo = new Obj[0];
( foo === null ) is true
Obj[] foo = new Obj[1];
foo.length = 0;
still ( foo === null ) is true

howevery with a little hacking you can do it
Obj[] makeZeroLengthArray() {
	Obj[] ar = new Obj[1];
	(cast(int*)&ar)[0] = 0;
	return ar;
}
works, and its passable and retains its non null status and 0 length :)

the returned array has a length of 0 but is not null

the reason I want this is to do the following;

I want to define a tree walking class that allows a callback if a specific pattern exists within the tree
the pattern is defined as the class at the root and then an array of what the children patterns should be (null meaning any/or none) a zero length array to mean no children only.

> at last I actually found a good reason why non null zero length arrays should exist (and a way to make them).

Yikes, I'd forgotten about this. I think it doesn't make sense to not allow zero-length arrays

Matthew Wilson wrote:
>>at last I actually found a good reason why non null zero length arrays
>>should exist (and a way to make them).
> 
> 
> Yikes, I'd forgotten about this. I think it doesn't make sense to not allow
> zero-length arrays
> 

this is another case of D being driven by implementation not semantics

Mike Wynn wrote:
> this is another case of D being driven by implementation not semantics

Why not call it a bug? ;)

-eye

Ilya Minkov wrote:
> Mike Wynn wrote:
> 
>> this is another case of D being driven by implementation not semantics
> 
> 
> Why not call it a bug? ;)
> 
> -eye
> 

because it's not a bug, just a missing feature due to the design of D arrays (which are struct of length + pointer) unlike Java, where they are objects (point to a block of data with an embedded length).
so in Java
	int[] ar = new int[n];
is is like the C

typedef struct Ar_s { int length; int data[0] } Ar;
Ar * new_int_array(int n) {
	Ar * ar = (Ar*)malloc( sizeof(Ar) + n ) );
	ar->length = n;
	return ar;
}
the ( ar == null ) check is exactly that

where as D ..
typedef Ar_s { int length; int * data } Ar;
Ar new_int_array( int n ) {
	Ar ar;
	ar.length = n;
	ar.data = (int*)malloc(n);
	return ar;
}
the (ar === null) check is infact (ar.data === null)

as it is common for malloc(0) to return null (how can you allocate 0 bytes) this makes the D zero length non null array a little hard.

either you have to allocate 1 element array (as I did) or use a non null  non valid pointer (you should never be deferencing it as its 0 length)

the latter does effect how to deal with
int[] ar = new int[0];
ar ~= 6;

Mike Wynn wrote:
> Ilya Minkov wrote:
>> Why not call it a bug? ;)

> because it's not a bug, just a missing feature due to the design of D arrays (which are struct of length + pointer) unlike Java, where they are objects (point to a block of data with an embedded length).
> so in Java

[Snipped away - you don't have to explain it to me :)]

> as it is common for malloc(0) to return null (how can you allocate 0 bytes) this makes the D zero length non null array a little hard.

Some implementations make malloc(0) be the same as malloc(1). :))))

Technically allocationg 0 bytes is a slight problem that 2 allocations would begin at the same adress, and thus would impose an ambiguity as to which of the allocations should be freed by "free".

> either you have to allocate 1 element array (as I did) or use a non null  non valid pointer (you should never be deferencing it as its 0 length)

> the latter does effect how to deal with
> int[] ar = new int[0];
> ar ~= 6;

Don't see how this would differ from expanding a non-allocated array - which IMO should be allowed to work...

-eye

"Matthew Wilson" <matthew@stlsoft.org> ha scritto nel messaggio news:bjtf5u$1k57$1@digitaldaemon.com...
> Yikes, I'd forgotten about this. I think it doesn't make sense to not
allow
> zero-length arrays

Agreed. After all, even an empty string an a null string are two different beasts, ain't they?

Ric

"Riccardo De Agostini" <riccardo.de.agostini@email.it> wrote in message news:bk4299$1gi5$9@digitaldaemon.com...
> "Matthew Wilson" <matthew@stlsoft.org> ha scritto nel messaggio news:bjtf5u$1k57$1@digitaldaemon.com...
> > Yikes, I'd forgotten about this. I think it doesn't make sense to not
> allow
> > zero-length arrays
>
> Agreed. After all, even an empty string an a null string are two different beasts, ain't they?

They are. Alas, this is probably an argument in favour of not distinguishing between the two, since the null / empty string has caused myriad confusion (not to mention "incorrectness") in C and C++.

Nonetheless, I cannot believe that an empty array will not be wanted, I've just not (yet) done enough hands-on D to produce a compelling example. However, it seems that the majority of commentators have the same gut feel about the issue that I do.

"Matthew Wilson" <matthew@stlsoft.org> ha scritto nel messaggio news:bk448p$1j2a$1@digitaldaemon.com...
> They are. Alas, this is probably an argument in favour of not
distinguishing
> between the two, since the null / empty string has caused myriad confusion (not to mention "incorrectness") in C and C++.

"Confusion" might as well be the original codename for the C RTL... So let's try not to make "Donfusion". :)

Say you have a function that, given an array of customers (references to instances of a Customer class), returns an array containing references to all customers who owe me money. An empty array means I have to develop (since what I've already done has already been payed for), while a null array means I have to debug (because something must have gone wrong in the function). Obviously enough, a non-empty array just means I have to make some unpleasant phone calls...

Needless to say, the function would use foreach! :)

Ric

In article <bk4bsn$1t6t$1@digitaldaemon.com>, Riccardo De Agostini says...
>
>"Matthew Wilson" <matthew@stlsoft.org> ha scritto nel messaggio news:bk448p$1j2a$1@digitaldaemon.com...
>> They are. Alas, this is probably an argument in favour of not
>distinguishing
>> between the two, since the null / empty string has caused myriad confusion (not to mention "incorrectness") in C and C++.
>
>"Confusion" might as well be the original codename for the C RTL... So let's try not to make "Donfusion". :)
>
>Say you have a function that, given an array of customers (references to instances of a Customer class), returns an array containing references to all customers who owe me money. An empty array means I have to develop (since what I've already done has already been payed for), while a null array means I have to debug (because something must have gone wrong in the function). Obviously enough, a non-empty array just means I have to make some unpleasant phone calls...
>
>Needless to say, the function would use foreach! :)
>
>Ric
>
>

I've been watching this and the "pleading for String" threads, and I guess it's time I embarassed myself (further) by stepping in...

If the main argument against "non-null empty arrays" is due to common problems with character arrays in C (loosely called strings) then making a String type (or class) should settle the situation and all the other types of array can be left alone, including allowing the (perhaps problematic) use of character arrays.

However it's possible (nay, likely!) that I didn't quite follow the arguments
closely enough.

John Boucher -- Quite contrary
The King had Humpty pushed.