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

Add std::mem::take as suggested in #61129 #61130

Merged
merged 1 commit into from
Jun 7, 2019
Merged

Conversation

jonhoo
Copy link
Contributor

@jonhoo jonhoo commented May 24, 2019

This PR implements #61129 by adding std::mem::take.

The added function is equivalent to:

std::mem::replace(dest, Default::default())

This particular pattern is fairly common, especially when implementing Future::poll, where you often need to yield an owned value in Async::Ready. This change allows you to write

return Async::Ready(std::mem::take(self.result));

instead of

return Async::Ready(std::mem::replace(self.result, Vec::new()));

EDIT: Changed name from take to swap_default.
EDIT: Changed name back to take.

@rust-highfive
Copy link
Collaborator

r? @sfackler

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 24, 2019
@cramertj
Copy link
Member

naming nit: mem::replace_with_default?

@jonhoo
Copy link
Contributor Author

jonhoo commented May 24, 2019

@cramertj I sort of intentionally wanted it to be relatively short and concise. I see the point about wanting the name to indicate what gets left in its place though. The signature would likely tell you very quickly, but we may want it reflected in the name as well. Maybe mem::swap_new?

@cramertj
Copy link
Member

swap_default would work for me.

@jonhoo jonhoo changed the title Add std::mem::take as suggested in #61129 Add std::mem::swap_default as suggested in #61129 May 24, 2019
@czipperz
Copy link
Contributor

czipperz commented May 25, 2019

For prior art: naming as take has precedence with Option::take and Cell::take. This is implementing a similar function to these stable methods.

@sfackler sfackler added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label May 26, 2019
@sfackler
Copy link
Member

@rfcbot fcp merge

@rfcbot
Copy link

rfcbot commented May 26, 2019

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

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels May 26, 2019
@SimonSapin
Copy link
Contributor

I’d prefer this be named replace_with_default, or take.

This is closer to a replace to a swap, since there is no second &mut T passed. It even calls replace. And replace_default sounds backwards, it’s not the default who is being replaced, but the &mut T argument. So replace_with_default. Accurate, but kinda lengthy.

take is less obvious with the name alone, but hopefully the bound in the full signature is suggestive enough: fn take<T>(&mut T) -> T where T: Default. And as @czipperz noted there’s precedent in Cell and Option.

@jonhoo
Copy link
Contributor Author

jonhoo commented May 26, 2019

I personally prefer take (as in the original suggestion) when compared to replace_with_default, as the latter is quite verbose. I could go either way though — happy to update according to consensus.

@jonhoo jonhoo changed the title Add std::mem::swap_default as suggested in #61129 Add std::mem::take as suggested in #61129 May 26, 2019
@timvermeulen
Copy link
Contributor

Is there any precedence for functions in the standard library that are related to Default but don't have default in the name?

@dtolnay
Copy link
Member

dtolnay commented May 26, 2019

Yes -- #61130 (comment) mentions Cell::take.

@timvermeulen
Copy link
Contributor

Ah, I saw that, but wasn't aware of how it works. I have no objections then.

@czipperz
Copy link
Contributor

Make sure to update the pr/issue to reflect the take name. The PR's example is messed up.

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

rfcbot commented May 28, 2019

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

@fhartwig
Copy link
Contributor

take is less obvious with the name alone, but hopefully the bound in the full signature is suggestive enough: fn take<T>(&mut T) -> T where T: Default. And as @czipperz noted there’s precedent in Cell and Option.

In Option's case the replacement is arguably obvious, though. And in my opinion having a suggestive type signature doesn't really help, considering you'll only see that when looking up the documentation.

@bors
Copy link
Contributor

bors commented May 29, 2019

☔ The latest upstream changes (presumably #61317) made this pull request unmergeable. Please resolve the merge conflicts.

The name `swap_default` was suggested but rejected. @SimonSapin observed
that this operation isn't really a `swap` in the same sense as
`mem::swap`; it is a `replace`. Since `replace_default` is a bit
misleading, the "correct" name would be `replace_with_default`, which is
quite verbose.

@czipperz observed that we have precedence for using `take` to refer to
methods that replace with `Default` in `Cell::take` and `Option::take`,
so this reverts commit 99c00591c29b472c8a87c4a9342d0e0c508647a3 to
return to the original `take` method name.

The name `replace_with_default` was suggested, but was deemed too
verbose, especially given that we use `take` for methods that replace
with `Default` elsewhere.
@scottmcm
Copy link
Member

scottmcm commented Jun 1, 2019

Given that it's a function, I like the take name since I'd end up always calling it as mem::take, which is distinct enough for me to remember what's going on.

@rfcbot rfcbot added the finished-final-comment-period The final comment period is finished for this PR / Issue. label Jun 7, 2019
@rfcbot
Copy link

rfcbot commented Jun 7, 2019

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

@rfcbot rfcbot removed the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label Jun 7, 2019
@SimonSapin
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Jun 7, 2019

📌 Commit 5a01b54 has been approved by SimonSapin

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 7, 2019
@bors
Copy link
Contributor

bors commented Jun 7, 2019

⌛ Testing commit 5a01b54 with merge f5e8c96c1dd9a6d9d71b328846264570b9233bff...

Centril added a commit to Centril/rust that referenced this pull request Jun 7, 2019
Add std::mem::take as suggested in rust-lang#61129

This PR implements rust-lang#61129 by adding `std::mem::take`.

The added function is equivalent to:
```rust
std::mem::replace(dest, Default::default())
```

This particular pattern is fairly common, especially when implementing `Future::poll`, where you often need to yield an owned value in `Async::Ready`. This change allows you to write
```rust
return Async::Ready(std::mem::take(self.result));
```
instead of
```rust
return Async::Ready(std::mem::replace(self.result, Vec::new()));
```

EDIT: Changed name from `take` to `swap_default`.
EDIT: Changed name back to `take`.
@Centril
Copy link
Contributor

Centril commented Jun 7, 2019

@bors retry r0lled up

@bors
Copy link
Contributor

bors commented Jun 7, 2019

⌛ Testing commit 5a01b54 with merge d132f54...

bors added a commit that referenced this pull request Jun 7, 2019
Add std::mem::take as suggested in #61129

This PR implements #61129 by adding `std::mem::take`.

The added function is equivalent to:
```rust
std::mem::replace(dest, Default::default())
```

This particular pattern is fairly common, especially when implementing `Future::poll`, where you often need to yield an owned value in `Async::Ready`. This change allows you to write
```rust
return Async::Ready(std::mem::take(self.result));
```
instead of
```rust
return Async::Ready(std::mem::replace(self.result, Vec::new()));
```

EDIT: Changed name from `take` to `swap_default`.
EDIT: Changed name back to `take`.
@bors
Copy link
Contributor

bors commented Jun 7, 2019

☀️ Test successful - checks-travis, status-appveyor
Approved by: SimonSapin
Pushing d132f54 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 7, 2019
@bors bors merged commit 5a01b54 into rust-lang:master Jun 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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. merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.