What is your evaluation of the proposal?
This is an excellent proposal, and I fully support it with a strong +1.
Is the problem being addressed significant enough to warrant a change to Swift?
Yes! It fills a major hole between the loss of information between types such as Result and Task and the Swift's error-handling system.
Does this proposal fit well with the feel and direction of Swift?
It provides a nice abstraction over carrying a generic type parameter throughout throwing effects, which eliminates the need for previous workarounds like rethrows and @rethrows protocol annotations. Additionally, it opens doors for AsyncSequence to FINALLY introduce primary associated types now that we have a notion to express a generic Failure type.
The only thing I miss from subtyping relationships (or from future directions) section is that
we could accommodate subtyping the relationship of f() -> Element? and f() throws(Void) -> Element, as brought up by Xiaodi in the pitch thread.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Previously relying on Result types in Swift for internal error type information in our SDK was cumbersome, particularly during type conversion and unwrapping. Most other strongly types languages I used deal with similar Result constructs (e.g. Rust). What stands out in this proposal is the ability to consistently use multiple try statements within function bodies while preserving static error type information.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I closely monitored the proposal's evolution and its discussion history, as well as Doug's pull requests throughout the process. Moreover, I had the opportunity to test it with the provided toolchain.