[basic.life] p5 Fixed destructor calls not ending lifetime of objects with trivial destructors

[sdkrystian]

[basic.life] p4 states that calling the destructor for an object of class type will end its lifetime. [class.dtor] p16 reaffirms this. So does [dcl.init] p21, as if it didn't, destroying an object of a class type with a trivial destructor would not end its lifetime. However, [basic.life] p5 seems to disagree.

Changing

A program may end the lifetime of any object by reusing the storage which the object occupies or by explicitly calling the destructor for an object of a class type with a non-trivial destructor.

To

A program may end the lifetime of any object by reusing the storage which the object occupies or by explicitly calling the destructor for an object of a class type.

Resolves this issue.

[jensmaurer]

I'd like to see this addressed in the context of #2872 (which might very well need CWG review), as opposed to piecemeal.

It seems to me that [basic.life] p5 should become a note entirely; there is no new information here, unless it wants to say that reusing the storage of an in-lifetime object of class type with a non-trivial destructor is undefined behavior.

[randomnetcat]

The existing text in [basic.life]/5 is technically correct, as it is true that

A program may end the lifetime of any object by reusing the storage which the object occupies or by explicitly calling the destructor for an object of a class type with a non-trivial destructor.

It is simply excluding/ignoring other cases that end lifetime, which does not make it wrong, per se, just not super helpful.

[sdkrystian]

@random-internet-cat We can probably do away with it all together. As I said on slack and Jens did here, no new information is introduced, but rather it reaffirms how implicit destruction works (although, the wording might be changing quite drastically, see #2879)

[zygoloid]

Deferring; this should be addressed by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0593r3.html#pseudo-destructor-calls

[jensmaurer]

Please rebase and fix the conflicts, then force-push.

[sdkrystian]

@jensmaurer We can close this; this has been addressed by the aforementioned paper.