I want to have a pointer to a value in an associative array. Does AA guarantee that the value will remain at the same address all the time unless I remove the corresponding key? I couldn't find any guarantees similar to C++ iterator invalidation in D Language Reference.

No, the AA does not guarantee that the value will remain in the same location. Inserting or removing any keys could cause the AA to resize, which may change the locations of all of its values.

However, you do not have to worry about undefined behavior, because the garbage collector will keep the "stale" copy of the value alive as long as you hold a pointer to it.

On Friday, 29 October 2021 at 17:40:38 UTC, Andrey Zherikov wrote:

No, the AA does not guarantee that the value will remain in the same location. Inserting or removing any keys could cause the AA to resize, which may change the locations of all of its values.

However, you do not have to worry about undefined behavior, because the garbage collector will keep the "stale" copy of the value alive as long as you hold a pointer to it.

This is incorrect, the buckets are each heap allocated. Just the array of bucket pointers would change.

In addition, AAs do not deallocate the key/value pairs ever. You are safe to obtain a pointer to a value and it will stay there, even if you remove the key.

On Friday, 29 October 2021 at 21:00:48 UTC, Steven Schveighoffer wrote:

Who's going to document these implementation details? ;) I mean, if no one, then the above shouldn't be stated. Wouldn't you agree?

Given the premise of the question at hand, it does seem useful to know these. But at least one should stress what is and isn't subject to change (even if unlikely).

On Friday, 29 October 2021 at 21:00:48 UTC, Steven Schveighoffer wrote:

Who's going to document these implementation details? ;) I mean, if no one, then the above shouldn't be stated. Wouldn't you agree?

Given the premise of the question at hand, it does seem useful to know these. But at least one should stress what is and isn't subject to change (even if unlikely).

It should be documented. There isn't a valid way to remove these requirements, even if they are currently just an implementation detail -- code already depends on these properties.

And D is a GC-based language, especially when using AAs. There is no reason to introduce undefined behavior for existing usage.

On Saturday, 30 October 2021 at 11:59:15 UTC, Steven Schveighoffer wrote:

You won't introduce UB by deallocating unreferenced elements, which a given GC may be able to figure out. Therefore I object to "AAs do not deallocate the key/value pairs ever" part. Strongly :) Until such time that such a requirement is indeed set in stone, and not incidental.