Zig: Proposal: Concerning Zig Structs

[bjornpagen]

Zig needs to figure out what a struct is, and stick to its guns about it

Is it an encapsulating class? Is it a general namespace? A c-like struct?
It's clear that users of zig all have different answers (and visions) to what they want a struct to look like.

Structs in Zig as they stand right now, do not fit into any of the above categories. They have aspects of being classes, since they can contain functions, and public and private fields (although they don't do anything: #569. They have aspects of being namespaces, as they can contain functions. And they have aspects of being c-structs, since they are concrete, unabstracted, blocks of data. Zig Structs are just an unorganized amalgamation of these concepts.

As a result, Zig structs not only _cause_ complexity elsewhere, they are not able to properly function as any of the abstractions mentioned above: an object, a namespace, or even a c-struct. No matter how the programmer tries to use Zig structs, they will run into problems. Here's a short list of github issues:

• #1170 exists because you can write struct-local namespaced functions are good for OO, but not for c-structs
• #1205 exists because Zig's way of implementing "Traits" is unelegant #1205 (comment)
• #782 exists because some think of a Zig struct as a "class" that does self-cleanup, and others think of a Zig
• #1027 exists because not everyone want OO
• "its curious how zig prioritizes reading over writing and yet here we are reading two hours allocator function pointer indirections trying to figure things out or squinting at some obscure init functions just because there is no proper ctor dtor and things are hacked together in some way" - some guy on IRC

This is a question that needs to be answered as soon as possible.

There are many solutions to this problem. We can implement proper OO, or proper Rust-like traits, or namespacing, whatever. We just have to pick one and go with it, or else this unproductive bickering will continue forever.

---

Now, done summarizing. Here's what I think.

Zig structs should be more or less like c-structs. No functions, no pub/priv, only concrete values. Note that this still allows function pointers to be in a c-struct, since these are concrete values. There will be no more worrying about where functions are defined, or how to do inheritance, or implement Traits. A struct will be a struct, and any futher abstraction will come out of cleverness out of using them.

If anyone thinks C-structs are not good enough abstractions, read through the Plan 9 C library here. It is the most beautiful public interface I have ever seen (much better than OO). If Zig wants to be a C alternative, this is, in my eyes, the only way to do this right.

But of course, I know nothing compared to some of you, and this needs more all-around discussion. But struct should be finalized as _something_, and that's that.

[isaachier]

I don't think methods or pub are a problem. If anything, the only advantage Zig has over C is a better model for encapsulation. Then again, I think there are a few clear cut rules that will distinguish Zig from the classic OO languages (i.e. C++, Java, Rust, etc.):

• No constructors or destructors. Factory functions and cleanup functions should be provided in struct instead.
• No implicit this passed to methods. All struct "methods" are really free functions prefixed with the struct type identifier (i.e. String.append compiles to String_append).
• No implicit polymorphism. An embedded struct (#1214) or an explicit vtable member must be specified to implement features of polymorphism.

[bjornpagen]

I don't think methods or pub are a problem.

Methods lead to this problem. https://github.com/ziglang/zig/issues/1170#issuecomment-405110428
If functions were disallowed in structs, this problem would not exist. Additionally, encapsulation may not make sense in a language such as Zig. There is nothing to hide.

[andrewrk]

Zig structs should be more or less like c-structs. No functions, no pub/priv, only concrete values.

You are proposing to remove the ability for structs to be namespaces.

Rejected.

See also #1047

[isaachier]

@andrewrk I think that was just a suggestion. The idea was to draw a line in the sand as to the definition of a struct. Not sure if this can be 100% resolved before 1.0, but a rule for reference would be nice.