Mutating an immutable variable: temporary flaw or design decision?

[JoanaBLate]

struct MyStruct {
mut:	
    list []string
}

fn main() {

    a := MyStruct{["aaa"]} // immutable variable
    
    mut b := a
    b.list[0] = "BBB"

    println("now first in 'a.list' is ${a.list[0]}")
    
    // output:
    // now first in 'a.list' is BBB
}

Sorry if it's already been discussed; I couldn't find a similar post.

[Wajinn]

The claim that such is a "flaw" is very debatable to bogus. It was originally presented by a user who unceasingly trolls V on other websites, and is an evangelist for a competing language (who hides their affiliation), that appears not bothered by underhandedness.

The struct has been set to mutable (mut:). What has been done is similar to what is present in C and other languages, by having a const pointer. This can also be referred to as a const struct (a mutable field accessed by reference). In Go, they avoided this by omission, where V gives users the option. I argue this is a justifiable option that should stay in V, as it is. The programmer should have enough sense to know what they are doing, when setting a struct to mutable or immutable. At most, think it should only be an "alert" or warning.

If you don't want the contents of the struct to be mutable, then don't set it as so.

struct MyStruct {
    list []string // set to immutable
}

fn main() {

    a := MyStruct{["aaa"]} // is immutable, after assigning value
    
    mut b := a
    b.list[0] = "BBB" // mutable var b can not change values in struct of immutable var a

    println("now first in 'a.list' is ${a.list[0]}")
    
    // output:
    // error: field `list` of struct `MyStruct` is immutable
}

[JoanaBLate]

Excellent!

Now that you accept that mutating an immutable variable is not simply "how V is supposed to work" we can move to the next phase.

Next phase:

If the user has the intention of doing something stupid, then...

Wait! How can you be sure that the user HAS the intention? Maybe he is doing a painful mistake/typo that will create a VERY HARD TO FIND BUG. So he must be forbidden!!!

In case, he really has the intention. You forbid him and tell him to write CORRECT CODE by making the variable 'a' mutable!

There is no need to increase complexity in V creating exceptions for corner cases.

EDIT: if the compiler warns, it solves the part about "has the intention"; maybe OK at compile time. But is bad for who reads the code later. Mutating an immutable variable should not be admited.

[Wajinn]

Now that you accept that mutating an immutable variable is not simply "how V is supposed to work" we can move to the next phase.

That is not quite what I believe is going on or how I see it.

While the variable itself might be designated as immutable, that doesn't necessarily apply to the object it is pointing to/referencing or other variables that may also point to/reference that same object. So there are different situations or conditions that the variable may be in.

I think there is a distinction or misconception about immutability, which might be at the heart of misunderstandings or the way that the narrative is being framed. Though, it should be noted, that competitors of V appeared to have purposely mangled and twisted the narrative versus having an actual misunderstanding. Hopefully, there can be more clarity on what is actually going on.

1) The variable may hold no references to objects outside of the function.

In that case, "simplistic" immutability applies. In this case, V never had a problem.

2) The variable may point to/reference an object outside of the function.

In this case, the immutable concept becomes cloudy for all programming languages. This is because we may want to mutate what is considered a constant or default values. Thus concepts such as const pointer and const struct.

Some languages, such as Go, completely ran from const struct and instead use "helper" functions to give initial default values of the struct. It's a kind of workable cheap trick of Go (which can be used in V too). In V, however, we are empowered with the choice between immutability or mutability by reference and the choice of having structs with default values.

As many other languages don't handle immutability explicitly or obviously, people's experiences in those languages may not apply or distort their perception of what is going on in V. They may think in terms of simplistic immutability, like "on" or "off", where there is more going on.

When we choose to make an object outside of the function mutable, we may need to temper our expectations over immutability and proceed with caution, in order to get what we actually want.

3) If we are working with a mutable object outside of the function, it must be decided if we want to interact with it directly or with a copy.

This is where the intent of the user comes in. Does the user want to work with a copy or directly modify objects outside of the function by reference?

This is where conflicted intent and expectations can come in. The user has mutable objects, is mixing immutable variables with mutable variables (by possible inappropriate use of mut), but expects "full" immutability.

You forbid him and tell him to write CORRECT CODE by making the variable 'a' mutable!

This is not what I've stated nor are referring to. In no way is the user being "forbidden" from doing anything. If the user's expectation is "full" immutability, then they should be cautious or understand what they are doing when mixing in mutable objects and mutable variables (by using mut).

The compiler is giving a notice, when the user is trying to assign or mixing the immutable with mutable. If the user is not working with a copy of the object inside the function, then it is being considered to use unsafe {} for when they are attempting to modify an outside object directly (by reference). I'm actually kind of against or undecided about such an unsafe {} designation. I believe the user should understand what they are doing, not be so careless, or ambiguous. If they are, then suffer the consequences of not getting what they want. That's how we learn.

There is no need to increase complexity in V creating exceptions for corner cases.

Again, I'm not sure where we are going with this. Team V is handling an issue as presented to them. V also provided the ability to choose immutable or mutable from the beginning. This is a core feature of the language that is being addressed, to increase usability for users. And all programming languages, in one way or another, must deal with or address immutability versus mutability. There is no true increase in complexity, when such a feature and concept already exists. It's just an advanced topic that all programmers and languages must confront at some point and in some way.

[Ddiidev]

I don't have as deep a knowledge as my colleagues, but if I may point something out.

1. Simpler to just print a warn as a potential error.
2. apply a new keyword, eg ref
   mut b := ref a // mut a
   // That way I would be making it clear that I want a reference and not a copy of the struct.

Makes sense?
If you couldn't explain why doesn't it make sense?

[JoanaBLate]

Where I wrote

"You forbid him and tell him to write CORRECT CODE by making the variable 'a' mutable!" I

please read

"V should forbid him..."; (my fault when writing the message).

About everything else, I was not expecting a long and deep discussion.

I just wanted to point something that I found very important.

I just read the message from JalonSolov.

I will not reply anymore.

Thanks for your attention ;)

[Wajinn]

1. Simpler to just print a warn as a potential error.

I lean towards such, as in a notice to the user.

2. apply a new keyword, eg ref

Don't know about using the ref keyword, but maybe some form of the concept could work. Maybe some new function that forces mutability of the object to be the same as the variable it's assigned to, inside of a function.

So if part of the problem is awareness of or dealing with 2 levels of mutability, the object's mutability versus the variable's mutability it's assigned to, then maybe something like, a := MyStruct{["aaa"]}.sync(). So now mutability is synchronized on assignment and it's ensured that both are the same, and that it's a copy.

Yet another way that might work, declare and assign the struct inside the function. Instead of confusion about the mutability of an object outside the function versus the mutability of the variable its assigned to inside the function, the user can declare and assign the struct inside the function.

fn foo(){
    mut my_struct := struct {
        list []string
        }
}

[JalonSolov]

Perhaps it would be better to just ask the right person, to get the definitive answer?

@medvednikov can you answer the original question posed in this thread?

[medvednikov]

This is a bug, just like the mut x := my_const which was fixed recently.

Here things are complicated by the array field, so it'll be trickier to fix.

[JalonSolov]

@JoanaBLate please open an issue on this so it can be fixed.

[JoanaBLate]

OK

[JalonSolov]

Thank you!