@@ -52,7 +52,7 @@ for developers to want to handle errors from different operations in
5252the same basic way, either by reporting the error to the user or
5353passing the error back to their own clients.
5454
55- These errors will be the focus on this proposal.
55+ These errors will be the focus of this proposal.
5656
5757The final two classes of error are outside the scope of this proposal.
5858A **universal error ** is theoretically recoverable, but by its nature
@@ -305,7 +305,7 @@ generalized ``do`` statement::
305305As with ``switch `` statements, Swift makes an effort to understand
306306whether catch clauses are exhaustive. If it can determine it is, then
307307the compiler considers the error to be handled. If not, the error
308- automatically propagates out out of scope, either to a lexically
308+ automatically propagates out of scope, either to a lexically
309309enclosing ``catch `` clause or out of the containing function (which must
310310be marked ``throws ``).
311311
@@ -691,7 +691,7 @@ can throw, and so it must also be marked with ``try``::
691691 }
692692
693693This marking feels redundant. We want functions like
694- ``autoreleasepool `` to feel like statements, but marks inside builtin
694+ ``autoreleasepool `` to feel like statements, but marks inside built-in
695695statements like ``if `` don't require the outer statement to be marked.
696696It would be better if the compiler didn't require the outer ``try ``.
697697
0 commit comments