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).
-
-
[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
Show 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.
Show 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).
Show this thread
End of conversation
New conversation -
-
-
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
"specialize on enum members in fn signatures"....oh yes, please! Plus impl on enum members! :-)
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
I like it! Being able to use enum variants as types would be SO COOL and would unlock lots of neat stuff like this.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
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.