Confusing error message with type unification of impl Traits

[adamlesinski]

It took a colleague explaining to me that the return type of a function returning an impl Trait is unique across function definitions for me to understand the following error: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4ceda076c82b01ea279e8864518ab5d9

This becomes more important for async/await because of the automatic translation of async fn foo() -> i64 to fn foo() -> impl Future<Output = i64>: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=b109446a49d22a632e395aacaa2cb8ff

In the first case, can the error maybe call out that the opaque types are different due to how the compiler treats them? And for the second error, can this be called out in async-specific language. That error happens when you forget to call .await.

[Centril]

In the first case, can the error maybe call out that the opaque types are different due to how the compiler treats them?

How about?:

   = note: expected type `impl Foo` (opaque type)
              found type `impl Foo` (opaque type)

   = note: distinct uses of `impl Trait` result in different opaque types

And for the second error, can this be called out in async-specific language. That error happens when you forget to call .await.

In the second case I think we should suggest that the .awaits be moved into the branches tho this may be complicated to encode as a diagnostic.

cc @estebank

[adamlesinski]

In the first case, can the error maybe call out that the opaque types are different due to how the compiler treats them?

How about?:

   = note: expected type `impl Foo` (opaque type)
              found type `impl Foo` (opaque type)

   = note: distinct uses of `impl Trait` result in different opaque types

This is perfect! It's the exact hint I needed to understand the problem :)

And for the second error, can this be called out in async-specific language. That error happens when you forget to call .await.

In the second case I think we should suggest that the .awaits be moved into the branches tho this may be complicated to encode as a diagnostic.

cc @estebank

Agreed, this is definitely a bit trickier. I'll defer to you on the best way to message this error.

[Arnavion]

In the first case, can the error maybe call out that the opaque types are different due to how the compiler treats them?

Doesn't it already does so?

17 | |         two()
   | |         ^^^^^ expected opaque type, found a different opaque type

[estebank]

@Centril what is the correct nomenclature for a regular, non-opaque type that we could use here? With that we could say something like "consider materializing to an explicit type in both branches from the opaque type" and "for impl std::future::Future you can .await them on both branches to unify the types". This is rough wording, but gives an idea of what I'm thinking.

[Centril]

@estebank The antonym of opaque is transparent but I'm not sure that is situationally good to use here. ISTM you'd want to say something like "use an enum with variants for both cases" (at least that's the advice I'd give in person). I'd go for a non-actionable description as a first pass at this problem and consider an improvement later.

[gilescope]

Are opaque types the same as anonymous types in C#/Java? If so I think 'anonymous' is clearer than opaque (pardon the pun!).

[gilescope]

This is a real gotcha of rust and needs a great error message. We could show the definition sites of the opaque types so it's clear which type is expected in this position:

Something like:

17 | |         two()
   | |         ^^^^^ expected type produced at: `one() -> impl Foo`
   | |                  found type produced at: `two() -> impl Foo   
   | |                  note: distinct uses of `impl Trait` in function signatures 
   | |                       result in different opaque types.

[Centril]

It doesn't matter where the impl Trait resides in. Two uses will result in two distinct types from the POV of the type system. Only by naming an impl Trait through a type alias can you refer to the same inferred type. Adding the qualification "in function signatures" does not enlighten.

As for "anonymous", the closest equivalent Java's anonymous classes, which conjure new types, in Rust are closures. Also, with Java's anonymous classes you can recover the type identity at runtime using anon.getClass() but you cannot name them. However, impl Trait in Rust can be named (using a type alias), they do not representationally create new types (although they do nominally), and they do not leak their type identities. Rather, impl Trait is about hiding the underlying type (think of expr as impl Debug as a coercion that hides the type). The impl Trait is most similar to Stanard ML's opaque matching (see section G.2 in the definition of Standard ML) All in all, opacity is therefore the most appropriate description rather than anonymity.