Ask HN: Guaranteed destructive update == reinventing Rust?

In a language with mutability we can mutate parts of an array, like<p><pre><code> a[10] = 3.14 </code></pre> In a pure functional language we cannot do this. Instead we have to in principle create a new array<p><pre><code> a2 = writeArray a1 10 3.14 </code></pre> If a1 is a huge array doing this by making a copy of the whole of a1 would be horribly expensive. We would like the compiler to be able to infer situations where a1 is not used after this statement and actually implement the above statment by mutating a1 is place. This is a destructive update.<p>Because the performance costs of not being able to do a destructive update are so large, we would like the programmer to be able to specify that an update should be destructive, with the compiler throwing an error if if cannot guarantee that that would be the case.<p>To work correctly across function calls the compiler of such a language would have to keep track of which of its arguments a function updates destructively.<p>To keep this analysis tractable across separately compiled modules it seems to me that the programmer would have to be able to write explicit annotations to this effect in the types of functions.<p>But in working out how these annotations should work it seems to me that I&#x27;m ending up reinventing Rust with its system of mutable and immutable references.<p>Is this inevitable?