null Vs [] return arrays

[Regan Heath]

On Fri, 01 Apr 2011 18:23:28 +0100, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:
> On Fri, 01 Apr 2011 11:52:47 -0400, Regan Heath <regan at netmail.co.nz>  
> wrote:
>> But, in D it seems I cannot do this.  In D I would have to pass an  
>> additional boolean parameter, or add another level of indirection i.e.  
>> pass a string[]*.  The same problem exists in C if I want to pass an  
>> 'int' or any primitive type, I have to pass it as int*, use a boolean,  
>> or invent a 'special' value which means essentially  
>> NULL/not-set/ignored.
>
> assert("" !is null); // works on D.  Try it.

Yes, but that's because this is a string literal.  It's not useful where  
you're getting your input from somewhere else.. like in the other 2 use  
cases I mentioned.

However.. I've realised that in those cases, where you have an input array  
you can slice, eg.
   auto y = "a=123&b=&c=456"
   auto z = y[8..8];

I do get an array 'z', with a non-null ptr.  So, provided D doesn't lose  
this information when I pass it around I am fine.  The other use case may  
be a little more problematic depending on the method used to read the  
input from the keyboard, IIRC one of the methods returns null for a blank  
line of input, which I would have to detect and 'fix' using emptyArray if  
I wanted to pass it to something that cares about the distinction.


>> I'm not too bothered what syntax gets used, provided it was something  
>> that you don't accidently use when you do not want it, and wasn't too  
>> horrible to use as I don't see this as being a very uncommon occurance  
>> (which would warrant/allow ugliness of syntax).  "[]" >> seems logical,  
>> as does "new T[]", both are not "null" so the programmer was obviously  
>> trying to do something other than pass null.
>It's one thing to want an array with a non-null pointer, but it's  
> another thing entirely to want an array with a non-null pointer which  
> points to a valid heap address.

I don't specifically want either of those things.  I just want _some way_  
to represent 'exists but is empty' and for it to be different to 'does not  
exist'.  Currently D's arrays cannot do that, yet a plain old pointer can.


> In my opinion, [] means empty array.  I don't care what the pointer is,  
> as long as the array is empty.  The implementation can put whatever  
> value it wants for the pointer.  If it wants to put null, that is fine.   
> null means I want a null pointer.
> If I had it my way, all array literals would be immutable, and the  
> pointers would point to ROM (even empty ones).  We should not be  
> constructing array literals at runtime.  But my opinion is still that  
> you should not count on the pointer being anything because
> it's not specified what it is.

Sure, I agree with all that, but I still want some way of representing  
both states and detecting both states and the problem is that if the  
language cannot do it at a fundamental level, and requires some weird hack  
or reliance on string literals then when I use any 3rd party library, or  
phobos itself it will tell me null and I will have to guess which state it  
actually means and 'fix' it manually.


>> That seems to work, but it's hideous syntax for something that is not  
>> that uncommon IMO.
>  My opinion is that it is uncommon, but it can be abstracted:
>  template emptyArray(T)
> {
>    enum emptyArray = (cast(T*)0)[1..1];
> }
>  rename as desired.

Not useful if you're getting your input from somewhere else, vs trying to  
create a new empty array.

That said, if I were to want this I'd use the literal instead as it seems  
safer, eg.

template emptyArray(T)
{
    enum emptyArray = cast(T[])""[0..0];
}


> This code seems to disagree with your results for case 5 (dmd 2.052):
>
>      auto x = cast(char[])""[0..0];
>      assert(x.ptr != null); // no failure

Nope, my case 5 had a 'dup' which you're missing.  If I add a new case  
returning a literal as you have there I get the same result as you.  I was  
intentionally avoiding the literal because I knew it would be non-null (I  
believe D null terminates literals) and because I want to be able to  
detect these states on more than just empty string literals.

R

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