Empty VS null array?

Regan Heath regan at netmail.co.nz
Mon Oct 21 03:58:07 PDT 2013


On Fri, 18 Oct 2013 20:58:07 +0100, H. S. Teoh <hsteoh at quickfur.ath.cx>  
wrote:

> On Fri, Oct 18, 2013 at 02:04:41PM -0400, Jonathan M Davis wrote:
>> On Friday, October 18, 2013 10:38:12 H. S. Teoh wrote:
> [...]
>> > IMO, distinguishing between null and empty arrays is bad
>> > abstraction. I agree with D's "conflation" of null with empty,
>> > actually. Conceptually speaking, an array is a sequence of values of
>> > non-negative length. An array with non-zero length contains at least
>> > one element, and is therefore non-empty, whereas an array with zero
>> > length is empty. Same thing goes with a slice. A slice is a view
>> > into zero or more array elements. A slice with zero length is empty,
>> > and a slice with non-zero length contains at least one element.
>> > There's nowhere in this conceptual scheme for such a thing as a
>> > "null array" that's distinct from an empty array. This distinction
>> > only crops up in implementation, and IMO leads to code smells
>> > because code should be operating based on the conceptual behaviour
>> > of arrays rather than on the implementation details.
>>
>> In most languages, an array is a reference type, so there's the
>> question of whether it's even _there_. There's a clear distinction
>> between having null reference to an array and having a reference to an
>> empty array. This is particularly clear in C++ where an array is just
>> a pointer, but it's try in plenty of other languages that don't treat
>> as arrays as pointers (e.g. Java).
>
> To me, these are just implementation details. Conceptually speaking, D
> arrays are actually slices, so that gives them reference semantics.
> Being slices, they refer to zero or more elements, so either their
> length is zero, or not. There is no concept of nullity here. That only
> comes because we chose to implement slices as pointer + length, so
> implementation-wise we can distinguish between a null .ptr and a
> non-null .ptr. But from the conceptual POV, if we consider slices as a
> whole, they are just a sequence of zero or more elements. Null has no
> meaning here.
>
> Put another way, slices themselves are value types, but they refer to
> their elements by reference. It's a subtle but important difference.
>
>
>> The problem is that D put the length on the stack alongside the
>> pointer, making it so that D arrays are sort of reference types and
>> sort of not. The pointer is a reference type, but the length is a
>> value type, making the dynamic array half and half. If it were fully a
>> reference type, then there would be no problem with distinguishing
>> between null and empty arrays. A null array is simply a null reference
>> to an array. But since D arrays aren't quite reference types, that
>> doesn't work.
> [...]
>
> I think the issue comes from the preconceived notion acquired from other
> languages that arrays are some kind of object floating somewhere out
> there on the heap, for which we have a handle here. Thus we have the
> notion of null, being the case when we have a handle here but there's
> actually nothing out there.
>
> But we consider the slice as being a thing right *here* and now,
> referencing some sequence of elements out there, then we arrive at D's
> notion of null and empty being the same thing, because while there may
> be no elements out there being referenced, the handle (i.e. slice) is
> always *here*. In that sense, there's no distinction between an empty
> slice and a null slice: either there are elements out there that we're
> referring to, or there are none. There is no third "null" case.
>
> There's no reason why we should adopt the previous notion if this one
> works just as well, if not better. I argue that the second notion is
> conceptually cleaner, because it eliminates an unnecessary distinction
> between an empty sequence and a non-existent sequence (which then leads
> to similar issues one encounters with null pointers).

If what you say is true then slices would and could never be null... If  
that were the case I would stop complaining and simply "box" them with  
Nullable when I wanted a reference type.  But, D's strings/slices are some  
kind of mutant half reference half value type, and that's the underlying  
problem here.

Regan

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/


More information about the Digitalmars-d mailing list