Ability to specify export name for struct

[mniak]

Describe the feature

Currently [export: "name"] does not work for structs when exporting C code. I have not tested exporting as a shared library, but I believe that the this is also not supported.

I suggest making it possible to specify the name of the struct that should be used when exporting the code/library.

Example:

module vlib

[export: "MyStruct"]
struct MyStruct{

}

Would produce a C struct named MyStruct instead of the current vlib__MyStruct with a double underscore that looks not like a code that I would write

Use Case

I'm writing a library and would like to distribute also its C version for maximum cross-platformism. The library has structs and I thoght that this:

[export: "TheStruct"]
struct MyStruct {
	field1 int
}

would produce a struct with the name TheStruct in the C file, but it actually generates a struct named mylib__MyStruct.

Proposed Solution

It would be great if the export directive worked with structs because it would make the language more welcoming for people like me that want to develop a library in a language with modern features but also wants the library to work in a wide variety of platforms, and C is the current "de facto cross platform assembly language".

Other Information

Alternative 1:

Allow customization of the module prefix during compilation instead of having the

Example: <compiler and args> --module-prefix mylib="" --module-prefix utils="utilities_"

Alternative 2

Allow customization of the module prefix with a directive on top of the module keyword.

Example 1:

lib1.v

[export_prefix: ""]
module vlib

struct MyStruct{

}

that would produce a struct named MyStruct

lib2.v

[export_prefix: "X"]
module vlib

struct MyStruct{

}

that would produce a struct named XMyStruct

lib3.v

[export_prefix: "mylib_"]
module vlib

struct MyStruct{

}

that would produce a struct named mylib_MyStruct.

Acknowledgements

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

Version used

V 0.3.3 d1f57ea

Environment details (OS name and version, etc.)

OS: linux, "Arch Linux"
Processor: 12 cpus, 64bit, little endian, Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
CC version: cc (GCC) 12.2.1 20230201

getwd: /home/andre/Downloads/vtest
vmodules: /home/andre/.vmodules
vroot: /usr/lib/vlang
vexe: /usr/lib/vlang/v
vexe mtime: 2023-03-09 10:58:59
is vroot writable: false
is vmodules writable: true
V full version: V 0.3.3 d1f57ea

Git version: git version 2.40.0
Git vroot status: Error: fatal: not a git repository (or any of the parent directories): .git
.git/config present: false
thirdparty/tcc status: Error: fatal: detected dubious ownership in repository at '/usr/lib/vlang/thirdparty/tcc'
To add an exception for this directory, call:

    git config --global --add safe.directory /usr/lib/vlang/thirdparty/tcc

Error: fatal: detected dubious ownership in repository at '/usr/lib/vlang/thirdparty/tcc'
To add an exception for this directory, call:

    git config --global --add safe.directory /usr/lib/vlang/thirdparty/tcc

[JalonSolov]

The problem with exporting a struct is that many of the types in V don't match types in C. You would be better off declaring a C struct for both to use.

[medvednikov]

We allow [export] for functions, I think it'd be consistent to allow it for structs.

[JalonSolov]

Yes. It will lead to all sorts of errors when the fields don't match any C types, but it could be allowed.