Change:
*/ use cast::transmute; <ins> use cell::Cell; </ins> use clone::Clone; use cmp::{Eq, Ord}; use kinds::marker; use ops::{Deref, Drop}; use option::{Option, Some, None}; use ptr; <ins> use ptr::RawPtr; </ins> use rt::global_heap::exchange_free; struct RcBox<T> { value: T, <del> strong: uint, weak: uint </del> <ins> strong: Cell<uint>, weak: Cell<uint> </ins> } /// Immutable reference counted pointer type

Discussion:
To the extent possible, we should try to have all interior mutability be done via , , , or (not yet landed) . If one of these patterns doesn't suffice, it'd be nice to know why!
Nominating for P-Low
Tagging as E-Mentor; I can mentor.
Related to Other types that use interior mutability I can think of off the top of my head: -
I'm definitely interested. Though---having never been a part of a project like this before---not quite sure how the mentoring works just yet :P
This is the part: .
I don't understand the reasoning behind doing this for . Using a marker type makes the intent clearer, and will perform better with optimizations disabled. The type is also supposed to be when is and this will make it always non-. The type should also be .
Marker types do not seem clearer to me than , quite the opposite, but of course thi is a matter of opinion. At first I thought you were on to something regarding , but then I realize that I was mistaken. In particular, we need to settle on precisely what makes something not : must the interior mutability be something interior, something that you own, or just something you can reach? But this question is orthogonal to whether we use markers or . If I understand it, the use of would look something like this: In this case, whether or not is will hinge directly on what we decide about owning vs mutability. At present, the definition is based on reachability. But this definition may be stronger than what we need. I guess it depends on just what is to be used for. So after considering this some more, I still think that using is the right call for is the right call, but the real discussion is what precisely ought to mean, which is most properly discussed I think under . make sense?
I don't think we have a way of enforcing deep immutability. There are many existing types doing internal writes due to I/O. I don't know of a purpose for beyond the high-level semantic meaning (perceived inherited mutability) and type-based alias analysis (which is not deep) so that's the lens I'm viewing it through.
Every type using memory allocation needs to become non- if means deep immutability. The function is mutating memory via the pointer.

So it's not just a problem with I/O.
I don't believe that is an accurate summray of what was proposed, but it is a moot point, as in the latest plan there is no Freeze.
Is there a change to coming? is already using .
I think and I decided that is already using the right primitives and it was just that wasn't.
Though I didn't dig too deeply, maybe can confirm. But it looked to me like it was using the proper abstraction (is there more than one?)
Indeed, is correctly implemented as-is it appears.
I'm running into tests not compiling because something doesn't implement Freeze. Should I wait for to land before I continue?
I actually did not realized that is already on this issue. I'll let you handle this one :D
Assigning P-low as suggested.