On Mon, Oct 21, 2013 at 11:53:44AM +0100, Regan Heath wrote: > On Fri, 18 Oct 2013 18:38:12 +0100, H. S. Teoh > <hst...@quickfur.ath.cx> wrote: [...] > >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.
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. 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). T -- Кто везде - тот нигде.
