Earlier quoted context omitted.
> 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, b…
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.
That said, Rust also makes it very easy to define your own types that can only be constructed/unpacked in limited ways, which can enforce special constraints on their contents. And it has a cultural norm of doing this in the standard library and elsewhere
Eg: a sibling poster noted the NonZero type. Another example is that Rust's string types are guarantees to always contain valid UTF-8, because whenever you try and convert a byte array into a string, it gets checked and possibly rejected.