mut is now optional. Thank you!

[gchumillas]

Wonderful!

% v -disable-explicit-mutability run hello.v
Hello, World!

// hello.v
fn main() {
	msg := "Hello, World" // not `mut` needed
	msg = "Hello, World!"
	println(msg)
}

This simple change will allow the user to

1. quickly prototype and
2. decide what level of security to implement and how to implement it

[programmingkidx]

Thank you for letting us know. I never liked the v rule about all variables being read-only by default.

[JalonSolov]

mut is one of the things that both made V unique, and made it safe.

I will be very UNhappy if this is made the default. 👎🏼

[Wajinn]

It appears you are arguing that "immutability by default" features are a mistake, however, many others would disagree. "Evolve" does not necessarily mean for the better, as can be both good or bad. Thus we also have terms like "enshittification".

Part of why people are attracted to V, is greater safety. That attraction (to safety) looks much greater than classic OOP notions of encapsulation.

On that point (encapsulation), there was never a response (to jorgeluismireles) about using alternatives (with previous version), like a factory function (example below).

// "doing the mut internally and returning a never mut again object" -- jorgeluismireles
pub struct MyStruct {
mut:
    aaa bool
pub:
    bbb string
}

fn (mut u MyStruct) aaa() {
    u.aaa = false
}

pub fn new_my_struct_bbb() MyStruct {
	mut m := MyStruct{}
	m.aaa()
	return m
}

fn main() {
	m := new_my_struct_bbb()
	println(m)
}

[Wajinn]

I also checked out the example presented in 24718 as justification for the feature request. That example no longer appears to be true (per present version of V). The user can use the variable as immutable, without needing to use any flag.

module my_library

pub struct MyStruct {
mut:
    // the variable 'aaa' is not accessible outside the library
    aaa bool
pub:
    bbb string
}

// the 'aaa' function changes a property that is inaccessible outside the library
fn (mut u MyStruct) aaa() {
    u.aaa = false
}

pub fn (mut u MyStruct) bbb() {
    u.aaa()
}

Below is the previous case of a user being forced to declare the variable as mutable.
That no longer appears to be a valid situation for present versions of vlang.

import my_library

fn main() {
	// the user is forced to declare the variable 'a' as mutable
	// although they don't understand why, since apparently no visible property changes
	mut a := my_library.MyStruct{}
	a.bbb()
}

Presently (0.5.1 7f8fc05), the user can use the variable as immutable.
The below is done without using any flag.

import my_library

fn main() {
	// the user is "not" forced to declare the variable 'a' as mutable
	a := my_library.MyStruct{}
	a.bbb()
	println(a)
}

[gchumillas]

Yes, that issue was solved. About the "Cascading Propagation", see this example:

struct Parent {
	child Child
}

fn (p Parent) bbb() {
	p.child.aaa()
}

struct Child {
	aaa int
}

fn (ch Child) aaa() {
	println(ch.aaa)
}

Later I decide that Child.aaa() can change the property Child.aaa:

struct Child {
mut:
	aaa int
}

fn (mut ch Child) aaa() {
	ch.aaa = 100 // now 'aaa()' changes the property 'aaa'
	println(ch.aaa)
}

But that change "propagates upwards", forcing me to change the parent class:

struct Parent {
mut:
	child Child
}

fn (mut p Parent) bbb() {
	p.child.aaa()
}

And this is not good. Sorry for the example :)

Basically, one change in one point implies changing a lot of things in a lot of places. This is not convenient in a production environment with many people working together, where commits should be self-explanatory and localized.

However, I could understand this approach in small, critical programs, such as drivers. And now the user can decide which strategy to use. That's why I consider this change advantageous.

[Wajinn]

Later I decide that...

I see that as more about an issue with the creation of the original struct, that is being described as "propagates upwards". The Child struct was changed to mutable, therefore, it should have been designated as mutable in the Parent struct in the first place, if that was the intent. "Propagates upwards" comes across as an euphemism for "I changed my mind" or "The compiler should guess my future intentions".

Vlang should not be trying to guess what our future intentions will be, especially in any indeterminable way or situation. It should be doing, what we tell it to do, with the code we typed out. If we want the Child struct to be mutable and embedded into the Parent struct, then we should arguably be typing the code accordingly.

[medvednikov]

mut will always be the default.

This flag is experimental.

