On Wed, 23 Apr 2025 at 04:15, Herb Sutter via SG12
<sg12_at_[hidden]> wrote:
>
> (Jens and Gašper, please correct/expand anything below.)
>
>
>
> Hi everyone, this is an update on progress on the UB/IFNDR work, and a request for this group’s feedback on the questions below.
>
>
>
> The first step is to document the current UB/IFNDR we already have: tag all instances and create Annexes. Shafik (thanks!) with help from some others (especially Timur and Josh, thanks!) has a pretty complete first pass as a draft PR here for explicit cases of IFNDR (25 cases) and UB (63 cases):
>
>
>
> https://github.com/cplusplus/draft/pulls?q=is%3Apr+is%3Aopen+label%3Aub-ifndr
>
>
>
> The goal is to turn this into a comprehensive submission to CWG. Two major next substeps:
>
>
>
>
>
> A) Before it’s ready for CWG we need to eradicate all mentions of normative-looking words: “shall”, “may”, “might”, “could”, and “should”.
>
>
>
> Using the example \ubxref{expr.delete.dynamic.type.differ} as a test for what we want to do:
>
>
>
> Current PR says:
> If the static type of the object to be deleted is different from its dynamic type and the selected deallocation function (see below) is not a destroying operator delete, the static type shall be a base class of the dynamic type of the object to be deleted and the static type shall have a virtual destructor or the behavior is undefined.
>
>
>
> Possible rewrite 1 – just avoid normative words:
> Issue: Deleting an object whose static type is different from its dynamic type and the selected deallocation function is not a destroying operator delete, and:
> * the static type is not a base class of the dynamic type of the object to be deleted; or
> * the static type does not have a virtual destructor.
>
>
>
> Possible rewrite 2 – condensed paraphrase:
> Issue: Deleting an object of type T, where the operand of the delete-expressions is of type "pointer to U", for certain combinations of T and U.
>
>
>
> Jens suggested that style 2 may be better: It’s less likely to become inconsistent if we ever change the normative rule in the future. It avoids trying to exactly reproduce the rule (we have cross-references for that).
>
>
>
> Call for feedback: What do you think? Do we prefer style 1, or style 2, or something else?
>
>
>
> If there’s deafening silence, we’ll interpret that as unanimous consent for “Jens is always right, do style 2.” 😊

I concur with Jens's suggestion, use Rewrite 2 with cross-references.
The rationale is 2+-fold:

1) This is an index-annex.
1.1) It should attempt to be explanatory beyond what a mere specification is.
2) It's not productive to rephrase existing wording in it with only
"let's not use 'shall'" modifications.
That loses the opportunity to be more explanatory, and gets out of
sync when the spec-wording changes
and the annex-wording doesn't, so don't aim for Specification Wording
in the annex, make it an index with an explanatory
summary of what's what, and link to the actual spec-standardese with a
cross-reference.