Title
Unsequenced throw-expressions
Status
tentatively ready
Section
7.6.18 [expr.throw]
Submitter
Jan Schultke

Created on 2024-10-23.00:00:00 last changed 1 week ago

Messages

Date: 2024-11-09.00:21:39

CWG 2024-11-08

Check with implementers (in particular MSVC) that the proposed resolution is acceptable.

Date: 2024-11-09.00:21:39

Proposed resolution (approved by CWG 2024-11-08):

Change in 6.9.1 [intro.execution] paragraph 11 as follows, adding bullets:

When invoking a function (whether or not the function is inline), every argument expression and the postfix expression designating the called function are sequenced before every expression or statement in the body of the called function. For each
  • function invocation,
  • evaluation of an await-expression (7.6.2.4 [expr.await]), or
  • evaluation of a throw-expression (7.6.18 [expr.throw])
F, each evaluation that does not occur within F but is evaluated on the same thread and as part of the same signal handler (if any) is either sequenced before all evaluations that occur within F or sequenced after all evaluations that occur within F; [ Foonote: ... ] if F invokes or resumes a coroutine (7.6.2.4 [expr.await]), only evaluations subsequent to the previous suspension (if any) and prior to the next suspension (if any) are considered to occur within F.
Date: 2024-10-23.00:00:00

(From submission #626.)

The semantics of unsequenced throw-expressions is unclear. For example:

  (throw /* ... */, 0) + (throw /* ... */, 0);

This appears to cause two unsequenced transfers of control, which makes little sense. In contrast, a co_await expression is indivisible (6.9.1 [intro.execution] paragraph 11) per issue 2466.

History
Date User Action Args
2024-11-09 00:21:39adminsetmessages: + msg7891
2024-11-09 00:21:39adminsetstatus: open -> tentatively ready
2024-10-28 07:08:21adminsetmessages: + msg7863
2024-10-23 00:00:00admincreate