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.
