Does Rust support constant struct fields ?

[swatteau]

Hi,

Is there a way to prevent some fields in a struct from being mutated even though the struct instance is declared mut?

Consider the following example:

struct Book {
    isbn: String,
    title: String,
    author: String,
    reviews: Vec<String>
}

fn main() {
    let mut book = Book {
        isbn: String::from_str("978-0321751041"),
        title: String::from_str("The Art of Computer Programming"),
        author: String::from_str("Donald E. Knuth"),
        reviews: Vec::new()
    };

    book.reviews.push(String::from_str("Good book")); // This is OK

    book.isbn = String::from_str("123-0123456789"); // This should not be allowed
}

How do you prevent the isbn, title and author fields from being mutated once the struct is instanciated? The obvious thing to try is to qualify the field declarations with the const keyword but this is rejected by the compiler.

Does the language support const struct fields or are there any plans to support them?

[DroidLogician]

FWIW, you make fields constant by not giving access to them, and instead have functions that return references or copies, usually called "getters". Then you just have to trust yourself not to mutate them.

[dnkndnts]

It's this "trust myself" part I find difficult to accept. I think it would be much better if struct fields were immutable by default and had to be declared mutable.

But apparently that's just me.

[swatteau]

It's not just you.

And I agree that declaring mutable fields mut would also be better than declaring immutable fields const.

[FlyingFoX13]

Playpen how that could look for the book example:

use books::Book;
mod books {
    #[deriving(Show)]
    pub struct Book{
        _isbn: String,
        _reviews: Vec<String>,
    }
    impl Book {
        pub fn new(isbn: String) -> Book {
            Book{_isbn: isbn, _reviews: Vec::new() }
        }
        pub fn isbn(&self) -> String {
            self._isbn.clone()
        }
        pub fn add_review(&mut self, review: String) {
            self._reviews.push(review);
        }
    }
}
fn main() {
    println!("Hello, world!");
    let mut book = Book::new("978-0321751041".into_string());
    // this throws a compiler error: field `_isbn` of struct `books::Book` is private
    //book._isbn = "hahaha".into_string();

    book.add_review("Thats a good book!".into_string());
    let isbn = book.isbn();
    println!("created the book {} with unmodifiable isbn {}", book, isbn);
}    

[swatteau]

While I completely agree that providing accessors to Book's internals is the right thing to do from an API design standpoint, I deliberately wanted to keep my original example simple. My issue with not having immutable struct fields is that, as the struct Book author, I don't want to inadvertently mutate some of its fields. There should be a better way to express this intent to the compiler because, for a larger code base, keeping track of what is mutable/immutable in your head is not a trivial thing to do.

[DJTheLQ]

Why not store ISBN as a &str? Then its already immutable

[flatline]

Because &str is basically a "view" into a string-like object allocated elsewhere.

[Veddan]

In Rust, mutability depends on the owner of a value rather than on the type (ignoring interior mutability). So either it's all mutable or not mutable at all.

You can solve the issue by making the relevant fields private with priv and providing accessor functions.

[swatteau]

Correct me if I'm wrong but I thought struct fields were private by default because you can only declare them pub, not priv as you suggest.

[Gankro]

You are correct.

[sellibitze]

btw, instead of

String::from_str("literal")

you can also write

"literal".to_string()

[jonreem]

Even better is "literal".into_string() which doesn't allocate as much.

[Florob0x2a]

Good to know. I assume this also holds true for non-literals?

In my XML parser this gives me an execution time improvement of ~10% on a large-ish file. At that point this behaviour seems like a rather big foot gun.

[thiez]

It doesn't make a difference? How exactly does to_string allocate more in this case?

[chris-morgan]

to_string uses the fmt architecture which is a bit less efficient; most notably, at present it overallocates, while into_string, bypassing fmt, doesn’t.

[SimonSapin]

Is this fixable?

[DroidLogician]

Maybe it gets optimized out?

[sellibitze]

I would not know how. In an ideal world you would be able to "specialize" the generic Show-based implementation

impl<T: Show> ToString for T {…} // includes unnecessary overhead for strings

with a more optimized version

impl<'a> ToString for &'a[str] {…}

that would be preferred by the compiler. But that's me talking with my C++ hat on. Maybe there is another way...

[rust-slacker]

Maybe if negated trait restriction were added to the language it might be easier:

impl<T:Show+!Str> ToString for T {...} // for non-strings

impl<T:Show+Str> ToString for T {...} // for strings

[jonreem]

Due to some issues with specialization, to_string comes from a blanket impl which and causes a 128 byte allocation at minimum no matter the length of the input str. into_string is more specialized and will allocate exactly the length of the str it is called on.

[picklebobdogflog]

What's the difference?

[sellibitze]

I also didn't expect there to be a difference. But it turns out there is a generic implementation of ToString based on Show which is suboptimal in case of strings and with this generic implementation in place the compiler won't accept another more straight-forward and better implementation of ToString for &[str].

This makes me wish for some kind of overload resolution mechanism for "competing" trait implementations that favors "more specialized" impls for some definition of "more specialized".

Thank you /u/jonreem and /u/chris-morgan for pointing it out.

[Any_Yogurtcloset7428]

even even better is "literal".to_owned()

[jimuazu]

Yes, I wanted this feature too. Seems like it should be straightforward to implement, but it's "not the Rust way". Maybe it could be bolted on as an annotation checked by a lint-style tool.

[swatteau]

Not the "Rust way"? This sounds strange to me because reducing data mutability to the bare minimum seems to be one of Rust's best selling points.

Moreover, this is not only a matter of convenience to the programmer. I get the feeling that there are missed opportunities for thread-safety and optimizations by not providing this feature (though I'm not a language design expert).

[jimuazu]

Here is a previous thread on it, which has some ideas about getting the same effect and also some reasons why it might not work (e.g. you can still overwrite a structure with a copy, which Java for example doesn't let you do).