Zig Quirks

https://www.openmymind.net/Zig-Quirks/

by andreabergia • 3 years ago

256 164 3 years ago

pjmlp3• 3 years ago

Well the amount of @ uses, it seems either to be to appeal to annotation heavy Java folks, or recovering Objective-C users.

pavlov• 3 years ago

Or maybe Rogue/Nethack players who identify with @.

kristoff_it10• 3 years ago

@ is just the prefix used by builtins, it's not used for anything else.

pjmlp3• 3 years ago

Hence recovering Objective-C users.

kuon3• 3 years ago

Usually, I never use @ in code directory, I use either stdlib or I write my own wrapper with added semantic.

kuon3• 3 years ago

Directly*

lionkor• 3 years ago

The biggest quirk is arrays vs slices, their notation, and pointer types. Its a nightmare

Joker_vD4• 3 years ago

Arrays vs slices seem to be pretty much the same as in Go, and the notation is completely straightforward: "ARRAY 100 OF INTEGER", except instead of "ARRAY" and "OF", the "[" and "]" are used — type constructor goes first, before its arguments, as it should be.

As for pointer types, they look reasonable but can't say much more.

kristoff_it10• 3 years ago

One correction: Go slices also own their memory, so their equivalent would be Zig's `std.ArrayList`. Slices in Zig are just ptr+len, so you will have to manage the underlying memory separately. This makes sense for Zig since it's a lower-level language than Go.

kristoff_it10• 3 years ago

The notation is very "compressed", that's for sure.

On the other hand, manipulating sequences of data and pointers of various kinds is one of the main things you do when programming, and concise notation (especially in a low level programming language) is akin to how mathematicians have concise notation for the most common objects they manipulate in their formulas.

throwawaymaths8• 3 years ago

it's difficult, but they are there for a reason. Working through them helped me appreciate all of the different options that exist (and yes sentinel termination is sometimes better: https://lemire.me/blog/2020/09/03/sentinels-can-be-faster/)

If there's one thing that's a nightmare about how zig handles these is that sometimes coercion between array types is a bit hidden and the rules are not obvious, though their application in code is usually straightforward and you don't have to think about it too much (AFAICT it doesn't let you do the wrong thing)

rstarast• 3 years ago

Re 9, would it be possible to change the signature of expectEqual from

    pub fn expectEqual(expected: anytype, actual: @TypeOf(expected)) !void

    pub fn expectEqual(expected: @TypeOf(actual), actual: anytype) !void

What would the downsides be?

ptato3• 3 years ago

It isn't possible, compiler will complain about "actual" being an undeclared identifier. The function arguments are declared in order.

hiccuphippo2• 3 years ago

The compiler already allows using functions defined later in the same file. This is a solvable problem.

latch3• 3 years ago

No, it won't work. It'll say "actual" is undeclared.

https://github.com/ziglang/zig/issues/4437 is tracking the issue. I think std.testing is going to see some major changes, so it's possible this gets fixed. But going from the responses in that issue, I think that fix might be more of a side effect, since there doesn't seem to be too much sympathy for the issue as-is.

nyanpasu64• 3 years ago

Why not place actual as the first argument and expected as the second? This matches the way I hand-write asserts like `assert(x == 5)`.

ptato3• 3 years ago

Please don't do "const Self = @This();" if the type isn't generic. It is pointless, redundant, ugly.

What issues could public struct fields have caused?

latch3• 3 years ago

Self is used in the standard library for non generic types every now and again.

As for public fields, the 0.9 change to allocator comes to mind. This was written off as a minor change, because Zig is pre 1.0. But what I haven't heard (and 100% upfront, I haven't looked hard), is how Zig plans on dealing with it post 1.0. Like, where are we in the gradient of: "1.0 will never break the public API (struct fields included)" to "deal with it".

kristoff_it10• 3 years ago

1.0 for Zig is going to mean not only never break the API, but also that we'll be pretty much done with the language. The current idea is to release v1 only after a few releases that only contain bug fixes.

As for public fields, the 0.9 change to allocator comes to mind.

