Wording

P2490R3.html

@@ -2275,7 +2275,7 @@ <h3 class="heading settled" data-level="3.4" id="coroutines"><span class="secno"
    <p>In several places in the coroutines machinery exceptions are specified as being caught and rethrown, e.g. if the initial suspend throws (before initial <em>await-resume</em>), the exception is caught and rethrown to the coroutine caller; from this point onwards, exceptions are caught as if by <code class="highlight"><c- p>...</c-></code> and <code class="highlight"><c- n>unhandled_exception</c-></code> is called on the promise.
 This will result in stacktraces retrieved in the caller being truncated to the rethrow point, and not being available at all to <code class="highlight"><c- n>unhandled_exception</c-></code>.</p>
    <p>The issue of truncation could be addressed by special wording; implementations may be able to use automatic object cleanups (which do not interrupt a stacktrace).</p>
-   <p><code class="highlight"><c- n>unhandled_exception</c-></code> could be fixed by allowing the <code class="highlight"><c- p>[[</c-><c- n>with_stacktrace</c-><c- p>]</c-></code> attribute to appertain to member function declarations as well as <em>exception-declarations</em>, such that it could be applied to a promise type’s <code class="highlight"><c- n>unhandled_exception</c-></code> member function, thereby directing the implementation to make exception stacktrace available to that handler.</p>
+   <p>By allowing the <code class="highlight"><c- p>[[</c-><c- n>with_stacktrace</c-><c- p>]</c-></code> attribute to appertain to member function declarations as well as <em>exception-declarations</em>, it could be applied to a promise type’s <code class="highlight"><c- n>unhandled_exception</c-></code> member function, thereby directing the implementation to make exception stacktrace available to that handler.</p>
    <h3 class="heading settled" data-level="3.5" id="allocators"><span class="secno">3.5. </span><span class="content">Allocators</span><a class="self-link" href="#allocators"></a></h3>
    <p>Previously, we suggested that some syntaxes could permit the user to supply an allocator; this might be desirable for performance and/or latency.
 On the other hand, allowing the user to supply an allocator opens the door to abuse (running arbitrary user code during unwinding).

paper.md

@@ -228,7 +228,7 @@ This will result in stacktraces retrieved in the caller being truncated to the r
 
 The issue of truncation could be addressed by special wording; implementations may be able to use automatic object cleanups (which do not interrupt a stacktrace).
 
-`unhandled_exception` could be fixed by allowing the `[[with_stacktrace]` attribute to appertain to member function declarations as well as *exception-declarations*, such that it could be applied to a promise type's `unhandled_exception` member function, thereby directing the implementation to make exception stacktrace available to that handler.
+By allowing the `[[with_stacktrace]` attribute to appertain to member function declarations as well as *exception-declarations*, it could be applied to a promise type's `unhandled_exception` member function, thereby directing the implementation to make exception stacktrace available to that handler.
 
 ## Allocators