Define "interior mutability"

[shepmaster]

per @RalfJung..

at least in my mind, interior mutability is pretty much settled

[RalfJung]

Hm, I know it was me who said that but the "non-transitively" part is probably confusing. Might be better to remove this and instead mention that this stops at raw pointers.

Or maybe this is better explained by pointing out the pattern this violates? "Memory behind a shared reference is not mutated (transitively through references and boxes, but not through raw pointers)". If you do it anyway, (a) you need to wrap the memory being mutated (NOT the reference!) into UnsafeCell and (b) then you have interior mutability. Does that make sense?

[glaebhoerl]

(Maybe this is the wrong place to raise this but I've always wished we called this "shared mutability" rather than inventing our own terminology with "interior". "Shared mutability" is a concept already widely known outside of Rust, and AFAIA, its definition matches what we wish to denote by it within Rust. Also the shared mutability <-> shared references suggestiveness is nice.)

[avadacatavra]

I would also prefer to call this "shared mutability." Personally, I associate interior mutability with using a Cell to mutate a field on a struct.

[RalfJung]

@avadacatavra I am confused. I do not understand the distinction you are making between Cell in general and Cell to mutate a field on a struct.

[avadacatavra]

@RalfJung ...now that I'm rereading this I'm not sure what was going on in my head...

I think that the definition in this PR confused me (and I was commenting at 1am which couldn't have helped)

[avadacatavra]

Since the wider Rust community uses interior mutability, I consider it out of scope for this WG to change it to "shared mutability." I'm going to merge this and if we decide to refine the definition at a later date, then we can

[gnzlbg]

Should we open an issue to track that? Whether it is in scope for this WG to change that, and whether it should be changed?