[Wajinn]

Agree with JalanSolov. This turn is very disappointing. It gives people the impression that the language is backtracking on safety features.

Furthermore, it looks very conflicted or even arbitrary, because on the one hand there was a turn to enforcement of no unused parameters. Yet, we can disregard default immutability at will. Where is the flag for turning off unused parameters enforcement? In fact, what are we doing? There does not seem to be enough communication as to goals and direction.

The unused parameter turn looks to have unleashed havoc on many modules interacting with C libraries (edit: problems caused by long uncaught bugs that were recently revealed), as they no longer work. VUI and GUI, which are supposedly supported, their examples do not work anymore. There are also many 3rd party libraries that are not working properly with the new version. They all need updating.

Many perceive vlang as striving to be a better golang and safer alternative to C. Removal or waffling with safety features arguably lowers the value of vlang as an alternative. The direction, vision, and goals of vlang need to be more coherent. And what that is, should be clearly communicated to its community and the general public. More so, as the language creeps up in age.

[JalonSolov]

No. The unused parameter notice is only given when a function is declared as taking a parameter, and that parameter is not used at all within the body of the function.

It has nothing at all to do with optional parameters.

[Wajinn]

I'm not disagreeing with you. Was not stating that unused parameters are optional parameters, but rather, usage or intent can be like if they were. There can be an intent to use a certain parameter under some condition, which gives the appearance of being optional. Not saying always, but sometimes. It is easy to get involved in such an issue when translating from C, especially when translating exactly, and all affected modules now require updating.

In fact, the "unused issue" of vlang is more expansive than just parameters, as also includes warnings for unused functions. This can be resolved (in various cases) by adding pub to the unused function, but this information is not presented in V's documentation. Thus making it easier for a programmer to get tripped over such issues involving unused, when not discussed or taught.

Though we understandably went on a tangent, as you are stating the unused parameters are a separate issue to VUI and GUI bugs that are instead the reason for their present example failures, the wider point being made was about safety and communicating with users.

If vlang's intent is for widespread use, over personal or select group, then the communication and teaching aspect has to become stronger.

[medvednikov]

The unused parameter feature is experimental. May move it to v vet.

[Wajinn]

An issue about unused parameters, is it also being "user facing" as opposed to being for developers or library writers. I do think there is a divide (between casual users and high level developers) that should be acknowledged, particularly as V sees more widespread use. Casuals may not or may become more advanced or increase their usage of the language, but that is usually a gradual process (over months or even years), unless they are professionals or experts in other languages.

A casual or newbie who is trying things out and say importing the ui module, is likely to be perplexed or might come to an unfavorable opinion about seeing notices for unused parameter(s), for example e (fn scrollview_mouse_up(mut sv ScrollView, e &MouseEvent, _ voidptr)).

It might be better to have unused parameters as a flag that can be turned on for developers and library writers checking over their work. In the case of newbies or casuals, they are way less likely to be involved with troubleshooting official modules. Mentioning it in the documentation, would maintain awareness of it and that unused parameters are not considered good practice.

[medvednikov]

It might be better to have unused parameters as a flag that can be turned on for developers and library writers checking over their work.

Agreed, will implement this by tomorrow.

[programandala-net]

Gonzalo Chumillas escribió/skribis/wrote/scrit (2026-04-15T10:24:49-0700):

```bash % v -disable-explicit-mutability run hello.v ``` ```v msg := "Hello, World" // not `mut` needed msg = "Hello, World!" ```

a drawback of "changing" the language by a compiler option is that the code becomes harder to understand out of context, i.e. you need to know how the code is compiled in order to be sure you understand its behaviour. perhaps the default mutability does not affect so much in that matter, but still…

[JalonSolov]

It definitely affects it. If you look at most V code now, you can tell which things are writable because of the mut keyword. If you don't see that, you assume it is not writeable. However, if the command line switch is used, it will be writeable.

Confusion from simple reading of the code...

[Jengro777]

It definitely affects it. If you look at most V code now, you can tell which things are writable because of the mut keyword. If you don't see that, you assume it is not writeable. However, if the command line switch is used, it will be writeable.

Confusion from simple reading of the code...

This should be a bug issue

[iperov]

mut system is just inconsistent in current implementation

struct Host {
    cached []int = [0,0,0]
}

