nested RPIT and HRTB: unclear semantics and future incompatibility · Issue #96194 · rust-lang/rust (original) (raw)

(Original post in internals forum)

Given the following code (stable sin 1.30!):

fn f() -> impl for<'a> Tr<'a, Assoc = impl Copy> {}

It is undocumented whether the inner existential type, impl Copy, is allowed to access 'a or not. In other words, it is equivalent to which of the following?

type Assoc = impl Copy; fn f() -> impl for<'a> Tr<'a, Assoc = Assoc> {}

or,

type Assoc<'a> = impl Copy; fn f() -> impl for<'a> Tr<'a, Assoc = Assoc<'a>> {}

On stable

The behavior in current stable is consistent with the first as shown by:

• If Assoc uses the lifetime 'a, the compiler complains about Implementation is not general enough as expected.
• The following test on the return type passes

fn assert_unique_assoc(_: impl for<'a> Tr<'a, Assoc = Assoc>) {} fn main() { assert_unique_assoc(f()); }

It looks like this was unintentionally stabilized and changing that now would break the above test (unless we leak the fact that impl Copy captures 'a ??).

On beta

#94081 makes #88236 pass but that seems to be inconsistent with the behavior in stable:

• If Assoc uses 'a, it gives ICE, see yet another ICE with HRTB and RPIT #95647.
• Using the above test on the return type fails, which is quite surprising since removing the lifetime from impl Copy + 'a makes the test pass. playground. And I believe adding a lifetime bound shouldn't change the semantics in this regard.
• It would be a backward compatibility risk if we ever want to reject the code in the future.

Meta

stable version: 1.60.0
beta version: 1.61.0-beta.3 2022-04-17 2431a974c2dcf82ba513)

@rustbot label +T-Lang +A-impl-Trait