That's a good example of why it makes sense for Zig to have all fields be public: the change that we did to allocators has important implications that in Zig we don't want to hide behind a `private` descriptor. This is obviously not a universal truth, but it makes sense for a low-level programming language that cares about the details.

Self is used in the standard library for non generic types every now and again.

I agree with the parent poster, those should probably be removed, as they don't really help make the code more readable or provide any other advantage. A overhaul of the stdlib is planned, but we're not there yet, as we're still busy working on the package manager and incremental compilation.

the_mitsuhiko2• 3 years ago

The Zig documentation states that "Identifiers are never allowed to "hide" other identifiers by using the same name."

I see this desire to get rid of shadowing all the time, but in practice it's such a disruptive restriction.

sophiabits2• 3 years ago

The very last paragraph sums it up pretty nicely imo:

You'll have to be more creative when coming up with variables that don't shadow existing ones (which, for me, generally means using more obscure names).

The last adjective I want used in relation to my variable names is “obscure.”

jackosdev2• 3 years ago

I really like in Rust how you can reinit a variable with a different type e.g. “let rect: Rect<f32> = rect.into();”

It’s just so damn useful and I’m not sure what the downside is, it sucks when you have to keep coming up with different names so you can keep around an identifier that you don’t need anymore.

throwawaymaths8• 3 years ago

that's a super weird reflex. For me, I would probably wind up making a more specific variable name, instead of obscuring.

Zecc• 3 years ago

The last adjective I want used in relation to my variable names is “obscure.”

Well, second-to-last right after "misleading".

Wildgoose• 3 years ago

Don't forget that zig files are essentially a struct using the same name as the file. That means you can differentiate between identifiers that are using the same name by supplying the struct name as a prefix.

AnIdiotOnTheNet3• 3 years ago

You make it sound so difficult, but in my experience it hardly ever comes up in practice. When it does, rather than naming things obscurely I can just tack a temp_ or local_ or something else descriptive on the front.

jeltz2• 3 years ago

When I used Zig I ran into this all the time in practice when using iterators. It is the combination of that you cannot nicely create a locally scoped iterator and that Zig forbids shadowing.

Specifically this kind of code (and I do not feel calling them e.g. iter1 and iter2 or foo_iter and bar_iter make the code nice):

    var iter1 = foo_dir.iterate();
    while (try iter1.next()) |entry| {
        // Do something
    }

    var iter2 = bar_dir.iterate();
    while (try iter2.next()) |entry| {
        // Do something else
    }

cztomsik• 3 years ago

It's accidental complexity. There's an artificial limitation which you need to work around. What you get back is very questionable, I certainly don't remember when it was last time I've messed up the scoping, if ever.

fatneckbeard• 3 years ago

two hardest problems in programming

what to name things

cache coherency

off by one bugs

fractalb• 3 years ago

Maybe, they'll remove it in a future version if many people raise the same complaint.

throwawaymaths8• 3 years ago

they'll never remove it, because not shadowing variables really encourages you to break up your code into well-organized files. IMO, it's only painful if you

1) have bad coding habits. (playing with zig broke me of some of these)

2) you need to autogenerate code.

2 is a much harder nut to crack.

WalterBright7• 3 years ago

I added shadowing protection to D a couple decades ago. It has saved me from numerous difficult-to-find bugs, especially if the function gets a bit large. It's a big win.

xchkr1337• 3 years ago

Are tabs supported yet?

kristoff_it10• 3 years ago

Yes, have been for a while now.

latch3• 3 years ago

Is there an update since this 2 year old thread (1) which leaves the door open to removing tab support in the future?

I use relatively large fonts for medical reasons and tabs are much more accessible to me.

(1) https://github.com/ziglang/zig/issues/544

nektro• 3 years ago

I hope not

quietbritishjim6• 3 years ago

(Non-user of Zig here.)

    // tea.zig
    full: bool = true,
    const Self = @This();
    
    pub fn drink(self: *Self) void {
      self.full = false;
    }

    // other.zig
    const Tea = @import("tea.zig");

This example seemed to stop just short of the really interesting bit: what if other.zig called Tea.drink()? Would it set Tea.full to false? Maybe this is obvious to Zig users, but coming from C++, that would be a violation of const correctness.

