P3471R4 Standard library hardening

[Eisenwave]

Fixes #7674.
Fixes cplusplus/papers#2125.

[Eisenwave]

@jwakely I have had some issues when creating this PR:

• The new note for [string.view.access] looks as if it had a paragraph number, but it's most likely intended to be attached to the hardened precondition paragraph. I have elected to ignore the paragraph number.

• The paper deletes "Two kinds of implementations are defined" in [intro.compliance] but the library has the same sort of wording in [compliance] (library intro). How to proceed? Delete redundant wording? Mirror changes?

• [structure.specifications] in the paper explains "Hardened preconditions" simply with two bullets that begin with "When". This is not how we usually do things. My suggestion would be something like "If the implementation is hardened ([intro.compliance]), ..." for the first bullet, and "Otherwise, ..." for the second bullet.

• [basic.contract.eval] is a dead reference at this point. It should be resolved after merging with contracts.

• It was very annoying that the paper doesn't have a wording diff that follows the structure of the standard linearly. For example, the paper first has the wording diff for 23.7.3.6.3 [mdspan.mdspan.members], and then the diff for 27.7.3.6.2 [mdspan.mdspan.cons]. The only thing this accomplishes is to bully the editor, and I'm the editor, and I feel bullied!

[frederick-vs-ja]

• The new note for [string.view.access] looks as if it had a paragraph number, but it's most likely intended to be attached to the hardened precondition paragraph. I have elected to ignore the paragraph number.

The old note was semantically connected to the preconditions paragraph but placed in a bad (IMO) place. I guess the intent wasn't attaching the note to the paragraph, but such attaching seems to be an editorial improvement to me.

• The paper deletes "Two kinds of implementations are defined" in [intro.compliance] but the library has the same sort of wording in [compliance] (library intro). How to proceed? Delete redundant wording? Mirror changes?

I think it's safest to mirror changes.

[burblebee]

The paper was applied correctly except for 2 missing edits, but there were other issues - see comments.

[burblebee]

Not your doing (from existing text), but wanted to point out that this is where the \defnadj for "freestanding implementation" should be (not above) since this is the definition. Same for "hosted implementation" in the sentence below.

[jwakely]

I think we want the defnadj to be on the first occurrence of the term.

[burblebee]

I respectfully disagree - suppose the introduction of the term came paragraphs before the actual definition, yet in the same section? I'd say we always want the definition to be at the actual definition.

[Eisenwave]

@jwakely what if we fixed it up like this, which seems like it would make both of you happy?

\pnum
A \defnadj{freestanding}{implementation}
is one in which % ...
A \defnadj{hosted}{implementation}
supports % ...
An implementation is either a
hosted implementation or a freestanding implementation.

[Eisenwave]

Actually I think this change is an absolute must anyway because [library] currently states whether an implementation is hosted or freestanding (it's impldef). This is way too late; core wording like [intro.multithread] already refers to freestanding.

If the \impldef for hardened implementations is in [intro], then so should the \impldef for hosted vs. freestanding. This is also about mirroring changes and getting rid of the "there are two kinds of implementations" wording. See a7a861a

[jensmaurer]

These might all be good ideas, but (because changing existing, unchanged text) feel out-of-scope for the pull request that applies an approved paper from the motions. And it most certainly not a "fixup".

[Eisenwave]

The reason I still feel like it should be included here is that the paper intentionally removes "two kinds of implementation" wording. It seems like an obvious oversight that this wasn't also done in [library], and like something that this paper (and therefore this PR) should do. If we merged without the fix, then we'd need to fix up the knowingly incorrect state we've created later anyway.

Would it be fine to split up the commit that just mirrors the changes in [library] and append the remaining stylistic improvements as a non-fixup?

[jensmaurer]

When applying papers, the contents of the primary paper application commit should be what the paper says, plus punctuation and typo fixes.

If there are additional fixes that are editorial and directly triggered by the paper, they should be in a separate commit, with the usual "[label] title" description.

If, beyond that, there is a reason to clean up the wording even further, I'd prefer to have a separate editorial pull request that can be considered on its own merits. Just because the outcome of a paper application is a bit suboptimal doesn't mean we should rewrite the entire surrounding words; presumably, the applied paper was peer-reviewed by LWG and/or CWG.

Let's address that separately after the motions.