Theoretically it's possible.
I sincerely hope that would never happen.
It's impossible to make it robust.
I think the whole discussion which goes around year after year is about “magic”.
Essentially all popular languages in use today are full of “magic”. Memory is magically handled by tracing GC, strings are handled by another magical subsystem, all the code in Go is magically made interruptible via yet another flavor of magic and so on.
And the fundamental property of all that magic is that it just doesn't work.
And while people often argue about “Rust way” of doing things (whether it's explicit or not, etc)… the actual rule that Rust development follows is: Rust doesn't believe in magic.
I think that's the simplest formulation of all-encompassing principle: no magic at runtime. It's as simple as that.
Rust have tons of magic. Type inference, lifetime calculations, tricky HRBT rules and so on.
But under all that… the guiding idea of Rust is: magic is fallible and thus it must only be used in compile time.
I'm not sure if anyone ever planned to make Rust an anti-magical language, but that's how it works today: most constructs which are rejected are rejected “because they are not explicit enough”, but in reality they are rejected because they add potentially fallible, hidden, runtime magic to Rust.
That's how Rust become the hope of the embedded world (which is close to the metal and with consequences of failure so dire they just simply couldn't afford magic), that's how it become most loved language for many years in row… and that's how it become language where desires like these discussed in that thread have no hope of becoming reality:
That's plea for more magic.
That's request for even more magic.
Something that may help you, the developer to solve the issues. As I have said Rust includes tons of magic and is not shy of adding more.
The only catch: all that magic belongs to compile-time, not runtime!
You probably would get traits that would allow you not to think about which tokio functions you need to call — but you would think about which standard library function you'll need to call, instead.
You may get some more syntax sugar, but when it would break — it would be your responsibility to take both pieces and make it whole.
On one hand this makes it possible to be sure that program you wrote is actually working, reliably, not by accident or quirk of local configuration.
On the other hand it means that if something doesn't work — it's your fault and you would never get that permission not to think about some of these things that you want to ignore while Rust runtime would magically resolve issues for you.