`&immut T` without interior mutability?

[jeehoonkang]

&T has interior mutability: depending on the nature of type T, it is allowed to change the referenced data, and you cannot assume that the value of &T doesn’t change. For example, if you have &AtomicUsize, then you can change the value of it by fn AtomicUsize::store().

Will it be useful to support another reference type, &immut T, which doesn’t allow any modification to the referenced data? Right now I can see one benefit: &immut T will admit more compiler optimizations than &T.

[kennytm]

As Rust uses monomorphization, the compiler will know exactly whether T has interior mutability or not, so “optimization” is not really a valid argument for this feature.

[ExpHP]

As Rust uses monomorphization, the compiler will know exactly whether T has interior mutability or not, so “optimization” is not really a valid argument for this feature.

I have to wonder though… what does it do for trait objects?

[parkovski]

I don’t see how that reference type would work - you either let it convert to &T, where you could call a method that mutates a RefCell or similar, or you don’t and the type is incompatible with all existing code. If the compiler knows whether you’re accessing an UnsafeCell, there’s no optimization benefit to adding that type, and if it doesn’t (through a trait object), you have to either make the type unusable or redundant.

Plus you still have transmute, and the idea of undefined behavior there has to do with aliasing optimizations. Since regular references can alias, it would be perfectly safe to transmute to an &T anyways, like C++’s const_cast.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.