Empty VS null array?

[Regan Heath]

On Mon, 21 Oct 2013 17:34:51 +0100, H. S. Teoh <hsteoh at quickfur.ath.cx>  
wrote:

> On Mon, Oct 21, 2013 at 04:41:23PM +0100, Regan Heath wrote:
>> On Mon, 21 Oct 2013 15:01:04 +0100, H. S. Teoh
>> <hsteoh at quickfur.ath.cx> wrote:
>>
>> >On Mon, Oct 21, 2013 at 11:53:44AM +0100, Regan Heath wrote:
> [...]
>> >>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.
>> >
>> >The thing is, D slices are value types even though the elements they
>> >point to are pointed to by reference. If you treat slices (slices
>> >themselves, that is, not the elements they refer to) as value types,
>> >then the problem goes away. If you want to have a *reference* to a
>> >slice, then you simply write T[]* and then it becomes nullable as
>> >expected.
>>
>> True, and that's a pointer, and I am comfortable using pointers..
>> however I worry this will limit the compilers ability to optimise
>> somehow.. and doesn't it make the code immediately un"safe"?
>
> No, pointers are allowed in @safe. What is not allowed is pointer
> *arithmetic* and casting pointers into pointers of different types.

Ah, thanks.

>> >I do agree that the current situation is confusing, though, mainly
>> >because you can write `if (arr is null)`, which then makes you think
>> >of it as a reference type. I think that should be prohibited, and
>> >slices should be treated as pure value types, and all comparisons
>> >should be checked with .length (or .empty if you import std.range).
>>
>> IMO, this would be preferable to the current situation even thought I
>> would rather go the other way and have a reference type.  I can see
>> the argument that it would be safer and easier for most users, even
>> though I do not believe I am in that category.
> [...]
>
> Well, either way would work, though I do prefer treating slices as value
> types. It's just cleaner conceptually, IMO. But I suppose this is one of
> those things in which reasonable people may disagree.

I agree that conceptually if you slice something, you cannot get a 'null'  
reference.  So, a null state for slices makes no sense.  However, most  
people see arrays as slices, slices as arrays - do you?  If so, for arrays  
the same conceptual argument does not apply.  If not, how do we tell we  
have a slice, or an array?  If we can't tell, then we have to check for  
null with both anyway..

R

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