3 ms·

> I really don't like intermixing mutability with allocation location. Those seem like two completely separate concerns. They're not. The semantics of value ty

> I really don't like intermixing mutability with allocation location. Those seem like two completely separate concerns. They're not. The semantics of value types and reference types are different in the presence of mutation. So if you want uniform object semantics in a language, then objects that can be implemented as values must be immutable. There are many languages that have kept these independent and bifurcated their type system instead (Java, C#), but it's been a source a great deal of pain and frustration (e.g. Java's `int` versus `Integer` awkwardness). Fortunately, there's nothing you can do with mutation that you can't do just as well by modifying and replacing an immutable value in a mutable cell – the compiler implements them the same way. Wrap an immutable in a mutable `Ref` and voila, you've got something equivalent to a mutable value type without exposing completely incompatible semantics in the language.

vvanders 9y ago
> They're not. The semantics of value types and reference types are different in the presence of mutation. I think C#'s overloaded term for "value-types" may have caused you to misinterpret the above. Let me be more clear, if a value lives on the stack or the heap is completely separable from if it is mutable or not, that's my objection. > ... just as well by modifying and replacing an immutable value in a mutable cell In terms of "correctness", sure. In terms of performance see my 300+ float block example above. I shouldn't have to copy, modify, copy when I can just mutate in-place(and be explicit about that rather than relying on language semantics). Also I can seem to find any mention in the docs about Ref's semantics aside from a passing mention in the FFI section.