make @import require a string literal rather than a comptime expression

[andrewrk]

Zig's comptime evaluation is already powerful enough to allows conditional importing without having to have the @import target be a comptime expression. For example:

const target = if (builtin.mode == .Debug) "debug_mutex.zig" else "release_mutex.zig";
const mutex = @import(target);

This could be rewritten - and I would even say would be preferred to be rewritten - as:

const debug_mutex = @import("debug_mutex.zig");
const release_mutex = @import("release_mutex.zig");
const mutex = if (builtin.mode == .Debug) debug_mutex else release_mutex;

If import syntax is required to be trivially resolvable to either a file or a package name, then Zig can find all the source files for testing without this kind of thing:

zig/test/stage1/behavior.zig

Lines 1 to 19 in 7c38651

	comptime {
	_ = @import("behavior/align.zig");
	_ = @import("behavior/alignof.zig");
	_ = @import("behavior/array.zig");
	_ = @import("behavior/asm.zig");
	_ = @import("behavior/atomics.zig");
	_ = @import("behavior/bit_shifting.zig");
	_ = @import("behavior/bitcast.zig");
	_ = @import("behavior/bitreverse.zig");
	_ = @import("behavior/bool.zig");
	_ = @import("behavior/bswap.zig");
	_ = @import("behavior/bugs/1025.zig");
	_ = @import("behavior/bugs/1076.zig");
	_ = @import("behavior/bugs/1111.zig");
	_ = @import("behavior/bugs/1120.zig");
	_ = @import("behavior/bugs/1277.zig");
	_ = @import("behavior/bugs/1322.zig");
	_ = @import("behavior/bugs/1381.zig");
	_ = @import("behavior/bugs/1421.zig");

There is still a problem though, because if zig ran all tests indiscriminately, this would stop working:

zig/std/os/linux.zig

Lines 1537 to 1541 in 7c38651

	test "import" {
	if (builtin.os == builtin.Os.linux) {
	_ = @import("linux/test.zig");
	}
	}

The general problem here is that @import has compile-time side effects:

• changes the set of unit tests
• causes additional symbols to be exported, with export or @export - potentially conflicting.
• could cause @compileError to trigger based on build mode or something else in top level comptime blocks.
• could cause a @cImport which causes a compile error

It would be weird to activate these side effects for tests but not for other builds. And these side effects are important; they're not going away.

So I think the benefits of this proposal are not clear. But I think this is a sort of important topic in Zig so it deserves an issue that we can reference.

[Vexu]

One thing to consider here is that the path might be a compile time variable from somewhere like @import("build_options").

[andrewrk]

One thing to consider here is that the path might be a compile time variable from somewhere like @import("build_options").

const tag = @import("build_options").which_package_do_you_want;
const thing = switch (tag) {
    .one => @import("one.zig"),
    .two => @import("two.zig"),
}

This pattern will work for the linked use case, and it will help with static code analysis tools. Is there another use case that would be problematic?

[minierolls]

How would you handle the case of when a user might want to specify a path to include? (e.g. through command line args or maybe a loaded "build configuration" file)

[Vexu]

That could be better handled by having the build file declare a package pointing to that file.

[minierolls]

How would the build file declare a package if @import only allows for string literals? I might be missing something here.

Edit: Sorry, realized that this was under the assumption that addPackage used @import in its implementation, which I now realize is not the case(?)