Update commonly_proposed.md

fixed incorrect location for "ErrorHandlingRationale" document, which was under the old `apple/swift` repo to `swiftlang/swift`, and also had wrong `.rst` file extension, which resulted in a 404 error when going to the document.

Author: AliMark71

commonly_proposed.md

@@ -29,7 +29,7 @@ Several of the discussions below refer to "C family" languages. This is intended
  * [Change closure literal syntax](https://forums.swift.org/t/streamlining-closures/487/3): Closure syntax in Swift has been carefully debated internally, and aspects of the design have strong motivations.  It is unlikely that we'll find something better, and any proposals to change it should have a very detailed understanding of the Swift grammar.
  * [Use pattern-matching in `if let` instead of optional-unwrapping](https://forums.swift.org/t/obsoleting-if-let/1301/4): We actually tried this and got a lot of negative feedback, for several reasons: (1) Most developers don't think about things in "pattern matching" terms, they think about "destructuring". (2) The vastly most common use case for `if let` is actually for optional matching, and this change made the common case more awkward. (3) This change increases the learning curve of Swift, changing pattern matching from being a concept that can be learned late to something that must be confronted early. (4) The current design of `if case` unifies "pattern matching" around the `case` keyword.  (5) If a developer unfamiliar with `if case` runs into one in some code, they can successfully search for it in a search engine or Stack Overflow.
  * [Remove or deprecate the force-unwrap operator `!`](https://forums.swift.org/t/moving-toward-deprecating-force-unwrap-from-swift/43455/82): Force-unwrap and force-try are legitimately useful parts of the language, and not just for source stability reasons. Therefore, proposals to deprecate or remove the force-unwrap operator (or `try!`), even in a mode enabled via compiler flag, will not be considered by the core team. Whether the Swift compiler should gain a more general "linting" capability to guide coding style remains a possible topic of discussion.
- * [Replace the `do`/`try`/`repeat` keywords with C++-style syntax](https://forums.swift.org/t/use-standard-syntax-instead-of-do-and-repeat/791/2): Swift's error handling approach is carefully designed to make it obvious to maintainers of code when a call can "throw" an error.  It is intentionally designed to be syntactically similar in some ways, but different in other key ways, to exception handling in other languages.  Its design is a careful balance that favors maintainers of code that uses errors, to make sure someone reading the code understands what can throw.  Before proposing a change to this system, please read the [Error Handling Rationale and Proposal](https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst) in full to understand why the current design is the way it is, and be ready to explain why your changes would be worth unbalancing this design.
+ * [Replace the `do`/`try`/`repeat` keywords with C++-style syntax](https://forums.swift.org/t/use-standard-syntax-instead-of-do-and-repeat/791/2): Swift's error handling approach is carefully designed to make it obvious to maintainers of code when a call can "throw" an error.  It is intentionally designed to be syntactically similar in some ways, but different in other key ways, to exception handling in other languages.  Its design is a careful balance that favors maintainers of code that uses errors, to make sure someone reading the code understands what can throw.  Before proposing a change to this system, please read the [Error Handling Rationale and Proposal](https://github.com/swiftlang/swift/blob/main/docs/ErrorHandlingRationale.md) in full to understand why the current design is the way it is, and be ready to explain why your changes would be worth unbalancing this design.
 
 ## Miscellaneous