-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Tracking issue for RFC 2115: In-band lifetime bindings #44524
Comments
@aturon Could we word the unresolved question as something like "what is the appropriate convention, if any" rather than "is this particular convention worthwhile"? Thanks! |
also, that wasn't the only suggested alternative. There is also completely explicit lifetimes using |
This supposedly ergonomic change is going to require updating a lot of code, including all of our docs and examples. I guess you could just do |
@glaebhoerl Done, thanks! |
I expanded the unresolved question a bit. |
Mentoring instructionsI'm not sure 100% the best way to implement this yet, but let me start by giving some pointers. Perhaps @eddyb can elaborate, as he is the last one to touch the relevant code in a serious way, as far as I know. First thing is a kind of list of what the tasks are in the RFC. This is roughly the order in which I think we should approach them. It may even be worth breaking this out into separate issues. XXX task list moved into main header I don't have time for detailed mentoring notes, but here are a few things to start reading into. At present, region resolution etc kind of works like this:
|
To support
|
Implement underscore lifetimes Part of #44524
Implement in-band lifetime bindings TODO (perhaps in a future PR): Should we ban explicit instantiation of generics with in-band lifetimes, or is it uncontroversial to just append them to the end of the lifetimes list? Fixes #46042, cc #44524. r? @nikomatsakis
Sorry that I come “after the battle” (this RFC was accepted during the pre-impl-period rush), but as @durka pointed out applying this lint to existing code bases will likely generate a lot of busy work for questionable benefits. I looked for the rationale for this lint but couldn’t find it. https://rust-lang.github.io/rfcs/2115-argument-lifetimes.html#lifetimes-in-impl-headers mentions a “convention”, but doesn’t say why enforcing it is important enough to warn by default. We don’t have such a lint for local variable names or field names, for example. I assume that proposed lints are intended to warn by default. If they’re silent by default I have no concern. |
The idea is that there will no longer be |
@rpjohnst Sorry, I have a hard time figuring out if your comment is arguing for or against something, and whether that thing is the lint I mentioned or some other change proposed by this tracking issue. |
@SimonSapin It's just trying to describe the reasoning behind the lint's existence, not necessarily argue for or against it. |
…rochenkov Remove `in_band_lifetimes` from `rustc_mir_transform` Like rust-lang#91580, this was inspired by the conversation in rust-lang#44524 about possibly removing the feature from the compiler. This crate is a heavy `'tcx` user, so is a nice case study. r? ``@petrochenkov`` Three interesting ones: This one had the `'tcx` declared on the function, despite the trait taking a `'tcx`: ```diff -impl Visitor<'_> for UsedLocals { +impl<'tcx> Visitor<'tcx> for UsedLocals { fn visit_statement(&mut self, statement: &Statement<'tcx>, location: Location) { ``` This one use in-band for one, and underscore for the other: ```diff -pub fn remove_dead_blocks(tcx: TyCtxt<'tcx>, body: &mut Body<'_>) { +pub fn remove_dead_blocks<'tcx>(tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>) { ``` A spurious name, since there's no single-use-lifetime warning: ```diff -pub fn run_passes(tcx: TyCtxt<'tcx>, body: &'mir mut Body<'tcx>, passes: &[&dyn MirPass<'tcx>]) { +pub fn run_passes<'tcx>(tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>, passes: &[&dyn MirPass<'tcx>]) { ```
@rfcbot fcp reviewed I agree with what @scottmcm wrote. I am definitely still interested in us spending time to address some of the ergonomic pain around using lifetimes, but I'd want to step back and do an initiative, and in particular to spend some time identifying precisely which problems are most pressing now. |
@davidtwco @estebank @nagisa Friendly one-week ping for the FCP close here. It only needs one more ✅! |
✅ |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
One no-brainer thing we can do to help here is to add an in-editor fix to create a declaration for “in-band” lifetimes |
The final comment period, with a disposition to close, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. |
With the FCP completed here, this is currently open because the feature still exists in the compiler, with the tracking issue number referencing this item: rust/compiler/rustc_feature/src/active.rs Line 401 in 9747ee4
We're unsure how difficult it will be to remove the code about this from the compiler, but if anyone is interesting in picking up something, grepping for the feature should give a bunch of places to start: https://github.com/rust-lang/rust/search?q=in_band_lifetimes+path%3Acompiler |
…r=cjgillot Remove in band lifetimes As discussed in t-lang backlog bonanza, the `in_band_lifetimes` FCP closed in favor for the feature not being stabilized. This PR removes `#![feature(in_band_lifetimes)]` in its entirety. Let me know if this PR is too hasty, and if we should instead do something intermediate for deprecate the feature first. r? `@scottmcm` (or feel free to reassign, just saw your last comment on rust-lang#44524) Closes rust-lang#44524
…r=cjgillot Remove in band lifetimes As discussed in t-lang backlog bonanza, the `in_band_lifetimes` FCP closed in favor for the feature not being stabilized. This PR removes `#![feature(in_band_lifetimes)]` in its entirety. Let me know if this PR is too hasty, and if we should instead do something intermediate for deprecate the feature first. r? ``@scottmcm`` (or feel free to reassign, just saw your last comment on rust-lang#44524) Closes rust-lang#44524
…r=cjgillot Remove in band lifetimes As discussed in t-lang backlog bonanza, the `in_band_lifetimes` FCP closed in favor for the feature not being stabilized. This PR removes `#![feature(in_band_lifetimes)]` in its entirety. Let me know if this PR is too hasty, and if we should instead do something intermediate for deprecate the feature first. r? ```@scottmcm``` (or feel free to reassign, just saw your last comment on rust-lang#44524) Closes rust-lang#44524
Update for 2022: With the FCP close finished, this is no longer on a stabilization path, and will likely be removed from nightly. The issue will remain open so long as it's referenced by an implemented
feature
in the compiler, however.This is a tracking issue for the RFC "In-band lifetime bindings" (rust-lang/rfcs#2115).
Steps:
'_
(this has its own tracking issue, Tracking issue for'_
#48469)Tracking issue for lifetime elision for impl headers (feature impl_header_lifetime_elision) #15872: Enable elision in impl headers (mentoring instructions here)impl_header_lifetime_elision
in Tracking issue for lifetime elision for impl headers (feature impl_header_lifetime_elision) #15872'_
in where-clauses on functions. -- blocked on Tracking issue for lifetime elision for impl headers (feature impl_header_lifetime_elision) #15872Unresolved questions:
'tcx
and'gcx
to be used consistentlyCan we find an unequivocally-better syntax than'_
for elided lifetimes?Known bugs (possibly incomplete list):
The text was updated successfully, but these errors were encountered: