Revised import rules

[lerno]

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's import 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:

1. No implicit imports in the hierarchy (std::io doesn't see std::io::net nor vice-versa)
2. Top down implicit imports: std::io sees std::io::net but not vice versa.
3. Bottom up implicit imports: std::io::net sees std::io but not vice versa
4. Bidirectional: std::io::net sees std::io and vice versa, but std::io::net does not see std::io::file
5. Full module visibility: std::io::net sees std::io and std::io::file (and would even see things like std::mem and std).

Of these, the bidirectional visibility (4) seems the most promising. What do people think?

[TheOnlySilverClaw]

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:

1. When there's multiple imports, there's no indication where submodule qualifiers are even coming from.

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
}

2. Unexpected collisions:

Let's assume the code above compiled perfectly.
Then someone adds a submodule with a colliding name:

module glfw::joystick::button;

enum Button {
	ONE,
	TWO
}

Even if you have no intention of using that, you now have to change button::Buttonto mouse::button::Button on every colliding usage.

3. Pro-active redundant namespacing:

While I was thinking about how to solve these issues for my libraries and then incidentally also encountered this commit regarding QOI:
d4fb5b7

So I take it event the standard library suggest one should put namespaces on all struct names to prevent future namespace clashes?
Which means when the ecosystem grows, there might eventually be a lot of ever longer struct names to circumvent these problems.

Don't get me wrong, these aren't game breaking problems.
Apparently, most of them can be locally resolved by rust re-def-ining the types wherever they collide:

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.

[lerno]

Thank you for this discussion. I have a lot of thoughts on the subject and I definitely value feedback on this. Let me go through them.

• The implicit recursive import is an experiment. I've found some cases where I don't like it, so I've been thinking of changing it. After all, something like import std::io::*; would not be particularly onerous for people wanting the recursive import!

• The QOI situation is interesting. I consider Desc or Button exceptionally poor naming unless you are deliberately name-squatting on a concept. I encountered things like Context in some libraries in Java. The name that actually reflected the meaning would have been SSLContext (or whatever it was). So my conclusion is that this is less of a problem if things are properly named. Now I didn't write those bindings, but using Button is just setting things up for grief later on – recursive imports or not!

It is fine to use Button in non-library code, but name squatting the Button or Context name is just wrong and I don't think anything can save that.

• Finally there is a useful mechanism in the case this happens – using def:

import glfw;
import foo;
import bar;

// This button is our favourite button:
def Button = glfw::joystick::button::Button;

fn void main(String[] args) {
  // No ambiguity, will always match 
  // glfw::joystick::button::Button     
  Button button;	
}

[TheOnlySilverClaw]

The implicit recursive import is an experiment. I've found some cases where I don't like it, so I've been thinking of changing it. After all, something like import std::io::*; would not be particularly onerous for people wanting the recursive import!

That would have exactly been my suggestion, if you really wanted to keep the behavior.
Personally, I prefer importing submodules explicitly in most cases.

The QOI situation is interesting. I consider Desc or Button exceptionally poor naming unless you are deliberately name-squatting on a concept. I encountered things like Context in some libraries in Java. The name that actually reflected the meaning would have been SSLContext (or whatever it was). So my conclusion is that this is less of a problem if things are properly named. Now I didn't write those bindings, but using Button is just setting things up for grief later on – recursive imports or not!

I would disagree here. I would say Context out of... well, context, is a bad name, but ssl::Context tells me what I need just fine. Given that the resolution mechanism treats the namespace accordingly.

I actually rarely have naming problems with Java, unless I

• explicitly import some_big_package.* multiple times in a file
• have to do some mapping of the same domain objects to some other representation, like an entity model to a JSON object

And btw, I'm doing Java for my job. I'm fleeing to C3. ;)

I would have named Desc something like ImageDescription or ImageFormat. Because that would have more informative meaning. But I wouldn't care to name it QoiImageFormat, when it's already in a module named qoi. There's no additional information in duplicating the prefix. And in C3, if I need to use both in the same place, I can just qualifiy qoi::ImageFormat and png::ImageFormat, which is great!

The annoying part is when qualifiers become necessary for names that aren't even used.

Finally there is a useful mechanism in the case this happens – using def:

That's actually what I mentioned above. Might not have been clear.

However, I would argue, if you only knew GLFW superficially, you'd read this code wondering why the def would be necessary:

module namespacing;
import glfw;

def Allocator = std::core::mem::allocator::Allocator;

fn void main(String[] args) {

	Allocator allocator;

}

[lerno]

In Java, as you know, if you'd import something which has a name collision like foo.bar.Context and baz.abc.Context you'd have to disambiguate it with the full path. Aside from Context and a few similar I've never seen this needed to be used. In the few cases when it was needed it was because the class name was generic and bad.

But there is another issue. Even without collisions, a name like "Context" is saying absolutely nothing to the reader what it does. SSLContext? That's quite clear. "ParserContext" etc. I don't really want people to rely on namespacing except for very special cases. And if someone is actively using names that is conflicting with the standard library, then that's really a mistake that this person did, and not really a problem the language can solve.

Like I was asked the question "well, we know that people should do com::foo::mylib::io and com::bar::somelib::io, but what if everyone starts using io as their module names???". Again if one deliberately violates language recommendations it's hard to say the language should accommodate people making poor naming decisions against all recommendations.

The best is always if types are unique enough to not require prefixes. It's like that because I prefer FooList over foo::List and that just works overall better with namespaces.

The recursive import though... that could possibly be dropped.

[Caleb-o]

One thing I like from Rust, is how it handles imports. I believe you can do a recursive import with * like a lot of languages, but you can also write something like mymodule::{symbol1, symbol2}; to import specific things. You can also use self like mymodule::{ self, symbol1 } so that you can use the module name later to use mymodule::other_thing().

I feel if C3 had more options around its imports, it could solve a lot of problems where people have concerns around naming collisions etc. Rust also allows as in the import, so you can alias a symbol if needed. With Rust's import system, I've never had any issues around collisions or confusion around where things come from. Something like this should give people the ability to do both FooList and foo::List if they so pleased.

Just a thought though.

[TheOnlySilverClaw]

I don't really want people to rely on namespacing except for very special cases. And if someone is actively using names that is conflicting with the standard library, then that's really a mistake that this person did, and not really a problem the language can solve.

I'm honestly a bit confused by this. C3 already brings surprisingly good tools for dealing with namespaces. So why not make use of that?
I agree Context would be an unhelpful name on its own. That's why I would actually prefer that you'd always have to use the namespace, either in the import or as a qualifier. And ssl::Context looks quite elegant to me.

The recursive import though... that could possibly be dropped.

I'd appreciate that. Or making them explicit with ::*.

I agree imports in Rust are quite good. They just overdid it a little with stuff like crate:: and all the different combinations it allows.

I really like this approach in C3, where things have simple names in their respective namespace and when there's ambiguity in a different context, you can just resolve it as needed:

module namespacing;
import glfw;

def MouseButton = glfw::mouse::Button;
def JoystickButton = glfw::joystick::Button;

fn void main() {

	MouseButton button;

}

Even this works perfectly already:

module namespacing;
import glfw;

def Allocator = mem::allocator::Allocator;
def GlfwAllocator = glfw::allocator::Allocator;

fn void main() {

	Allocator allocator;
	GlfwAllocator glfwAllocator;
}

[lerno]

I would mostly compare it to C, and try to see if it has a similar look-and-feel. mylib::some_function() feels like C, because we can naturally imagine the name being mylib_some_function() with any (good) C API. Types are a different matter. Because they should in general already have unambiguous names, I really don't want to encourage the mylib::Context. People are free to use this of course, but ambiguous type names are a bad practice.

For instance, there is a Mutex type in the SDL2 bindings. There is also a std::threads::Mutex type. If someone would see Mutex in a game what would they assume that type was? Well I bet people familiar with the C3 stdlib would assume the latter. But if it was SDLMutex there would be no ambiguity at all. I don't think sdl::Mutex is a solution, because I don't want to write threads::Mutex or allocator::ArenaAllocator everywhere on the off-chance that someone decided that it was a good idea to have an ambiguous name.

Contrast this to functions, where the module is intended to bring context to the name, so that for example file::open relies on the file path to disambiguate it.

If we'd follow the same principle with the allocator, it would be arena::Allocator, libc::Allocator. However, this would require creating modules just for the sake of naming, which is problematic – especially if you consider generics, not to mention that we'd have to do allocator::arena::Allocator if anyone used the same scheme in other libraries, if you know what I mean.

[TheOnlySilverClaw]

I would mostly compare it to C, and try to see if it has a similar look-and-feel. mylib::some_function() feels like C, because we can naturally imagine the name being mylib_some_function() with any (good) C API. Types are a different matter. Because they should in general already have unambiguous names,

Great support for modularity is one of the main reasons I tried C3 instead of both C and Zig. If you want to stick to C, that's your call to make, but a global namespace might not be the aspect that needs retaining.

For instance, there is a Mutex type in the SDL2 bindings. There is also a std::threads::Mutex type. If someone would see Mutex in a game what would they assume that type was?

