It's not. "Forced error handling" in Rust (particularly when contrasted with something like Go like we're doing here) is exemplified with the Option and Result types, and how the compiler will maintain type safety around the concepts of success and error. ADTs are what lets it do that, and the MLs do that as well. You can also see this in how Typescript for example uses ADTs for typesafe error/success state space enumeration.
But you could have ADTs without using them for 'forced error handling', and you could have 'forced error handling' without using ADTs for it - C could require 'consumption' (for a slightly less strict meaning of it) of return values. That's the bit I think is interesting/was new to me. You can't just call `maybe_works();`, you have to explicitly consume its 'result', even if just to propagate the error as `maybe_works()?;`.
Oh, ok. Yeah that in fact does exist in C and C++ the same way as in Rust. Rust doesn't actually by default require you to consume a return value; a lot of functions are just marked as #[must_use]. C and C++ do the same thing with [[nodiscard]] and __attribute__((warn_unused_result)).
No, not really, it's an accurate summation of where the pattern is commonly found. ADTs, like Rust's Enum, enable this kind of error handling, and are made more ergonomic with monad behaviors.
Sure. Result is specific, you get a value or an error. Either can be used the same way, but you don't have to. The convention is use Right for the value and Left for the error but you can use it in other ways too, eg Left for an Int and Right for a Float.
Well that's not true, that's completely orthogonal?