Understanding mutability

[mindplay-dk]

I find the mutability concept in V somewhat confusing.

I've read the documentation, and didn't really find answers to my questions.

Looking at the example from the documentation:

struct User {
	name string
mut:
	is_registered bool
}

fn (mut u User) register() {
	u.is_registered = true
}

mut user := User{}
println(user.is_registered) // "false"
user.register()
println(user.is_registered) // "true"

Here, the is_registered field in the struct is declared mutable - it's pretty clear what that means, that the value of the field can be changed.

Now, in the function declaration, the argument mut u User is also declared mutable. Here's where I start to get confused. What does it mean for an argument to be mutable? We've already declared that the field is mutable. Yet, the compiler demands we make the function argument mutable as well. Why?

And then, when we declare the mut User instance, the local variable is also declared as mutable. What does it mean for a local variable to be mutable? Again, the field was declared as mutable, but the compiler demands we make the local variable mutable as well. Why?

To make one mutable field, we had to make three mutable declarations.

The only reason I can think of, is you want to be extremely explicit about which functions could enact side-effects?

But if that's the reason, it seems the keyword mut means two very different things: in structs, it makes fields mutable, that's pretty clear. But in argument and variable declarations, it doesn't seem to have any direct effect on the symbol itself? It doesn't make something mutable, it's more like an assertion that says "I know that something else, like a method I call, could have effects on something mutable in this struct".

I don't know, maybe that buys you some guarantees in terms of memory management or threading in the future?

But it's a bit confusing as a language concept, since mut doesn't appear to mean one thing.

Also, what happens if you declare a mutable argument or variable, but the struct/type itself doesn't have any mutable fields? For example, a function with a mut value int argument can't somehow change the non-local value of a variable being passed to it, can it?

If this is all by design and working as intended, it really needs better documentation - like a whole section explaining mutability, what it is and when to use it, etc.

[Richiban]

The mut keyword does two things. As you've correctly grokked you can use it on a field to mark the field as mutable:

struct User {
	name string
mut:
	is_registered bool
}

The other use, on a function argument, as in

fn (mut u User) register() {
	u.is_registered = true
}

is where you require permission from the caller the mutate the struct they've given you a reference to.

Mutability is not inherently dangerous to your program, but uncontrolled mutability is. Languages differ slightly in how they deal with this (if at all): marking individual fields as mutable or not is kinda OO-style whereas reference-level controls come from Rust. V is a bit unusual in that it has both styles of mutability controls at once.

[ntrel]

What does it mean for a local variable to be mutable?

It means its value can be changed. If you don't declare user with mut, then trying to mutate it with user.register() (or an assignment) will error.

Again, the field was declared as mutable, but the compiler demands we make the local variable mutable as well. Why?

Immutable fields are useful to prevent direct changes to those fields, whilst allowing mutable fields to change. Or even with all fields immutable, a user can assign another struct to a mutable instance of the struct - but they can't directly change immutable fields. This can help to enforce creating only certain valid values of a struct, by requiring the user to call a function/method. To truly enforce this, we should probably make it illegal to name private fields in a struct initializer.

[dumblob]

even with all fields immutable, a user can assign another struct to a mutable instance of the struct - but they can't directly change immutable fields. This can help to enforce creating only certain valid values of a struct, by requiring the user to call a function/method.

This is great explanation which should be copy & pasted to the documentation to avoid future questions.

To truly enforce this, we should probably make it illegal to name private fields in a struct initializer.

Sounds like a good idea. Go for it!

[spytheman]

We already have the [noinit] tag.
Structs that are marked with it, can not be created directly with x := Name{}, instead they have to be returned by constructor functions, in the same module, that declared the structs.
The constructor functions can check that the returned instances are valid, beside other things.