Repository navigation
Add give method to Option<T> #1416
Description
Currently, Option<T> has the method take, which is implemented as replace(&mut self, None). To complement this method, I propose adding a give as well:
pub fn give(&mut self, val: T) -> Option<T> {
::std::mem::replace(self, Some(val))
}
#[test]
fn it_works() {
let mut opt = None;
assert_eq!(opt.give(5), None);
assert_eq!(opt, Some(5));
assert_eq!(opt.give(6), Some(5));
assert_eq!(opt, Some(6));
}
This follows the same standard that HashMap, BTreeMap, and other collections use. Inserts a value into the option and returns the old value.
I feel like this is a common enough pattern to warrant a method from the standard library.
Reacted by Tom
Activity
[-]Add `insert` method to `Option<T>`[/-][+]Add `give` method to `Option<T>`[/+]steveklabnik commentedon Dec 18, 2015
I haven't had a need for this, but I do like the symmetry 👍
Stebalien commentedon Dec 20, 2015
nit: personally, I'd call it offer.
jonas-schievink commentedon Dec 20, 2015
withoutboats commentedon Dec 20, 2015
This seems to provide the same functionality as the methods requested in #1405 and #1278. While this proposal is symmetrical with take, I find the return value here really confusing (like difficult to reason about even with the code in front of me, which is not true of take) and don't know when it would be useful.
oli-obk commentedon Dec 21, 2015
I find this very confusing.
HashMapandBtreeMapreturn the value that previously was in the slot. This api returns the value you just tried to put in. I find both solutions to be more readable in the following ways:abonander commentedon Dec 21, 2015
I think
put()makes more sense coupled with returning the previous value.withoutboats commentedon Dec 21, 2015
So
putwould be something like this, right?abonander commentedon Dec 21, 2015
@withoutboats More like
For your suggestion, a more descriptive name like
put_and_refwould probably be better.withoutboats commentedon Dec 22, 2015
That would replace the value even if the value is
Some; I think most of these requests have wanted the function to only insert in theNonecase.burdges commentedon Dec 22, 2015
There is no reason to have a
putthat overwrites because you can always just overwrite it yourself by writingx = Some(y)or whatever.Yes,
giveis meant to act likeinsertdoes on collections. I imagine the reasoning behindgiveis : If I've anOption<T>that I want to put into a struct but the location is occupied, then I want to handle it some other way, like by merging theT. It's maybe helpful ifTis aBoxor something.I suppose a
replaceorswapfunction that always replaced the value and returns the contents sounds more intuitive, but maybe that's expensive ifTis big. In principle, one could argue that ifTwere aBox,Arc<Mutex<S>>, etc. thenTis small andreplaceis fast, and that bigTs should be handled another way.withoutboats commentedon Dec 22, 2015
The behavior @cybergeek94 suggested is the same as
insert: it always replaces the value and returns the prior value.leoyvens commentedon Dec 25, 2015
I recently proposed something similar however I came to the conclusion that this would be a bad API because after being called it guarantees that the option will be
Some, this encourages unwrapping and dosen't seem like a good use ofOptionafter all.BlacklightShining commentedon Dec 27, 2015
A
give()that returns the value you pass ifself.is_some()already would confuse me. I agree with calling thatoffer()and makinggive()unconditionally replaceself. I dunno whether this is good API, though; I've never usedtake()or wantedgive(), myself.jaroslaw-weber commentedon Jul 12, 2017
unwraping option with result is nice but setting the value may be confusing when u dont know what is underneath the api. also writing Some(3) is not that inefficient
Centril commentedon Oct 7, 2018
Tracked in rust-lang/rust#51998.