Bug 1886 – Inserting into an AA of structs with opAssign results in ArrayBoundsError

Inserting into an associative array with structs as value types results in a runtime error, as soon as the struct defines an opAssign. Structs without opAssign work fine. The code below will abort at runtime with an ArrayBoundsError exception: ----------------- struct S { void opAssign( in S s ){} } int main() { S[string] aa; aa["test"] = S(); // throws ArrayBoundsError return 0; } ----------------- Error: ArrayBoundsError bug_aaassign.d(8)

This bug still exists (2.023) and makes it impossible to use a Variant as the value in an associative array, which is one of the most important uses for it. However, the error message has changed to "core.exception.RangeError@test(16): Range violation".

Its not adding just opAssign. Having post-blit in a struct can do it too. Documentation on struct in Associative Arrays in D2 is out of date. Probably because it mostly does not work. To return a pointer to the struct have to take address of this struct pblit { int x; pblit* opAssign(ref const pblit S) { this.x = S.x; } this(this) { } ~this() { } } void main(char[][] args) { pblit[string] map; string[pblit] rmap; pblit val; val.x = 12; rmap[val] = "test"; // this works map["test"] = val; // oops! range error }

We are now 2.037 and still not fixed. The documentation on D2.0 Associative Arrays with struct is wrong. Adding the post-blit still allows the struct to be used as key, but not a value. This is wierd. What is the approved opAssign example return type now? pblit opAssign(ref const pblit S) { this.x = S.x; return this; // return a value } -- OR --- pblit* opAssign(ref const pblit S) { this.x = S.x; return &this; // this is a struct! }

Sorry to split into 3 bits. When I press tab the focus goes to the submit button. I stepped thru the x86 code generated in the debugger using Visual Studio 2008 after conversion with cv2pdb -- great tool. In the noblit case :- The code calls __aaGet the arguments are the key, TypeInfo_Aa@__init, and address of the map structure. An address? is returned in EAX, which is checked for null, The value of nval is directly blitted to the returned address. __aaGet does the checking if the key points to existing value, and allocates memory for new value as required. In the postblit case the generated code seems to miss the point entirely. The code initially makes a temporary copy of val. and calls the postblit constructor, which calls this(this). --> @postblit__cpctor --> postblit@__postblit. Why is a prior temporary copy required, when one hopes that its the map that is going to provide the final destination? From the temporary copy, it then pushes the bits value of the temporary (not the address!), then the key, then TypeInfo_Aa@__init, and address of map. The code then calls __aaGetRvalue ( not __aaGet ) __aaGetRvalue gives up very quickly, failing its first check. It pushes registers, and then checks the address in [esp+18h]. This being null, it pop-exits with null as the result in eax. Obviously __aaGetRvalue is expecting something else to be setup. Presumably if __aaGetRvalue actually worked, it would just reblit the value in the temporary to the memory it allocated or found, without calling postblit again. I would like to see ideally. No temporary copy made initially. The map lookup able to allocate or find memory for the key. The address returned. The copy made and then post-blit called. Failing that , please fix up __aaGetRvalue so it does the right thing.

Duplicate of bug 2451. However there is some useful information in the comments for this bug.

The patch for bug 2451 fixes this. Clearly a duplicate. *** This issue has been marked as a duplicate of issue 2451 ***