cplusplus / CWG

Core Working Group
24 stars 7 forks source link

[stmt.dcl] Is the order of destruction of the parameter covered by this clause? #126

Open xmh0511 opened 2 years ago

xmh0511 commented 2 years ago

Full name of submitter (unless configured in github; will be published with the issue): Jim X

[stmt.dcl] p2 says

A variable with automatic storage duration ([basic.stc.auto]) is active everywhere in the scope to which it belongs after its init-declarator. ... all variables with automatic storage duration that are active at P and not at Q are destroyed in the reverse order of their construction.

As pointed out in https://github.com/cplusplus/CWG/issues/42#issuecomment-1142309296, this clause seems to only cover block declarations. Although, a parameter has automatic storage duration, however, it's neither a block variable nor it a grammar that matches init-declarator. From this perspective, [stmt.dcl] does not specify the order of the destruction of the parameter. The order of the destruction of the parameter is underspecified in this document. Nontheless, we say the initialization of the parameter is indeterminately sequenced with that of other parameters, however, it does not prevent that they eventually have an determined order of the initialization at the call point. Once the order of the initialization is determined, the order of the destruction of the parameters should have the similar manner as other variables: they are destroyed in the reverse order of their initialization.

JohelEGP commented 2 years ago

It is.

1# Variables that belong to a block or parameter scope and are not explicitly declared static, thread_­local, or extern have automatic storage duration.

So parameters have automatic storage duration.

Upon each transfer of control (including sequential execution of statements) within a function from point P to point Q, all variables with automatic storage duration that are active at P and not at Q are destroyed in the reverse order of their construction.

And this mandates that they're destroyed in reverse order of construction.

jensmaurer commented 2 years ago

So, is the remaining issue that we should amend init-declarator in [stmt.dcl] p2 to add parameter-declaration-clause or maybe parameter-declaration?

JohelEGP commented 2 years ago

It is.

The premise is right. Where a parameter is active is underspecified, so is its destruction.

xmh0511 commented 2 years ago

So, is the remaining issue that we should amend init-declarator in [stmt.dcl] p2 to add parameter-declaration-clause or maybe parameter-declaration?

An awkward issue is that, p2 also says

When a declaration-statement is executed, P and Q are the points immediately before and after it; when a function returns, Q is after its body.

However, the parameter is special here, since [expr.call] p7 says

It is implementation-defined whether the lifetime of a parameter ends when the function in which it is defined returns or at the end of the enclosing full-expression.

That is to say, we only want [stmt.dcl] p2 partially covers the destruction of parameters(specifically, their order).

xmh0511 commented 1 year ago

We may either move [stmt.dcl] p2 to [basic.stc.auto] to indicate the rule applies to all variables(objects) that have automatic storage duration, or we should entirely mention syntaxes such as init-declarator, parameter-declaration-clause, as well as exception-declaration the rule presumably covers in the list of [stmt.dcl] p2. The first suggestion is preferred, I think.