3 ms·
To me it would be conceptually simpler to consider one named variable as analogous to a memory location. So I would not be able to write to assign to a variabl
by skohan 6y ago
To me it would be conceptually simpler to consider one named variable as analogous to a memory location. So I would not be able to write to assign to a variable after a move, because essentially I could read that as "assign some_other_value to the memory location x", which in this case is already owned by the match statement. It seems here that after the assignment, `x` is essentially being implicitly re-declared as a shadowed variable. I have to think in terms of "can the compiler find a way to make this safe" rather than having a more-or-less one-to-one mapping between the code I write and the machine behavior.
- paavohtl 6y ago> To me it would be conceptually simpler to consider one named variable as analogous to a memory location. But that's how it already is! The variable x is conceptually a single memory location within the stack frame. The match statement doesn't own the variable x, it owns its previous contents. It has effectively removed whatever was in x and whatever remains in x's memory location is no longer accessible, but the variable is still there.
- deleted 6y ago[deleted]
- sdht0 6y ago> To me it would be conceptually simpler to consider one named variable as analogous to a memory location. I don't think this will work well in practice. For example, would you want to declare a new variable every time an array is reallocated at a new memory location? Reusing variables has both ergonomic (don't have to think about and manage new names) and conceptual (x may represent the same "thing", e.g., a reallocated array) values. And in this particular case, the compiler will very helpfully tell you what went wrong, so it's not like a programmer will have to hunt down the bug for hours trying to understand what happened. The programmer has to learn this once. Can we then call this a complexity issue then?
- deleted 6y ago[deleted]