memory location is maybe not a great replacement for value in this article. values are preserved when moving them, but the memory location changes. The location doesn't matter for the purpose discussed in the blog post.

Models where the value `1` in `let x = 1` gets a memory location - they unnecessarily mix in details about where the value is stored. In most cases, the value is not stored anywhere, neither stack nor heap etc, it's just a value and the compiler and compiler settings determines what happens next. A common case is that it's constant folded into some operation, so the `1` then doesn't have any relationship to memory at all.

I think the terms used are typical for Rust. Doesn't each language have its own terms? The C standard's object is not the same as Python's object and so on.

"variable" seems untypical for rust. We have "bindings", which are not 100% the same as "variables" (hence maybe GP's feeling of something odd).

Value is OK.

The compiler calls it "variable" so I wouldn't say it's untypical, "variable binding" seems to be synonymous. I think I've seen "binding" used alone within destructuring/matching patterns, but in the end that fulfills the same purpose.

I don't see what's wrong with variable, it's not like Rust does anything special that warrants a different term.

Do you have a quick example for a situation where binding is better than variable in Rust?

The usage of the `@` operator is usually called a binding:

    match value {
        n @ 0..8 => println!("{n}"),
        _ => {},
    }

It lets you bind and use the specific value within a matched range. I don't think I ever used it though, I tend to write something like `n if n<8 => {...}` instead

I'm sure you have used it in things like `if let Some(x) = foo` where x is the binding, then.

I recognize the name binding being used there all the time, but maybe variable would work well in this particular context too?

The reason people say binding is because the words “immutable variable” are an oxymoron. It never makes sense to use variable for immutable bindings; they are not able to be varied. Binding is just the meaning of the word “variable” but without the implied mutability.

This aligns with the fact that the mutability is (syntactically and conceptually) a property attached to the binding, and hence there is a need to talk about bindings generally without implying anything about the mutability. Lots of languages don’t have immutable bindings, all bindings are mutable, so you may as well call them variables in C, Go, etc.

> The reason people say binding is because the words “immutable variable” are an oxymoron.

Mathematics has had immutable variables since long before computers.

"Immutable variable" is not an oxymoron, because the value of a variable can and typically will vary via other means than mutation. The value of a variable is potentially different every time it comes to scope, e.g. whenever a function is called.

Even immutable variables can be just redefined/shadowed. You can't do that with constants.

Usually, you think of the shadowing variable and the shadowed variable as different variables though. They just happen to use the same variable name.

I think you're right that this is the reason why some people avoid that.

I agree! "Resource" instead of "value" and "reference" instead of "variable" would bring this in line with the program logic community, from which many of these ideas spring or draw inspiration from.

Reference can't be used for this article since it has a specific meaning in Rust, i.e the most basic safe pointers, those with the & syntax, are references.

> it uses the terms "variable" and "value" with different meanings than most programmers would use

Have to disagree on this, these are very common words with normal meanings, from the Assignment page on Wikipedia:

> Assignments typically allow a *variable* to hold different *values* at different times during its life-span and scope

https://en.wikipedia.org/wiki/Assignment_(computer_science)

Unless there's something I'm missing, this is exactly how Matt is using those words.

I have recently seen "exclusive" for &mut, instead of "unique" here.

The "value" and "variable" naming is unambiguous though. "Variable" might be problematic for someone that conflates the concepts of reference and value - but that's an issue that should be solved far earlier than ownership.

Exclusive is an interesting description in this context because it describes the semantics of the mut as regards the borrow checker. "mut" in Rust means much more than just "mutable".