Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🎁 [Feature Request]: feature to derive Debug on generated types #35

Closed
jkneer opened this issue Nov 20, 2024 · 5 comments · Fixed by #39
Closed

🎁 [Feature Request]: feature to derive Debug on generated types #35

jkneer opened this issue Nov 20, 2024 · 5 comments · Fixed by #39
Assignees
Labels
enhancement New feature or request

Comments

@jkneer
Copy link
Contributor

jkneer commented Nov 20, 2024

What is the feature you would like to see?

When integrating a builder for a subaspect into another implementation for a larger struct, you may run into the situation where you have to explicitely return or take a stated type generated by state-shift. It would be nice to have Debug derives as a crate feature flag in those cases...

@jkneer jkneer added the enhancement New feature or request label Nov 20, 2024
@ozgunozerk
Copy link
Owner

ozgunozerk commented Nov 20, 2024

Instead of that, we can have a simpler solution.

The macro for the struct #[type_state] is able to capture other macro annotations on top of the struct, so it can preserve them and place the other macros on top of the generated struct (type-state version of the struct).

I think this would be a more generalized approach. What do you think @jkneer ?

@jkneer
Copy link
Contributor Author

jkneer commented Nov 20, 2024

Hi,

yes that would be good, as currently the behaviour depends on the order of the annotations

# derive Debug
# type state 

-> Debug is derived on the struct
edit just tested that, rust-analyzer says it is, but in reality it is not for the stated versions of the struct that is annotated.

# type state
# derive Debug

-> Debug is not derived.

Hmm I guess that would be mostly ok, for Debug, Clone, Copy

What if the trait cannot be derived? like Send or Sync?

@ozgunozerk
Copy link
Owner

What if the trait cannot be derived? like Send or Sync?

The macro does not change the struct name, one can always implement the traits manually.

@jkneer
Copy link
Contributor Author

jkneer commented Nov 20, 2024

The macro does not change the struct name, one can always implement the traits manually.

Wouldn't all State types also need carry those traits?

@ozgunozerk
Copy link
Owner

ozgunozerk commented Nov 28, 2024

Wouldn't all State types also need carry those traits?

Yes. As long as the generic type T implements Trait, it should be ok and we should not need any manual implementation for the variants of T. For example:

#[derive(Debug)]
struct MyStruct<T = bool> {
    value: T,
}

fn main() {
    let int_struct = MyStruct { value: 42 };
    let string_struct = MyStruct { value: String::from("Hello") };

    println!("{:?}", int_struct); // Works because i32 implements Debug
    println!("{:?}", string_struct); // Works because String implements Debug
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants