Hacker News new | past | comments | ask | show | jobs | submit login

Please don't spread misinformation. Zig does not have implicit null.

Also depending on how you define "dependent types" - there are a few competing definitions - Zig has them.




> Also depending on how you define "dependent types" - there are a few competing definitions - Zig has them.

How is it ambiguous? Dependent type systems/algorithms can be weaker than desired, but there's no way you can say Zig has dependent types.


I think Andy refers to this [1].

For example you can do:

  const std = @import("std");
  
  fn Int(comptime value: i32) type {
      return struct {
          pub fn value() i32 {
              return value;
          }
      };
  }
  
  pub fn main() anyerror!void {
      const int3 = Int(3);
      const int4 = Int(4);
  
      std.debug.warn("Types: {} {}\n", @typeName(int3),   @typeName(int4));
      std.debug.warn("Sum: {}\n", int3.value() + int4.value());
  }
Output being:

  Types: Int(3) Int(4)
  Sum: 7
Edit: The compiler does the right thing:

[2] https://godbolt.org/z/eLWeU2

[1] https://ziglang.org/documentation/master/#Generic-Data-Struc...


Oh, I must be mistaken then. So pointers are guaranteed not to be null? Can I mark pointers as nullable, and be forced to explicitly check?

Although there are differing ways to define dependent types, and they come in different varieties (dependent functions, dependent pairs/structs, very dependent types, dependent intersections, inductive types), they are all founded on a foundation of type theory. I guess if you want me to clarify, it is 'dependent types based on a well understood foundation from type theory'.

---

Edit: seems like Zig does have optional types! That is a good thing! https://ziglang.org/documentation/master/#Optionals




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: