-
Notifications
You must be signed in to change notification settings - Fork 13.3k
RPIT(IT)s "leak" internal implementation details of lifetime capturing via boundedness #140517
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
You've encountered a detail of the type system: "Boundedness". The |
I guess you could call this an implementation detail of RPIT(IT)s leaking through (existential impl-Trait in return position). If an RPIT captures an in-scope lifetime, it forces it to be early-bound. So if you have: fn f0<'a>() {} // 'a is late-bound
fn f1<'a>() where 'a: {} // 'a is early-bound
fn f2<'a>() -> impl Sized {} // 'a is late-bound in Rust <2024 and early-bound in Rust >=2024
fn f3<'a>() -> impl Sized + use<> {} // 'a is late-bound
fn f4<'a>() -> impl Sized + use<'a> {} // 'a is early-bound |
I g2g can't finish my explanation rn. Later then. |
Okay, but there are indeed super fishy things going on...
This is what this issue essentially boils down to! Doesn't need RPITIT, RPIT also exhibits this behavior:
Footnotes
|
Let's look what
but that doesn't tell us anything we don't already know. |
Like, I obviously know of lifetime duplication for RPITITs (RPITs, too??) but that's not necessarily related. The rules observed above seem super "arbitrary" just looking at these four examples. I obviously haven't looked into the compiler impl yet, I first need to find the relevant place. So I don't yet know if this is intentional, WONTFIX or 'worth fixing'. Edit: Aye, I'm pretty sure what we observe here gets fully determined in fn |
I tried this code:
I expected to see this happen: implementation of
X<Foo>
onJack
compiles without errorBar<'a>
and<Foo as A>::B<'a>
are exactly the same type.X<Foo>
onJack
andEric
should have identical behavior.X<Foo>
onEric
compiles.Instead, this happened: implementation of
X<Foo>
onJack
gives the following errorMeta
rustc --version --verbose
:Using the nightly version, it still doesn't work
The text was updated successfully, but these errors were encountered: