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

[Andrei Alexandrescu]

On 7/5/13 2:05 AM, Regan Heath wrote:
> On Thu, 04 Jul 2013 18:26:09 +0100, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>> Why do you want so much an empty array that's not null? I can't make
>> sense of this entire argument.
>
> Suppose you have a web page, suppose it has a text field on it called
> "comment". Suppose you load a pre-existing record from your database and
> populate the page, suppose it had a value for comment, suppose you want
> to set that comment to be blank. you edit and click save.
>
> The code backing this page is going to get a string for "comment", that
> string should be empty but not null.
>
> Why? Because if it were null it would have a different meaning. It would
> mean that the comment field was not present on the page at all, and
> should not be altered.

I find the example tenuous. Even assuming it has merit, it does not 
explain the need for a syntactic _literal_ to fulfill that need.

> There are many such examples.

I am not convinced there are many such examples. I'd call it poor design 
to make it a cornerstone to distinguish between empty arrays that are 
null and empty arrays that are not only non-null, but aren't part of any 
other array!

Let me emphasize the last part. Ironically, there is a potential 
interesting use of empty non-null arrays as anchors: an empty slice 
referring to the interior of an array may be combined with another 
slice, pointer, or length, to create a new, meaningful slice. However, 
the discussed literal does nothing of that kind - it just fabricates a 
slice of an array that does not exist.

> All of them can be worked around by
> various means but these are all more complex and require additional
> containers or variables to represent state.

I would say those are better designs.

> null - does not exist, was not specified.
> empty - exists and was intentionally set to be empty.

Such empty arrays occur as natural reductions from other arrays. Why yet 
another literal for such?

> I think arrays will be most useful if we can treat them like safe
> reference types - this wrappers around the unsafe ptr reference type. To
> do that, we need null/empty to be stable/reliable states.
>
> If not, then array becomes like 'int' and we have to invent a special
> value to represent the null case (or use other containers/variables to
> represent null) like we do for int.

I am not convinced.


Andrei