4 ms·
Beyond Memory Safety with Types
- panic 10y agoSee also: http://pcwalton.github.io/blog/2012/12/26/typestate-is-dead/ http://pcwalton.github.io/blog/2012/12/26/typestate-is-dead/
- Animats 10y agoYou can do this in almost any typed language that lets you consume things. Whether you should is another matter. One problem is where to put your state-specific type info when you're not using it. When you're a thread and your state information is tied to where control is, this is fine. When you're an object which gets called with events, where do you keep this type-specific info? Something like a variant record with all the possible states?
- GolDDranks 10y agoIs the support for "consuming things" really common, though? C++ supports move semantics, invalidating the older copies of the objects (and still does disallow uses statically), but for example, Java has everything behind a pointer, and keeping a reference to the older states would keep the states around. Java would need a runtime-check too, so the type system wouldn't really help that much. I think it's especially the linear types (or "affine", which is the Rust's variety of almost-linear types) that allows for this kind of statically-checked state machines.
- staticassertion 10y agoI don't think C++ can statically constrain use after move. A moved value is considered valid, but unspecified. It is entirely possible to use the value after moving it, though maybe there's a warning? Using Unique Ptr it's a bit hard IIRC (it's been 2 years since I've written C++) but still possible.
- staticassertion 10y ago"You can do this in almost any typed language that lets you consume things." True, but languages with support for affine types are, to my knowledge, uncommon. "One problem is where to put your state-specific type info when you're not using it." Can you elaborate? I have not run into this issue.