In C++ (thinking of classes rather than files), you wouldn't be able to call the drink method of a const object because it's not marked as a const method. Or, if it was marked as a const method, you wouldn't be able to modify full from in drink. You could get around this by marking full as mutable, which means you're going to deliberately violate const correctnees, but at least you have to be explicit about it. (In theory mutable is meant for things like caches that don't affect the visible behaviour of the class.)

kristoff_it10• 3 years ago

what if other.zig called Tea.drink()?

To be clear: you would first need to create an instance of `Tea`.

   var t: Tea = .{};
   t.drink(); // will work and set t.full to false

If instead we declared `t` as `const`, then yes the call to `drink` would not have been possible.

`const Self = @This();` just binds the top-level struct type definition to a name, which then allows you to refer to it in other plances. Nothing more than that.

quietbritishjim6• 3 years ago

Ah that does make sense, thanks.

Is it possible to mark a method const in Zig, like in C++? I guess you set the type of the self parameter to const *Self or similar?

stefncb2• 3 years ago

The type of Tea is 'type', not Tea. Unlike in C++, types are values in Zig, so it would be like calling Tea::drink() in C++.

You need an instance of Tea in order to call drink, and if it's const it won't compile because drink takes type *Tea, not *const Tea.

quietbritishjim6• 3 years ago

Interesting, thanks. In that case, what if `Tea` was not const? Could I assign a different type to it? What would the static type of an instance of Tea be, if its runtime value could be two incompatible types?

ngrilly• 3 years ago

Regarding naming conventions, there is an issue about switching to snake case for functions as well, the main rationale being there is no difference between snake_case and camelCase for one word identifiers:

https://github.com/ziglang/zig/issues/1097

kuon3• 3 years ago

I have PTSD about 1097 :D

overthrow• 3 years ago

Then you better refill your Zoloft because it looks like there's going to be one last big disruption before it's over. https://github.com/ziglang/zig/issues/1097#issuecomment-1404...

JonChesterfield2• 3 years ago

Good discussion there, thanks for linking.

Shout out to llvm for sticking with camelCase while the c++ library is all snake_case. Turns out eventually one gets used to reading mixtures of them and only occasionally writes dense_map or unorderedMap, but I still wish it wasn't like this.

edit: I write large patches in the one true style and then begrudgingly fix them up for review using ad hoc emacs macros but it looks like clang-tidy can automate that. Wonder if it's robust enough to bidirectionally convert between review acceptable and legible

0x37• 3 years ago

I don't usually like participating in bikeshedding, but the @ annotation feels like PHP's $ to me in that I don't see why it needs to exist. The language design could've easily just left that out and I don't think anything would be lost.

Other than that, I'm definitely excited for Zig as a potential C++ replacement.

kristoff_it10• 3 years ago

I don't see why it needs to exist

The symbol namespaces builtins, as those are the only identifiers that aren't declared in the file (either directly or by using `@import`).

tialaramex7• 3 years ago

Although namespacing them keeps them out from under a programmer's feet, which is a significant benefit, it does seem like this would make it harder to find stuff. @cmpxchgStrong, @wasmMemorySize and @embedFile are completely unrelated, but since they're all builtins they're neighbours.

tleb_• 3 years ago

My belief is that it is about builtin functions that are provided by the compiler versus part of the standard library. They are documented in the language reference [0] versus in the standard library documentation [1].

[0] https://ziglang.org/documentation/master/

[1] https://ziglang.org/documentation/master/std/

ptato3• 3 years ago

Built-in names are essentially reserved words, and there are dozens of them. The @ prefix ensures you don't step on user's variable names, and that you can add new built-ins without making breaking changes.

andrepd2• 3 years ago

Why aren't they simply namespaced, like `core.some_function`?

throwawaymaths8• 3 years ago

one side benefit is that at lot of @ code is "dangerous shit" so it draws your eye during code review. You will want to code review the "dangerous shit" that GPT-5 gives you.

nromiun3• 3 years ago

Functions are camelCase
Types are PascalCase
Variables are lowercase_with_underscores

Just why? It does not seem like the same language that used to treat tabs as a compiler error. Looks like the worst of every worlds to me. Why not just stick to one style?

TeaDude• 3 years ago

Did they remove that? I thought that tabs were still forbidden...

nromiun3• 3 years ago

https://github.com/ziglang/zig/issues/544

Maybe? They say their stage2 parser accepts them now.

generichuman• 3 years ago

I don't see what's the problem here. That style has the advantage of being able to look at any identifier and understand whether it is an fn, a type or a variable.

nromiun3• 3 years ago

Isn't fn and () already doing that for functions? Anyway, I just think it is a weird style for a minimalist language.

Edit: Looks like they are already aware of the problem. That is good news.

https://github.com/ziglang/zig/issues/1097#issuecomment-6142...

zamalek• 3 years ago

Like int_age and string_name make the type of a value obvious? Hard pass.

throwawaymaths8• 3 years ago

it's a convention, not enforced. You can do whatever you want with names. These are just guidelines.

claytongulick• 3 years ago

It's helpful when reading code.

I actually use this approach in my style guides for my teams writing js too.

Once you get used to it, it's quite pleasant.

In js you run into some grey areas, like function type callable variables that look weird, but still make sense when named well: click_handler() read_complete_callback()

randyrand• 3 years ago

I’ve written 100k lines of C code the past 2 years, and this is also the convention I use.

It’s quite nice to work with, and comes naturally after a short while.

stephc_int13• 3 years ago

Some parts of the Zig syntax reminds me of the old K&R style function declaration, that seemed absurd and was replaced at some point, but it was released, used in production and defended for a while.

There is often a strong rationale behind clumsy syntax decisions, I hope they will fix those quirks.

avinassh• 3 years ago

why this wouldn't be possible (or not preferred) without the dot?

    var tea = Tea{.full = true};

like:

    var tea = Tea{full = true};

throwawaymaths8• 3 years ago

I'll counter with one reason why to prefer the dot: it mirrors the C99 standard. Part of zig's ethos is being friendly to C programmers.

https://stackoverflow.com/questions/32698293/assign-values-t...

brabel• 3 years ago

Yep, I also noticed that Zig just does what C does... coming from other C-like languages, like Java, JS, Go, though, which don't do that, I was also surprised.

pornel• 3 years ago

Languages tend to avoid having parsing ambiguities and syntaxes that require unbounded lookahead, because things like that make parsers slower and/or more complex. This is a pain not just for the compiler, but also syntax highlighting, IDEs and other tooling. Languages also need to consider future syntax extensions and ability to give good error messages for syntax errors. This usually requires some redundancy and extra sigils or keywords.

Here `full = true` is a valid expression syntax, and it'd be problematic if `{` could start a block of code here. This case may be parseable unambiguously thanks to `Tea` ident in the front, but e.g. if Zig ever wanted to add something like Swift's final closure syntax, then `expr { expr }` could become valid, and this would be ambiguous.

In Rust `if struct {}` is a parsing edge case. JS has ambiguous `{field: value}` objects and `{label: code}` blocks. CSS struggles to add nested rules, because syntaxes of `selector { property:value` and `selector { selector:selector` overlap, and that requires slower and/or more complicated parsers.

Joker_vD4• 3 years ago

Here `full = true` is a valid expression syntax, and it'd be problematic if `{` could start a block of code here.

Golang has almost this exact problem in its grammar but in practice they manage just fine even though there are indeed some edge cases where parser gets confused:

A parsing ambiguity arises when a composite literal using the TypeName form of the LiteralType appears as an operand between the keyword and the opening brace of the block of an "if", "for", or "switch" statement, and the composite literal is not enclosed in parentheses, square brackets, or curly braces. In this rare case, the opening brace of the literal is erroneously parsed as the one introducing the block of statements. To resolve the ambiguity, the composite literal must appear within parentheses.

    if x == (T{a,b,c}[i]) { … }
    if (x == T{a,b,c}[i]) { … }

scoutt• 3 years ago

Coming from C, I always see these "Self" variables/types as counter-intuitive, and contribute to those cases where a function requires a parameter which I don't have to supply (just for these functions accepting "Self"), which could be an exception instead of a rule. I would rather prefer the C++ "this" keyword usage.

Also, do "Self" kind-of variables occupy memory?

How can I declare a (packed) struct describing a payload in a way that the struct can be then sent "as is" as a network packet?

Let's say this struct has a "calculateChecksum()" method. Will I need to declare "Self"? If so, will be "Self" part of the struct's memory layout?

wchar_t• 3 years ago

Nope, since Self is a declaration and not a field it won't take up memory.

quietbritishjim6• 3 years ago

Will I need to declare "Self"? If so, will be "Self" part of the struct's memory layout?

I'm only familiar with C++, not Zig, but it doesn't seem that different to me. If a C++ class includes a typedef, then that doesn't contribute to the class's footprint.

Even the explicit self parameter is not so different. In C++, a method can be marked as const or even && (rvalue reference) and that's applied to the implicit this parameter. If anything, it would be clearer if this was an explicit parameter; as of C++23, it actually is allowed to be [1], called "deducing this".

[1] https://devblogs.microsoft.com/cppblog/cpp23-deducing-this/

flohofwoe• 3 years ago

There's nothing special about the 'Self' (it's just a type).

