This means you either have to pass around permission-to-sleep tokens or you need additional function colors to make sure that it is enforced on the entire function call tree. The former might be possible with the lifetime trickery that chostcell does (I'm not certain, advanced type system hacks aren't my forte) but it's cumbersome. The latter would require an effects system which rust currently doesn't have.

"Effects system" seems to mean different things in different contexts. I found a few rust specific blog posts but they didn't obviously apply to this. Probably distinct from dependent types.

The rust compiler has the counting machinery to do this, perhaps it's not surfaced to the language outside of built-in types (arc?). In fairness I can't think of many languages which are up for that sort of hooking into the compiler.

It looks to me like a callgraph walk accumulating some state on known function calls plus error on taking address-of the mutator functions would work for sufficiently static graphs, which is probably what you have for careful concurrent code.

Semantic linters running across llvm IR are probably useful things to have. Not really related to rust at that point though.

This wrapper type requires two special language features: a way to run code when a type is "dropped" (think destroyed), and a way to have a type forward method calls to another type. But any regular code can use these features.

That lets you write a straightforward wrapper that forwards calls and manages the reference counting (increment on clone, decrement on drop). There's a bit more cleverness in the math, but it's all regular rust code. See <https://doc.rust-lang.org/src/alloc/rc.rs.html#15896>

This lack of special standard-library-only magic is a key part of rust's appeal to me. Those same features let the crate parking_lot implement a better mutex than the standard library, for example.

I wonder if it's possible to do this better. Somehow applying the type system onto the "execution context" feels like it would be the "ideal" solution here. From just 2 minutes of superficial thought, it would really be quite similar to permission-to-something tokens. Just a bunch of syntactic sugar on how it's done, plus making it easier to extend for additional tokens/colors/...?

This suggests a general pattern given the above on memory allocation - some things are expressible on static call graphs. On dynamic call graphs, they need to either fail (could be at compile time) or induce a runtime cost.

In other words, arguments and the type system can be used to tell a callee what it can do, but not what it cannot do.

If I am trying to call X and I need a CanSleep token but I haven't got one, this prompts me to investigate why I haven't got one. Oh! I gave my CanSleep token to this Spin Lock. Why did the Spin Lock need my CanSleep token? Ah, because sleeping while holding a spin lock is death, that makes sense. I can get my CanSleep token back but only by releasing the spin lock, however I need this spin lock. Hmm. Aha! I should re-factor this code so that I just remember we need to call X, and I ensure I do it right after I have released the Spin Lock and retrieved my CanSleep token. Excellent.

Leveraging the type system scales better than ad hoc lints. Maybe later we need to keep track of several tokens, Rust has no problem making a Vec<CanSleep> and will optimise that exactly the way you expect (it's just a counter, the CanSleeps don't need storing anywhere) likewise a [Option<CanSleep>; 4] is just four bytes to track whether each element is None or Some(CanSleep).