Why V doesn't have "modular variables"?

[gchumillas]

That is, you can declare mutable global variables:

__global(
    newline = false
    tabs = 0
)

But why can't we declare "modular variables"? Variables accessible only at module scope:

module my_custom_module

// These variables are accessible only at module scope
mut newline := false
mut tabs := 0

Instead, we are forced to follow an approach similar to object-oriented programming.

[gchumillas]

This is the origin of my frustration:

struct MyStruct {
    my_var int
}

// the `aaa` method does not mutate `my_var`
fn (m &MyStruct) aaa() {
    println(m.my_var)
}

fn (m &MyStruct) bbb() {
    m.aaa()
}

fn (m &MyStruct) ccc() {
    m.aaa()
}

Both the bbb() and ccc() methods use aaa(), which does not mutate the variable my_var. However, if I suddenly decide that aaa() should mutate the variable my_var, I would have to change the receiver of all the methods that use the aaa() function. That is:

struct MyStruct {
mut:
    my_var int
}

// the `aaa` method mutates `my_var`
fn (mut m MyStruct) aaa() {
    m.my_var++
}

fn (mut m MyStruct) bbb() {
    m.aaa()
}

fn (mut m MyStruct) ccc() {
    m.aaa()
}

That is, a simple change in strategy forces me to modify a lot of code that is unrelated to that decision.

[gchumillas]

According to Claude "opinion" :)

V sanctions global variables for the classic reasons that have dominated language design for decades, but which ironically contradict your initial point about modular simplicity.

The "official" reasons why V requires -enable-globals:

V doesn't allow global variables by default, but recognizes that "in low-level applications they have their place" and allows enabling them with the Global Variables compiler flag. Traditional arguments against global variables include:

• Implicit coupling: Any function can modify any global variable, creating hidden dependencies
• Concurrency problems: In multithreaded environments, global variables can cause race conditions
• Difficulty testing: It's harder to isolate and test functions that depend on global state
• Namespace pollution: Risk of name collisions

But here's the irony:

V forces you to use structs and methods (with all the complexity you just described), but then makes it difficult to use the simple modular approach you propose. It's as if it artificially pushes you toward objects.

The philosophical problem:

V seems to be applying anti-global dogma without considering that modular variables (not really "global" but scoped to the module) are different. A variable that is only accessible within a specific module doesn't have the same problems as a truly global variable.

Languages ​​that do it better:

• Go: Allows package-level variables without drama
• JavaScript modules: Module variables are private by default
• Rust: Static variables are explicit but not prohibited

It seems V is being conservative to the point of contradicting his own philosophy of simplicity. Your frustration is totally valid—he's forcing you toward object complexity while penalizing the simple approach you'd prefer to use.

[JalonSolov]

"modular variables" - your words - are just namespaced globals.

They have all the same problems that full globals do, just slightly narrowed due to the namespacing.

Yes, they are simpler to use, but oh, so much harder to debug, since they can be modified from anywhere in the code.

[gchumillas]

I think you're right.

I was working on the JS backend in my free time and found something that caught my attention:
https://github.com/vlang/v/blob/master/vlib/v/gen/js/js.v#L43

The JsGen structure is instantiated only once and contains mixed properties used in different files within the module. For me, this was a way to emulate the absence of "namespace variables".

But what if we want to run the gen function twice? Or worse, what if we want to run the gen function twice in parallel? If we use namespace variables, it could lead to a potential race condition:

// possible race condition
go js.gen(...)
go js.gen(...)

By using a structure, we ensure that the gen function uses only its own properties, thus avoiding the race condition and ensuring the properties are correctly initialized.

This also reminds me that we should use AI models with caution :)

[ghost]

"modular variables" - your words - are just namespaced globals.

No, modular variables should be private to the module -- at least by default -- in the same way that functions are by default private to the module. So they're not just "namespaced globals". (They're not globals at all.)

so much harder to debug, since they can be modified from anywhere in the code.

A private module-variable would of course not be modifiable from code outside the module.

[jorgeluismireles]

I had a similar problem, a method returned read-only elements from a matching list. Then I needed return writeable elements to write some fields so I would had to change all the callers adding mut . I decided instead to leave the original method renamed to box_read and the new one as box_write with mut, something like these:

pub fn (b Boxes) box_read(src u8, box_fn fn(box Box)!) ! {
	for _, box in b.boxes {
		if box.on && box.id == src {
			box_fn(box) !
		}
	}
}

pub fn (mut b Boxes) box_write(src u8, box_fn fn(mut box Box)!) ! {
	for _, mut box in b.boxes {
		if box.on && box.id == src {
			box_fn(mut box) !
		}
	}
}

I though was better to prevent read only callers from having mutable access and modifying any they should not and adding extra muts.

[JalonSolov]

... and since those are methods on Boxes, you could shorten the names to just read and write. :-)

[jorgeluismireles]

Yes, is something attractive to do... but... Since V does not have method overloading next is invalid

pub fn (b Boxes) read(box Box) { ... }
pub fn (b Boxes) read(config Config) { ... }

Method overloading is valid in Java and you can have several read methods with different arguments but I have found that they difficult to debug, so I find is better to be a little bit more verbose this time and like C do the

pub fn (b Boxes) read_box(box Box) { ... }
pub fn (b Boxes) read_config(config Config) { ... }

I think is time that someone could start writing about V patterns and anti-patterns. Because V mut "filter" is very handy and tricky to use. Also comes to mind, also mentioned in this discussion, the Java singleton pattern, where you have a single instance of a static object that even can be thread safe, synchronized internally. V could have a singleton whether with __global or another construction.

Actually one wonder also what is "better" box_read and box_write or read_box and write_box

[JalonSolov]

I was thinking more

pub fn (b Boxes) read(box Box) { ... }
pub fn (b Boxes) read_config(config Config) { ... }

or you could have a separate Configs struct, so it would be

pub fn (b Boxes) read(box Box) { ... }
pub fn (c Configs) read(config Config) { ... }

or something along those lines... whatever makes the most sense.

[JalonSolov]

In other words, if you're reading the same type as the struct the method is attached to, you don't need to specify what is being read.

[lignx]

Module variables, or "Module State"

Upvoted. Recommended for V lang.

Finding myself needing this, a lot.

Module variables can greatly simplify programs in many cases.

• It can replace deep chains of parameter passing.

• It can simplify weird state-keeping inside of module functions.

• It can replace the need to use objects, in many cases.

• Easy to opt-out: simply don't put any variable declarations, at top module level.

• It allows to write elegant code.

• Remember to pay attention to module-scoped variables, to avoid confusion.

Valid in C language

Importantly. Module state is already valid in C language.

This will bring V code to parity with C lang.
It would make translation of C code, easier, more straightforward.
As it would not put top-level module variables inside of __global

Example code

module my_custom_module

// These variables are accessible only at module scope
mut name := "Person"

// PUB option: This variable can be imported in other modules
pub mut module_var := 5   


fn main() {
    // Say hellocode:
    println("Hello ${name}")
}

// Imagine that you needed `name` in the last function call, of
// a 4-level nested chain of function calls.
//
// Without Module-state, you have to pass parameters in all 4 functions.
//
// With module-state, you can simply call the variable in the last function.
// No need for clumsy excess parameters.

Conclusion

Module variables can greatly simplify code.
Simpler code -> Less trouble -> less bugs -> Easier to maintain

[jorgeluismireles]

We already have "module functions" so a "workaround" can be using static variables

File america/us/texas/houston.v

module houston

pub fn population(p ...int) int {
	unsafe {
		mut static pop := 2_350_000
		if p.len == 1 {
			pop += p[0]
		}
		return pop
	}
}

File main.v

import america.us.texas.houston

fn main() {
	houston.population(1) // would houston.pop++ aka birth
	houston.population(1) // would houston.pop++ aka birth
	houston.population(-1) // would houston.pop-- aka death
	println('pop ${houston.population()}') // would println('${houston.pop}') 
}

The method should be written, but can be improved internally for access protection for multi-threading apps. IMHO I think sooner or later a pattern emerges and one ends making object oriented programming.

[ghost]

Hugely important, this. I'm puzzled that it hasn't received more attention. As I see it, the inability to store module state affects the usability of the entire language. The points made by xzzulz are all quite valid, and indeed it's something that C has always had (static keyword used at the file level).

Also, what's the use of a module's init function if you can't statefully keep whatever you initialize there? What about database connections? Open file handles? Thread pools? What about memoized function results? What about caches? Where are you going to keep all that stuff if global vars are out, and static vars are "possible (using unsafe) but discouraged"?

Do correct me if I'm wrong. I'm very new to V, and I love the syntax, and how fast it is, and many other things. But I've no idea how I'm going to write a non-trivial app if there's no canonical way for modules to keep state. Having to resort to keyword unsafe (in order to have static vars) within hours of getting to know the language just feels wrong.