In general, consts in Zig are purely compile time things and don't take up memory.

And putting a function inside a struct which takes a pointer to its struct type as first argument just allows method-call-syntax-sugar, but you can also write it as regular function (which must then be namespaced with the struct type though):

    const Bla = struct {
        const Self = @This();
        val: i32 = 0,
        fn add(self: *Self, val: i32) void {
            self.val += val;
        }
    };

    pub fn main() void {
        var bla = Bla{};
        // with method-call syntax sugar
        bla.add(2);
        // without method-call syntax sugar
        Bla.add(&bla, 3);
    }

...but in this case it's probably better to not use Self and @This() (it mostly makes sense with generics).

    const Bla = struct {
        val: i32 = 0,
        fn add(self: *Bla, val: i32) void {
            self.val += val;
        }
    };

bobbylarrybobby• 3 years ago

I think Rust does this quite well. There are a few handy rules.

1. If the first argument of a function is `self`, then that function is treated as a method and can be called like `obj.meth(args)`. Functions without `self` must be called statically, which in the case of an object would look like `Type::meth(obj, args)`. The second form is used occasionally by common wrapper types like Box and Rc to avoid dereferencing “piercing the veil” and calling a method on the wrapped object (Rust has no separate `obj->meth` syntax, which IMO is its own issue). 2. Having access to `Self` lets you specify the types of non-this arguments as well as return types, like `fn add(self, other: Self) -> Self {...}`. You can also use it as the name of the type when (de)structing objects, e.g., `let Self { fields } = other` or `return Self { fields }`. Writing out the name of the current type each time could get unwieldy. 3. `Self` as a namespace is handy when dealing with enums, e.g., `match self { Self::First => ..., Self::Second => ...}` or static functions like `Self::func(args)`. It's crucial in trait implementations when referring to associated types, e.g., in Iterator there's `type Item; fn next(&mut self) -> Option<Self::Item>;`

