When are associative arrays meant to throw a RangeError?

[Ben Davis]

On 19/02/2012 03:31, Daniel Murphy wrote:
> "Ben Davis"<entheh at cantab.net>  wrote in message
> news:jhotcm$13ag$1 at digitalmars.com...
>> I've seen some line-blurring between 'null' and 'empty' for dynamic arrays
>> (non-associative). Specifically, I read that array.init returns null for
>> both static and dynamic, but I think I also read that a dynamic array's
>> default value is the empty array. I also observed that null~[1] == [1],
>> and I wondered if actually 'null' becomes an empty array when cast to
>> dynamic array and they're effectively the same thing.
>>
>
> null is not the same thing as an empty array, and I'm not aware of any
> situations where null will implicitly turn into one.
> null == { length == 0, ptr == null }
> empty == { length == 0, ptr != null }
> To make an empty array you (generally) need to allocate memory for it, and
> having this happen implicitly would be a problem.

So 'null' implicitly turns into { length == 0, ptr == null } when 
implicitly cast to the array type (and then it behaves like an empty 
array in many situations). That needs documenting :) Coming from any of 
C, C++ or Java, you would think of null (or NULL) as a pointer to 0, 
which will crash if you try to dereference it in any way - so the fact 
that (null array).length is valid and gives 0 is not obvious!

Thanks for explaining it to me in any case :)

>> If I'm right, then the same could be true for assoc arrays - that 'null'
>> cast to an assoc array type becomes an empty assoc array. Which would
>> explain the magic you're seeing.
>
> This is not what's happening.
>
> With the lvalue AA lookup, the call turns into this:
> *_d_aaGet(&AA, keyinformation ...) = value;
>
> Because it passes a pointer to the actual AA variable, if the AA doesn't
> exist it is created.  All of the rvalue AA methods behave the same for null
> and empty AAs.

... Cool!

> Except for this magic initialization, AAs behave the same as classes - ie a
> reference type.

That's not quite true, because 'length' is passed around by value 
alongside the reference, leading to semantics you could never reproduce 
with classes, unless I'm mistaken.