How can I force a struct's field to always be immutable in Rust?

Question

In Rust, you don't specify mutability inside a struct, but it is inherited from the variable binding. That's great, but is it possible to force a field to be always immutable, even when the root is mutable?

Something like this hypothetical syntax:

struct A {
    immut s: Shape, // immutable by design
    bla: Bla, // this field inheriting (im)mutability
}
let mut a = make_a();
a.s = x/*...*/; // illegal

This would help to maintain nice semantic restrictions in a program, just like Java's final does (in a very limited way).

Also, we could imagine this kind of struct having some non-owning references to internal immutable data, taking advantage of this immutability...

Selfabnegation

Well, if you make it priv and don't modify it in any code inside the same module, it is effectively immutable. And of course one can always replace a wholesale (a = make_another_a();), which may or may not be a problem. – Howlett

Answer 1

It's impossible to have immutability of a single field. That was an option in an ancient version of Rust (think before 0.8), but it was dropped because the rules confused a LOT of people. How was it confusing, you might ask? Think about it like this: if a field is declared mutable and struct is declared mutable and the reference used was an immutable reference (&) then the field is _______.

The best, as Lily Ballard noted, is that you can declare your Shape field as private and make a getter method using impl A {...}.

mod inner {
    pub struct A {
        s: i32, // can't be seen outside of module
        pub bla: i32,
    }

    impl A {
        pub fn new() -> Self {
            Self { s: 0, bla: 42 }
        }

        pub fn get_s(&self) -> i32 {
            self.s
        }
    }
}

let mut a = inner::A::new();
a.s = 42; // illegal
println!("{}", a.s); // also illegal
println!("{}", a.get_s()); // could be made to serve as a read-only method

error[E0616]: field `s` of struct `main::inner::A` is private
  --> src/main.rs:20:5
   |
20 |     a.s = 42; // illegal
   |     ^^^

error[E0616]: field `s` of struct `main::inner::A` is private
  --> src/main.rs:21:20
   |
21 |     println!("{}", a.s); // also illegal
   |                    ^^^

There is proposition that might drop notions of mutability and immutability completely (you can't say a struct never changes). See Niko's explanation for that change.

Weddle

Okay, I understand it could be confusing. Out of curiosity, what was the actual behaviour when taking an &A and trying to mutate its field? My guess is that it would be impossible since immutability is deep (inherited)... – Selfabnegation

Here you go a detailed explanation by kibwen: reddit.com/r/rust/comments/264d2t/… – Weddle

@LP_ Basically, you had inherited mutability of fields of a struct. E.g. struct Foo {priv mut stuff} could be modifed, so for example let a = &Foo { stuff: 2 } could be modified using a.stuff = 3. You could never guarantee that a field would be immutable, and how could you? – Weddle

Why isn't it possible to declare just the field as immutable? It could be immutable externally and act like a normal field internally. Like sugar syntax for a public getter method for a private field. Or is that still potentially confusing? – Hardball

Answer 2

You can create a struct and only implement the Deref trait for it. Without the DerefMut trait it won't be possible for contained values to be mutated.

https://doc.rust-lang.org/std/ops/trait.Deref.html

This way the compiler will make the member usable as if it's not wrapped in another struct, no need for any written getter method call.

use std::ops::Deref;

/// A container for values that can only be deref'd immutably.
struct Immutable<T> {
    value: T,
}

impl<T> Immutable<T> {
    pub fn new(value: T) -> Self {
        Immutable { value }
    }
}

impl<T> Deref for Immutable<T> {
    type Target = T;

    fn deref(&self) -> &Self::Target {
        &self.value
    }
}

struct Foo {
    bar: Immutable<Vec<u8>>,
    baz: usize,
}

impl Foo {
    pub fn new(vec: Vec<u8>) -> Self {
        Foo {
            bar: Immutable::new(vec),
            baz: 1337,
        }
    }

    pub fn mutate(&mut self) {
        self.bar.push(0); // This will cause a compiler error
    }
}

|
|         self.bar.push(0);
|         ^^^^^^^^ cannot borrow as mutable
|
= help: trait `DerefMut` is required to modify through a dereference, but it is not implemented for `runnable::immutable::Immutable<std::vec::Vec<u8>>`

Jambeau

If you end up using this approach, remember to implement the same traits for Immutable<T> as for T, else a user of your library might encounter weird errors when attempting to use a Immutable<T> as a T. See this example – Monogamist

You can always just deref to fix that: example. But if you want the ergonomics of normal trait use, then you may find it desirable to impl a trait or two on Immutable<T> – Jambeau

This does nothing to stop you from putting a new value into bar though. – Metagenesis

Fair point - and that's actually what the OP asked for. I guess if you combine a private field with a getter and this immutable wrapper struct you'd have a perfect, deeply immutable solution (when used outside of the struct). – Jambeau

Answer 3

You can't force immutability on a field. How would the struct mutate its own value when necessary?

What you can do is make the field private and expose a getter method to return a reference to it (or to copy/clone the value).

Natalyanataniel

It doesn't always make sense to be able to mutate data; have you heard about functional programming, for instance? The Java final modifier could be considered useless since a simple getter can accomplish the same effect. It's just a matter of making it easy (so that people do it more naturally -- it is always good to avoid useless potential states in code) and clearer (auto-documenting that a value will never change can be useful). – Selfabnegation

@LP_ I think it should be up to the API user of a struct to decide if they want to mutate or not... if they don't want to, they can hold an immutable reference. – Preliminary

@DavidCallanan That really depends on whether the struct has to maintain invariants on its fields that aren't enforced by the type system. For example, Vec has a private field len and a public getter fn len(&self). Mutating the len field would break the safety of Vec so it has to be kept read-only. – Natalyanataniel

@LilyBallard Sorry I was talking about structs with public fields only. – Preliminary

Immutability is an extremely valuable construct. As a rule of thumb, I think that everything should be immutable by default. Mutability should be the exception. – Bobwhite

Answer 4

Probably the easiest way to achieve this today is by using the readonly crate from prolific developer David Tolnay (author of serde and many others). From the github documentation:

This crate provides an attribute macro to expose struct fields that are readable and writable from within the same module but readable only outside the module.

#[readonly::make]
pub struct S {
    // This field can be read (but not written) by super.
    #[readonly]
    pub(super) readable: i32,

    // This field can be neither read nor written by other modules.
    private: i32,
}

Wallie

Answer 5

A Solution could be to have a more general approach:

pub struct Immutable<T> {
    value : T ,
}

impl<T> Immutable<T> {

    pub fn new(value : T) -> Immutable<T> {
        Immutable { value : value }
    }

    pub fn get( &self) -> &T { &self.value }
}

Now it is possible to use the Immutable struct in every case for every other type.

Given this into a module avoids changing the content of the Immutable object. It is still possible to change the variable which holds the Immutable object itself by overwriting it by a new Object but you should notice it by the Immutable::new statement and so you can avoid using it.

Larimer

Answer 6

In many cases an associated constant achieves the desired behaviour:

struct Foo { blah: Blah }

impl Foo {
    const S: Shape = Shape { x: 1, y: 1 };
}

Of course, constants cannot be set on creation, they are set at compile-time. Making the field private as explained in other answers will work if dynamicism is required.

Aventine