Empty VS null array?

[Regan Heath]

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

> On Fri, Oct 18, 2013 at 01:32:58PM -0400, Jonathan M Davis wrote:
>> On Friday, October 18, 2013 09:55:46 Andrei Alexandrescu wrote:
>> > On 10/18/13 9:26 AM, Max Samukha wrote:
>> > > *That's* bad API design. readln should be symmetrical to writeln,
>> > > not write. And about preserving the exact representation of new
>> > > lines, readln/writeln shouldn't preserve that, pure and simple.
>> >
>> > Fair point. I just gave one possible alternative out of many. Thing
>> > is, relying on client code to distinguish subtleties between empty
>> > and null strings is fraught with dangers.
>>
>> Yeah, but the primary reason that it's bad design is the fact that D
>> tries to conflate null and empty instead of keeping them distinct
>> (which is essentially the complaint that was made). Whether that's
>> ultimately good or bad is up for debate, but the side effect is that
>> relying on the difference between null and empty ends up being very
>> bug-prone, whereas in other languages which don't conflate the two, it
>> isn't problematic in the same way, and it's much more reasonable to
>> have the API treat them differently.
> [...]
>
> 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.

This describes the empty/not empty distinction.

> There's nowhere in this conceptual
> scheme for such a thing as a "null array" that's distinct from an empty
> array.

And this is the problem/complaint.  You cannot represent specified/not  
specified, you can only represent empty/not empty.

I agree you cannot logically have an existing array that is somehow a  
"null array" and distinct/different from an empty array, but that's not  
what I want/am asking for.  I want to use an array 'reference' to  
represent that the array is non existent, has not been set, has not been  
defined, etc.  This is what null is for.

> 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.

It is not an implementation detail, it's a conceptual difference.  A  
reference type has the power to represent specified/not specified in  
addition to referring to an array which is empty/not empty.  A value type,  
like int, cannot do the same thing without either boxing (into a reference  
type, whose reference can be null) or by giving up one of it's values  
(i.e. 0) and pretending it's something special.

This is what D's string has done with empty, it is pretending that it is  
special and means "not specified", and because it converts null into  
empty, that means we cannot rely on empty really being empty (as in the  
user wants the value set to empty), as it might also be a value the user  
did not specify.

It's actually a fairly simple distinction I want to be able to make.  If  
you get input from a user a field called "foo" may be:
  - not specified
  - specified

and if specified, may be:
  - empty
  - not empty

null allows us the specified/not specified distinction.

Regan

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