Unable to create a table with multiple StateA to StateB transitions with same event but different guards and actions.

[phelter]

Have a more complex transition table where:

return transition_table {
    * "stateA"_s + event<Start>              / doStart  = "stateB"_s
    , "stateB"_s  + event<Done> [ isX ] / completeX = "stateA"_s
    , "stateB"_s  + event<Done> [ isY ] / completeY = "stateA"_s
    , "stateB"_s  + event<Done> [ isZ ] / completeZ = "stateA"_s
};

The above won't work because of an error .... specified more than once as a direct base class

But If I change it to:

return transition_table {
    * "stateA"_s + event<Start>              / doStart  = "stateB"_s
    , "stateB"_s  + event<Done> [ isX || isY || isZ] / completeXYZ = "stateA"_s
};

where completeXYZ action now also needs to identify which of the guards triggered it is fine.

Is this expected?

[phelter]

Another usage quirk is that you can specify a No transition to a new state but same event with different guards and actions:

eg:

return transition_table {
    * "A"_s + event<Start>              / doStart  = "B"_s
    , "B"_s  + event<Done> [ (isX || isY || isZ) && !isRetryOk ] / completeXYZ = "A"_s
    // Try again - these are allowed to be discerned based off of guards.
    , "B"_s  + event<Done> [isX && isRetryOk] / retryX
    , "B"_s  + event<Done> [isY && isRetryOk] / retryY
};

So there are two different requirements of the sml2::sm based on whether you have a transition to a state or not.

[kris-jusiak]

Yeah, I see the issue, thanks @phelter for pointing it out. I am aiming to provide this week, as there is one more issue to fix with entry transactions on my to-do list. Will post the progress here.

[phelter]

Great - thanks for the heads up.