I can't easily see what the rules are. Specifically, I'm finding:

Chunk[][char[4]] chunks;
//chunks["DATA"] is an array of Chunk objects, where Chunk is a class.
//I'm using this structure to remember positions of chunks in a file format.

//These both work:
chunks["AAAA"]~=new Chunk();
chunks["BBBB"]=chunks["BBBB"]~new Chunk();

//These all throw RangeErrors
Chunk[] tempVar=chunks["CCCC"]~new Chunk();
if (chunks["DDDD"].length!=1) throw new Exception("");
writefln("%s",chunks["EEEE"]);

//This works and formats the null as "[]"
writefln("%s",cast(Chunk[])null);

So, as far as I can tell, chunks[nonexistentKey] throws a RangeError in most cases, including with ~ in general, but not if the ~ is used for an in-place modification.

My initial expectation would be that every example above would throw a RangeError (except the one that doesn't use 'chunks' at all).

So here are my theories, in the approx order I came up with them:

1=. It's an optimisation accident, and it's meant to throw.

1=. It's a nasty bodge specifically to make assoc arrays usable with modify-assign expressions.

3. It could be a quirk of assignment expression evaluation order. Perhaps the assignment expression FIRST creates an entry in the assoc array using the value type's default value (an empty dynamic array), AND THEN evaluates the RHS, which is able to read the empty array that's just been inserted.

Whatever the case, I couldn't find any documentation on the subject. I looked under associative arrays (obviously), and also under assignment expressions, and also under expression statements just for good measure.

Would appreciate any comments :)

Thanks,

Ben :)

It's 3.  It also has the nasty side effect that throwing while evaluating the rhs leaves the AA with a default-initialized key.

When AA[key] needs to be an lvalue, it gets translated to something like:
*_aa_get_lvalue(AA, key)
which creates the key if it doesn't exist and returns a reference to it.

"Ben Davis" <entheh@cantab.net> wrote in message news:jhn2e7$2urh$1@digitalmars.com...
>I can't easily see what the rules are. Specifically, I'm finding:
>
> Chunk[][char[4]] chunks;
> //chunks["DATA"] is an array of Chunk objects, where Chunk is a class.
> //I'm using this structure to remember positions of chunks in a file
> format.
>
> //These both work:
> chunks["AAAA"]~=new Chunk();
> chunks["BBBB"]=chunks["BBBB"]~new Chunk();
>
> //These all throw RangeErrors
> Chunk[] tempVar=chunks["CCCC"]~new Chunk();
> if (chunks["DDDD"].length!=1) throw new Exception("");
> writefln("%s",chunks["EEEE"]);
>
> //This works and formats the null as "[]"
> writefln("%s",cast(Chunk[])null);
>
> So, as far as I can tell, chunks[nonexistentKey] throws a RangeError in most cases, including with ~ in general, but not if the ~ is used for an in-place modification.
>
> My initial expectation would be that every example above would throw a RangeError (except the one that doesn't use 'chunks' at all).
>
> So here are my theories, in the approx order I came up with them:
>
> 1=. It's an optimisation accident, and it's meant to throw.
>
> 1=. It's a nasty bodge specifically to make assoc arrays usable with modify-assign expressions.
>
> 3. It could be a quirk of assignment expression evaluation order. Perhaps the assignment expression FIRST creates an entry in the assoc array using the value type's default value (an empty dynamic array), AND THEN evaluates the RHS, which is able to read the empty array that's just been inserted.
>
> Whatever the case, I couldn't find any documentation on the subject. I looked under associative arrays (obviously), and also under assignment expressions, and also under expression statements just for good measure.
>
> Would appreciate any comments :)
>
> Thanks,
>
> Ben :)

Daniel Murphy:

> It's 3.  It also has the nasty side effect that throwing while evaluating the rhs leaves the AA with a default-initialized key.

Maybe related to this thread.
A lot of time ago I have added this issue to Bugzilla, I have never received a comment on it, so far:
http://d.puremagic.com/issues/show_bug.cgi?id=3825

