7 ms·

Honestly, I know it's minor, but when I tried Zig the fact I couldn't do the classic for loop to do a "for (int i = 0; i < n; ++i)" was quite annoying. It pollu

Honestly, I know it's minor, but when I tried Zig the fact I couldn't do the classic for loop to do a "for (int i = 0; i < n; ++i)" was quite annoying. It pollutes the scope, so you need to add scope braces every time, and I find it's much easier to forget the ++i at the end of the while loop. I understand where it's coming from, but having something like "for (i32 i in [0,n[)" would be so much nicer in my opinion.

pron 6y ago
> and I find it's much easier to forget the ++i at the end of the while loop. You can do: var i: usize = 0; while (i < 10) : (i += 1) { ... } or var i: usize = 0; while (i < 10) { defer i += 1; ... } although the two have slightly different semantics (the latter would increment even after a break; the former wouldn't).
- jeltz 6y ago
  Given how Zig does not allow variable shadowing (which is a choice which makes sense on its own) I find the scope leak to be very annoying in practice.
- dilap 6y ago
  Neither of those fix the scope leak, tho.
  - AnIdiotOnTheNet 6y ago
    This is true. There have been proposals to alter the `while` syntax to fix the scope leak, as well as proposals to extend `for` to support ranges, but none have been accepted (and they aren't very compelling in my opinion). Honestly, I'm not sure why people think it is such a big deal. I've written a lot of zig, mostly gamedev stuff, and I rarely use that construction. I find that the vast majority of loops are over arrays or slices.
    - dilap 6y ago
      While I don't have much experience with Zig, I agree -- from my little bit of playing around, it also hasn't been a big deal. (The biggest thing I've hit that I want is a way to return information with an error. If that were fixed, I think Zig's error handling would be perfect.)
      - jorangreef 6y ago
        Loris Cro did a great talk on error handling in Zig, which also deals with how to return information with an error if you need to, and why the common case optimizes for simpler error values: https://www.youtube.com/watch?v=TOIYyTacInM https://www.youtube.com/watch?v=TOIYyTacInM
        dilap 6y ago
        Thanks, that was a nice talk. But the answer there is basically, "if you care about payload, don't use zig's built-in error handling." Which, obviously, you can do, but I'm not convinced it's a great answer! Even for something as simple as parseInt, it would be nice, I would argue, if it returned, along with InvalidCharacter, which character was invalid. This would enable e.g. very precise indications in messages to the end user of what was wrong with the input. In general, because currently it's super-ergonomic to return just error codes but more of a pain to return errors w/ payloads, what you'll get in practice is no error payload even when it would be useful, which will end up turning into less-helpful-than-ideal errors for end users, which is contrary to zig's goal of enabling the creation of perfect software. :-) I found this thread interesting https://github.com/ziglang/zig/issues/2647 https://github.com/ziglang/zig/issues/2647
        jorangreef 6y ago
        Thanks for the link to that proposal. Just thinking out loud, given Zig's errors primarily allow the compiler to enforce that errors are handled, and exhaustively, beyond that why can't error payloads just be passed as an input argument pointer to the function call? Maybe this is a dumb idea, but it's what C programs already do, except C programs don't have the safety of compiler checked errors offered by Zig. Does the Zig compiler need to check error payloads beyond the type system already provided? I'm not sure. I agree with you that having such a super-ergonomic error handling system will direct most code towards a certain style, but I don't think this is contrary to Zig's goals of perfect software or simplicity. It's already such a huge win on top of C's error handling.
- pfalcon 6y ago
  Both forms feature "implicit flow of control", contrary to Zig's stated goals. In "while (i < 10) : (i += 1)", it's hard to understand what the heck "(i += 1)". The best concept one might get is that it's puposely made be different from C, just to be different and confuse people. In second case, it's "defer", coming from Go, the language which chickened out to add normal exceptions, because they're "implicit transfer of control", and LOLishly added "defer", as if it's not such.
  - pron 6y ago
    > Both forms feature "implicit flow of control", contrary to Zig's stated goals. They absolutely don't. All control paths are explicitly represented by syntax (no different from the hidden goto in a while loop -- it's explicitly recognised by the while syntax); proof: you can draw all of them by just examining the syntax of the current subroutine, while knowing nothing about others. Exceptions, however, are implicit: any call, foo(), might or might not cause some control flow change in the client without there being any explicit acknowledgement of that by the client; you cannot draw all the flow paths just by examining the syntax of the current subroutine.
    - pfalcon 6y ago
      Sorry, but throwing an exception in a function call is equivalent to: res, exc = fun(); if (exc) goto exception_handler; That's underlying model of how exceptions behave, and how they're implemented "manually" in languages with no exception handling (C, Go). You absolutely can draw that by examining syntax of a subroutine, and it's no more implicit than "defer".
      - pron 6y ago
        Right, both the C style and Zig's defer are explicit, as opposed to exceptions, which are implicit, only Zig's error handling is less error-prone (it forces you to handle errors) and makes the code more readable, IMO, than the C style.
        6y ago

pron 6y ago

> and I find it's much easier to forget the ++i at the end of the while loop. You can do: var i: usize = 0; while (i < 10) : (i += 1) { ... } or var i: usize = 0; while (i < 10) { defer i += 1; ... } although the two have slightly different semantics (the latter would increment even after a break; the former wouldn't).

jeltz 6y ago
Given how Zig does not allow variable shadowing (which is a choice which makes sense on its own) I find the scope leak to be very annoying in practice.
dilap 6y ago
Neither of those fix the scope leak, tho.
- AnIdiotOnTheNet 6y ago
  This is true. There have been proposals to alter the `while` syntax to fix the scope leak, as well as proposals to extend `for` to support ranges, but none have been accepted (and they aren't very compelling in my opinion). Honestly, I'm not sure why people think it is such a big deal. I've written a lot of zig, mostly gamedev stuff, and I rarely use that construction. I find that the vast majority of loops are over arrays or slices.
  - dilap 6y ago
    While I don't have much experience with Zig, I agree -- from my little bit of playing around, it also hasn't been a big deal. (The biggest thing I've hit that I want is a way to return information with an error. If that were fixed, I think Zig's error handling would be perfect.)
    - jorangreef 6y ago
      Loris Cro did a great talk on error handling in Zig, which also deals with how to return information with an error if you need to, and why the common case optimizes for simpler error values: https://www.youtube.com/watch?v=TOIYyTacInM https://www.youtube.com/watch?v=TOIYyTacInM
      - dilap 6y ago
        Thanks, that was a nice talk. But the answer there is basically, "if you care about payload, don't use zig's built-in error handling." Which, obviously, you can do, but I'm not convinced it's a great answer! Even for something as simple as parseInt, it would be nice, I would argue, if it returned, along with InvalidCharacter, which character was invalid. This would enable e.g. very precise indications in messages to the end user of what was wrong with the input. In general, because currently it's super-ergonomic to return just error codes but more of a pain to return errors w/ payloads, what you'll get in practice is no error payload even when it would be useful, which will end up turning into less-helpful-than-ideal errors for end users, which is contrary to zig's goal of enabling the creation of perfect software. :-) I found this thread interesting https://github.com/ziglang/zig/issues/2647 https://github.com/ziglang/zig/issues/2647
        jorangreef 6y ago
        Thanks for the link to that proposal. Just thinking out loud, given Zig's errors primarily allow the compiler to enforce that errors are handled, and exhaustively, beyond that why can't error payloads just be passed as an input argument pointer to the function call? Maybe this is a dumb idea, but it's what C programs already do, except C programs don't have the safety of compiler checked errors offered by Zig. Does the Zig compiler need to check error payloads beyond the type system already provided? I'm not sure. I agree with you that having such a super-ergonomic error handling system will direct most code towards a certain style, but I don't think this is contrary to Zig's goals of perfect software or simplicity. It's already such a huge win on top of C's error handling.
pfalcon 6y ago
Both forms feature "implicit flow of control", contrary to Zig's stated goals. In "while (i < 10) : (i += 1)", it's hard to understand what the heck "(i += 1)". The best concept one might get is that it's puposely made be different from C, just to be different and confuse people. In second case, it's "defer", coming from Go, the language which chickened out to add normal exceptions, because they're "implicit transfer of control", and LOLishly added "defer", as if it's not such.
- pron 6y ago
  > Both forms feature "implicit flow of control", contrary to Zig's stated goals. They absolutely don't. All control paths are explicitly represented by syntax (no different from the hidden goto in a while loop -- it's explicitly recognised by the while syntax); proof: you can draw all of them by just examining the syntax of the current subroutine, while knowing nothing about others. Exceptions, however, are implicit: any call, foo(), might or might not cause some control flow change in the client without there being any explicit acknowledgement of that by the client; you cannot draw all the flow paths just by examining the syntax of the current subroutine.
  - pfalcon 6y ago
    Sorry, but throwing an exception in a function call is equivalent to: res, exc = fun(); if (exc) goto exception_handler; That's underlying model of how exceptions behave, and how they're implemented "manually" in languages with no exception handling (C, Go). You absolutely can draw that by examining syntax of a subroutine, and it's no more implicit than "defer".
    - pron 6y ago
      Right, both the C style and Zig's defer are explicit, as opposed to exceptions, which are implicit, only Zig's error handling is less error-prone (it forces you to handle errors) and makes the code more readable, IMO, than the C style.
      - 6y ago