What is your evaluation of the proposal?
I love it! Big +1 from me. This was the feature I was missing most in Swift. And the way it is executed makes a lot of sense and fits right into the existing feature set and APIs.
Is the problem being addressed significant enough to warrant a change to Swift?
Yes, definitely! It will entirely change the way I do error handling in my apps, mostly making it easier and clearer. This feature will directly correlate with how useful error messages will be to my users. Also, some well-chosen functions in my open-source libraries might use this, too.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
No in-depth study of the implementation, but I have thought about error handling in Swift in depth. I even prepared an error-handling framework for app developers based on the Result type to work around the current lack of typed throws in the language (I didn't release it yet because I saw this proposal coming which will have a big impact on that framework). I've read the full proposal twice (first an earlier version of it) – note though that I'm no compiler expert and do not understand the Swift grammar part fully.
Does this proposal fit well with the feel and direction of Swift?
The Swift website states Swift is "modern, safe, and a joy to write". This proposal makes Swift even more modern, safe, and a joy to write. So: Yes! Less guessing of potential error types for APIs where they can be made clear. This means basically all of my own error types I create within my apps can now be clearly communicated both to the compiler and to the users of those APIs. This will reduce a lot of boilerplate I currently have in my code and make my code safer while reducing cognitive load by offloading that to the compiler, improving safety & joy. (I had already stated why untyped throws are not safe here.) And the way it still supports the untyped throws feels very modern, giving the developers the choice. Another useful tool in their belt.