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

[associative.reqmts, unord.req] insert_return_type only for unique keys #969

Conversation

danieljames
Copy link
Contributor

The requirements for associative and unordered associative containers require insert_return_type for all containers, but it's only defined for containers with unique keys.

I'm not sure about the wording, I followed the example of other entries in the table which say things like (map and multimap only), although it might be better to say it's only for containers that support unique keys.

I think this is an editorial change, because it just changes the requirements to match what's specified elsewhere.

The requirements for associative and unordered associative containers
require `insert_return_type` for all containers, but it's only defined
for containers with unique keys.
@danieljames danieljames changed the title [wssociative.reqmts, unord.req] insert_return_type only for unique keys [associative.reqmts, unord.req] insert_return_type only for unique keys Nov 6, 2016
@jwakely
Copy link
Member

jwakely commented Nov 7, 2016

I agree this is an issue, but I don't think it's an editorial one. It's possible that the return type will be changed to pair<iterator, bool> anyway, but if that doesn't happen I agree we should fix this. An LWG defect report would be the correct avenue.

@danieljames
Copy link
Contributor Author

OK, thanks. I'll submit one soon.

@danieljames danieljames closed this Nov 7, 2016
@jwakely
Copy link
Member

jwakely commented Nov 7, 2016

Great, thanks. You could mention in the issue that it depends on the resolution to LWG 2772.

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

2 participants