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

[Andrei Alexandrescu]

On 7/4/13 9:51 AM, Jonathan M Davis wrote:
> 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.

I don't see where that derives from at all.

> 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.

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.

> 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.

Why do you want so much an empty array that's not null? I can't make 
sense of this entire argument.


Andrei