Hacker News Reader

Comment by paavohtl | Hacker News Reader

> 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.

View on HN

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.

> 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.

> 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?

Reply on news.ycombinator.com