3 ms·

> suddenly I had an ownership error, because `x` was moved by the first match statement How do you propose it should work instead? Disallow using match with ow

> suddenly I had an ownership error, because `x` was moved by the first match statement How do you propose it should work instead? Disallow using match with owned values, so that match never moves? Disallow assigning to a variable where the value has been moved, requiring a new or shadowed variable instead? You could do either of those things, but neither would remove complexity, just move it elsewhere and perhaps cause some new issues. It's easy to complain about complexity, but almost all of it exists for a reason, and hasn't been added just because Rust programmers are "attracted to esoteric topics and arcane knowledge". The implicit behavior you are talking about in this case is the ownership system.

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]

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]