5 ms·

> If I were to use indices out of range, presumably that would that give me a compile time error? Yes, if all operands are comptime-known (or comptime-length-k

> If I were to use indices out of range, presumably that would that give me a compile time error? Yes, if all operands are comptime-known (or comptime-length-known), bounds checks happen eagerly at compile time. > Could I use variables as the indices and, if so, could I get a seg fault at runtime or are there some sort of guards on there? Yes you can use variables. If they're out of range, behavior depends on the build mode: - In Debug and ReleaseSafe, you get a guaranteed panic (which aborts the app with a stack trace) - In ReleaseSmall and ReleaseFast, you get undefined behavior On their discord I suggested a version of slicing that bounds checks in all modes (something like `slice?[1..5]`, syntax doesn't matter) and returns an optional slice, which is null if the bounds are out of range. But they didn't seem too keen on it. So I've been using a little wrapper function instead.

throwawaymaths 3y ago
Why not just compile your whole program safe and then demarcate which functions you want to not be safety checked?
- estebank 3y ago
  Careful, you're dangerously close to suggesting an effects system. If the function explicitly marked as doing unsafe math operations calls another that doesn't specify a preference, should its math operation be safe or unsafe? If the former, this makes it likely a better default, but limiting in its usefulness. If the later, then your compiler now has to keep track of this information for the entire call graph.
  - throwawaymaths 3y ago
    The form of safety we are talking about here is not like rust's "safety", it does not color functions, and is strictly scoped to the compiled unit (in this case, function) https://ziglang.org/documentation/master/#setRuntimeSafety https://ziglang.org/documentation/master/#setRuntimeSafety
    - estebank 3y ago
      I am aware, my point is about how the following is dealt with: fn foo(x: i32) i32 { return x + 100; } fn bar(x: i32) i32 { @setRuntimeSafety(false); return foo(x + 100); } Particularly when you have arbitrarily deep call graphs where some explicitly enable and disable runtime safety.
      - throwawaymaths 3y ago
        You mean overflow checking? It only applies to the `x + 100` in bar. Bar can still panic if the `x + 100` in foo overflows. Why should it be any other way?

throwawaymaths 3y ago

Why not just compile your whole program safe and then demarcate which functions you want to not be safety checked?

estebank 3y ago
Careful, you're dangerously close to suggesting an effects system. If the function explicitly marked as doing unsafe math operations calls another that doesn't specify a preference, should its math operation be safe or unsafe? If the former, this makes it likely a better default, but limiting in its usefulness. If the later, then your compiler now has to keep track of this information for the entire call graph.
- throwawaymaths 3y ago
  The form of safety we are talking about here is not like rust's "safety", it does not color functions, and is strictly scoped to the compiled unit (in this case, function) https://ziglang.org/documentation/master/#setRuntimeSafety https://ziglang.org/documentation/master/#setRuntimeSafety
  - estebank 3y ago
    I am aware, my point is about how the following is dealt with: fn foo(x: i32) i32 { return x + 100; } fn bar(x: i32) i32 { @setRuntimeSafety(false); return foo(x + 100); } Particularly when you have arbitrarily deep call graphs where some explicitly enable and disable runtime safety.
    - throwawaymaths 3y ago
      You mean overflow checking? It only applies to the `x + 100` in bar. Bar can still panic if the `x + 100` in foo overflows. Why should it be any other way?