On Thursday, July 04, 2013 10:26:09 Andrei Alexandrescu wrote: > The way code should do is use null on the creation side and .empty on > the testing side. Making [] non-null does not change that.
True. But if [] is guaranteed to be non-null, then you have a way to explicitly create empty arrays which are non-null, and then the only ways that you end up with an array that's actually null are via its init value and by actually using null. It makes it easier to actually distinguish between null and empty in your code without accidentally getting the wrong one. > Why do you want so much an empty array that's not null? I can't make > sense of this entire argument. To distinguish between the cases where you have a value, but it's empty, and the cases where you don't actually have a value. It's the same reason why we have std.typecons.Nullable for types that don't have null. Arrays have null, so they shouldn't need Nullable, but if you want to be able to distinguish between null and empty, then you need to be able to be certain that something is null when you mean for it to be null and not null when it's is supposed to have a value, and arrays tend to treat null and empty as almost the same thing, so it becomes easy to screw it up if you're doing anything more complicated than checking whether a function returned null or not. - Jonathan M Davis