Skip to content

Conversation

@hewillk
Copy link
Contributor

@hewillk hewillk commented Oct 7, 2025

No description provided.

Copy link
Member

@jwakely jwakely left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't do this elsewhere for exposition-only helpers, do we?

e.g. [container.intro.reqmts] and [sequences.general] and [associative.general].

Is there any possible confusion about what this exposition-only concept means? Is it relevant which namespace it's a member of, given that users can never refer to it?

@hewillk
Copy link
Contributor Author

hewillk commented Oct 7, 2025

Maybe. But this is only to consistent with [expos.only.entity] which also belongs to [library].

@tkoeppe
Copy link
Contributor

tkoeppe commented Oct 31, 2025

Hm, it's true that we put the expos-only entities in [library] in namespace std. It's only in the specific library facilities where locally used expos-only entities are declared without namespace.

Ultimately I don't think it matters for the normative effect, but I can see an consistency argument for the present case.

@jwakely
Copy link
Member

jwakely commented Oct 31, 2025

Yeah, i don't mind either way.

@tkoeppe tkoeppe merged commit 04df25f into cplusplus:main Oct 31, 2025
2 checks passed
@hewillk hewillk deleted the main-allocator branch November 1, 2025 02:26
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.

3 participants