I don't why a Self variable would be placed on the stack differently from non-Self variables; method calls have always just been syntactic sugar + namespacing for a free function, no?

quietbritishjim6• 3 years ago

method calls have always just been syntactic sugar + namespacing for a free function, no?

Not quite; they're more than that for languages that have dynamic dispatch, like virtual methods in C++ or dyn impl in Rust. In that case, that argument affects which function is called. In the case of multiple inheritence (in C++), the implicit this parameter is also potentially subject to a pointer offset; if it's virtual multiple inheritence then that offset may even be computed at runtime.

haberman4• 3 years ago

Speaking of structure fields, they're always public. Structures and functions are private by default with an option to make them public. But struct fields can only be public.

This feels like a mistake to me. I own and maintain a C library, and lack of private struct members is one of the things that causes the most problems. My users frequently reach into struct members even though I really do not want them to. This causes problems when those members have subtly different semantics than what they expect. It's even worse when I want to change the internal representation, and I have to track down all my users' code and change it accordingly.

In C, my only options are:

(1) Define the structure in a .c file instead of .h. This works great in cases where I can take the performance hit of not being able to inline accesses of those struct members. But for performance-critical structures where I need to be able to inline, this is not an option.

(2) Make the member names something like private_foo, internal_foo, etc. and hope my users take the hint. But this also makes my own code more ugly and creates longer lines that are more likely to wrap.

