4 ms·

A big change like this makes me hopeful Zig may revisit and improve other design choices in the future.

by barelysapient 1y ago

bbkane 1y ago
Could you elaborate on the choices you'd like revisited?
- 90s_dev 1y ago
  Unused variables stops all further compilation, so that even future errors can't be seen until the variable is used.
  - Mond_ 1y ago
    Meh. I think this should be a warning on debug builds and an error on release builds, but it's a relatively minor thing and not a deal breaker by any means. If this is the worst thing that people would like to see revisited, Zig must be doing amazingly well.
    - josephg 1y ago
      > but it's a relatively minor thing and not a deal breaker by any means. It totally breaks my normal workflow. I don’t use zig at all because of this misfeature. Warn in debug and error on release builds would be strange but fine.
      - deleted 1y ago
        [deleted]
  - mlugg 1y ago
    This is simply not true. See https://zigbin.io/f57b94/run https://zigbin.io/f57b94/run. (That link seems to show the "unused local variable" error line twice for me; that's some kind of bug with this zigbin service and does not reproduce when running the Zig compiler normally.)
- thayne 1y ago
  Not the original poster, and I don't have very high hopes that these will be revisited, but some things I would like to see revisited are: - ability to define anonymous functions without having to put it inside an anonymous struct. I get the argument against closures (even if I don't fully agree with it), but not having first class support for anonymous functions feels pretty regressive for a modern language - have a way to include payload data with errors. Or at the very least, define an idiomatic pattern for handling cases where you have additional data for an error - allow struct fields to be private - bring back async support in some form (this one I do have some hope for)
- xmorse 1y ago
  I would like to have some kind of interfaces instead of having to always use anytype, so compiler errors will appear in the call site instead of the called function body

A big change like this makes me hopeful Zig may revisit and improve other design choices in the future.

bbkane 1y ago

Could you elaborate on the choices you'd like revisited?

90s_dev 1y ago
Unused variables stops all further compilation, so that even future errors can't be seen until the variable is used.
- Mond_ 1y ago
  Meh. I think this should be a warning on debug builds and an error on release builds, but it's a relatively minor thing and not a deal breaker by any means. If this is the worst thing that people would like to see revisited, Zig must be doing amazingly well.
  - josephg 1y ago
    > but it's a relatively minor thing and not a deal breaker by any means. It totally breaks my normal workflow. I don’t use zig at all because of this misfeature. Warn in debug and error on release builds would be strange but fine.
    - deleted 1y ago
      [deleted]
- mlugg 1y ago
  This is simply not true. See https://zigbin.io/f57b94/run https://zigbin.io/f57b94/run. (That link seems to show the "unused local variable" error line twice for me; that's some kind of bug with this zigbin service and does not reproduce when running the Zig compiler normally.)
thayne 1y ago
Not the original poster, and I don't have very high hopes that these will be revisited, but some things I would like to see revisited are: - ability to define anonymous functions without having to put it inside an anonymous struct. I get the argument against closures (even if I don't fully agree with it), but not having first class support for anonymous functions feels pretty regressive for a modern language - have a way to include payload data with errors. Or at the very least, define an idiomatic pattern for handling cases where you have additional data for an error - allow struct fields to be private - bring back async support in some form (this one I do have some hope for)
xmorse 1y ago
I would like to have some kind of interfaces instead of having to always use anytype, so compiler errors will appear in the call site instead of the called function body