PEP 765: add rejected ideas section (#4130)

Author: iritkatriel

peps/pep-0765.rst

@@ -156,6 +156,48 @@ that their code needs to change. The `empirical evidence <#appendix>`__
 shows that the changes necessary are typically quite
 straightforward.
 
+Rejected Ideas
+==============
+
+Emit ``SyntaxError`` in CPython
+-------------------------------
+
+:pep:`601` proposed that CPython would emit ``SyntaxWarning`` for a couple of
+releases and ``SyntaxError`` afterwards. We are leaving it open whether, and
+when, this will become a ``SyntaxError`` in CPython, because we believe that a
+``SyntaxWarning`` would provide most of the benefit with less risk.
+
+Change Semantics
+----------------
+
+It `was suggested <https://discuss.python.org/t/pep-765-disallow-return-break-continue-that-exit-a-finally-block/71348/32>`__
+to change the semantics of control flow instructions in ``finally`` such that an
+in-flight exception takes precedence over them.  In other words, a ``return``,
+``break`` or ``continue`` would be permitted, and would exit the ``finally``
+block, but the exception would still be raised.
+
+This was rejected for two reasons. First, it would change the semantics of
+working code in a way that can be hard to debug: a ``finally`` that was written
+with the intention of swallowing all exceptions (correctly using the documented
+semantics) would now allow the exception to propagate on. This may happen only
+in rare edge cases at runtime, and is not guaranteed to be detected in testing.
+Even if the code is wrong, and has an exception swallowing bug, it could be
+hard for users to understand why a program started raising exceptions in 3.14,
+while it did not in 3.13.
+In contrast, a ``SyntaxWarning`` is likely to be seen during testing, it would
+point to the precise location of the problem in the code, and it would not
+prevent the program from running.
+
+The second objection was about the proposed semantics. The motivation for
+allowing control flow statements is not that this would be useful, but rather
+the desire for orthogonality of features (which, as we mentioned in the
+introduction, is already violated in the case of ``except*`` clauses). However,
+the proposed semantics are complicated because they suggest that ``return``,
+``break`` and ``continue`` behave as they normally do when ``finally`` executes
+without an in-flight exception, but turn into something like a bare ``raise``
+when there is one. It is hard to claim that the features are orthogonal if
+the presence of one changes the semantics of the other.
+
 Appendix
 ========