Bye,
bearophile

Yes, that's the issue I'm talking about.  In this case no comments means no disagreements.  Unfortunately it requires changes to the AA api/codegen to fix, so it will probably be around until we move AAs completely into druntime.

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:jhn604$5ur$1@digitalmars.com...
> Daniel Murphy:
>
>> It's 3.  It also has the nasty side effect that throwing while evaluating the rhs leaves the AA with a default-initialized key.
>
> Maybe related to this thread.
> A lot of time ago I have added this issue to Bugzilla, I have never
> received a comment on it, so far:
> http://d.puremagic.com/issues/show_bug.cgi?id=3825
>
> Bye,
> bearophile

On Saturday, February 18, 2012 14:46:21 Daniel Murphy wrote:
> Yes, that's the issue I'm talking about.  In this case no comments means no disagreements.  Unfortunately it requires changes to the AA api/codegen to fix, so it will probably be around until we move AAs completely into druntime.

Which should probably be sorted out sooner rather than later given all of the bugs involved.

- Jonathan M Davis

Yeah, but that requires a design that fixes everything, including literals, template arg deduction, magic initialization etc.

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.514.1329537168.20196.digitalmars-d@puremagic.com...
> On Saturday, February 18, 2012 14:46:21 Daniel Murphy wrote:
>> Yes, that's the issue I'm talking about.  In this case no comments means
>> no
>> disagreements.  Unfortunately it requires changes to the AA api/codegen
>> to
>> fix, so it will probably be around until we move AAs completely into
>> druntime.
>
> Which should probably be sorted out sooner rather than later given all of
> the
> bugs involved.
>
> - Jonathan M Davis

On Saturday, February 18, 2012 15:13:38 Daniel Murphy wrote:
> Yeah, but that requires a design that fixes everything, including literals, template arg deduction, magic initialization etc.

Oh, it may not be easy, and it may take some time, but it should probably be one of the higher priorities.

- Jonathan M Davis

On Fri, Feb 17, 2012 at 09:06:20PM -0800, Jonathan M Davis wrote:
> On Saturday, February 18, 2012 15:13:38 Daniel Murphy wrote:
> > Yeah, but that requires a design that fixes everything, including literals, template arg deduction, magic initialization etc.
> 
> Oh, it may not be easy, and it may take some time, but it should probably be one of the higher priorities.
[...]

I agree. AA's are one of the big reasons I chose to learn D. I was very happy to finally have a language that has runtime speed comparable to C++ and has built-in AA's. Sad to say, I've been rather disappointed by the amount of AA related bugs in the current implementation.


T

-- 
MS Windows: 64-bit overhaul of 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand 1-bit of competition.

On 2/18/12 12:39 AM, H. S. Teoh wrote:
> On Fri, Feb 17, 2012 at 09:06:20PM -0800, Jonathan M Davis wrote:
>> On Saturday, February 18, 2012 15:13:38 Daniel Murphy wrote:
>>> Yeah, but that requires a design that fixes everything, including
>>> literals, template arg deduction, magic initialization etc.
>>
>> Oh, it may not be easy, and it may take some time, but it should
>> probably be one of the higher priorities.
> [...]
>
> I agree. AA's are one of the big reasons I chose to learn D. I was very
> happy to finally have a language that has runtime speed comparable to
> C++ and has built-in AA's. Sad to say, I've been rather disappointed by
> the amount of AA related bugs in the current implementation.

That will change.

Andrei

"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.521.1329547094.20196.digitalmars-d@puremagic.com...
>
> I agree. AA's are one of the big reasons I chose to learn D. I was very happy to finally have a language that has runtime speed comparable to C++ and has built-in AA's. Sad to say, I've been rather disappointed by the amount of AA related bugs in the current implementation.
>

Another way of looking at this is that the issues with AAs are one of the bigger implementation problems D has these days - not compiler crashes, wrong code generation, thousands of ice bugs with reasonable looking code... The implementation has come a long way in the last couple of years.