On Sunday, January 08, 2012 14:57:51 simendsjo wrote: > On 08.01.2012 14:40, Jonathan M Davis wrote: > > On Sunday, January 08, 2012 14:24:32 simendsjo wrote: > >> Thanks for your clarifications. > >> > >> Does this mean even this is undefined? > >> aa["a"] = new C(); > >> auto c = "a" in aa; > >> aa["b"] = new C(); > >> // Using c here is undefined as an element was added to aa > > > > Yes. Depending on the current implementation of AAs and the state of aa > > when "b" is added to it, c could still point to exactly what it did > > before, or aa could have been rehashed, which could move any or all of > > its elements around, in which case who knows what c points to. > > > > - Jonathan M Davis > > Thanks! You've saved me a couple of future bugs :)
No problem. It's a bit like how an array could be reallocated after you append to it, which causes slices to no longer point to that array, except that unlike the slice the pointer may not point to valid memory. Given that it's managed by the GC, it probably isn't pointing to complete garbage, but it could be used for something else now. In general, if you insert or remove elements from a container, you must be very careful about any references to the data within the container - be they pointers to elements in the container, or iterators or ranges for the container. That's why std.container has the stable functions. They guarantee that the container's existing ranges don't get invalidated when they're called, whereas the ones that aren't stable make no such guarantees. The issues with in are just one of the manifestations of the more general issue. - Jonathan M Davis