Re: When are associative arrays meant to throw a RangeError?

[Ben Davis]

On 18/02/2012 13:22, Daniel Murphy wrote:
"Ben Davis"<ent...@cantab.net>  wrote in message
news:jho2mf$2a1t$1...@digitalmars.com...
Starting with magic initialisation then...

I meant a different magic initialization:
int[int] aa = null;
aa[3] = 7; // aa is magically not null any more

Is it vital that e[nonexistentKey] throw a RangeError, or could it just
always return the type's default value if the key is absent?

This is what it does.

It throws a RangeError. See the examples in my first message in this 
thread. I'm asking if changing the semantics to NOT throw a RangeError 
would be an option.

If you change that, then you can make assignment evaluate the RHS fully
before even creating the LHS entry, and you won't in the process break the
common case where people want to go

count[key]++;
or
array[key]~=element;

without worrying about whether it's the first time for that key or not.


This problem is just a bug in code generation from what I can tell, because
lowering it manually results in the rhs being evaluated first.

import std.stdio;

int* getp()
{
     writeln("1");
     return new int;
}

void main()
{
     *getp() += { writeln("2"); return 1; }();
}

prints:
2
1

I have no idea where this is happening in the compiler.

Interesting - my gut feeling is that associative arrays are syntactic 
sugar and are being rewritten to use other constructs, and that 
rewriting is implementing a different execution order.