One of the biggest pain points of immutable in D is that it cannot be used with arrays and associative arrays while still allowing reassignment. The underlying reason for this is that it should be impossible to observe a value of a reference to an immutable type change.

However, with only a slight restatement, this becomes valid: "it should be impossible to observe the value of a reference to an immutable type change, *within the original value's lifetime.*"

Associative arrays work such that assigning a value to an already-existing field performs a reassignment operation. However, there is very little need for them to work that way. They could just as easily invalidate the previous value (ending its lifetime) and instantiate a new one in its place. Holding on to references to associative arrays while performing reassignment is perilous *anyways*, but could (worst-case) easily be supported by reallocating every time that a previous value would be overwritten, if this is something that one wants. Or if the performance and behavioral cost is not worth it, just specify the lifetime of references into associative arrays to end at an overwriting assignment to the field; in other words, make reassignment equivalent to ".remove" (invalidating the reference) followed by an "initial" assignment.

This change alone would greatly enhance the usefulness of immutable data types; in business logic, associative arrays often form the backbone of your data structure.

See title.