proposal: enforce files to be `opaque` but add default `pub`

[nektro]

this rides off the back of #6617 but provides a new solution that also makes Zig simpler while allowing more freedom and explicitness.

many Zig projects, including Zig itself, take advantage of the side effect that files are processed as structs to reduce the amount of characters needed to be able to do something along the lines of const Compilation = @import("Compilation.zig");. However, this shortcut is inconsistent, requires this knowledge of the compiler internals, and only works with structs.

But the idea of a file representing a single unit of code is very common and in that very same file, we have const Value = @import("value.zig").Value; and const Type = @import("type.zig").Type; because the main value of those files is an extern union and not a struct so the bare import trick doesn't work.

The syntax would roughly look like pub default <const|var> <expression>;. Other pubs in the namespace would be compile errors.

Ideally, this proposal would also enforce #6617 getting accepted, but offers a solution that allows all the following to work:

• const Compilation = @import("Compilation.zig");
• const Value = @import("Value.zig");
• const Type = @import("Type.zig");

since you would be able to default export any type, whether it be a struct, union, enum, fn, etc.

Compilers don't need files to make a program, but they're critical for the human organization of code.

So parsing this file would look like reading the top level declarations, if a default pub is found, then the type of the file is the value of the expression, otherwise the file is an opaque type with the discovered declarations.

[g-w1]

One thing that this doesn't consider is this top-level syntax for structs

x: u32,
y: usize,
<some functions>

Now, everything must have at least one level of indentation, which can hinder readability.

pub default const struct {
    x: u32
    y: u32
    <functions>
};

[nektro]

Now, everything must have at least one level of indentation, which can hinder readability.

I would argue the exact opposite, given the reasoning I listed in the issue.

[ifreund]

this rides off the back of #6617 but provides a new solution that also makes Zig simpler while allowing more freedom and explicitness.

I disagree that adding new syntax and semantics makes zig simpler.

While I do appreciate ##6617, I don't see what's wrong with @import("type.zig").Type. Sure, it's a bit more typing (zing!), but it gets the job done and it's clear.

[nektro]

because it breaks the model that you're using that file for a single unit of organization. its not really about the effort here but making things more concise, explicit, and consistent. I dont think you should be able to do @import("Compilation.zig") but then have to do @import("Type.zig").Type. We should pick one and adjust accordingly.

If we're picking one, I vote the latter. Less to remember that way.

[mikdusan]

if we were looking to complete the trifecta, I'd prefer syntax like so:

// this file body is a struct
@This() = struct;

// a union(enum)
@This() = union(enum);

// an enum
@This() = enum;

[nektro]

@mikdusan that is very unpragmatic code. you can't assign to a function call.

[g-w1]

Yes you can: ```zig @field(obj, "str") = true; ```

…

On Mon Jan 25, 2021 at 7:13 AM EST, Meghan wrote: @mikdusan that is very unpragmatic code. you can't assign to a function call. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #7881 (comment)

[mikdusan]

yes, @field() is the perfect example of a builtin used as lvalue.

[agathazeren]

A use case for this is library-level parameters. Your package root can then be a function, which takes the library level parameters, without having to come up with a name for it.