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

[Regan Heath]

On Thu, 04 Jul 2013 12:50:54 +0100, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:

> On Thu, 04 Jul 2013 05:25:30 -0400, Regan Heath <regan at netmail.co.nz>  
> wrote:
>
>> On Wed, 03 Jul 2013 19:10:40 +0100, bearophile  
>> <bearophileHUGS at lycos.com> wrote:
>>> Telling apart the literal for an empty array from the literal of a  
>>> empty but not null array is a bad idea that muds the language. And  
>>> thankfully this currently fails:
>>>
>>> void main() {
>>>      int[] emptyArray = [];
>>>      assert(emptyArray !is null);
>>> }
>>
>> As this comes up often you're probably aware that there are people  
>> (like myself) who find the distinction between a null (non-existant)  
>> array and an empty array useful.
>
> Nobody questions that.
> The biggest problem is making if(arr) mean if(arr.ptr) instead of  
> if(arr.length)

Indeed.  IMO if(arr) should mean if(arr.ptr) .. and I thought it did.. or  
did this change at some point?

> What [] returns should not be an allocation. And returning null is a  
> reasonable implementation of that.

Whether there is an allocation or not is secondary.  The primary goal is  
for [] to represent empty, not null.  We have null, if we want to  
represent null we pass null.  What we lack is a way to represent empty.

So, I would say that what [] returns should be empty, and not null.

Secondarily we want to avoid allocation, so .. can we not have [] return a  
slice of length 0 with ptr set to a global pre-allocated single byte of  
memory?

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/