Cycle detected in async fn but not with -> impl Future

[Ekleog]

Here is the reproducer:

use std::future::Future;
use futures::FutureExt;

struct Object(Box<Object>);

trait Trait {
    fn iter(&self) -> impl Sized + Send + Future<Output = ()>;
}

impl Trait for Object {
    // Compiles
    #[cfg(any())]
    fn iter(&self) -> impl Sized + Send + Future<Output = ()> {
        async move {
            self.0.iter().boxed().await;
        }
    }
    
    // Does not compile
    #[cfg(all())]
    async fn iter(&self) {
        self.0.iter().boxed().await;
    }
}

(playground link)

Interestingly, if you swap the any/all, then the version with -> impl Sized + Send + Future<Output = ()> does compile properly.

So something in async fn is not just desugared as -> impl Sized + Send + Future, but I'm not sure why that is?

Possibly related to:

• Unclear error message when using recursive future with tokio::spawn #112175
• Unclear TAIT error on auto trait solving #107320
• "computing type of ...::{opaque#0}" query cycle in async fn w/ auto trait obligations. #104343
• error[E0391]: cycle detected when computing type of async fn #78649

[traviscross]

@rustbot labels +AsyncAwait-Triaged +WG-async -C-bug

We reviewed this today in WG-async triage.

It seemed clear to us that this should necessarily result in a cycle error under the current rules. Doing otherwise in this case could be difficult. We didn't feel this was a bug.

[Ekleog]

Hmm just for my education, would it be possible for you to explain why the version with -> impl Future { async move { ... } } is expected to have a different behavior from the version with async fn? I'd love to understand which rules are different between the two versions, to avoid hitting this issue in the future.

(For some context, the non-reduced original issue was a struct that had basically a Vec<Self> member, and recursively called the functions by turning the futures into Box<dyn Future> to avoid the infinite type issue — and this did work with -> impl Future { async move { ... } } but not with async fn; so the obvious infinite recursion at runtime from the reproducer wasn't present then)

[traviscross]

It's not about the difference between async fn and -> impl Future, it's about the fact that in the -> impl Future case you explicitly added a Send bound. If we remove that from the -> impl Future case then it fails similarly:

use core::future::Future;

struct Object(Box<Object>);

trait Trait {
    fn iter(&self) -> impl Future<Output = ()> + Send;
}

impl Trait for Object {
    fn iter(&self) -> impl Future<Output = ()> {
        //~^ ERROR cycle detected
        async move {
            Box::new(self.0.iter()).await;
        }
    }
}

That's how the async fn version is desugared.