I don't have the time to shepherd this RFC (or something similar), but I really wish that the whole Async ecosystem was built on something less error prone / magic-y than ThreadLocalState.
Its not ideal to ever have any "hidden" functionality like auto-propagation, but it would be way better than the current state of async Rust.
In fact the equivalent Scala functionality is mentioned in the issue thread. They might be confusing but they are probably a million time better than actual mutable globals.
"Shared mutable global state" is "IO monad" all over.
(Ia! Ia! Ruskell fhtagn!)
> It can also panic whenever a timer is created outside of a Tokio runtime.
Note that nothing in the signature tells you that, just the function documentation.
In practice, this ends up not being a big deal, IMHO. The ecosystem has largely coalesced around tokio as an executor. The only times I've run into it are when running Actix, which has its own global state on top of tokio.
But another part of me questions why it’s ok that calling a function in the wrong context is a runtime panic rather than a compilation error. Coming from a C background it seems pretty normal to just have a “tokio_context*” argument on tokio functions that would at least make the statefullness less obscure?
Maybe I'm just jaded from writing too much C, but it doesn't seem like a big deal to me to change sleep(duration) to sleep(ctx, duration). Three letters to be correct, transparent, and not have global state? Look at what a complete mess the C standard library is from where they used global state like that.
I'm sure there are lots of other ways you could do it, like make the context it's own struct and call a sleep impl for the struct or something?
I guess it's more common than what my personal experience suggests (which is that it never happens).