Remove module declaration from .v files

[dmitryuck]

Describe the feature

Since folder determine the module name in V and each folder is a module, can we remove module declarations from .v files?
Then all code in a file will start with imports like in javascript

Benefits of this:

• make module system simpler in language code internally
• one thing less to care about when creating new and renaming existing module
• improve compilation speed (no need to parse, check module names in each file)

Use Case

module my_module // removing this declarations

import ...

Proposed Solution

No response

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

Version used

V 0.4.9

Environment details (OS name and version, etc.)

V full version	V 0.4.9 b91bbad
OS	linux, Debian GNU/Linux 12 (bookworm) (VM)
Processor	2 cpus, 64bit, little endian, Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
Memory	1.24GB/2.02GB
V executable	/home/admin/v/v
V last modified time	2025-01-31 21:25:26
V home dir	OK, value: /home/admin/v
VMODULES	OK, value: .vmodules
VTMP	OK, value: /tmp/v_0
Current working dir	OK, value: /home/admin/playground
Git version	git version 2.39.5

Note

You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote.
Other reactions and those to comments will not be taken into account.

[JalonSolov]

Moved to a discussion as this would be a MAJOR breaking change to V, and the pros and cons will have to be debated, first.

[Jengro777]

If the modification does not introduce new complexity, I agree to do so

[Jengro777]

Display declaration module:

1. "Multiple subdirectories together form a logical module"
   In this scenario, display declaration makes more sense

[dmitryuck]

following the phylosophy one thing one way we have to consider each directory as a module,
if you want to have a subdirectory in the module consider this as a new module, otherwise crate a file in a current module,
In this case no two meanings in module management appear

[jorgeluismireles]

Right now we have a folder cmd or any other name and in it have several files starting with module main and each with a main() function. An we can run/build each as a separate program with v run cmd/file_1.v etc. Removing the module main

• Would require modify the folder cmd name to main?
• Would have at most a single main file per folder?
• main would be an exception?

[jorgeluismireles]

which user put in v.mod

Right now, v.mod is optional, you can make folders and files and run tests and build execs without any .mod. Useful when your code is not to be published as a library for others and/or private. Useful to test or debug copy/paste code reported by others as issues inside your machine when playground is not possible to use. You decide where to put your several module main files.

[JalonSolov]

Actually, you do need a v.mod file, but it can be a 0-length file (just touch v.mod on Linux/Mac/etc.). V uses this file as an anchor point to find local modules.

If you don't have a v.mod file at all, V may not be able to find your modules.

[jorgeluismireles]

you do need a v.mod file

I don't have any v.mod in folder bugs and can test and run V programs without problems:

$ ls bugs/food/fruit/apple
apple_1_test.v  apple_2_test.v  apple.v

$ cat bugs/food/fruit/apple/*
module apple

fn test_apple() {
	assert 'apple' == name()
	assert 3 == colors().len
}
import apple

fn test_apple() {
	assert 'apple' == apple.name()
	assert 3 == apple.colors().len
}
module apple

fn name() string { return 'apple' }
fn colors() []string { return [ 'red', 'yellow', 'green' ] }

$ v test bugs/food/fruit/apple/*
---- Testing... ----------------------------------------------------------------------------------------------------------------------------
 OK    [1/2] C:   312.9 ms, R:     1.454 ms /home/jorge/bugs/food/fruit/apple/apple_2_test.v
 OK    [2/2] C:   312.6 ms, R:     1.789 ms /home/jorge/bugs/food/fruit/apple/apple_1_test.v
--------------------------------------------------------------------------------------------------------------------------------------------
Summary for all V _test.v files: 2 passed, 2 total. Elapsed time: 315 ms, on 2 parallel jobs. Comptime: 625 ms. Runtime: 3 ms.
$

By the way, apple_2_test.v doesn't need a module apple directive and works import apple but is needed to have apple.name() instead simple call name() when you have module apple.

[JalonSolov]

All the files you've shown are in the same directory. Try moving your tests out of the apple subdir.

[jorgeluismireles]

Try moving your tests

I did something similar: Rename my v.mod in another complex project and got errors after that. As you said, complex projects require v.mod. But also, simpler folders like for quick & dirty or simpler don't. This came about having said that v.mod should contain the replacement for main in the remote case V drops module and main as now.

[Wajinn]

Against such a change. Not only that, but think team V needs to be careful.

1) Huge breaking changes, like that and so late in development, can sabotage user trust.

This fans the flames for those looking to call the language unstable or unfocused, whether that's justified or not. Arguably, should avoid doing anything dramatic, unless demonstrably necessary. There is a lot on the todo list, as is.

2) Change would undermine any existing videos, examples, books, or documentation that has it the present way.

Related to that, appears easier to teach the concept of modules to new users, when names are declared.

3) Module declaration creates clarity about which files are for what or if they belong together.

Individual files can be named something weird or unrelated to the directory, and then misplaced or moved. If the misplaced files all have the same unique module name, less of a problem to reorganize them correctly.

[dmitryuck]

1. For the first time , let's say until version 0.6 or 0.... it can be as a warning during compiler like:
   Declaration of module name here is not mandatory, will be removed in future

2. All information has an ability to become obsolete, especially for language which take a shape to become perfect and simple, we cannot rely on videos, examples few years old, (regarding books, as far as I know not too much them for now)

Related to that, appears easier to teach the concept of modules to new users, when names are declared.

without module declaration everything new user need to know is that each folder is a module, files in /src and root folder belong to main module

3. Belonging file to module easily can be understand when you look at file path

Individual files can be named something weird or unrelated to the directory, and then misplaced or moved

this doesn't have a relation with file naming, you can name files whatever you want. In case you misplace or move file, compiler will say that can't found a type which you try to import and use, then you take the type name and search in codebase, and decide what to do, move back or refactor somehow

[JalonSolov]

I think one of the key drivers for this was this phrase: Then all code in a file will start with imports like in javascript.

A standard problem for all new languages... everyone wants something new, but they want it to be just like what they are used to using.

V is like Go in this instance, rather than JavaScipt.

[dmitryuck]

Zig and Rust also don't have that, let's say like Zig or like Rust :)

[JalonSolov]

Ok, then we can also say "V is like Go in this instance, rather than JavaScript, Zig, or Rust."

V doesn't have to be like other languages (including Go), though it does tend to default to Go-like similarities in some cases - like this one. In others, it's not.

[jorgeluismireles]

I see Zig don't have module something but it requires the programmer to end every line with ;. Requires to end with , every enum or array element. Also requires the programmer use more tokens like const std = @import("std"); and requires the extra ( and ) for every if and for. Is removing module more helpful to the programmer's eyes that remove those ;, , and () that V syntax removed for us? I see also Rust is too verbose.

[Wajinn]

Hoped we could avoid the usual drama over languages, so wish the name dropping didn't happen. Many have called out Zig and Rust for being confusing, difficult, and not languages to learn first (that last one comes from many of their own users). There are receipts to back up that statement, though will not fully drop them all here.

Popular programmers like Muratori and Tsoding don't like Zig (and they went deeper than that in their comments). ThePrimeTime just went public, that he is given up on Rust, though is considering Zig (has not used much). Putting that out there, because everybody doesn't agree with what those languages do. Another example, Slant.co (product recommendation site), shows clear votes for V over Zig and Rust as a language to learn first, as a compiled language, for general purpose, its syntax...

Because Zig or Rust does something, does not mean that V has to follow. Looks like that V is presenting itself more as a language that can be the first one to learn, and can be an improvement or alternative for many people.

[Jengro777]

Actually, we just need to discuss the pros and cons of doing so and whether it will introduce new complexity

[JalonSolov]

Correct. It is already known that a change like with will be a MAJOR breaking change to V itself, as well as all currently existing modules.

With that in mind, is it worth making this change? If you think it is, please give concrete examples of why you think it will be worth it. We've already proven "because that's how X does it" is not a compelling reason.