korken89 / smlang-rs

A State Machine Language DSL procedual macro for Rust
Apache License 2.0
193 stars 28 forks source link

Syntax for adding derive/procedural macros on `States` and `Events` #55

Closed oblique closed 1 year ago

oblique commented 1 year ago

Some users may want to use derive on States and Events.

A possible syntax can be:

statemachine! {
    transitions: {
        *State1 + Event1 [guard1] / action1 = State2,
    }
    states_derive: {
        #[derive(Debug, Clone)]
    }
    events_derive: {
        #[derive(Debug, Clone)]
    }
}

Any comments or other ideas?

ryan-summers commented 1 year ago

I don't think this should be explicitly requested, but rather implicitly provided.

What I mean by that, is that states and events should follow https://rust-lang.github.io/api-guidelines/interoperability.html#types-eagerly-implement-common-traits-c-common-traits and these types should be implemented by default wherever possible.

oblique commented 1 year ago

That would be great, however I think it will hard and close to impossible to implement it.

The impossible part is when States or Events take as data a non-std type, which we do not know that traits it implements.

ryan-summers commented 1 year ago

We could reformulate the enums to accomodate this:

enum _InternalState<S1, S2> {
    State1(S1),
    State2(S2),
}

impl<S1, S2> Debug for _InternalState<S1, S2>
where
    S1: Debug,
    S2: Debug 
{
   // .. blah
}

type State = _InternalState<KNOWN_S1_DATA, KNOWN_S2_DATA>;

This would require manual implementation of the traits, but would make ti possible to conditionally bound the impls on the concrete types

oblique commented 1 year ago

Correct. Didn't think about it :)