Open leinlawun opened 5 years ago
Marking as deferred -- async-await closures are not part of the core async fn functionality we expect to stabilize.
@leinlawun -- I'm not sure precisely what the problem is here, but in general async closures don't really work correctly.
This is expressible now with reworked async closures (#120361) and async Fn()
bounds:
#![feature(async_closure)]
#![allow(unused)]
struct Task<T> {
task: T,
}
impl<T> Task<T>
where
T: Fn(),
{
fn new(task: T) -> Self {
Self { task }
}
fn execute(&self) {
(self.task)();
}
}
struct AsyncTask<T> {
task: T,
}
impl<T> AsyncTask<T>
where
T: async Fn(),
{
fn new(task: T) -> Self {
Self { task }
}
async fn execute(&self) {
(self.task)().await;
}
}
fn main() {
let string = "Hello, World!".to_string();
let _task = Task::new(move || {
println!("{}", string);
});
let string = "Hello, World!".to_string();
let _async_task = AsyncTask::new(async move || {
println!("{}", string);
});
}
Shouldn't this be closed then?
@dev-ardi: No. Async closures are not stable.
Is that how it works? If an issue in stable 1.78 is fixed in release 1.80 when is the issue closed? When the fixing PR is closed, at the beta release or when the fix becomes stable?
Hello, recently faced with strange behavior, please comment, is this a bug, or not? Compiler version: 1.35.0-nightly 2019-04-12 99da733f7f38ce8fe684
(Playground)(Updated PlaygroundErrors: