remove the (namespace) type and make every file an empty struct

[andrewrk]

There's not much of a difference between @typeOf(@import("std")) and struct {}. Here are the current differences for example:

• you cannot instantiate a namespace
• namespaces cannot have fields
• reflection reveals the top level declarations of structs but not namespaces (issue Why zig can not list pub variables name and type in namespace type at compiler time? #1043)
• structs cannot have tests inside them (but why not?)
• structs cannot have use inside them (but why not?)

Making a file be an empty struct instead of a namespace would accomplish the following things:

• solve the "but why not?" questions above
  • this is especially attractive for the reflection use case since one could eliminate redundant code for namespaces and structs
• remove a type from the language, thus making the language simpler and smaller
• if we allowed fields at top level, then it would solve the redundant import problem:

zig/std/index.zig

Lines 3 to 10 in 96164ce

	pub const BufMap = @import("buf_map.zig").BufMap;
	pub const BufSet = @import("buf_set.zig").BufSet;
	pub const Buffer = @import("buffer.zig").Buffer;
	pub const BufferOutStream = @import("buffer.zig").BufferOutStream;
	pub const HashMap = @import("hash_map.zig").HashMap;
	pub const LinkedList = @import("linked_list.zig").LinkedList;
	pub const IntrusiveLinkedList = @import("linked_list.zig").IntrusiveLinkedList;
	pub const SegmentedList = @import("segmented_list.zig").SegmentedList;

Thanks @tgschultz for coming up with this idea.

[bheads]

This is interesting

foo.zig

var x: i32 = 1;

When you var foo = @import("foo.zig"); in multiple places does each foo get is own copy of x? Also what about if you import in a threads function, is that now a thread local instance of foo?

[Hejsil]

@bheads There would only exist one x in your case, as var x: i32 = 1 is a definition and not a field.
This proposal would basically allow us to do this:

// Point.zig
const zero = this{ .x = 0, .y = 0 };

x: u64,
y: u64,

// test.zig
const Point = @import("Point.zig");

test "points" {
    const p1 = Point{ .x = 0, .y = 2 };
    const p2 = @import("Point.zig"){ .x = 0, .y = 2 };
    const zero1 = Point.zero;
    const zero2 = @import("Point.zig").zero;
}

The file will be a struct definition just like if you did const Point = struct { ... };

[bheads]

@Hejsil Right (my usage was wrong) wouldn't we lose global variables? Not the worse thing in the world but can be necessary.

[Hejsil]

@bheads Aah, that's what you were after. No, as structs can have global variables in their "namespace":

const A = struct {
    var a: u8 = 2;
};

test "" {
    A.a = 15;
}

[BraedonWooding]

Though I guess you would more refer to those variables as 'static' usage wise the same.

[Hejsil]

If the type of namespace changes to type, should we follow the naming convention of types?

const Std = @import("std");

[tiehuis]

@Hejsil I would argue no, unless the type had 1 or more fields.

[raulgrell]

• structs cannot have use inside them (but why not?)

At some point I was going to propose use inside a struct as a mechanism for making subtypes. At the time it felt like too much of an overload of use and an inferior solution to embedding the struct in its own field

const A = struct {
    var g = 4;
    a: u8,
    pub fn foo() { }
}

const B = struct {
    use A;
    b: u8 
}

// I'm not sure I'd make this fail only because of the redefinition of a, or because of the differing types
const Fails = struct {
    use B;
    a: f32
}

Where B is equivalent to

const B = struct {
    var g = 4;
    a: u8,
    b: u8
    pub fn foo() { }
}

• structs cannot have tests inside them (but why not?)

Yeah, why not!

[bheads]

@raulgrell that sounds a lot like what D did with alias this, useful for making wrapped types but leads to complexity (ie can you support multiple use?)

[binary132]

This reminds me of ML modules 👍

but also of Java mandatory classes everywhere 👎