v
v copied to clipboard
vlang
Ability to specify export name for struct
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
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.
We allow [export] for functions, I think it'd be consistent to allow it for structs.
Yes. It will lead to all sorts of errors when the fields don't match any C types, but it could be allowed.