Tracking transitive calls seems feasible until there is a call to a trait method via dynamic dispatch.
For it to work, it would require a warning on implementing a trait method that was not annotated with #[might_block] with an implementation that calls a blocking method.
In terms of dealing with higher order functions, it could be possible to create a marker trait: MightBlock which in implemented by any function which is annotated with #[might_block]. Then there could be blanket implementations like: impl<T:MightBlock> MightBlock for fn(T)->() etc.
This is an awesome idea that makes time-related effect/property more explicit.
Rust function, like C and Java, may block. Type system is the way to make something explicit. Blocking/none-blocking isn't part of type system. Making it part of types will make things too long to write, because we don't always care about this effect. Which brings us to: let's mark places that do care about blocking.
Writing async function
When I write an async function (indicated via type), I implicitly try to make something non-blocking. Hence, I want compiler to check for blocking everything going into my async function, even passed closures in args.
I'd love compiler to warn me here about consuming might_block-ing, unless I explicitly put #[allow(might_block)] into my async function.
Writing executors
Sometimes we write code that runs functions and closures. In this instances it might be nice to ask compiler to ensure that certain sections of code are non-blocking #[error(might_block)]?
Writing non-async function
At this instance I am usually not concerned about blocking. I don't even need a warning. But we want an implicit transitivity to happen, so that when this function is used elsewhere with interest about blocking compiler can do its job.
Can we frame this feature not as "won't block", but as "most probably won't block"?
However imperfect implementation can be for "sure, no blocking", this is by far the best thing since "sliced async/await" . As an example, a decade has passed since nio stuff appeared in Java, and this pain of not knowing anything about blocking is always with many of us. Let's ease this situation in Rust.
May I also suggest that true "sure, no blocking" requirement arises only in real time systems. For 99% of us the "most probably won't block" is good enough.
. As an example, a decade has passed since nio stuff appeared in Java, and this pain of not knowing anything about blocking is always with many of us. Let's ease this situation in Rust.