Empty VS null array?

Regan Heath regan at netmail.co.nz
Fri Oct 18 03:44:11 PDT 2013


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

> On Fri, Oct 18, 2013 at 01:27:33AM +0200, Adam D. Ruppe wrote:
>> On Thursday, 17 October 2013 at 23:12:03 UTC, ProgrammingGhost
>> wrote:
>> >is null still treats [] as null.
>>
>> blah, you're right. It will at least distinguish it from an empty
>> slice though (like arr[$..$]). I don't think there's any way to tell
>> [] from null except typeof(null) at all. At runtime they're both the
>> same: no contents, so null pointer and zero length.
>
> I think it's a mistake to rely on the distinction between null and
> non-null but empty arrays in D. They should be regarded as
> implementation details that user code shouldn't depend on. If you need
> to distinguish between arrays that are empty and arrays that are null,
> consider using Nullable!(T[]) instead.

This comes up time and again.  The use of, and ability to distinguish  
empty from null is very useful.  Yes, you run the risk of things like null  
pointer exceptions etc, but we have that risk now without the reward of  
being able to distinguish these cases.

Take this simple design:

   string readline();

This function would like to be able to:
  - return null for EOF
  - return [] for a blank line

but it cannot, because as soon as you write:

   foo(readline())

the null/[] case merges.

There are plenty of other such design/cases that can be imagined, and  
while you can work around them all they add complexity for zero gain.

A simple pointer can do this.. string cannot, this is sad.

R

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


More information about the Digitalmars-d mailing list