Zig: Special name for the current package: `@import("self")`

[xackus]

Proposal: "self" becomes a special package name (like "root" currently is), referring to the current package.

This allows using @import("self") in any file, without specifying a relative path ("../../packagel.zig").

For now, the previous way to refer to the library is the preferred way. The only reason std has itself in its own package map is for this check:

https://github.com/ziglang/zig/blob/a496f94be92581cdf97a1bd60c4dea0369e26395/lib/std/os.zig#L42

I'd like to keep it referring to std.zig because that is what user made packages will have to do and it's nice to keep the std lib code to match the same thing as an example.

If you like we can do a proposal for a special name to be used for a package to refer to itself. For example we already have @import("root") for referring to the application's root source file, but we could also introduce @import("self") which would refer to its own package. Then for the std lib we would no longer put "std" in the package table; we would rely on the "self" feature, which would be available to all packages. Are you interested in making that proposal?

_Originally posted by @andrewrk in https://github.com/ziglang/zig/pull/6278#discussion_r484555160_

[andrewrk]

Accepting now as I think this will be uncontroversial and I don't really see any downsides.

One interesting thing to note is that for applications, @import("root") == @import("self") however that will not be true for libraries.

[MasterQ32]

May i add a follow-up proposal that could be included here:

As @import is a built-in, it might allow both strings (always user packages) and enum literals (.root, .self, .std) to be imported:

const network = @import("network");
const std = @import(.std);

This would make clear that these packages are magic and provided by the compiler whereas every string is to be given on the command line or in build.zig. It would also free those magic package names

[xackus]

@MasterQ32: I don't think this can be done with std because the types used in builtins reside in std.builtin.

[MasterQ32]

@xackus Builtins (as in functions) can accept any type. In this case: A enum literal, not value from a explicit. This means it should work... But some of the compiler/language devs should think about it as well

[daurnimator]

@xackus / @MasterQ32 even a normal zig function can do that:

fn somefunc(a: anytype) type {
  switch(@typeInfo(@TypeOf(a))) {
    .Pointer => .....,
    .EnumLiteral => ....,
    else => @compileError("invalid type to import"),
  }
}

[andrewrk]

@MasterQ32 here's a good place for your follow-up proposal: https://github.com/ziglang/zig/issues/2206