As a daily user of F# I'm not sold on this suggested alternative. It seems to be trying to make it as easy as possible to make the Result type behave like excep

As a daily user of F# I'm not sold on this suggested alternative. It seems to be trying to make it as easy as possible to make the Result type behave like exception handling, but I think there are some key downsides to the approach. First, Result is often used in place of Choice only to communicate the intent that the 2nd case is an error case. Making it more work to use Result (by requiring the types used for the Error to implement some special interface) means programmers will simply use Choice instead. But the bigger issue is that this suggested change would remove the ability to ensure that cases of an error type are exhaustively matched. They introduce the FailAs active pattern at the very end of the blog to deal with logic that wants to inspect the underlying error cases, but active patterns break the compilers ability to check if a match is exhaustive. This is a really useful property for program correctness, I can ensure that a caller of my function will receive a compiler error when a new error case is introduced that wasn't previously handled. I wonder if a better design for the error type could be some kind of error type set that could automatically collect possible error cases up the call stack, so that when confronted with an IFault you at least know what possible cases it could have. With some type inference help it might not even be that painful to deal with, the first example could automatically infer a type like Errors<AtlasError, ForExError>. As touched on briefly in the article, the elephant in the room here is that changing the Result type doesn't do anything to unify the two distinct worlds of exceptions vs error values that currently exist in F#. Dealing with obscure C# exception flow from F# has been the biggest source of subtle, hard to track down bugs in my production code.