inconsistent behaviour regarding @mut and &mut in managed and borrowed reference types

[dhardy]

Using @int instead of @mut int in a type causes a compile error, but using &int instead of &mut int does not.

let o = @mut 5;
let mut m : @int = o;       // error: mismatched types: expected `@int` but found `@mut <VI5>` (values differ in mutability)
let mut b : &int = o;       // compiles (with type '&int' or '&mut int')?
let mut c : &int;           // to contrast...
c = o;      // error: mismatched types: expected `&int` but found `@mut int` (expected &-ptr but found @-ptr)

This could be intended behaviour, but I presume not since as I understand it variable typing is either automatic (from the rvalue) or explicit, not some mixture of the two.

[nikomatsakis]

This is expected behavior. The reason is that you are allowed to take immutable references to mutable data, which causes the mutable data to be frozen. (This is what is happening when you assign to &int). But you can only freeze for a limited lifetime. The assignment to @int is disallowed because that would be a permanent freeze. It's possible we could allow this, but we don't today.

[dhardy]

Seems very very strange to me (that assignment to variables b and c is not handled equivalently), but as you say...

I'll try to update the tutorial to explain this. No, maybe I won't just yet, there's enough other documentation on Rust I haven't yet read.