I don't think sdl::Mutex is a solution, because I don't want to write threads::Mutex or allocator::ArenaAllocator everywhere [...]

But you don't have to assume or repeat yourself.

You can clearly spell out

def Mutex = sdl::Mutex;

And if you ever need to use both in the same place (which I assume would rarely happen, since they both cover the same use case), there's always the fallback;

def Mutex = std::threads::Mutex;
def SdlMutex = sdl::Mutex;

If we'd follow the same principle with the allocator, it would be arena::Allocator, libc::Allocator. However, this would require creating modules just for the sake of naming, which is problematic – especially if you consider generics, not to mention that we'd have to do allocator::arena::Allocator if anyone used the same scheme in other libraries, if you know what I mean.

I would not follow that principle though, because that's a different case. Allocators behave differently, are used for different use cases and often mixed in the same place. So I'm perfectly fine with the current naming scheme distinguishing the type names themselves.

As a side note, I only ended up going down that route of using modules for naming because I couldn't use enums for certain values and that was one of the suggested workarounds.

[lerno]

I've in my experience never encountered a case where an ambiguous type name + namespacing has been preferred over a clear single type name. I understand that your experience might be different, but I have to rely on my personal experience to make this judgment call.

On one hand we have people who advocate even full paths (e.g. Zig proponents), on the other side of the divide people insist that namespace folding should be the standard.

We have all probably experienced the "joy" of repeatedly writing std:: everywhere when programming in C++ as the unadorned string would usually mean some custom (non std) string.

I've tried to find a different compromise that has more to do with what I've seen work over time than more hypothetical needs. All module resolution schemes are trade-offs.

The "alias the import" suffers from the need to do consistent naming, coming up with names and be understandable by a reader who might not have seen the import statement.
The "fold the namespace" suffers from having to have longer names to avoid function name ambiguities.
The "the full module path" suffers from readability issues.
The C3 solution has the limitations we discuss above.

I don't think there is a perfect trade-off.

Somewhat off topic, C3's scheme is very similar to Java in practice:

1. Java classes, like C3 types, are almost never prefixed with the package names.
2. Java static methods, like C3 functions are generally used with a single prefix. In the Java case, it's the name of the class, in C3 it's the last path section: Compare File.open("abc.txt") and file::open("abc.txt")

So I guess that what I'd like answered is that if in practical Java usage this scheme works, why would it not work for C3?

(Yes I know that this isn't the full namespacing rules of Java, but it's in practice the relevant ones)

[TheOnlySilverClaw]

On one hand we have people who advocate even full paths (e.g. Zig proponents), on the other side of the divide people insist that namespace folding should be the standard.

Well, full paths were my main issue with Java's packages. Elevated by the convention of using whole domain names, so you'd end up with

some.big.framework.domain.Context someContext;
other.huge.library.stuff.context.Content otherContext;

with no way to redefine the name.
C3 is already a huge improvement over that.

[lerno]

Well, full paths were my main issue with Java's packages. Elevated by the convention of using whole domain names, so you'd end up with

Wait?? Are people doing this these days? I know the "modern" Java community were off in the wrong direction the last I looked, but that's certified insanity. So incredibly bad and divorced from what's ACTUALLY good practice.

[lerno]

A possibility:

import std::io; // recursive
import std::io @norecurse; // non-recursive

[TheOnlySilverClaw]

Obviously I'd like it the other way round. :)
I mean, one would usually require more import statements doing non-recursive, so a proper equivalent would be:

import std::io;

import std::io @norecurse;
import std::io::file @norecurse;
import std::whatever @norecurse;
import std::foo @norecurse;

or

import std::io @recursive; // or @recurse;

import std::io;
import std::io::file;
import std::whatever;
import std::foo;

Obviously that would break some existing code, but I think at this point in time, most people using C3 are expecting some major changes.

[lerno]

Remember that C3 offers the way to declare multiple modules, and the attribute would apply to all of them:

import std::io, std::io::file, std::whatever, std::foo @norecurse;

[lerno]

But I would prefer to avoid the attribute, maybe there is some operator or keyword I've overlooked.

// A discarded possibility for non recursive imports (period indicating no recurse)
import std::io., std::io::file.;

[Caleb-o]

What if it maybe used a bang?

import std::io!, std::io::file!;

Or carrot

import std::io^, std::io::file^;

Just trying to think of a more noticeable character. A period might be missed on a glimpse of imports.

[lerno]

Yeah, "." is pretty unreadable. ^ is kind of ugly but works (! is already so overloaded that I don't want to consider it)

[lerno]

See #1480 for the issue to track for non-recursive imports.