Unfortunately Zig is even less capable than C in this regard, because Zig takes away option (1). Since there is no header/source split in Zig, I cannot make a struct opaque by defining it in a source file only. Though I do see that there is "opaque {}", perhaps that plus some casting could accomplish a similar thing?

I see that rationale for not having private struct members was given here: https://github.com/ziglang/zig/issues/9909#issuecomment-9426...

The idea of private fields and getter/setter methods was popularized by Java, but it is an anti-pattern. Fields are there; they exist. They are the data that underpins any abstraction. My recommendation is to name fields carefully and leave them as part of the public API, carefully documenting what they do. [...] In my subjective experience, public fields generally lead to better abstractions by eliminating the temptation to attempt full encapsulation, when the more effective strategy is to provide composable abstraction layers.

Java does indeed represent an anti-pattern of verbose and frequently trivial getters and setters. But newer languages like C#, Swift, and Dart have more elegant and low-overhead syntax for properties, even allowing a property to move between being an actual field member and being derived, without breaking users.

As a library maintainer, full encapsulation is very important for evolution of a system over time. The only way for layers to truly be layers is if the contract at each layer boundary is clear. Otherwise the layers gel together and you cannot safely change any one layer independently.

michaelg7x• 3 years ago

What are the downsides of keeping the public fields in a struct which is in turn embedded in a private struct created by the library? Inferring the "outer offset" could get irritating but it depends on your tolerance of additional complexity (in every public function...).

haberman4• 3 years ago

What are the downsides of keeping the public fields in a struct which is in turn embedded in a private struct created by the library?

That seems similar to using "opaque {}", if I am understanding you correctly?

I think either of those solutions could potentially work, at the cost of one explicit cast in each function that actually needs to access the data. I would love to know if this works well enough in practice.

JonChesterfield2• 3 years ago

The answer in C would be it constrains ordering/packing of fields, so you'd end up with N public/private wrappers and generally a lot of line noise, but I have a vague recollection that zig reorders fields as it sees fit anyway making that a non-issue

hota_mazi3• 3 years ago

Java does indeed represent an anti-pattern of verbose and frequently trivial getters and setters.

It's not an anti-pattern.

This is how Java provides the exact functionality that you describe as very important (field encapsulation). Because Java doesn't support properties, it needs to go through getters and setters.

As you point out, more modern languages support this functionality directly in the language with properties.

haberman4• 3 years ago

To me the anti-pattern is lots of redundant, trivial, verbose getters and setters. If I see a source file with tens or hundreds of lines of trivial method definitions, I think something has gone wrong.

Properties help avoid this anti-pattern by making it possible to transparently swap in a computed property for what used to be a plain field. This removes the incentive to proactively create trivial getters and setters "just in case."

WalterBright7• 3 years ago

D has a more unusual take on private fields. Private fields prevent access by other modules, but do not prevent access from within the same module. The module is really the unit of encapsulation, not the struct.

The purpose of this was to eliminate the need for "friend" classes.

This sometimes conflicts with what people coming from C and C++ are used to with everything being in one file (after headers are added by the preprocessor). But having modules gives opportunities for better ways to organize the code.

As for trivial property accessors and setters, those get inlined, so are not overhead.

justeleblanc2• 3 years ago

D has a more unusual take on private fields. Private fields prevent access by other modules, but do not prevent access from within the same module. The module is really the unit of encapsulation, not the struct.

Other languages would call these "internal", not "private".

TUSF• 3 years ago

Zig compiles everything as one large compilation unit, so inlining isn't much of an issue there. If you want to have private fields, there's a couple ways to go about it. You can make use of opaque types, of course, or you could use @fieldParentPtr to hide your private implementation from the API.

