Hacker News Reader

Comment by kzrdude | Hacker News Reader

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, that is just a value and the compiler and compiler settings determine 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.

View on HN

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

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.

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.

Reply on news.ycombinator.com