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.

[gilescope]

I'll get used to opaque :-)

Only by naming an impl Trait through a type alias

You're refering here to existential types? Most of the time when someone gets this error they're assuming they can do this but don't realise they need existential types to make the two impl Traits be the same type. We could hint that there's an unstabilised feature that could help?

But if they weren't trying to bind both impl Traits to be the same type, then given both types textually look the same it would be great if the error message could point out the difference between those two types. Currently the error says:

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

As a nubie I need to see something different between the two types that I can get my teeth into.
How about:

    = note: expected type `impl Foo` (opaque type) @ file2:1257
               found type `impl Foo` (opaque type) @ file1:1234

Somehow it would be great to distinguish these two opaque types (or does the compiler at this point has no knowledge of where these two opaque types came from - only that they are not the same?).

[estebank]

Fwiw, we desire to keep jargon to minimum.

[Centril]

You're refering here to existential types? Most of the time when someone gets this error they're assuming they can do this but don't realise they need existential types to make the two impl Traits be the same type. We could hint that there's an unstabilised feature that could help?

existential type was removed from the language in #63180 in favor of just type Alias = impl Trait;. We could hint towards that on nightly.

How about:

Seems like a nice improvement.

[gilescope]

Thanks Centril - hadn't seen that switch. If people are ok with adding line numbers to pinpoint the different impl Traits I'll have a go at rolling a PR?

[gilescope]

With all the various improvements that we've done, is there more we could do? or shall we close this issue for now?