[:] as empty associative array literal, plus warning for null

[Jonathan M Davis]

On Thursday, July 04, 2013 08:41:47 Andrei Alexandrescu wrote:
> On 7/4/13 8:02 AM, Regan Heath wrote:
> > On Thu, 04 Jul 2013 15:35:30 +0100, Andrei Alexandrescu
> > 
> > <SeeWebsiteForEmail at erdani.org> wrote:
> >> On 7/4/13 6:32 AM, Steven Schveighoffer wrote:
> >>> I would not be opposed to a pull request that made [] be non-null, as
> >>> long as it doesn't allocate.
> >> 
> >> What would be the benefits?
> > 
> > Being able to naturally specify a non-null empty array (literal) such
> > that...
> > 
> > char[] n = null;
> > char[] e = [];
> > 
> > assert(n is null)
> > assert(e !is null);
> 
> And what would be the benefit of that?

Making the distinction between null and empty cleaner. There are plenty of 
cases in CS in general where distinguishing between null and empty is useful, 
but unfortunately, the way we've gone about implementing null and empty with 
arrays in D tends to blur to the point that it's kind of iffy to use null as 
something distinct from empty. You can do it for simple stuff if you're careful 
(like explicitly returning null from a function), but it's very easy to end up 
with an array that's empty when you want null or vice versa. One prime case of 
this is [] vs null. [] is supposed to indicate an empty array, but it results 
in a null one, which not only helps blur the line between null and empty, but 
it makes it so that (similar to AAs), there's no clean way to simply declare 
an empty array. Now, because of how much empty and null gets blurred with 
dynamic arrays, you don't generally end up caring much about being able to 
declare an empty, non-null array as you do with AAs, but a lot of that is 
simply because it's arguably too risky to try and distinguish between null and 
empty with arrays even if you wanted to (because of how easy it is to get one 
when you wanted the other and how they act almost - but not quite - the same).

- Jonathan M Davis