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.

Sign up for GitHub

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

Jump to bottom

Entry APIs should have or_default for V: Default #44324

Closed
jonhoo opened this issue Sep 4, 2017 · 8 comments
Closed

Entry APIs should have or_default for V: Default #44324

jonhoo opened this issue Sep 4, 2017 · 8 comments
Labels
A-collections Area: std::collections. B-unstable Blocker: Implemented in the nightly compiler and unstable. C-enhancement Category: An issue proposing an enhancement or a PR with one. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@jonhoo
Copy link
Contributor

jonhoo commented Sep 4, 2017

The various Entry APIs (e.g., hash_map::Entry, btree_map::Entry) currently have or_insert, and or_insert_with. However, when V: Default, I believe they should also have an or_default. This would make it nicer to work with things like maps of maps, maps of lists, etc. While it's true that this is equivalent to or_insert_with(Default::default), I would argue that or_default is much more readable.

I'd be happy to take a stab at implementing this, but wanted to air the idea first.
@Mark-Simulacrum Mark-Simulacrum added C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Sep 4, 2017
@steveklabnik
Copy link
Member

Generally, the way the libs team works is "open a PR if a change is small, open an RFC if a change is big." I'm not on the libs team, but this feels pretty small to me; you already almost have an implementation in the comment!

@jonhoo jonhoo mentioned this issue Sep 5, 2017
Merged
@jonhoo
Copy link
Contributor Author

jonhoo commented Sep 5, 2017

@steveklabnik PR submitted!

@BurntSushi BurntSushi added the B-unstable Blocker: Implemented in the nightly compiler and unstable. label Sep 11, 2017
bors added a commit that referenced this issue Sep 12, 2017
@bors
Auto merge of #44344 - jonhoo:entry_or_default, r=BurntSushi
817e1b8 
Add or_default to Entry APIs

As argued for in #44324, this PR adds a new `or_default` method to the various `Entry` APIs (currently just for `BTreeMap` and `HashMap`) when `V: Default`. This method is effectively a shorthand for `or_insert_with(Default::default)`.
@TimNN TimNN added the A-collections Area: std::collections. label Sep 17, 2017
@kennytm kennytm mentioned this issue Sep 23, 2017
Closed
@dtolnay dtolnay removed the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Nov 15, 2017
@dtolnay
Copy link
Member

dtolnay commented Nov 15, 2017

An unstable or_default() method was added in #44344. This issue is now the tracking issue for stabilization.

@XAMPPRocky XAMPPRocky added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jan 22, 2018
@khuey
Copy link
Contributor

khuey commented Feb 20, 2018

Is there any reason not to just stabilize this?

@SimonSapin
Copy link
Contributor

In Nightly for 6 months, looks good to me to stabilize.

@rfcbot fcp merge

@rfcbot
Copy link

rfcbot commented Mar 17, 2018 •
edited by aturon
Loading

Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Mar 17, 2018
@rfcbot
Copy link

rfcbot commented Mar 19, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot removed the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Mar 19, 2018
@rfcbot
Copy link

rfcbot commented Mar 29, 2018

The final comment period is now complete.

@Centril Centril added disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels May 24, 2018
@GuillaumeGomez GuillaumeGomez mentioned this issue May 26, 2018
Merged
bors added a commit that referenced this issue Jun 10, 2018
@bors
Auto merge of #51079 - GuillaumeGomez:stabilize-entry-or-default, r=S…
900037e 
…imonSapin

Stabilize entry-or-default

Fixes #44324.

cc @SimonSapin
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-collections Area: std::collections. B-unstable Blocker: Implemented in the nightly compiler and unstable. C-enhancement Category: An issue proposing an enhancement or a PR with one. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests