Phil Lavoie:

> You think it should check for length to be more programmer friendly,

My proposal is to turn "if(dyn_arr)" into a syntax error.

Bye,
bearophile

On Monday, 25 March 2013 at 16:46:46 UTC, Dmitry Olshansky wrote:
> 25-Mar-2013 20:43, Phil Lavoie пишет:
>> I do believe that, in any case, this form is best:
>> if( arr !is null && !arr.empty )
>>
>
> Now write that one thousand times and count the typos.
>
>> Peace,
>> Phil

A thousand? !arr.empty instead of arr.length? Was that your point?

Timon Gehr:

> Also, IMO null arrays should either be removed or [] should be guaranteed to be non-null.

This is a separated topic. Associative arrays share related problems.

Bye,
bearophile

On Monday, 25 March 2013 at 17:05:31 UTC, bearophile wrote:
> Phil Lavoie:
>
>> You think it should check for length to be more programmer friendly,
>
> My proposal is to turn "if(dyn_arr)" into a syntax error.
>
> Bye,
> bearophile

Yeah, but I also read you were in favor of changing its behavior. I'd say that it would make more sense to remove it than to change its behavior.

However, testing for null is kinda useful :)

Phil

On Mon, Mar 25, 2013 at 08:46:42PM +0400, Dmitry Olshansky wrote:
> 25-Mar-2013 20:43, Phil Lavoie пишет:
> >I do believe that, in any case, this form is best:
> >if( arr !is null && !arr.empty )
> >
> 
> Now write that one thousand times and count the typos.
[...]

What's wrong with just writing: if (arr.length > 0) ?  .length will return 0 both when arr is null and when it's non-null but empty.


T

-- 
Heads I win, tails you lose.

> However, testing for null is kinda useful :)

Scratch that, I thought you were implying something else :)

On Monday, March 25, 2013 17:43:24 Phil Lavoie wrote:
> I do believe that, in any case, this form is best:
> if( arr !is null && !arr.empty )

That's utterly pointless. empty checks that length == 0, and length == 0 if the array is null. It can be useful to check whether an array is null with the is operator for cases where that's used to indicate that a result wasn't found or something like that, but very little cares about the difference between a null array and an empty one, and attempting to treat them as different tends to be very error-prone.

I don't really like how null works with arrays, since it's generally treated as the same as an empty array (including for ==), but that's the way it works in D, and you just have to deal with it. And given how arrays in D work in general, having if(arr) check specifically for null rather than empty is definitely error-prone.

- Jonathan M Davis

On Monday, 25 March 2013 at 17:14:47 UTC, H. S. Teoh wrote:
> On Mon, Mar 25, 2013 at 08:46:42PM +0400, Dmitry Olshansky wrote:
>> 25-Mar-2013 20:43, Phil Lavoie пишет:
>> >I do believe that, in any case, this form is best:
>> >if( arr !is null && !arr.empty )
>> >
>> 
>> Now write that one thousand times and count the typos.
> [...]
>
> What's wrong with just writing: if (arr.length > 0) ?  .length will
> return 0 both when arr is null and when it's non-null but empty.
>
>
> T

Nothing is wrong with that apparently. I was not aware arr.length tolerated null slices. Does it keeps its behavior in unsafe or system mode?

Phil

On 03/25/2013 06:13 PM, Phil Lavoie wrote:
> ...
>
> However, testing for null is kinda useful :)
> ...

It is currently basically useless for array slices, because relying on it is brittle.

On Mon, Mar 25, 2013 at 01:15:59PM -0400, Jonathan M Davis wrote:
> On Monday, March 25, 2013 17:43:24 Phil Lavoie wrote:
> > I do believe that, in any case, this form is best:
> > if( arr !is null && !arr.empty )
> 
> That's utterly pointless. empty checks that length == 0, and length == 0 if the array is null. It can be useful to check whether an array is null with the is operator for cases where that's used to indicate that a result wasn't found or something like that, but very little cares about the difference between a null array and an empty one, and attempting to treat them as different tends to be very error-prone.
> 
> I don't really like how null works with arrays, since it's generally treated as the same as an empty array (including for ==), but that's the way it works in D, and you just have to deal with it. And given how arrays in D work in general, having if(arr) check specifically for null rather than empty is definitely error-prone.
[...]

I think this is all just a storm in a teacup. Just use .length:

	import std.stdio;

	void main() {
		int[] a;
		writeln(a is null);	// prints true
		writeln(a.length);	// prints 0

		a ~= 1;
		a.length = 0;
		writeln(a is null);	// prints false
		writeln(a.length);	// prints 0
	}

So just use "if (a.length > 0)" and you're fine.

The distinction between null and non-null for arrays is, IMO, an implementation-specific detail that should not be relied upon. In my mind, it's the implementation that gets to decide when an array should be null and when it shouldn't. User code had better not be dependent on that kind of detail. If you *really* need to tell the difference, just use Nullable to wrap around the array.


T

-- 
English has the lovely word "defenestrate", meaning "to execute by throwing someone out a window", or more recently "to remove Windows from a computer and replace it with something useful". :-) -- John Cowan