fn (mut self Host) numbers() []int {
    return self.cached // Can be mutated by caller
    //return self.cached.clone() // Expensive
}

fn main() 
{  
    mut h := Host{}
    mut numbers := h.numbers()
    numbers[0] = 1
    h.cached[0] = 1 //code.v:15:4: error: field `cached` of struct `Host` is immutable
    
    println(h.cached) // [1,0,0]
}

In a logical system, everything should be logical.

[gechandesu]

This seems like a bug in the checker that can be fixed, please open issue.

[iperov]

this is a fundamental concept issue, not a bug.

[iperov]

Moreover, the vast majority of real tasks don’t require mut at all. It’s only needed by less than 1% of programmers — for the rest, it just hinders readability.

[gechandesu]

The -disable-explicit-mutability flag divides the V codebase into two parts: one that compiles without the flag and one that can't be compiled without it. In the future, we'll be forced to use the flag even when compiling code that doesn't require it, because its dependencies may contain code that violates the default immutability rule. Thus, in the long run, default immutability may disappear from the language altogether. The arguments about easy prototyping and the programmer's ability to choose the "degree of safety" are very weak. Another argument about immutability being inconsistent also doesn't seem justified—bugs and shortcomings can be fixed.

I'd rather see V become stricter than weaken security for the sake of illusory convenience.

[gechandesu]

My position isn't even based on whether immutability by default is good or bad, although I tend to find it extremely useful. The problem is that introducing such a flag creates two incompatible codebases.

I can accept special flags that are needed for very specific things, such as -div-by-zero-is-zero and -no-bounds-checking, which can be useful in some cases, but this is affecting a core language feature that is used in all programs.

[medvednikov]

Yeah, it's an experimental flag.

The split is not a good thing.

I do think it'd be useful for an education platform, since it's easier to teach a language without mutability.

Perhaps it's better to implement auto generation of mut for such code instead.

[Jengro777]

@medvednikov

Mut becomes an optional keyword, which in itself should be a throwback to the V language.Will you consider mut as a mandatory option in the future?

[medvednikov]

mut will always be the default.

[jorgeluismireles]

Personally I prefer original V mut design and enforcement. For those don't wanting waste time with mut typing, still unsafe can be used:

fn main() {
	not_mut := 1
	unsafe{
		not_mut = 2 // hold my beer
	}
	assert not_mut == 2
}

Saving time in Golang without needing mut is relative, says if x, err := call(); err != nil { ... } else { ... } thing.

[Jengro777]

v -disable-explicit-mutability run main.v    // mut is optional
v run main.v    // mut required

It is merely an optional feature, and it should not affect the development direction of v

[bakul]

Given it has to be turned on with a command line flag I am ok with it as It may be useful in some initial code conversion from another language. Once the translated code works, you can remove the flag and fix up all mutability errors. Provided a file so compiled can be used with files/libraries compiled without this flag.

[programandala-net]

Jengro escribió/skribis/wrote/scrit (2026-04-18T19:43:07-0700):

It is merely an optional feature, and it should not affect the development direction of v

it shoud not, but it may, because it's an optional feature that changes the behaviour of the language. besides, without knowing the compilation options (say, which "dialect" the program is written in), the code may be confusing or more difficult to understand.

[programandala-net]

Bakul Shah escribió/skribis/wrote/scrit (2026-04-18T20:22:53-0700):

It may be useful in some initial code conversion from another language. Once the translated code works, you can remove the flag and fix up all mutability errors.

yes, it may be useful in certain cases. but the feature also opens the door to programs with a different mutability default, depending on a command-line option, i.e. on something which is not explicit in the code itself. it would be clearer if such an option would be explicit in the code, for example with a file-scope directive. then the "dialect" the file is written in would be explicit in any context.

[bakul]

I was just guessing at the reason. Better justification should be provided. If deemed useful, then yes, a file scope directive would be better.

[iperov]

mut, ownership, and other code constraints are merely artificial disciplines for projects accessed by many low-level programmers.

When you're programming alone, you don't need such protections against yourself because you know exactly how the code works. You clearly understand that your code is divided into several independent modules, each performing narrow, well-defined tasks, so mut safeguards are essentially unnecessary.

Moreover, with the advancement of AI, projects are increasingly being developed by single developers. In the AI era, programming languages with such excessive restrictions are no longer needed—they will only slow down both the AI and the human programmer.