6 ms·

A whole lot of cleverness for a language that refuses to compile when you have unused parameters.

by selfmodruntime 2y ago

conradev 2y ago
With the Zig language server it’s not terribly annoying: _ = foo; // autofix
AlienRobot 2y ago
And has no multi-line comments.
MineBill 2y ago
If you want to see true cleverness just go see the last devlog on the zig website.
- mtlynch 2y ago
  I think this is the post parent is referencing: https://ziglang.org/devlog/2024/#2024-11-04 https://ziglang.org/devlog/2024/#2024-11-04 It seems like an interesting idea, but I wish Andrew spent more time fleshing it out with complete examples. I can't tell if the _ characters are eliding values or if that's literally what's in his code.
  - defen 2y ago
    It's Zig's equivalent of the newtype idiom: https://doc.rust-lang.org/rust-by-example/generics/new_types.html https://doc.rust-lang.org/rust-by-example/generics/new_types... for integers. The underscores mean that it's a non-exhaustive enum. An exhaustive enum is where you list all the names of the possible enum values, and other values are illegal. A non-exhaustive enum means any value in the underlying storage is allowed. So at root this code is creating a bunch of new integer types which are all backed by u32 but which can't be directly assigned or compared to each other. That means you can't accidentally pass a SectionIndex into a function expecting an ObjectFunctionImportIndex, which would be impossible to do if those functions just took raw u32's.
    - mtlynch 2y ago
      Ah, thanks! I tried converting that example to Zig: https://tars.run/t3eInpPFAgc https://tars.run/t3eInpPFAgc Is that the idea? You can do the same thing wrapping integers with structs, but enum makes it slightly more concise?
      - ImprobableTruth 2y ago
        Yes, that's how it works. I think in Zig for new types you'd use enums for ints and packed structs for more complex types.
  - fallingsquirrel 2y ago
    It's an interesting pattern, but it's a shame there's no way to efficiently use one of those OptionalXIndex with zig's actual null syntax, `?` and `orelse` and etc. It would be smoother if you could constraint the nonexhaustive range, and let the compiler use an unused value as the niche for null. Maybe something like `enum(u32) { _ = 1...std.math.maxInt(u32) }`
    - samatman 2y ago
      There's an issue tracking that: https://github.com/ziglang/zig/issues/3806 https://github.com/ziglang/zig/issues/3806
- quotemstr 2y ago
  That's just newtype.
norir 2y ago
I am not a fan of zig, but I am a fan of discipline so I like this particular design decision.
- alpaca128 2y ago
  I would be fine with it if it only threw an error about that when building in release mode or if there was a flag to silence it temporarily. But while trying out some things and learning the language I find it annoying. And I don't know how it makes me more disciplined when I can just write `_ = unused;` to suppress the error. Even worse, if I forget that assignment in the code the compiler will never warn me about it again even when I want it to. So far I haven't seen any upside to this.
  - dgfitz 2y ago
    I feel like this is like saying “python shouldn’t care so much about indentation, I’m just trying to learn!”
    - Phil_Latio 2y ago
      Wrong syntax is (and must be) an error. Totally different. The Problem in Go and Zig is that they put theory over practice: No compiler warnings is a good idea in theory, but fails in practice for things like unused variables or unused imports. Defending that makes it even worse and begs the question what other treasures they have burried in their language design. This thread is a testament to that.
      - riwsky 2y ago
        Forbidding unused imports was a direct response to the practical difficulty of compiling google-scale C++ binaries: https://go.dev/talks/2012/splash.article#TOC_5 https://go.dev/talks/2012/splash.article#TOC_5. In theory, programmers can just be disciplined enough or set up CI lints for unused imports. In practice…
        2y ago
deleted 2y ago
[deleted]
jeroenhd 2y ago
That's one if the great advantages of Zig. Other languages can't always enforce this rule (because of inheritance and such) and will generate strong warnings instead. If you like copying dead memory around, you can always do `_ = unusedParam` to confirm to the compiler that you don't need that variable after all, despite going out of yiur way to declare it.

A whole lot of cleverness for a language that refuses to compile when you have unused parameters.

conradev 2y ago

With the Zig language server it’s not terribly annoying: _ = foo; // autofix

AlienRobot 2y ago

And has no multi-line comments.

MineBill 2y ago

If you want to see true cleverness just go see the last devlog on the zig website.

mtlynch 2y ago
I think this is the post parent is referencing: https://ziglang.org/devlog/2024/#2024-11-04 https://ziglang.org/devlog/2024/#2024-11-04 It seems like an interesting idea, but I wish Andrew spent more time fleshing it out with complete examples. I can't tell if the _ characters are eliding values or if that's literally what's in his code.
- defen 2y ago
  It's Zig's equivalent of the newtype idiom: https://doc.rust-lang.org/rust-by-example/generics/new_types.html https://doc.rust-lang.org/rust-by-example/generics/new_types... for integers. The underscores mean that it's a non-exhaustive enum. An exhaustive enum is where you list all the names of the possible enum values, and other values are illegal. A non-exhaustive enum means any value in the underlying storage is allowed. So at root this code is creating a bunch of new integer types which are all backed by u32 but which can't be directly assigned or compared to each other. That means you can't accidentally pass a SectionIndex into a function expecting an ObjectFunctionImportIndex, which would be impossible to do if those functions just took raw u32's.
  - mtlynch 2y ago
    Ah, thanks! I tried converting that example to Zig: https://tars.run/t3eInpPFAgc https://tars.run/t3eInpPFAgc Is that the idea? You can do the same thing wrapping integers with structs, but enum makes it slightly more concise?
    - ImprobableTruth 2y ago
      Yes, that's how it works. I think in Zig for new types you'd use enums for ints and packed structs for more complex types.
- fallingsquirrel 2y ago
  It's an interesting pattern, but it's a shame there's no way to efficiently use one of those OptionalXIndex with zig's actual null syntax, `?` and `orelse` and etc. It would be smoother if you could constraint the nonexhaustive range, and let the compiler use an unused value as the niche for null. Maybe something like `enum(u32) { _ = 1...std.math.maxInt(u32) }`
  - samatman 2y ago
    There's an issue tracking that: https://github.com/ziglang/zig/issues/3806 https://github.com/ziglang/zig/issues/3806
quotemstr 2y ago
That's just newtype.

norir 2y ago

I am not a fan of zig, but I am a fan of discipline so I like this particular design decision.

alpaca128 2y ago
I would be fine with it if it only threw an error about that when building in release mode or if there was a flag to silence it temporarily. But while trying out some things and learning the language I find it annoying. And I don't know how it makes me more disciplined when I can just write `_ = unused;` to suppress the error. Even worse, if I forget that assignment in the code the compiler will never warn me about it again even when I want it to. So far I haven't seen any upside to this.
- dgfitz 2y ago
  I feel like this is like saying “python shouldn’t care so much about indentation, I’m just trying to learn!”
  - Phil_Latio 2y ago
    Wrong syntax is (and must be) an error. Totally different. The Problem in Go and Zig is that they put theory over practice: No compiler warnings is a good idea in theory, but fails in practice for things like unused variables or unused imports. Defending that makes it even worse and begs the question what other treasures they have burried in their language design. This thread is a testament to that.
    - riwsky 2y ago
      Forbidding unused imports was a direct response to the practical difficulty of compiling google-scale C++ binaries: https://go.dev/talks/2012/splash.article#TOC_5 https://go.dev/talks/2012/splash.article#TOC_5. In theory, programmers can just be disciplined enough or set up CI lints for unused imports. In practice…
      - 2y ago

deleted 2y ago

[deleted]

jeroenhd 2y ago

That's one if the great advantages of Zig. Other languages can't always enforce this rule (because of inheritance and such) and will generate strong warnings instead. If you like copying dead memory around, you can always do `_ = unusedParam` to confirm to the compiler that you don't need that variable after all, despite going out of yiur way to declare it.