typestate-rs
typestate-rs copied to clipboard
[Feature Request] Allow pre-declaring the `enumerate` type's output for Derive usage
It would be helpful if the enum
produced by typestate(enumerate = ...)
could be pre-declared such that #[derive(...)]
can be used upon it or potentially (a subset of?) its members.
#[typestate(enumerate = "StateMachineStates")
pub mod state_machine {
#[automaton]
#[derive(Debug, Clone, PartialEq, Eq)]
pub struct StateMachine;
#[state] pub struct In;
#[state] pub struct Out;
// No field-specific annotations
#[enumerate]
#[derive(Debug, Clone, PartialEq, Eq)]
pub enum StateMachineStates;
// or, with fields annotated for another annotation-macro
#[enumerate]
#[derive(derivative)]
#[derivative(Debug)]
pub enum StateMachineStates {
#[derivative(Debug="transparent")]
In,
// Note that only some states are included
// Any not explicitly mentioned are filled in prior to other #[derive]s expanding.
}
// ...
}
Hey @Dessix! Thank you for your interest!
This crate has been in a weird state since this was my MSc's thesis PoC and I haven't had time since to work on it. Only recently I have started to think about ways to make it simpler both the DSL and the macro powering it.
That said, I can't make any promises. If you have any more ideas or suggestions, feel free to share them in the discussions or issues!
Thanks! I'm hoping to make use of this for its self-documenting features to more-strictly encode various protocols in one of my projects, and have been mulling over a helper annotation for creating the trait impl
s without all of the verbosity and boilerplate. Ideally, the proc-macro annotation would handle this so it could utilize the contextual information from the main mod
body.
I think one of the big parts of making an effective DSL is keeping it from getting in the way of the language's features- the relevant one here being derive
. Feel free to bounce ideas off of me if you're not sure of a particular syntactical direction to take, or how to implement some aspect of the macro processing.