3 ms·

Haskell throws an exception and rust panics on division by zero for ints. This is just defensive programming. The None state here is already an invalid state.

Haskell throws an exception and rust panics on division by zero for ints. This is just defensive programming. The None state here is already an invalid state. If you want to use the type system to ensure correctness you would change the second argument to be a type representing multiplicatively invertible integers.

deltaonefour 5y ago
You need to employ pattern matching for exhaustive type checking to be deployed. For haskell it will give you a warning. For Rust it will actually not compile. The key here is that you MUST use pattern matching.
- jcranberry 5y ago
  If the compiler can figure out that you are dividing by zero at compile time then you will get those results. That is not a realistic expectation in general. Having to wrap every division call in a maybe monad or rust result enum is bad from a usability standpoint and potentially unacceptable from a performance standpoint. Exhaustive pattern matching is great. But not a replacement for other types of error handling.
  - deltaonefour 5y ago
    Performance is a trade off and usability is arguable. There are ML style languages where a Maybe monadic value is the default return value of division due to the division by zero issue. There are languages that employ this philosophy everywhere. Such languages are actually incapable of having a runtime error outside of edge cases like ffi. Just so you know, you don't have to wrap every type in an enum. Types and enums share a bijective relationship. A type IS an enum and vice versa. You CAN in fact define an Int in terms of an enum (and an enum in terms of an int, in C). The mechanisms behind an Int and a bool are roughly the same, it's just the cardinality and mappings that are different. Pattern matching implementations usually check types based off of cardinality and do not differentiate between enums and other built in types like floats or ints.

deltaonefour 5y ago

You need to employ pattern matching for exhaustive type checking to be deployed. For haskell it will give you a warning. For Rust it will actually not compile. The key here is that you MUST use pattern matching.

jcranberry 5y ago
If the compiler can figure out that you are dividing by zero at compile time then you will get those results. That is not a realistic expectation in general. Having to wrap every division call in a maybe monad or rust result enum is bad from a usability standpoint and potentially unacceptable from a performance standpoint. Exhaustive pattern matching is great. But not a replacement for other types of error handling.
- deltaonefour 5y ago
  Performance is a trade off and usability is arguable. There are ML style languages where a Maybe monadic value is the default return value of division due to the division by zero issue. There are languages that employ this philosophy everywhere. Such languages are actually incapable of having a runtime error outside of edge cases like ffi. Just so you know, you don't have to wrap every type in an enum. Types and enums share a bijective relationship. A type IS an enum and vice versa. You CAN in fact define an Int in terms of an enum (and an enum in terms of an int, in C). The mechanisms behind an Int and a bool are roughly the same, it's just the cardinality and mappings that are different. Pattern matching implementations usually check types based off of cardinality and do not differentiate between enums and other built in types like floats or ints.