Forbid dynamic arrays in boolean evaluation contexts

[Phil Lavoie]

On Monday, 25 March 2013 at 17:44:42 UTC, Jonathan M Davis wrote:
> 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.

I wrote it before reading your post on everything regarding 
length. I realize now it makes less sense, though there is still 
the possibility of having a special case for nulls, I mean, this 
is why Nullable exists in the first place, right?

All I'm saying is, there is no point for me to use Nullable for 
types that I know can be null unless somebody plans on removing 
null for that type. I'm not sure how much clarity doing 
var.isNull vs. var is null is going to add for an already 
nullable type?

Regarding the if(dynamic_array) issue, I am not in favor of 
keeping it. I just think that it currently does exactly what I 
expect from it (though I don't use it), and I'm not sure how much 
changing it would be helpful. I understand that you think it 
should test for length, I'm just saying this maybe ain't the 
predictable behavior for everybody.

Phil