Something like so:

    /// The internal implementation of this type.
    const PrivateType = struct {
        // Private fields.
        field_a: u32,
        field_b: bool,
        // Public object exposed 
        public: PublicType,

        // private functions here.
    }

    /// This gets exposed to the public API
    pub const PublicType = struct {
        // Public fields.
        field_a: u32,

        // Public functions here.
        pub fn create(alloc: Allocator) !*PublicType {
            var priv = try alloc.create(PrivateType);
            return &priv.public;
        }

        /// Flips internal field b.
        pub fn flip(p: *PublicType) void {
            // Grabs the PrivateType that contains this PublicType as a field.
            const self = @fieldParentPtr(PrivateType, "public", p);
            self.*.field_b = !self.*.field_b;
        }
    }

jcelerier• 3 years ago

My users frequently reach into struct members even though I really do not want them to.

if as a library writer you don't want me to access your private struct layout and as a user I want to, I promise there is absolutely nothing that I won't try, from casting to bytes and working there, passing things from / to DLL writtens in C, to running your program in a VM, etc. So why try to fight this fight? Just tell your users that go outside of the sanctioned route that you won't help them just like a car manufacturer won't help you hack into their engine but you still can and should be able to if you want to

felixgallo• 3 years ago

With private fields, there's a clear signal that you will be crossing a line by doing all those shenanigans -- like a 'no running' sign at the pool, you violate the rule and you accept responsibility for what happens next. With only public fields, there is no way to signal a rule. The pool no running sign is taken down.

And, there are valid reasons for a library writer to want to warn people off using certain fields, but still have them in-structure. Work-in-progress, internal machinery that the writer may wish to refactor at their leisure, whatever.

You could write that warning up in the documentation, but it's probably better as a structural affordance in the code, because then it's not just enforceable, but also lends itself to automation.

haberman4• 3 years ago

I'm completely content with that deal. But the deal only works if the warranty is clear. Unless it's unmistakable to users that they have crossed the line, they will complain if you break them. A comment next to the member is not enough: IDEs will happily auto-complete the names of internal-only members.

scrubs• 3 years ago

For my interests (DPDK, NIC, low level storage I/O etc.) I have high hopes for Zig. And for reasons other have explicated over the last year on HN, I think it'll work much better than Rust.

Readers should have realistic expectations. It's not substantially downhill to write C like code. I ran into this bug right off the bat. TL/DL: Zig's linker does not pull in dynamic libs. It finds static libs but alas the .tsk doesn't give expected behavior anyway:

https://github.com/ziglang/zig/issues/14939

A. Kelly (head Zig dev), to his credit, seems to already be on top of in this through a related bug:

https://github.com/ziglang/zig/issues/14963

I didn't expect to run into link problems on day 1.

adamrezich• 3 years ago

Speaking of structure fields, they're always public. Structures and functions are private by default with an option to make them public. But struct fields can only be public. The recommendation is to document allowed/proper usage of each field.
I don't want to editorialize this post too much, but it's already caused the type of issues that you'd expect, and I think it'll only cause more difficulties in a 1.x world.

I wish the author elaborated a bit more here because I've always been interested in what problem exactly `private` (and all the language complexity/overhead) that comes with it solves. for something like C# it kind of makes sense because it's a language built around chaining method calls and IntelliSense, so the user types `foo.` and IntelliSense shows literally everything you could want to do with that `Foo` instance, excluding `private` members/methods. I can see the use-case for this in a corporate-type setting. in absence of this feature (which I believe is the case for Zig?), what possible difficulties can be caused, in practice?

nixpulvis• 3 years ago

Correct me if I'm wrong, but it really seems like bad const inference that `x` from the 8th example is typed as a `comptime_int`. Is all comptime inference only done at the point of declaration?

frodowtf• 3 years ago

Haven't used Zig but that comptime coercion seems very annoying.

rurban• 3 years ago

In my compiler I loosely coerce comptime_int's to int's if needed by subsequent API's. You also need to expand or truncate it's size on demand. E.g. C compilers do that.

zig just error's, which is a silly behaviour.

Zig Quirks

Related Stories