luker-os / variantly Goto Github PK

Same as {variant_name}_ref but yielding mutable references.

Example:

enum Enum { X, Y(String) }

impl Enum
{
    fn y_mut(&mut self) -> Option<&mut String>
    {
        match self
        {
            Enum::Y(string) => Some(string),
            _ => None
        }
    }
}

fn main() {
    let mut something = Enum::Y("world".into());

    if let Some(string) = something.y_mut() {
        *string = "mutated world".into();

        println!("Hello, {string}!");
    }
}

As far as I can tell, the following example in the Readme is slightly wrong:

use inflector::cases::snakecase::to_snake_case;

fn name_fn(operation: String, variant_name: String) -> String {
    let snake_case_variant = to_snake_case(&variant_name);
    format!("{}_{}", snake_case_variant, operation) // swap the arguments here
}

#[test]
fn it_makes_a_name() {
    assert_eq!(
        name_fn("unwrap","VariantA"),
        "unwrap_variant_a".into()
    )
}

The operation goes in front, so the function should return

format!("{}_{}", operation, snake_case_variant)

Love the crate, saw it featured on crate of the week, congrats!
Am on mobile, otherwise would be happy to provide a pull request!

Hi.

Nice crate! 😊

I'd really like to use this for another crate I'm working on. I've got a compile issue, though. The generated code from the Variantly derive macro is using the Result type from the standard rust prelude (in the global namespace). This clashes with my own crate's custom Result type.

The fix should be pretty easy: fully qualify all uses in the generated code like this: core::result::Result. I applied this patch to the 0.3.0 version and it worked nicely. 👍

I was going to open a PR against develop, but it seems develop is in quite a different state to 0.3.0 - many generated methods from 0.3.0 seem to be missing. I wonder whether it would be possible to do a 0.3.1 hotfix which would include this bugfix patch?

Thanks!
Ben

I was rather confused when I encountered this, I thought it was unrelated to my usage of variantly but later realized it was due to the derive using Variantly caused the compiler error.

However on an enum without that derive, it's possible to have a generic with trait bound, otherwise it's incompatible with Variantly (EDIT: Workaround below).

error[E0658]: associated type bounds are unstable

117 | pub enum MyEnum<T: SomeTrait> {
    |                       ^^^^^^^^^^^^^^ associated type not allowed here

There is other error output related to this, where it suggests to add the generic again but without the bound:

error[E0107]: enum takes 1 generic argument but 0 generic arguments were supplied
note: enum defined here, with 1 generic parameter: `T`
help: add missing generic argument
    |
117 | pub enum MyEnum<T, T: SomeTrait> {
    |                       ++

This has already been addressed by PR #16 AFAIK? It just needs @luker-os to review, merge and publish?

UPDATE: In the meantime it appears that a workaround is to use alternative syntax via a where clause:

#[derive(variantly::Variantly)]
pub enum MyEnum<T> where T: SomeTrait {
  Variant(T)
}