←back to thread

611 points LorenDB | 1 comments | | HN request time: 0.248s | source
Show context
simpaticoder ◴[] No.43910617[source]
I don't get it. Isn't this a runtime problem and not a compile-time problem? buy() or sell() is going to be called with dynamic parameters at runtime, in general. That is, calls with concrete values are NOT going to be hard-coded into your program. I would write the function to assert() invariants within the function, and avoid chasing compile-time safety entirely. If parameter order was a concern, then I'd modify the function to take a struct, or similar.
replies(1): >>43910710 #
brundolf ◴[] No.43910710[source]
> Isn't this a runtime problem and not a compile-time problem? buy() or sell() is going to be called with dynamic parameters at runtime, in general.

Yes, but the strength of Rust's type system means you're forced to handle those bad dynamic values up front (or get a crash, if you don't). That means the rest of your code can rest safe, knowing exactly what it's working with. You can see this in OP's parsing example, but it also applies to database clients and such

replies(1): >>43910929 #
simpaticoder ◴[] No.43910929[source]
What if the valid input for quantity must be greater than 0? A reasonable constraint, I think. The OP's example is contrived to line up with Rust's built-in types, and ignores the general problem.
replies(2): >>43911650 #>>43912604 #
1. siev ◴[] No.43911650[source]
Rust also has the standard NonZero<T> type for that use case.