Oooops, accidentally spent most of the afternoon thinking about state machines instead of working on my talk. Think I'm onto something fun though (and probably should write in a longer fashion about it at some point).
-
Show this thread
-
Definitely not the first person to think of this. But if enums encapsulate state. And all state machines do is describe transitions between states, then if we could specialize on enum members in fn signatures then that would be enough to implement state machines concisely.
5 replies 0 retweets 8 likesShow this thread -
[usual disclaimer I'm not a lang designer, nor on any lang team -- take w/ salt] What I'm thinking is that both examples below are functionally equivalent. I suspect that if we could encode state transitions onto enums it would feel more natural -- e.g. lean into &mut selfpic.twitter.com/5tf49IdDct
4 replies 1 retweet 17 likesShow this thread -
Oh lol; the second example doesn't have enough information to track what it transitions into. The signature implies this is valid: if x { *self = Self::A } else { *self = Self::B } The point is that this can't happen. Either compiler should infer, or syntax is needed. Oops.
2 replies 0 retweets 2 likesShow this thread
Yeah maybe the answer is that it only works for Self::A -> Self::B, taking ownership of Self each time. I mean, it's not perfect but it would remove a lot of boilerplate when trying to store the states inside another struct (something the first example doesn't even try).
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.