[basic.stc.dynamic.general] Fix definition/explanation of dynamic storage duration #7330
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As part of #7261.
This PR fixes numerous issues with [basic.stc.dynamic.general] p1:
"dynamically" is not defined in the standard, and the paragraph does not define it (judging by formatting), so this term is meaningless.
The paragraph specifically states "during program execution", but C++20 allows the user to create dynamic storage duration objects during program translation, i.e. within constant evaluation.
The explanation given here is not exhaustive. Normative wording in [basic.stc.general] p2 already states "The dynamic storage duration is associated with objects created by a new-expression ([expr.new]) or with implicitly created objects ([intro.object]).". Notably, implicitly created objects are not mentioned in [basic.stc.dynamic.general].
It is worth noting that the new definition explicitly gives dynamic storage duration to objects, which is inconsistent with the other definitions. For example, [basic.stc.static] says:
@jensmaurer has stated in #6523 (comment) that we have long-standing problems with the term "variable". At first sight, this may be a blocker for this edit.
However, this editorial issue does not introduce a novel problem because [expr.new] p10 already states:
In other words, this PR makes no normative changes. It aggregates existing wording from [expr.new] and [basic.stc.general] and replaces old incorrect or incomplete wording.