[jorgeluismireles]

the inability to store module state

I think V is able to store module states, and the state is writable and readable with a single public module function, see here for module main: https://play.vlang.io/p/2c8d313a6f . Works for any other modules.

[ghost]

The example you linked uses a *function-level* static var, not a module level var. How does a function-level static enable me to open a DB connection in a module's #init function, and use that DB connection later in another function in the same module? (Answer: it doesn't.)

…

-- Earnest ***@***.***)

On Thu, 7 Aug 2025, at 15:25, Jorge Mireles wrote: > the inability to store module state > I think V is *able* to store module states, and the state is *writable* and *readable* with a *single* public module function, see here for module `main`: https://play.vlang.io/p/2c8d313a6f . Works for any other modules. — Reply to this email directly, view it on GitHub <#24709 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BVV5KDFB2RMTGXKW2N53L2T3MNVWXAVCNFSM6AAAAAB7GRB252VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMBTGYZDSOA>. You are receiving this because you commented.Message ID: ***@***.***>

[jorgeluismireles]

Yes, a function is needed and if were not public only module code could access the state only. But V is not C and the function hides the static object. Also I haven't check how init and cleanup would interact with such function. IMHO objects are better to manage shared objects that sooner or later need synchronization for web apps. Ultimately V calls C and there you could have your statics.

[ghost]

I haven't check how init and cleanup would interact with such function.

No offense but it sounds like you're not particularly qualified to comment on the matter.

…

-- Earnest ***@***.***)

On Thu, 7 Aug 2025, at 17:50, Jorge Mireles wrote: Yes, a function is needed and if were not public only module code could access the state only. But V is not C and the function hides the static object. Also I haven't check how `init` and `cleanup` would interact with such function. IMHO objects are better to manage shared objects that sooner or later need synchronization for web apps. Ultimately V calls C and there you could have your statics. — Reply to this email directly, view it on GitHub <#24709 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BVV5KDAO6MI4ZHGNGAN26R33MOGXHAVCNFSM6AAAAAB7GRB252VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMBTG44DEMY>. You are receiving this because you commented.Message ID: ***@***.***>

[Wajinn]

I'm in agreement with JalonSolov on this. Do not think modular variables are needed and struct fields can be used instead.

Many people are used to just throwing in global variables as a matter of habit. Part of the confusion appears to come from not clarifying and showing examples of what to use instead of global variables in V's documentation. Team V needs to be more aware of the habit, and arguably should take a few extras steps to explain and give examples of what to do instead.

[JalonSolov]

V and D have nothing to do with each other. If you found similar phraseology, that is coincidence, not plagiarism.

It is completely feasible to have module private state with V's current style of code.

As suggested, create a struct. Do NOT declare any fields in it as public - only allow access/modification outside the module via methods on that struct.

[ghost]

It is completely feasible to have module private state with V's current style of code.

How? I've asked several times and you nor anyone has given a clear answer.

Let's say I'd like to keep a single integer as a module's private state. I'd like to set it to 42 in the module's #init method, and I'd like this value to be accessible and modifiable from inside all the module's methods, but not from anywhere outside the module.

Please show me a code snippet that demonstrates how to do this.

[JalonSolov]

.
├── main.v
├── my_module
│   └── m.v
└── v.mod

my_module/m.v:

module my_module

struct MyStore {
mut:
        my_int int = 42
}

pub fn MyStore.new() MyStore {
        return MyStore{}
}

pub fn (m MyStore) get_stored_int() int {
        return m.my_int
}

pub fn (mut m MyStore) set_stored_int(n int) {
        m.my_int = n
}

main.v:

import my_module

fn main() {
        ms := my_module.MyStore.new()

        println(ms.get_stored_int())
}

$ v run .
42
$

[JalonSolov]

Note that all the functions in the module are receiver methods on the struct, or the static new function to allocate an instance of the struct.

[ghost]

Oh boy... You're simply returning a struct out of the module, wrapping the int. You're not keeping the state inside the module.

At this point it's perfectly evident that you either don't understand the matter, or you pretend not to understand it. Either way, discussing it with you further can serve no purpose.

Moreover, seeing as how no way to keep module-private state has been shown me in spite of quite a few back-and-forths, and seeing as how even Mr. Medvenikov refuses to comment in spite of the request I sent him, I can only conclude that it is impossible in V to keep state inside the module -- as I suspected from the moment I joined this thread. (.)

I'm writing V off as unusable, and blocking you for good measure.