Repository navigation
Tracking Issue for RFC 3216: "Allow using for<'a> syntax when declaring closures" #97362
Description
Activity
I'd like to work on implementing this 👀
@rustbot claim
Reacted by Guillaume Depardon and jynReacted by hirrolot, Luca Barbato, Mick Dekkers, jyn and Kisaragi- added a commit that references this issue
on Jul 15, 2022 Found an ICE involving this feature: #103736
(Maybe we could use an
F-closure_lifetime_bindertag?)- added a commit that references this issue
on Nov 4, 2022 11 remaining items
Is this feature blocked by any ongoing process? The implementation seems completed for a while, maybe we can push this to stabilization?
Reacted by Ondřej Perutka, Artem S, louchenyao, Js2xxx, ZhangJun, Élie ROUDNINSKI, Théodore Prévot, Ziru Niu, cjw, Chayim Refael Friedman and 3 moreIs this feature blocked by any ongoing process? The implementation seems completed for a while, maybe we can push this to stabilization?
same question here.
Reacted by Élie ROUDNINSKI, Tim (Theemathas) Chirananthavat and ArmoredPonyIdeally, the compiler would infer the most permissive signature possible, and so the
for<'a>syntax would not be necessary (except as documentation).I'm just saying
for<'a> |x: &'a ()| -> &'a () { x }should work exactly like|x: &()| -> &() { x }, but it is currently not.It is my understanding that the binding of a specific lifetime and a
for<'lt>(which, as I understand it, is effectively the ∀ lifetime) are not interchangeable in all cases, for the precise reason that ∀ and ∃ are different quantifiers.@safinaskar As far as I understand compiler internals, a closure is inherently not invariant in regards to the lifetime of the arguments, and you need strong hints in order to make a closure such similar to a normal
fn. For example, the higher ranked closure macros in thelending_iteratorcrate.In other words, the compiler is very conservative when closures could possibly have something like a
for<'all> where Closure: 'allbound and instead only inherently satisfiesFnOnce(&'1 ()) -> &'2 ().#![feature(closure_lifetime_binder)] trait X<'a> { } impl<'a, T, K> X<'a> for T where T: FnOnce(&'a ()) -> K {} fn foo<F>(f: F) where F: for<'a> X<'a>, {} fn main() { foo(for<'a> |x: &'a ()| -> &'a () { x }); // COMPILES // foo(|x: &()| -> &() { x }); // DOESN'T COMPILE fn hrc_hint<F>(f: F) -> F where F: for<'all> FnOnce(&'all ()) -> &'all () { f } foo(hrc_hint(|x: &()| -> &() { x })); // NOW COMPILES }
Finally, to avoid this, as far as I can tell, either: the compiler becomes less conservative on closures (possibly E.2024?), we get bounded HRTBs (
for<'all> where *: 'all) (very unlikely), orclosure_lifetime_binderbecomes popular enough to be stabilized.Reacted by JubileeReacted by cupofc0tThis is a tracking issue, for the record. If you have a bug with a specific feature, please open a new issue! If you want to discuss the implementation, please also open a new issue and it can be tagged C-discussion. Tracking issues have a linear history so they are not conducive to any kind of discussion.
- locked as off topic and limited conversation to collaborators
on Aug 30, 2024
View all comments
This is a tracking issue for the RFC "Allow using
for<'a>syntax when declaring closures" (rust-lang/rfcs#3216).The feature gate for the issue is
#![feature(closure_lifetime_binder)].About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
for<>lifetime binder for closures #98705Unresolved Questions
How does the explicit lifetime binder deal interact with elided lifetimes. The addition of higher-kinded inference variables (rust-lang/types-team#131) may change the preferred design here.
Implementation history
for<>lifetime binder for closures #98705