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.