Repository navigation
Extra methods for Option #1597
Description
I noticed that a few potentially useful methods convertingOption to Result aren't currently implemented: ok_or_default, err_or, err_or_else, and err_or_default.
ok_or_default could be useful as a complement to unwrap_or_default when converting Options to Results with a certain error type.
All of the err_or functions are complements to ok_or and aren't implemented at all.
Activity
ticki commentedon Apr 29, 2016
Also,
unchecked_unwrap()andgive(opposite oftake).ticki commentedon Apr 29, 2016
https://doc.redox-os.org/doc/extra/option/trait.OptionalExt.html
oli-obk commentedon Apr 30, 2016
*opt = value;, there's no reason for a method.unchecked_unwraphas been discussed and the comments suggest that you should rather stabilizestd::intrinsics::unreachableok_or_defaultcan be expressed asok_or_else(Default::default)err_or_*? turnSome(x)intoErr(x)? That's very confusing, please us a matchticki commentedon Apr 30, 2016
No, you might misunderstand what I want.
(assuming you're referencing libextra) Yes, we do use those a lot. They are a better and faster alternative to panicking, especially when making CLI tools.
oli-obk commentedon Apr 30, 2016
Wouldn't you get the same behaviour with abort on panic? Or is this a choice that varies inside a single project?
The other cases are what i meant actually, are there lots of awkward matches when converting options to results?
ticki commentedon Apr 30, 2016
Nope, because of the way errors are handled and written to stderr. Abort on panic doesn't change that.
ticki commentedon Apr 30, 2016
For example, we don't want coreutils to do
thread '<main>' paniced at: "blah", we want to have simplyblah.leoyvens commentedon Jun 25, 2016
#1416 for previous discussion on
give. I'm against it because after being called it would guarantee that theOptionisSomewhich encourages use ofunwrap.Kerollmops commentedon Jan 14, 2018
Why not something like the new RefCell::replace method ?
F001 commentedon Jan 15, 2018
@Kerollmops
RefCell::replaceandCell::replaceare special because of interior mutability , so they only require&selfreceiver.Whereas, for
Optiontype, thereplacemethod must take&mut selfreceiver, which makes it not necessary, in which case we can use assignment directly orstd::mem::replace.F001 commentedon Jan 15, 2018
But I do wonder
Optioncan support placement-in protocol rust-lang/rust#30172.opt <- itemseems reasonable.Kerollmops commentedon Jan 15, 2018
I think the same kind of reflection can be applied to the
Option::map, it is useless,OptionimplementIntoIteratorso instead ofmy_option.map(|v| func)we can domy_option.into_iter().map(|v| func)but it's more convenient to use amapmethod directly.So yes we can use
mem::replacebut it can be more convenient to use aOption::replacemethod like theOption::takeone.What do you think ?
F001 commentedon Jan 15, 2018
Yes. It makes sense.
Option::takeis already there. No reason to not haveOption::replace.Kerollmops commentedon Jan 15, 2018
These two methods have not the same behaviors:
Option::takewill pop the value and return it if present, let aNonein place, it takes only&mut selfand no other argument.Option::replaceshould interchange values and return the previous value if present, let aSomein place, it takes&mut selfand one argument.EDIT: doesn't correctly read your answer, you are on my side, sorry.