Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: different way to specify exported symbols #462
Problem: We have some messy complications regarding the difference between pub and export.
Here's the proposal:
I think this solves all the problems.
When I made the comments last night I had not put together all the parts. It seems like there are a few mostly-orthogonal things here:
The reason I say mostly-orthogonal is, as you point out, that you need to have both a "global" visibility on a function and have it use the C calling convention in order for C code to call it. So the new export syntax above is only for things visible to C?
As I understand it (and maybe I am missing something important due to my lack of experience with Zig!), a C-callable function differs in two ways from a standard Zig function. It must be visible at the global level and it must use the C calling convention. So you would still use "pub" for module-level entities, right?
Would there be a use case for global entities that are not C-callable? If so, maybe then "export" becomes "global" and you retain the ccc part??
(I moved the original incoherent ideas over to the forum where they belong.)
I have related proposal. Modules (or packages) provide several features:
Here's the proposal about encapsulation:
This way one could:
This proposal also makes things like this more clear:
And now that symbol
and now exporting the main symbol is allowed for the user.