Re:State Machines and the Strange Case of Mutating API
by a1369209993 on Tuesday December 25, 2018 @12:02AM
(#18756006)
You can actually do the type-checking part of this even in C, it's just uglier:
Rust adds the constraint that any (non-copyable,non-dropable) variable has to be passed to a function (or operator, or return statement) exactly once:
[ Parent
| on HN ]
Re:State Machines and the Strange Case of Mutating API
by rumcajz on Tuesday December 25, 2018 @01:54AM
(#18756329)
The problem with the C solution is that you'll get hanging pointers. Try using i1 after the code above executes and you'll get a runtime error.
Re:State Machines and the Strange Case of Mutating API
by a1369209993 on Tuesday December 25, 2018 @01:45PM
(#18758663)
Er, yes; that's what I said (or rather, hanging various things including but not limited to pointers). C only supported the typechecking part of this because it doesn't have any facilities for compile-time linearity checking.
Linearity[0] and dependency[1] checking is what makes Rust a improvement over C, rather than yet another "let's reinvent C++, but slightly less awful" project.
0: "error: no implementation for copy〈T〉","error: no implementation for drop〈T〉"[2]
1: "error: cannot move/destroy x (of type T); y (of type T&'x) outlives it"
Re:State Machines and the Strange Case of Mutating API
by capitalsigma on Tuesday December 25, 2018 @02:18AM
(#18756406)
You can use C++ unique_ptr and turn on Clang warnings about "use after move", if you want that level of protection.