Replies: 4 comments 14 replies
-
Shame I missed this discussion by two years. I was just about to open a new one about this, but I'll answer here instead. So, I've been creating bindings for GLFW and WebGPU. Both have a tendency for name collisions within themselves (GLFW manages different input methods like mouse and joystick), with each other (GLFW and WebGPU refer to renderer instances) and with the standard library (GLFW defines its own allocator interface). And while I enjoyed C3 so far in most other aspects, trying to organize any project of some size has been more troublesome than I imagined. A few of the issues I've encountered so far:
module namespacing;
import std::io;
import glfw;
import foo;
import bar;
fn void main(String[] args) {
// where does button come from?
button::Button button;
}
module glfw;
// ... other stuff
module glfw::mouse::button;
enum Button {
LEFT,
RIGHT
}
Let's assume the code above compiled perfectly. module glfw::joystick::button;
enum Button {
ONE,
TWO
} Even if you have no intention of using that, you now have to change
While I was thinking about how to solve these issues for my libraries and then incidentally also encountered this commit regarding QOI: So I take it event the standard library suggest one should put namespaces on all struct names to prevent future namespace clashes? Don't get me wrong, these aren't game breaking problems. def Button = mouse::button::Button; It's just that I don't really see what problem the implicit recursive imports solve, but a lot of problems we would not even have to think about without them. |
Beta Was this translation helpful? Give feedback.
-
I would mostly compare it to C, and try to see if it has a similar look-and-feel. For instance, there is a Contrast this to functions, where the module is intended to bring context to the name, so that for example If we'd follow the same principle with the allocator, it would be |
Beta Was this translation helpful? Give feedback.
-
A possibility: import std::io; // recursive
import std::io @norecurse; // non-recursive |
Beta Was this translation helpful? Give feedback.
-
See #1480 for the issue to track for non-recursive imports. |
Beta Was this translation helpful? Give feedback.
-
Currently, imports are all implicit. In practice, it's likely that explicit imports will be better when using external libraries.
However, as previously discussed, recursive imports (e.g.
import foo::*
) are likely to be common in C3 as it is encouraged to use sub modules to organize functions.I am therefore considering making imports implicitly recursive, so that
import std::io;
would be the sam of today'simport std::io::*;
In making this change the current implicit import-less scheme would be removed.However, one important question remains, which is what should be visible from a sub module and a parent module respectively.
Let's say we have the following modules:
std::io
,std::io::net
,std::io::file
We then roughly have the following possibilities:
std::io
doesn't seestd::io::net
nor vice-versa)std::io
seesstd::io::net
but not vice versa.std::io::net
seesstd::io
but not vice versastd::io::net
seesstd::io
and vice versa, butstd::io::net
does not seestd::io::file
std::io::net
seesstd::io
andstd::io::file
(and would even see things likestd::mem
andstd
).Of these, the bidirectional visibility (4) seems the most promising. What do people think?
Beta Was this translation helpful? Give feedback.
All reactions