[except.ctor] Return object destruction from throwing postcondition evaluation

[notadragon]

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

Reference (section label): [except.ctor] p2

Link to reflector thread (if any):

Issue description: There is special dispensation in this paragraph to destroy the return object that was created already when an exception escapes the destruction of temporaries or local variables after the return statement has been evaluated. We need the same dispensation for an exception escaping the evaluation of postconditions (because the return object doesn't fall under the general rules for automatic variables because it's not automatic.

The existing paragraph also doesn't seem like it should be about "an exception thrown during the destruction..." but rather an exception escaping that destruction. (An exception thrown and then caught during that destruction should not result in destroying the return object, because that would be insane).

Suggested resolution:

Each object with automatic storage duration is destroyed if it has been constructed, but not yet destroyed,
since the try block was entered. If an exception is thrown during from the destruction of temporaries or local
variables for a return statement (8.8.4), or from the evaluation of postcondition assertions of the enclosing function ([expr.call]), the destructor for the returned object (if any) is also invoked. The
objects are destroyed in the reverse order of the completion of their construction.

[t3nsor]

It seems like the actual idea is really: if the try block corresponding to the matching handler encloses the return statement or is in a different function, then we have to destroy the returned object. Maybe we can say that instead of listing the things that can happen after the return statement?

[t3nsor]

Oh also the section label is [except.ctor], not [expr.ctor].

[notadragon]

(fixed the section). In thinking about this, i think that the real solution would be for objects like this whose lifetime is supposed to be completely managed by control flow and the compiler are really still automatic storage duration objects. I think it's very similar to how we should (and sorta do but aren't super formal about) treat const objects --- they're not really const complete objects until their final initializer is finished executing (otherwise a delegating constructor for such an object would blow up if it tried to change a member variable).

This could apply to both temporaries and return objects, and then they'd all be automatically cleaned up exactly when they should. (And if the return object iniitializes an automatic variable, it stays automatic. if it is dynamic or static storage duration, it changes storage duration at that time.) This should even match real implementations better --- a static storage duration object shouldn't be added to the list of things to destroy until its initializer is fully complete, and until that point its destruction is handled automatically by control flow. A temporary that gets lifetime extended by being bound to a static reference just changes storage duration when that reference is bound.

But that's all a bigger change. This wording could be adjusted like @t3nsor suggests, but it's not just about the scope, it's about the return statement having already been evaluated and the return object's constructor having already completed (just like automatic variables).

Looking at the words though, i wonder if we can just have the first sentence apply to return objects as well as automatic variables (without actually altering the definition of storage duration more globally) to say this:

Each object with automatic storage duration, as well as the return object (if any) of a return statement (8.8.4), is destroyed if it has been constructed, but not yet destroyed,
since the try block was entered. If an exception is thrown during the destruction of temporaries or local
variables for a return statement (8.8.4), the destructor for the returned object (if any) is also invoked. The
objects are destroyed in the reverse order of the completion of their construction.