3 ms·

> `slice[i]` is just sugar for `slice.get(i).unwrap()`. And whether it's a "local" invariant or not is orthogonal. And `unwrap()` does not "require lying about

> `slice[i]` is just sugar for `slice.get(i).unwrap()`. And whether it's a "local" invariant or not is orthogonal. And `unwrap()` does not "require lying about invariants across your API surface." It's not orthogonal. `Result` isn't a local invariant, and yes, `.unwrap()` does require lying. If your code depends on an API that can fail, and you cannot handle that failure locally (`.unwrap()` is not handling it), then your type signature needs to express that you can fail -- and you need to raise an error on that failure. > That's an extreme position. It isn't caveated to only apply to certain contexts. No, it's a principled position. Correct code doesn't `.unwrap()`, but code that hides failure cases -- or foists invariant enforcement onto programmers remembering not to screw up -- does. I've built and worked on ridiculously complex code bases without a single instance of `.unwrap()` or the local language equivalent; it's just not necessary. This is just liked the unchecked exception debate in Java -- complex explanations for a very simple goal of avoiding the thought, time, and effort to accurately model a system's invariants.

burntsushi 11mo ago
> No, it's a principled position. Correct code doesn't `.unwrap()`, but code that hides failure cases -- or foists invariant enforcement onto programmers remembering not to screw up -- does. I don't think you understand what an internal runtime invariant is. Either way, I don't know of any widespread libraries (in any language) that follow this "principled" position. That makes it de facto extreme. > I've built and worked on ridiculously complex code bases without a single instance of `.unwrap()` or the local language equivalent; it's just not necessary. Show me. If you're using `slice[i]`, then you're using `unwrap()`. It introduces a panicking branch. > If your code depends on an API that can fail, and you cannot handle that failure locally (`.unwrap()` is not handling it), then your type signature needs to express that you can fail -- and you need to raise an error on that failure. You use `unwrap()` when you know the failure cannot happen. I note you haven't engaged with any of the examples I provided in the blog.
- frumplestlatz 11mo ago
  > You use `unwrap()` when you know the failure cannot happen. That’s an invariant meant to be expressed by your type system — and it is. You’ve failed to model your invariants in your API — and thus the type system — if you ever reach a point where an engineer has to manually assess and assert whether “cannot” applies. You will get it wrong. That is bad code.
  - burntsushi 11mo ago
    You can't model all invariants in the type system. My blog even shows examples of this too.

burntsushi 11mo ago

> No, it's a principled position. Correct code doesn't `.unwrap()`, but code that hides failure cases -- or foists invariant enforcement onto programmers remembering not to screw up -- does. I don't think you understand what an internal runtime invariant is. Either way, I don't know of any widespread libraries (in any language) that follow this "principled" position. That makes it de facto extreme. > I've built and worked on ridiculously complex code bases without a single instance of `.unwrap()` or the local language equivalent; it's just not necessary. Show me. If you're using `slice[i]`, then you're using `unwrap()`. It introduces a panicking branch. > If your code depends on an API that can fail, and you cannot handle that failure locally (`.unwrap()` is not handling it), then your type signature needs to express that you can fail -- and you need to raise an error on that failure. You use `unwrap()` when you know the failure cannot happen. I note you haven't engaged with any of the examples I provided in the blog.

frumplestlatz 11mo ago
> You use `unwrap()` when you know the failure cannot happen. That’s an invariant meant to be expressed by your type system — and it is. You’ve failed to model your invariants in your API — and thus the type system — if you ever reach a point where an engineer has to manually assess and assert whether “cannot” applies. You will get it wrong. That is bad code.
- burntsushi 11mo ago
  You can't model all invariants in the type system. My blog even shows examples of this too.