zig icon indicating copy to clipboard operation
zig copied to clipboard

[Proposal] Allow `@export` to export any value, not just a declaration

Open mlugg opened this issue 2 years ago • 1 comments

Currently, the first argument to @export needs to be a name of some sort. Quoting from the documentation:

declaration must be one of two things:

  • An identifier (x) identifying a function or a variable.
  • Field access (x.y) looking up a function or a variable.

Once #14796 lands, this restriction seems pretty needless. @export(comptime get_my_u32(), .{ .name = "foo" }) has a clear meaning which is no harder to lower (you just need the behaviour implemented in that PR). The only necessary restriction on this builtin is that the first argument is:

  • comptime-known; or
  • some (comptime-resolvable) reference to a global, including a plain identifier, field access, array access, etc.

Put more simply, it's just any expression x where &x is comptime-known.

Exporting an arbitrary comptime-known expression is already possible by simply putting it in a const first (since that variable is comptime-known, it is then able to be exported). But making this change would simplify the language by removing a needless restriction.

An alternative approach, which is arguably clearer, is to make @export actually take a pointer; so rather than @export(foo, ...), you have to do @export(&foo, ...). This makes @export a nice parallel to @extern, as well as making @export even less of a special-case: it has no specific restrictions on its argument at all other than that it has to be a comptime-known pointer. I don't have strong feelings either way on this.

mlugg avatar Mar 14 '23 12:03 mlugg

I definitely much prefer the option of @export taking a pointer, since it mirrors @extern and simplifies the rules.

silversquirl avatar Mar 14 '23 12:03 silversquirl

Accepted variant is to take a pointer.

mlugg avatar Sep 22 '23 19:09 mlugg