Forbid dynamic arrays in boolean evaluation contexts

[Jonathan M Davis]

On Monday, March 25, 2013 18:34:23 Phil Lavoie wrote:
> On Monday, 25 March 2013 at 17:25:13 UTC, Timon Gehr wrote:
> > 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.
> 
> Well, since they CAN be null, it is at least useful in contracts
> programming.
> void foo( int[] zeSlice ) in {
> assert( zeSlice !is null, "passing null slice" )
> } body {
> 
> }

But why would you care? Almost nothing cares about the difference between a 
null array and an empty array, and unless a function is treating null as 
something explicitly different from empty (which is generally a bad idea), it 
really isn't going to care. All of the various array operations will treat 
them the same.

> Also, imagine, for some reasons, you have that
> string[ ( int[] ) ] mapOfSlices;
> ...
> //initialize all strings, but make sure their corresding slices
> are null, because an empty slice has a different meaning.
> 
> auto aSlice = mapOfSlices.get( "toto", null );
> 
> Still comparing against null, since it has a different meaning,
> maybe null means not found and empty means found but without
> value.

In general, relying on a null array and an empty array having different 
meanings is just begging for trouble. About the only places that I would even 
consider doing so is a member variable which is explicitly set to null to 
indicate the lack of a value (and even then, using Nullable might be a good 
idea for clarity and to reduce the risk of bugs) or a function which returns 
null to indicate something different from a valid value (like not found).

- Jonathan M Davis