Rust: Unification fails when type alias impl trait is used in non-return position

[jonhoo]

The following code fails to compile, but I believe this should be a supported use-case under https://github.com/rust-lang/rfcs/pull/2515 (and https://github.com/rust-lang/rust/issues/63063):

#![feature(type_alias_impl_trait)]
type X = impl Iterator<Item = u64> + Unpin;

struct Foo(X);
impl Foo {
    fn new(z: Vec<u64>) -> Self {
        Foo(z.into_iter())
    }
}

with

error[E0308]: mismatched types
  --> src/lib.rs:12:13
   |
12 |         Foo(z.into_iter())
   |             ^^^^^^^^^^^^^ expected opaque type, found struct `std::vec::IntoIter`
   |
   = note: expected type `X`
              found type `std::vec::IntoIter<u64>`

This code on the other hand works just fine with the above X:

fn foo(z: Vec<u64>) -> X {
    z.into_iter()
}

Including both Foo and foo in the same file still produces the same error, so foo does not "help" identify X.

[Centril]

I'm going to say this is a bug... @cramertj confirm?

[varkor]

I think the "defining uses" for TAIT are far too restrictive at the moment. I know that @alexreg was intending to look into similar issues.

[jonhoo]

This is also becoming increasingly common for people writing their own impl Future blocks as library authors move to async fn and -> impl Future functions (e.g., tokio::TcpStream::connect), since it is now impossible to name the return type so that it can be embedded in other (custom) futures. You can hack around it with Box or by adding generic parameters, but neither of those solutions are particularly attractive.

[cramertj]

I'm going to say this is a bug... @cramertj confirm?

Yes, the current set of defining uses is significantly reduced from what is allowed by the RFC.

[alexreg]

@varkor @cramertj I think we need a new summary-post (issue?) detailing the defining uses. I will expand it to consts/statics for sure, but within fn bodies is more subject to debate (and trickier to implement).

[cramertj]

RFC 2071 specified that any unification site inside the module could count as a defining use.

[varkor]

As long as each use uniquely defines the underlying type, it should be permitted as a defining use. That's as I understand the intention, and the one that makes the most sense (one that albeit might be trickier to implement in some cases).

[alexreg]

@varkor Yeah, it certainly will... I think I'm going to need some advice on how to implement it inside of bodies, in this case!

[varkor]

We can start with the easier cases, and then slowly address the remaining cases. Let's get consts and statics working first.

[clarfonthey]

I think that the error I'm dealing with is also this. Example:

#![feature(type_alias_impl_trait)]
use core::iter::Map;

trait Thing {
    type Iter: Iterator<Item = u32>;
    fn do_thing(val: u32) -> u32;
}

type DoThing<T: Thing> = impl FnOnce(u32) -> u32;

struct ThingIter<T: Thing> {
    inner: Map<T::Iter, DoThing<T>>,
}

Playground link