Unwrap methods about strum HOT 6 CLOSED

I'm down for this change; let's just make sure we're happy with the names and number of different Derives that it's split into.
So right now, I think there's 2 different Derives, unwrap, and try_unwrap (which I'm thinking should be try_as_)

impl MyEnum {
    // #[derive(Unwrap)]
    fn unwrap_variant(self) -> Type {}
    fn unwrap_variant_ref(&self) -> &Type {} // For Copy types, this is probably not useful, but not sure what to do with that.
    fn unwrap_variant_mut(&mut self) -> &mut Type {}
    // It's probably reasonable to choose a "default" for unwrapping that gets to be just `unwrap`, but that could
    // be a later feature

    // #[derive(TryAs)]
    fn try_as_variant(self) -> Option<Type> {}
    fn try_as_variant_ref(&self) ->Option<&Type> {}
    fn try_as_variant_mut(&mut self) -> Option<&mut Type> {}
}

from strum.

I also just had another idea that I'd like to be able to derive: a version of the Result::ok method for each variant to get an option.

impl Foo {
  pub fn single(&self) -> Option<bool> {
    match self {
      Self::Single(b) => Some(b),
      _ => None,
    }
  }
}

This would be useful in map methods, since you could pull all the variants out like this:

let vec: Vec<Foo> = vec![...];
let singles: Vec<bool> = vec.iter().filter_map(Foo::single).collect();

Edit: This might be better as a separate feature from unwraps

from strum.

I wrote the rest of the comment before looking at the is_* methods. Given that those were ultimately added to Strum, I think these will be as well. If you start a fork/PR, I'd love to be added as a collaborator!

This is definitely possible, but I'm not sure how useful it would be. Consider the following pattern:

// vanilla rust
let Foo::Double(integer, string) = foo else { panic!() };
// using unwraps
let (integer, string) = foo.unwrap_double();

// vanilla rust
let Foo::Named{a, b} = foo else { panic!() };
// no way to do this with these unwraps

I assume you meant that adding unwrap to Foo::Simple wouldn't make sense?

from strum.

I assume you meant that adding unwrap to Foo::Simple wouldn't make sense?

Good catch! I fixed my original comment.

from strum.

@Peternator7 also:
unwrap_variant_or, unwrap_variant_or_else, unwrap_variant_unchecked,
unwrap_variant_ref_or, unwrap_variant_ref_or_else, unwrap_variant_ref_unchecked.

Probably doesn't make any sense to do the same on mut versions.

Don't think we need all these for try as, since you can just use the Option methods on there.

from strum.

I know that I was the one to propose the unwrap methods in the first place, but after seeing the try_as methods, I'm not sure that they're still needed.
You can basically achieve the same result as foo.unwrap_variant() by doing foo.try_as_variant().unwrap().
And by using Option's unwrap methods, we get the other goodies like unwrap_or, unwrap_or_else, unwrap_unchecked, expect, without having to pay anything in compile time.

Thoughts?

cc @Peternator7 @PokeJofeJr4th

from strum.