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

[flat.set] [flat.multiset] [flat.map] [flat.multimap] Editorial part of LWG3802 #5923

Closed

Conversation

Quuxplusone
Copy link
Contributor

In LWG3802 I wrote:

(B) Almost certainly the Allocator parameter should be named Alloc instead,
and there should be a separate "Constructors with allocators" section with
wording similar to 24.6.7.3 [priqueue.cons.alloc] explaining that these
ctors don't participate in overload resolution unless
uses_allocator_v<KeyContainer, Alloc> && uses_allocator_v<MappedContainer, Alloc>.

This is that change. It is intended to be purely editorial (although possibly major/controversial). Specifically this commit is not intended to change any signatures, add or remove any signatures, nor trigger/untrigger any blanket wording based on the name of the Allocator/Alloc parameter. If you see anything non-editorial, please call it out, as it's probably a typo on my part.

This harmonizes the flat container adaptors' organization with {stack,queue,priqueue}.cons.alloc.
If adopted, I expect this will also make the resolutions for LWG 3802, LWG 3803, and LWG 3804 easier to understand and apply.

I've got proposed wording for the functional part of LWG3802, based on top of this patch; see that (non-editorial) wording here: Quuxplusone@f43c4c3

@tkoeppe tkoeppe added the needs rebase The pull request needs a git rebase to resolve merge conflicts. label Nov 8, 2022
@Quuxplusone
Copy link
Contributor Author

This has been rebased now.

…of LWG3802

In LWG3802 I wrote:

> (B) Almost certainly the Allocator parameter should be named Alloc instead,
> and there should be a separate "Constructors with allocators" section with
> wording similar to 24.6.7.3 [priqueue.cons.alloc] explaining that these
> ctors don't participate in overload resolution unless
> `uses_allocator_v<KeyContainer, Alloc> && uses_allocator_v<MappedContainer, Alloc>`.

This is that change. It is intended to be purely editorial (although possibly
major/controversial). Specifically this commit is *not* intended to change
any signatures, add or remove any signatures, nor trigger/untrigger any
blanket wording based on the name of the `Allocator`/`Alloc` parameter.
@Quuxplusone
Copy link
Contributor Author

Rebased; ping! I'd like to hear about this one, because it is large and yet the P/R for LWG3802 is based on top of it.

@jensmaurer jensmaurer removed the needs rebase The pull request needs a git rebase to resolve merge conflicts. label Feb 19, 2023
@jensmaurer
Copy link
Member

@jwakely , @tkoeppe : How should this be reviewed? It's quite some text churn.

@Quuxplusone
Copy link
Contributor Author

Superseded by #6274.

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 this pull request may close these issues.

None yet

3 participants