"Freezing" seems confusing

[marcoow]

I'm just going through Rust by example and was wondering about "Freezing" when I got to that. It seems what happens in the example

fn main() {
    let mut _mutable_integer = 7i32;

    {
        let _mutable_integer = _mutable_integer;

        _mutable_integer = 50;
        // FIXME ^ Comment out this line
    }

    // Ok! `_mutable_integer` is not frozen in this scope
    _mutable_integer = 3;
}

is that in the block a new variable is introduced that's initialized with the value of another one. The fact that the _mutable_integer in the outer scope is mutable seems irrelevant?

So essentially when reading this I was wondering whether "freezing" was even a concept of its own in Rust or what's being described is just behavior that results out of other concepts in the language?

Please not I'm still relatively new to Rust and might just be missing something here (which could mean though that if the example was changed to make the point clearer, people like me would be less likely to be missing the point here :) )

[niklaslong]

I think it's just meant to be a demonstration of how "scoped shadowing" works. Consider an example where the inner variable is made mutable:

fn main() {
    let mut _mutable_integer = 7i32;

    {
        let mut _mutable_integer = _mutable_integer;

        _mutable_integer = 50;
        
        println!("{:p} has value {}", &_mutable_integer, _mutable_integer);
        // Prints 0x7ffd6d5ee7b4 has value 50
    }
    
    println!("{:p} has value {}", &_mutable_integer, _mutable_integer);
    // Prints 0x7ffd6d5ee7b0 has value 7
}

They may have called it freezing because while the variable in the outer scope is shadowed by the one in the inner scope, its value can't be accessed or modified, but it can be once the scope is closed. In other words, it doesn't get "moved" in this case.

If you assign an exclusive reference to the inner var, you get this however:

fn main() {
    let mut _mutable_integer = 7i32;

    {
        let _mutable_integer = &mut _mutable_integer;

        *_mutable_integer = 50;
        
        println!("{:p} has value {}", _mutable_integer, _mutable_integer);
        // Prints 0x7ffe5ccc6b14 has value 50
    }
    
    println!("{:p} has value {}", &_mutable_integer, _mutable_integer);
    // Prints 0x7ffe5ccc6b14 has value 50
}

In addition you can print the memory addresses to convince yourself the variables are pointing to different memory locations in the first example and the same memory location in the second.

[marcoow]

Yes, that's what I mean – nothing ever seems to get "frozen" at any point and it's just implications of the shadowing mechanism? So I think that's what I found confusing: the introduction of "freezing" as a concept of its own seems to imply that there's somehow more to it than what you describe above and it remains unclear what that could me which makes you think you're missing something (while it seems like there just isn't anything beyond variable shadowing at play here in reality).

[Spoonbender]

It seems that the concept / idiom of "freezing" / "frozen data" / "frozen values" etc. isn't common among (yet), but it does seem to appear outside of RBE:

• The Frozen data structure
• The elsa crate of frozen collection types
• rust issue: Request: Make std::marker::Freeze pub again
• rust issue: add share kind - contains a discussion about the previously-present Freeze

And while the discussed Freeze is different than the "freezing" technique in this page, it does imply that "freezing" as a concept exists, at least in some minds. See this comment in particular.

And it does seem there is such an idiom in other programming languages or ecosystems:

• example 1
• example 2
• example 3

All of this is to say that perhaps freezing in Rust isn't a common or very well defined concept, but I do think there is room for it in our vocabulary and exemplar.

[marcoow]

@Spoonbender "Freezing" definitely exists as a concept in general which is why I found this extra confusing – all of the examples you share are very different from what's explained in the above example (as you say).

[marioidival]

Hi, I'm closing this issue just to clean up the items that already exist. If you think this issue makes sense to stay open, please create a new issue with updated information and mention this one.

thanks!