empty arrays and cast(bool): WAT

[Timon Gehr]

On 02/19/2012 04:38 AM, Jonathan M Davis wrote:
> On Sunday, February 19, 2012 04:24:46 Timon Gehr wrote:
>>> But the fact that == treats null and [] as the same thing _does_
>>> understandably cloud things a bit.
>>
>> Nothing cloudy about that, that is sane behaviour and I want it to be
>> consistently carried out everywhere. ('is' can still do a binary
>> compare, that is what it is designed to do.)
>
> It's lunacy IMHO. null and empty should _never_ have been conflated. They are
> two separate concepts. _That_ is a major wart in the language IMHO. We would
> have better off to not have null arrays at all than this halfway nonsense.

Agreed. I don't mind having it as a special value, but it should not 
have as far reaching consequences as it does right now.

> But that ship sailed ages ago.
>
>> I can't help myself noticing that you always seem to defend the position
>> that makes the code more verbose.
>
> I hadn't noticed. If that's true, it's probably because it's more explicit.

Ok.

> And with arrays, I don't trust them with regards to this sort of stuff
> precisely because null and empty have been conflated. So, I check for what I
> mean, whether that's null or empty. And I consider code like arr == null to be
> sign that someone doesn't know what they're doing.

Indeed. I have never needed arr == null. Comparing class references to 
null using '==' is illegal. Probably the same could be done for arrays. 
Would also increase consistency.

> Someone who understands how arrays work in D should either be doing arr.empty or arr.length == 0 if
> they're checking for empty and arr is null if they're checking for null.
>
> - Jonathan M Davis

That is true. It is also what worries me. Having cast(bool) evaluate to 
false for empty arrays is intuitive and has massive precedent in other 
programming languages.