Implement underscore lifetimes by cramertj · Pull Request #44691 · rust-lang/rust

cramertj · 2017-09-19T05:58:32Z

rust-highfive · 2017-09-19T05:58:43Z

(rust_highfive has picked a reviewer for you, use r? to override)

cramertj · 2017-09-19T06:01:02Z

Feel free to bikeshed this error message (it shows up in code that tries to explicitly bind '_ in the generics of an item declaration).

An equivalent error is already issued for 'static, so the wording can be reused:
invalid lifetime parameter name: `'static`

arielb1 · 2017-09-19T08:47:19Z

r? @eddyb

kennytm · 2017-09-19T09:08:40Z

Should be 1.22.0? (BTW match_beginning_vert should also be 1.22.0?)

I never know what to actually put here.

eddyb · 2017-09-19T09:11:25Z

r=me with build & nit fixed

petrochenkov · 2017-09-19T13:19:42Z

Lifetime definitions can happen in for<'a, 'b, 'c> in fn pointers, trait objects, etc.
It's better to place the error in fn visit_lifetime_def.

petrochenkov · 2017-09-19T13:24:38Z

@cramertj
What happens when '_ is written in some place where elided lifetimes are not supported currently?
For example bounds 'a: '_ + 'b, impl headers, struct definitions.
Could you add tests for these cases?

nikomatsakis · 2017-09-19T20:06:45Z

So I've never been crazy about using a "sentinel value" here rather than an enum -- now that we've got more than one sentinel, I feel even less good. Can't we change this to something like
enumLifetimeName{Elided,Underscore,Static,Name(Token)// or whatever this is}

It's a Symbol / ast::Name I think.

nikomatsakis · 2017-09-19T20:07:31Z

...if we were using an enum, this code would be rather cleaner

nikomatsakis · 2017-09-19T20:49:28Z

can we have some tests that use multiple lifetime parameters in one function? For example:
fnfoo(x:&'_u8,y:&'_u8) -> &'_u8{}// ERROR from elisionfn foo(x:&mutVec<&'_u8>,y:&'_u8){ x.push(y);// ERROR }structFoo<'a,'b>{a:&'au32,b:&'bu32}fnfoo_a<'b>(foo:Foo<'_,'b>) -> &'bu32{&foo.a}// ERRORfnfoo_b<'b>(foo:Foo<'_,'b>) -> &'bu32{&foo.b}// OK

nikomatsakis · 2017-09-19T20:50:02Z

@cramertj thanks for jumping on this btw -- so excited to see it land =)

petrochenkov · 2017-09-19T23:52:13Z

Nooooo.
This LifetimeName over Name is pure over-engineering, N extra lines of boilerplate just to avoid one string comparison.

Heh. I don't have any strong opinion here. Take it up with @nikomatsakis 😄
I left it as its own commit so it's easy to pull out if that's the decision.

I'd better turn '_ into a weak keyword.

I disagree. Sentinel values mean you wind up with if-else-if chains like if foo.is_elided() { ... } which are easily forgotten. Having an enum means we can use exhaustive matching, so that when we add variants in the future, the compiler helps us catch cases that are missing etc.
Plus, there isn't a lot of boilerplate here.

@nikomatsakis
Ok, not a big deal.
(I'll revert this when you are on vacation, ha-ha.)

cramertj · 2017-09-20T00:45:32Z

Gah! I didn't try building rustdoc and the others...

eddyb · 2017-09-20T16:33:06Z

cc @Mark-Simulacrum this is why I have rustbuild in my build setup.

petrochenkov · 2017-09-20T17:31:13Z

Symbol::intern("'static") => keywords::StaticLifetime.name()

petrochenkov · 2017-09-20T21:22:05Z

@cramertj
Could you add tests for '_ in impl headers and struct definitions? (But not as bounds or lifetime definitions.)

bors · 2017-09-21T02:59:54Z

☔ The latest upstream changes (presumably #44551) made this pull request unmergeable. Please resolve the merge conflicts.

petrochenkov · 2017-09-21T08:34:22Z

@cramertj
Actually, can you tweak the naming slightly.
enumLifetimeKind{// This is not a nameImplicit,// `Elided` is not correct, because implicit can be both elided and inferred, but we don't discern between them yet when lowering into HIRUnderscore,Static,Named(Name),// Named lifetime}

(The variants are going to change anyway when lifetimes are first resolved, then lowered into HIR.)

I think what we want is name resolution to give us a Def, and the existing resolve_lifetimes pass to do elision and compute the semantic representation from Def::Lifetime(DefId).

@petrochenkov I don't object to calling "Implicit" for sure, but I'm curious: what does "elided" mean to you? To me, it means "not written". I would then say that the behavior around elided lifetimes depends on context: in function signatures, we use defaulting rules (as specified by the lifetime elision RFCs plus the object-lifetime RFCs), and in function bodies, we use inference.

Using "elided" to mean literally "not written" may be correct wrt the English language but then "elision rules" doesn't mean much anymore and we have to say "default lifetime rules" I guess? And "lifetime defaulting" for the process of picking a lifetime.

So personally, when I explain to people, I say something like "sometimes you can elide lifetimes. The meaning of this depends on context. In a function signature, we use the following system of defaults. etc". In other words, I think I do use the terms the way you described. =) But also I rely on context. That is, I might say "elision rules" when it's clear we're talking about function signatures, in which case it just means "defaulting rules" (but including, naturally, the object defaults).
In any case, it seems clear that calling things elided is ripe for confusion. I prefer either "implicit", "not written", or "not present", all of which seem reasonably clear.

@nikomatsakis
Well, I usually associate "elided" with "lifetime elision RFCs", i.e. "defaulting", not inference.
It's useful to have some separate words for "not-written-in-signature" and "not-written-in-body", and "elided" and "inferred" already kinda serve this purpose given that "lifetime elision" is commonly used to describe what happens in signatures.

That makes some sense. I guess I prefer to have words that match their English meanings to the extent possible, though, and to me "elided" just means "not written" (whereas "defaulted" seems more specific -- we assigned it a default value). I admit that the distinction between defaulted (based on some simple rules) and inferred (based on complex analysis) is a subtle one as well. =)

Regardless, the question at hand is whether to use elided here with the broader meaning, right? In which case, "Implicit" or "Not written" seems fine.

…ions

nikomatsakis · 2017-09-21T17:33:07Z

@bors r+

bors · 2017-09-21T17:33:08Z

📌 Commit f5505d1 has been approved by nikomatsakis

bors · 2017-09-22T14:05:22Z

⌛ Testing commit f5505d1 with merge 3eb19bf...

Implement underscore lifetimes Part of #44524

bors · 2017-09-22T17:17:26Z

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing 3eb19bf to master...

rust-highfive assigned nikomatsakis Sep 19, 2017

cramertj commented Sep 19, 2017
View reviewed changes

kennytm reviewed Sep 19, 2017
View reviewed changes

petrochenkov reviewed Sep 19, 2017
View reviewed changes

cramertj force-pushed the underscore-lifetimes branch 2 times, most recently from 0c3b9ef to 942a85cCompare September 19, 2017 18:11

nikomatsakis requested changes Sep 19, 2017
View reviewed changes

arielb1 added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Sep 19, 2017

cramertj force-pushed the underscore-lifetimes branch from ac16bad to c91a1a7Compare September 19, 2017 23:46

petrochenkov reviewed Sep 19, 2017
View reviewed changes

cramertj force-pushed the underscore-lifetimes branch from c91a1a7 to 051b5cfCompare September 20, 2017 16:56

petrochenkov reviewed Sep 20, 2017
View reviewed changes

cramertj force-pushed the underscore-lifetimes branch from 051b5cf to 71c8ad4Compare September 20, 2017 18:13

Implement underscore lifetimes
64314e3

cramertj force-pushed the underscore-lifetimes branch from 8f5f35c to 31fd099Compare September 21, 2017 06:46

petrochenkov reviewed Sep 21, 2017
View reviewed changes

nikomatsakis approved these changes Sep 21, 2017
View reviewed changes

cramertj added 3 commits September 21, 2017 10:19

Refactor lifetime name into an enum
f64af7a

Add tests for multiple underscore and non-underscore lifetimes
06926b6

Add tests for underscore lifetimes in impl headers and struct definit…
f5505d1
…ions

cramertj force-pushed the underscore-lifetimes branch from 31fd099 to f5505d1Compare September 21, 2017 17:19

This was referenced Sep 21, 2017
Tracking issue for RFC 2115: In-band lifetime bindings #44524
Closed
In-band lifetimes: Lint against single-use lifetime names #44752
Open

nikomatsakis added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 21, 2017

bors added a commit that referenced this pull request Sep 22, 2017
Auto merge of#44691- cramertj:underscore-lifetimes, r=nikomatsakis
3eb19bf
Implement underscore lifetimes Part of #44524

bors merged commit f5505d1 into rust-lang:masterSep 22, 2017

This was referenced Sep 22, 2017
Initial support for ..= syntax #44709
Merged
Friendlier error message for closure argument type mismatch #44735
Merged

cramertj deleted the underscore-lifetimes branch September 22, 2017 17:22

Frederick888 mentioned this pull request Sep 23, 2017
Failed to build with rustc 1.22.0-nightly (14039a42a 2017-09-22) rust-lang/rust-clippy#2080
Closed

Uh oh!

Uh oh!

Conversation

cramertj commented Sep 19, 2017

Uh oh!

rust-highfive commented Sep 19, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

arielb1 commented Sep 19, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

eddyb commented Sep 19, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

petrochenkov commented Sep 19, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nikomatsakis commented Sep 19, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cramertjSep 19, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cramertj commented Sep 20, 2017

Uh oh!

eddyb commented Sep 20, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

petrochenkov commented Sep 20, 2017

Uh oh!

bors commented Sep 21, 2017

Uh oh!

petrochenkovSep 21, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

petrochenkovSep 21, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nikomatsakis commented Sep 21, 2017

Uh oh!

bors commented Sep 21, 2017

cramertjSep 19, 2017•
edited
Loading

petrochenkovSep 21, 2017•
edited
Loading

petrochenkovSep 21, 2017•
edited
Loading