Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[std] Update references to [container.requirements.general] #6184

Closed
JohelEGP opened this issue Mar 14, 2023 · 5 comments · Fixed by #6253
Closed

[std] Update references to [container.requirements.general] #6184

JohelEGP opened this issue Mar 14, 2023 · 5 comments · Fixed by #6253
Assignees

Comments

@JohelEGP
Copy link
Contributor

The entirety of [container.requirements.general] is a list of items of the form

  • X denotes ...

yet there are many references to this subclause, which probably need updating. For example

strings.tex-\tcode{InputIterator} is a type that qualifies as an input
strings.tex:iterator\iref{container.requirements.general}.
strings.tex-
@jwakely jwakely self-assigned this May 16, 2023
jwakely added a commit that referenced this issue May 16, 2023
…ntainer.requirements.general]

All the references for "qualifies as an input iterator" and "qualifies
as an allocator" are supposed to be to [container.reqmts] p69 which
begins:

> The behavior of certain container member functions and deduction
> guides depends on whether types qualify as input iterators or
> allocators.

The reference in [string.require] for obtaining an allocator should be
to [container.reqmts] p64.

The reference in [string.require] Note 2 should be to
[container.requirements.pre] p3.

Fixes #6184
@jwakely
Copy link
Member

jwakely commented May 17, 2023

N.B. this is a regression. In C++20 all of [container.reqmts] and [container.requirement.pre] and [container.requirements.general] was one big subclause called [container.requirements.general], so the refs were correct.

Looking at it now, I feel like we could have done better with the new subclause names. We currently have this structure under 24.2:

  1. Preamble [container.requirements.pre]
  2. General containers [container.gen.reqmts]
    2.1 General [container.requirements.general]
    2.2 Containers [container.reqmts]
    2.3 Reversible container requirements [container.rev.reqmts]
    2.4 Optional container requirements [container.opt.reqmts]
    2.5 Allocator-aware container requirements [container.alloc.reqmts]
  3. Container data races [container.requirements.dataraces]
  4. Sequence containers [sequence.reqmts]

The preamble is fine, and the new structure is fine, but the names could be improved. "24.2.2.1 General [container.requirements.general]" is actually just two paragraphs introducing some placeholder names for the following subclauses.

Maybe this would be better:

  1. Preamble [container.requirements.pre]
  2. General containers [container.requirements.general]
    2.1 Introduction [container.intro.reqmts]
    2.2 Containers [container.gen.reqmts]
    2.3 Reversible container requirements [container.rev.reqmts]
    2.4 Optional container requirements [container.opt.reqmts]
    2.5 Allocator-aware container requirements [container.alloc.reqmts]
  3. Container data races [container.requirements.dataraces]
  4. Sequence containers [sequence.reqmts]

This would not have broken the xrefs, because anything referring to [container.requirements.general] (including material outside the standard, like old proposals and Stack Overflow answers, etc.) would still be referring the the entire subclause containing all those requirements. Those refs could be more precise, pointing to one of the new subclauses like [container.alloc.reqmts], but they wouldn't be wrong (as they are now, because they just point to the two paragraphs introducing placeholder names).

@jwakely
Copy link
Member

jwakely commented May 17, 2023

@tkoeppe is it too late to rename those stable tags for C++23?

@tkoeppe
Copy link
Contributor

tkoeppe commented May 17, 2023

We're still in the process of submitting the DIS, and I expect it to come back at least once, so I'm happy to add a few more changes for the next round!

@jwakely
Copy link
Member

jwakely commented May 17, 2023

OK, I'll prepare a PR. It might take a few hours to make sure I've done it correctly ...

tkoeppe pushed a commit that referenced this issue May 17, 2023
…ntainer.requirements.general]

All the references for "qualifies as an input iterator" and "qualifies
as an allocator" are supposed to be to [container.reqmts] p69 which
begins:

> The behavior of certain container member functions and deduction
> guides depends on whether types qualify as input iterators or
> allocators.

The reference in [string.require] for obtaining an allocator should be
to [container.reqmts] p64.

The reference in [string.require] Note 2 should be to
[container.requirements.pre] p3.

Fixes #6184
@tkoeppe
Copy link
Contributor

tkoeppe commented May 17, 2023

No worries, I haven't heard back from ISO yet!

jwakely added a commit that referenced this issue May 17, 2023
….general]

This should refer to [container.alloc.reqmts] for an allocator-aware container.

Fixes #6184
jwakely added a commit that referenced this issue May 18, 2023
There are no more cross-references to [container.gen.reqmts] or
[container.requirements.general], so this doesn't affect anything else.

Related to #6184
jwakely added a commit to jwakely/draft that referenced this issue Jul 25, 2023
….general]

This should refer to [container.alloc.reqmts] for an allocator-aware container.

Fixes cplusplus#6184
jwakely added a commit to jwakely/draft that referenced this issue Jul 25, 2023
There are no more cross-references to [container.gen.reqmts] or
[container.requirements.general], so this doesn't affect anything else.

Related to cplusplus#6184
jwakely added a commit that referenced this issue Jul 25, 2023
There are no more cross-references to [container.gen.reqmts] or
[container.requirements.general], so this doesn't affect anything else.

Related to #6184
jwakely added a commit that referenced this issue Jul 25, 2023
….general]

This should refer to [container.alloc.reqmts] for an allocator-aware container.

Fixes #6184
jwakely added a commit that referenced this issue Jul 25, 2023
There are no more cross-references to [container.gen.reqmts] or
[container.requirements.general], so this doesn't affect anything else.

Related to #6184
timsong-cpp pushed a commit to timsong-cpp/draft that referenced this issue Feb 11, 2024
…ntainer.requirements.general]

All the references for "qualifies as an input iterator" and "qualifies
as an allocator" are supposed to be to [container.reqmts] p69 which
begins:

> The behavior of certain container member functions and deduction
> guides depends on whether types qualify as input iterators or
> allocators.

The reference in [string.require] for obtaining an allocator should be
to [container.reqmts] p64.

The reference in [string.require] Note 2 should be to
[container.requirements.pre] p3.

Fixes cplusplus#6184
timsong-cpp pushed a commit to timsong-cpp/draft that referenced this issue Feb 11, 2024
…ntainer.requirements.general]

All the references for "qualifies as an input iterator" and "qualifies
as an allocator" are supposed to be to [container.reqmts] p69 which
begins:

> The behavior of certain container member functions and deduction
> guides depends on whether types qualify as input iterators or
> allocators.

The reference in [string.require] for obtaining an allocator should be
to [container.reqmts] p64.

The reference in [string.require] Note 2 should be to
[container.requirements.pre] p3.

Fixes cplusplus#6184
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants