I have been working on a change to the definition of mutability in Rust. This is a much smaller change than my previous thought experiments, which were aimed at achieving better parameterization (those are still percolating; I think the best approach is a modified version of the latest proposal where not all types have mutability but type parameters do…but that’s a problem for another day with many complications). The goal of these changes is to enable operations like “freeze” and “thaw”.

OK, I’ve been thinking more about the mutability issue and I think I have found a formulation that I am happy with. The basic idea is that we refactor types like so: T = M T | X | @T | ~T | [T] | {(f:T)*} | int | uint | ... M = mut | const | imm This no doubt looks similar to some of my other permutations. The key difference is that before I separated qualified and unqualified types.

I have been thinking a bit more about the approach to mutability I recently discussed. It seemed a bit too good to be true (too clean) and I think I’ve realized a problem. The problem derives from my definition of types: T = Q U Q = mut | const | imm U = [T] | @T | &T | { (f : T)* } | X | int | uint | .

I am dissatisfied with how mutability is treated in the Rust type system. The current system is that a type is not prefixed mutable; rather, lvalues are. That is, a type T is defined like so: T = [M T] | @ M T | & M T | { (M f : T)* } | int | uint | ... M = mut | const | (imm) Note that there is no type mut int (a mutable integer).