Empty VS null array?

[Max Samukha]

On Friday, 25 October 2013 at 11:41:38 UTC, Kagamin wrote:
> On Monday, 21 October 2013 at 10:33:01 UTC, Regan Heath wrote:
>> null strings are no different to null class references, 
>> they're not a special case.
>
> True. That's an implementation detail which has no meaning for 
> business logic. When implementation deviates from business 
> logic, one ends up fixing the implementation details everywhere 
> in order to implement business logic. That's why 
> string.IsNullOrEmpty is used.

That's not an implementation detail. Whether "null" is in the set 
of values of a string type and whether it is identical to "empty" 
are fundamental properties of that type. If you define the string 
type to include "null", then "null" should be either identical to 
"empty" in *all cases* or distinct from that in all cases.

D chose to fuse "null" and "empty" together in an inconsistent 
manner, which is a mistake. If we include "null" in the set, then 
either the [] literal should be non-null (and "null" and "empty" 
properly disjoint), or "null" and "empty" should always represent 
the same value. If we exclude it - *then* "null" becomes an 
implementation detail and should be dealt with only via .ptr.

>
>> People seem to have this odd idea that null is somehow an 
>> invalid state for a string /reference/ (c# strings are 
>> reference types), it's not.
>
> That's the very problem: null and empty are valid states and 
> must be treated equally as "no data", but they can't for purely 
> technical reasons.

Whether they are valid states is irrelevant. What matters is 
whether they represent identical values. In D, they are 
unhealthily mixed.