• FeepingCreature (25/25) Jul 28 2019 One of the biggest pain points of immutable in D is that it
• FeepingCreature (1/1) Jul 29 2019 See title.

FeepingCreature <feepingcreature gmail.com> writes:

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.

FeepingCreature <feepingcreature gmail.com> writes:

See title.