The core functionality of lifetime-dependent types is under active design and development, and should be enough to implement a guard type in the nearish future. It would be nice to avoid having the completely unsafe independent lock and unlock methods if we can hold out until nonescaping types are a reality. While the preconditions for their use are describable, I fear that it'll be difficult for developers to intuit when it's safe to assume that a lock and unlock always happen under the same enclosing borrow, since that isn't a constraint that they're likely to be used to thinking about coming from these sorts of APIs in other languages, and the behavior when you get it wrong is incomprehensible.
8 Likes