Document RFC 1623: static lifetime elision.

[chriskrycho]

This should be the last item required for stabilizing RFC 1623 (#35897).

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @steveklabnik (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[frewsxcv]

Can you wrap this line to match the indentation of the surrounding lines?

[chriskrycho]

Agh, yes. I've updated it; I meant to fix that before I pushed it!

[steveklabnik]

So, @rust-lang/docs , this raises a question. How do we make the distinction between stable and unstable stuff here?

[chriskrycho]

I think at some point, we are going to need to build infrastructure for versioning. That is going to be some work, but I do not see how we can handle these kinds of cases long-term without it. I can open an issue to that effect if you like. And maybe ping some of the Ember people who worked on their infrastructure that way.

[GuillaumeGomez]

It should have an unstable version. I don't have much better idea. :-/

[chriskrycho]

I just noted that all the code samples in reference.md get tested. Neat! I'll update the sample accordingly in the morning.

[frewsxcv]

I don't have any great ideas either, other than explicitly mentioning that it's unstable in the paragraph above and adding in the #[feature(whatever_feature_name)] in the code example. At least we'll get a warning when it stabilizes.

[steveklabnik]

Putting this on this week's doc team agenda.

[llogiq]

We could change the feature implementation to my first commit, thus stabilizing the feature and removing the extra code adding the feature gate that makes it unstable in the first place. I presume this should make the doc tests pass.

[steveklabnik]

So, we talked about this at the docs meeting today.

What it really boils down to is this: it'd be a shame to block this based on figuring out the broader story here. However, once we know that the rest of the feature will be stable, we can just land this, then land the stabilization of the feature. @aturon just put the feature into FCP, so let's see how that goes before we merge.

And in the meantime, let's figure out the broader docs story. I'm going to open an issue on the RFCs repo about this.

[chriskrycho]

Related: I'll have time Friday or Saturday to update the not-the-feature-gate bits of the test that are broken here—there's one piece that needs to be tweaked independent of the stabilization/feature flag issue.

[chriskrycho]

Kept spacing this; came back to it via other issues. I'll update the non-feature-gate related parts tonight or tomorrow!

[llogiq]

@chriskrycho do you need any help?

[chriskrycho]

@llogiq gah. Slipped my mind. The only thing that needs tweaking is setting ignore on this example. It's re-using items from earlier in the reference, but they're not in scope for that specific example.

[chriskrycho]

I just pushed a fixed version of the commit which just includes all the required pieces. We'll see what Travis says…

[chriskrycho]

UGH. I pushed the rebase, but not the fix.

This is how my whole first day back at work has been. 🤦‍♂️

[steveklabnik]

@chriskrycho travis is still failing: https://travis-ci.org/rust-lang/rust/jobs/188704796#L1662

[chriskrycho]

🤔 Grr. I will follow up Wednesday evening. Family commitments till then.

[steveklabnik]

No worries!

[llogiq]

Actually this is full elision with a 'static default. This means that if the types contains fns, the usual elision rules will apply, only choosing 'static if no elision rule applies.

[chriskrycho]

@llogiq can you elaborate?

@steveklabnik I seem to have failed in pacifying Travis and the feature gate. Can you take a gander and indicate what I did wrong?

[llogiq]

This means if you have a static FOO : &Fn(&Bar) -> &Baz, you actually have a static FOO : &'static Fn<'a>(&'a Bar) -> &'a Baz for some unnamed 'a.

[est31]

I seem to have failed in pacifying Travis and the feature gate.

I think you can fix it by adding # #![feature(...)] to the doc test. It won't show up in the output then due to the leading #, while fixing the issue. See also the book and the asm documentation, it uses this as well.

[chriskrycho]

@est31 ah, it's the extra #. Got it.

@llogiq do you have a suggested change to the write-up here?

[clarfonthey]

this should be #![feature(static_in_const)]; you forgot the exclamation point.

[chriskrycho]

YOU ARE MY HERO

[llogiq]

I think I could improve it, but I need to find the time first.

[llogiq]

Also after the example, add a paragraph to explain the elision:

In case the static or constant items contain function references or closures, and those work with references, the compiler will try the usual elision rules (link to elision). Failing that, it will default the lifetimes to 'static. This is best explained by an example:

const FUN : fn(&str) -> &str = ..
// per rule #1, this is fn<'a>(&'a str) -> &'a str

const FUNNY : Fn(&Foo, &Bar, &Baz) -> usize = ..
// per rule #2, this is Fn<'a, 'b, 'c>(&'a Foo, &'b Bar, &'c Baz) -> usize

const UNFUNNY : Fn(&Foo, &Bar) -> &Baz = ..
// neither rule applies, so all `&`s are `'static`

[llogiq]

How about "will have elided lifetimes where applicable, otherwise – in most cases – defaulting to the 'static lifetime.

[est31]

Now that beta branched, I would like to ask for beta backport nomination, so that already 1.16 would have it stabilized.

[llogiq]

Good idea.

[steveklabnik]

@chriskrycho ping! any interest in keeping this going? this is still blocking stabilization.

@est31 I would be strongly against this; stabilization backports are incredibly rare.

[chriskrycho]

@steveklabnik yeah, should be able to allocate an hour to it tomorrow. I'll pull in @llogiq's comments, as well as fix the build issue, then.

[llogiq]

We may also want to show embedded lifetimes, e.g. Fn(&'a Foo) -> Bar<'a> can be shortened to Fn(&Foo) -> Bar.

[chriskrycho]

@llogiq regarding your last comment: did that change with this RFC/implementation? If not, I'd prefer to note it as something to add in a separate commit/PR. I think we actually need a dedicated section for lifetime elision in general; right now it appears to be documented in detail only in the nomicon.

[chriskrycho]

Updated with everything other than the embedded lifetimes scenario, and it passed rustup run nightly rustdoc --test ./doc/reference.md so we should finally be good to go. 🤞

[steveklabnik]

Travis passed!

@bors: r+ rollup

thanks a ton @chriskrycho

[bors]

📌 Commit 4096dd6 has been approved by steveklabnik

[chriskrycho]

YESSSSSSSSSSS. FINALLLYYYYYYYY.

Sorry for the many delays on this, everyone! Glad it's finally in. So it'll land in, what, 1.17?

[est31]

@chriskrycho

So it'll land in, what, 1.17?

yes.

[alexcrichton]

Removing beta nomination as sentiment seems to be to not backport (also see #35897)