RFC 1214 problems with bounds on associated type of type parameter

[jld]

Consider this function:

fn example<O, B: ToOwned<Owned=O>>(_:&B) { }

This gives an RFC 1214 warning about needing to also add a O: Borrow<B> constraint in order to mention ToOwned<Owned=O>, but I don't understand why. As I understand it, this is effectively a type-level function being passed a proof that B: ToOwned, which necessarily includes a proof that <B as ToOwned>::Owned: Borrow<B>. Requiring an additional proof that <B as ToOwned>::Owned == O to instantiate the fn shouldn't weaken that… right?

Indeed, what I'd expected was the opposite: that I could declare where B: ToOwned<Owned=O> and that would be enough to satisfy any O: Borrow<B> obligations within the scope of the binder (e.g., calling HashMap::get) without having to explicitly declare that.

The above example is trivial for simplicity's sake, but the context where I ran into this wasn't: the owned type was an associated type of a type parameter of the impl containing the fn that was parameterized on the borrowed type.

(cc @aturon)

[aturon]

cc @nikomatsakis

[ghost]

You run into this on any type which has the cyclic requirements that ToOwned has. You can also do it without an extra type parameter on the function in this contrived example:

trait Example {
    type Param;
}
trait NestedExample: Example where <Self as Example>::Param: Example { }

fn example<T: NestedExample>(_: &T) { }

impl Example for u32 {
    type Param = u32;
}
impl NestedExample for u32 { }

In this case, it appears that the associated type constraints aren't being propagated like they should. Similarly to how trait Eq: PartialEq tells us here that any type with Eq automatically has PartialEq, this example should imply that any type with NestedExample automatically has Example on its associated type.

[jonas-schievink]

Isn't this just an example of "non-supertrait bounds are not elaborated"?

[jld]

“non-supertrait bounds are not elaborated” seems to be either #20671 or #10950.

Those seem to be… mostly about type parameters. Associated types are either weaker or stronger (depending on which side you're on) than parameters in that there's exactly one per (self type * other parameters) instead of a set, but I don't know if that's significant for this area of typechecking.

[nikomatsakis]

@jonas-schievink wrote:

Isn't this just an example of "non-supertrait bounds are not elaborated"?

@jld replied:

Those seem to be… mostly about type parameters.

Nonetheless, I think @jonas-schievink is largely correct in terms of the underlying issues in the implementation.

[bstrie]

Triage: this is still relevant, although am I correct in thinking that this would be addressed once the Implied Bounds RFC (#44491) is implemented?

[jonas-schievink]

Closing in favor of #44491 / #20671