Treat weak alias types more like ADTs when computing implied bounds by fmease · Pull Request #122340 · rust-lang/rust (original) (raw)

I'm having second thoughts about this. Treating weak aliases like ADTs during infer_outlives, i.e., super-visiting them is meh (visiting its generic arguments), esp. for TAIT. Weak aliases aren't really nominal after all.

Let's take a look at ADTs: I can see why it's convenient to imply the bound T: 'a in struct Outer<'a, T>(&'a Inner<T>); (where struct Inner<T>(T);) even though this super-visiting approach is relatively "unrefined"/simple:

For example, for struct Outer<'a, T: Trait>(&'a T::P); (where trait Trait { type P; }) we "conservatively" infer &'a <T as Trait>::P (which is good!) instead of let's say T: 'a. However, once we hide the projection behind another ADT, we're back to the "component-wise" outlives inference.
Like, we imply the bound T: 'a in struct Outer<'a, T: Trait>(&'a Inner<T>) where struct Inner<T: Trait>(T::P); :)

So for weak aliases, this ADT-behavior would be even "worse". I don't think we want to imply the bound T: 'a in the following scenario:

#![feature(lazy_type_alias)] type Ty<'a, T: Trait> = &'a Aux; type Aux<T: Trait> = T::P; trait Trait { type P; }

On master, we imply the bound Aux<T>: 'a for Ty contrary to this branch which currently implies the bound T: 'a as it visits T inside &'a Aux<T>.


Yet again, I'm wondering if we should instead employ "type_of"/expand_weak_alias_tys here, even though I cringe at the thought already (well, regarding expand_weak_alias_tys that'd probably be problematic since it recursively drills through weak aliases without touching any potential predicates on the corresponding lazy type aliases, which seems pretty bad but I haven't spent much thought on that yet).

Ignoring the details for now, the "type_of approach" would allow us to keep implying the bound Opaque<T>: 'a in the following code I'm pretty sure:

type Opaque = impl Sized; fn define() -> Opaque {} struct Ty<'a, T>(&'a Opaque);

On this branch, we currently imply the bound T: 'a instead ... which is yuck?!


@oli-obk, thoughts? ^^'