> However, Nim's fundamentals (integer arithmetic, array access, etc) are based > on exceptions or "interruptable panics"
wait, what? `Defect` is not part of the effect system, not meant to be caught and has an compiler option/dialect to disable it / turn it into a panic meaning you can't rely on it in libraries. It's also a bit of a swiss cheese in terms of coverage, ie `SIGSEGV` is still pretty common because not all panics are defects in the language (in particular NPE). It's also not extensible: I cannot create a `Defect` the same way the system does it for say an overflow (because parts of it is implemented not in the std lib but in the compiler proper which leads to difficulties and differences), meaning that unlike "exceptions" it's not really a user-land feature. These are some reasons why it's comparing apples and pears to be talking about exceptions when really, panics are being discussed. When we talk about exceptions in the style guide, we're not at all referring to the `Defect` branch of the inheritance tree - but rather the `CatchableError` part which some code likes to use as part of its "normal" control flow. As mentioned, it's a set of tradeoffs - it's fine that others land with a different decision than us, though the one thing to say on this topic would be that in terms of primitive operations, it's usually the case that it's easier to write them exception-free (`raises: []`) and later add a layer of exceptions on top - `Result` offers this as a feature, so that primitive libraries can easily be built exception-free while usage in exception-based code is .. simple. We'd actually prefer that a number of the current defects become part of the effect system as well, including array access and integer overflow, such that `raises: []` prevents them from being ignored _at that boundary_.
