Extra methods for Option

[ghost]

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.

[ticki]

Also, unchecked_unwrap() and give (opposite of take).

[ticki]

https://doc.redox-os.org/doc/extra/option/trait.OptionalExt.html

[oli-obk]

• the opposite of take is *opt = value;, there's no reason for a method.
• unchecked_unwrap has been discussed and the comments suggest that you should rather stabilize std::intrinsics::unreachable
• ok_or_default can be expressed as ok_or_else(Default::default)
• what's the meaning of err_or_*? turn Some(x) into Err(x)? That's very confusing, please us a match
• do you have statistical evidence that those functions will carry their weight? I would have wanted some of them sometimes, but in hindsight those situations are so rare, an explicit match is much better, because the future reader (myself included) will instantly recognize this situation as "something hokey pokey is going on, pay attention while reading"

[ticki]

the opposite of take is *opt = value;, there's no reason for a method.

No, you might misunderstand what I want.

pub fn give(&mut self, val: T) -> Option<T> {
    ::std::mem::replace(self, Some(val))
}

do you have statistical evidence that those functions will carry their weight? I would have wanted some of them sometimes, but in hindsight those situations are so rare, an explicit match is much better, because the future reader (myself included) will instantly recognize this situation as "something hokey pokey is going on, pay attention while reading"

(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]

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]

Wouldn't you get the same behaviour with abort on panic? Or is this a choice that varies inside a single project?

Nope, because of the way errors are handled and written to stderr. Abort on panic doesn't change that.

[ticki]

For example, we don't want coreutils to do thread '<main>' paniced at: "blah", we want to have simply blah.

[leoyvens]

#1416 for previous discussion on give. I'm against it because after being called it would guarantee that the Option is Some which encourages use of unwrap.

[Kerollmops]

Why not something like the new RefCell::replace method ?

[F001]

@Kerollmops RefCell::replace and Cell::replace are special because of interior mutability , so they only require &self receiver.

Whereas, for Option type, the replace method must take &mut self receiver, which makes it not necessary, in which case we can use assignment directly or std::mem::replace.

[F001]

But I do wonder Option can support placement-in protocol rust-lang/rust#30172. opt <- item seems reasonable.

[Kerollmops]

I think the same kind of reflection can be applied to the Option::map, it is useless, Option implement IntoIterator so instead of my_option.map(|v| func) we can do my_option.into_iter().map(|v| func) but it's more convenient to use a map method directly.

So yes we can use mem::replace but it can be more convenient to use a Option::replace method like the Option::take one.

What do you think ?

[F001]

Yes. It makes sense. Option::take is already there. No reason to not have Option::replace.

[Kerollmops]

These two methods have not the same behaviors:

• Option::take will pop the value and return it if present, let a None in place, it takes only &mut self and no other argument.
• Option::replace should interchange values and return the previous value if present, let a Some in place, it takes &mut self and one argument.

EDIT: doesn't correctly read your answer, you are on my side, sorry.