That's not practical because it would mean *every* function has to take such a reference, since the default is "may sleep". The problem isn't functions requiring a special context, it's functions forbidding *all but* a special context.
Conversation
Replying to
It's not able to represent the inverse of that. If there's any way to use a function in a type or memory unsafe way it has to be marked unsafe. Safe code doesn't have non-atomic data races, etc. Most of this is already covered by safe vs. unsafe. You have to make safe primitives.
1
1
It's incorrect to use unsafe blocks to make safe functions where there's a way to use them in a way that causes undefined behavior, including via concurrency.
Locking has to be properly turned into safe primitives. It has to be done that way or it can't be non-unsafe Rust code.
2
2
Replying to
You're confused about what I want. This isn't about memory safety. It's about execution state. You can't call nonatomic functions from atomic context not because they'll corrupt memory, but because they may deadlock.
1
5
For example, safe code will often use mutexes to control access to shared resources, and you are not allowed to lock mutexes in atomic context since that operation may sleep. Obviously we can't mark every function that locks a mutex unsafe. It's a different concept.
1
5
There is a hierarchy of execution contexts you are allowed to be in, that you traverse with locking and IRQ disable operations (plus some special cases). Functions can require a broader context, not a narrower one. That's the opposite of how memory safety / locking works.
1
5
With memory safety you start out with *nothing* allowed, and you can only access objects you own/borrowed, and acquire ownership of or create more as you go.
With execution context, you start out with *everything* allowed, and cut that down as you lock deeper.
1
5
Replying to
I do understand what you want which is a generic effects system. Rust used to have a non-generic form of a single class of effect: pure vs. non-pure functions. It was very primitive and was missing the type system tools needed to avoid ruining making APIs with closures/generics.
1
5
Since it doesn't have effects, the best you can do is trying to enforce rules via the ownership system which is often completely impractical. It's also not quite as capable at truly enforcing things as it seems because the chosen trade-off was that safe code can skip destructors.
1
2
Safe code wasn't going to be allowed to create reference cycles but it required crippling Rc<T> and Arc<T> with type bounds preventing cycles. Could have developed something to make that less awful but it was decided it should just be safe with consequences that weren't foreseen.
1
Since that ended up permitting splitting off ownership with a reference cycle, skipping calling destructors, leaking had to be defined as safe and the function to skip destructors was made safe mainly to make that clear. Support for unwinding is also a problem within destructors.
Who can reply?
People @marcan42 follows or mentioned can reply