Skip to content
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

Add a `lifetime` specifier to `macro_rules!` #1590

Merged
merged 3 commits into from Jun 16, 2016

Conversation

Projects
None yet
9 participants
@sgrif
Copy link
Contributor

commented Apr 22, 2016

Rendered


Since a lifetime is a single token, there is currently no way to accept one
without an explicit matcher. Something like `'$lifetime:ident` will fail to
compile.

This comment has been minimized.

Copy link
@bluss

bluss Apr 23, 2016

lifetime tokens ('xyz) are matched by tt. So just like the literal matcher RFC, this caveat should apply, that it doesn't actually add much power just ease of use to macros by example. /pull/1576

#1576 (comment)

This comment has been minimized.

Copy link
@sgrif

sgrif Apr 23, 2016

Author Contributor

Ah good point. I would argue it does still add a good bit of power in the context of sequences. I will amend the RFC to note this, however.

This comment has been minimized.

Copy link
@sgrif

sgrif Apr 23, 2016

Author Contributor

As it turns out, you actually can't use a tt in a lifetime position:

 error: expected identifier, found `'a`
 impl<$($lifetime),*> SomeTrait

This comment has been minimized.

Copy link
@bluss

bluss Apr 23, 2016

tts don't expand anywhere without the ast coercion (reparse trick) that danielkeep was referring to.

This comment has been minimized.

Copy link
@bluss

bluss Apr 23, 2016

Don't get me wrong, I think this is a good addition, good RFC. But I don't think it gives macro_rules powers it didn't already have.

This comment has been minimized.

This comment has been minimized.

Copy link
@sgrif

sgrif Apr 23, 2016

Author Contributor

Gotcha. Thanks for the link. I'm also interested because I would like to use this in Diesel as a workaround until this (hopefully) is accepted and in stable

[design]: #detailed-design

This RFC proposes adding `lifetime` as an additional specifier to
`macro_rules!` (alternatively: `life` or `lt`). Since a lifetime acts very much

This comment has been minimized.

Copy link
@brendanzab

brendanzab Apr 23, 2016

Member

lt might be confused with 'literal', if it were ever added.

Also, perhaps these other names could be moved to the # Alternatives section?

This comment has been minimized.

Copy link
@sgrif

sgrif Apr 23, 2016

Author Contributor

Are differing names an alternative to the RFC? Seems like it's a detail of the RFC itself. And yeah, I'm strongly in favor of lifetime as the name

This comment has been minimized.

Copy link
@bluss

bluss Apr 23, 2016

I agree that the long word lifetime seems good. I don't see a reason to save letters here.

@pnkfelix pnkfelix added the T-lang label Apr 23, 2016

@durka

This comment has been minimized.

Copy link
Contributor

commented Apr 23, 2016

I know it's in the implementation, but the follow set for the matcher is probably a detail that should be in the RFC (and possibly included as a delta to RFC 550 as well).

@Diggsey

This comment has been minimized.

Copy link
Contributor

commented Apr 25, 2016

I wrote a PR for this a while back and @alexcrichton mentioned that lifetime might become a keyword, which would cause problems. Is that still the case?

@durka

This comment has been minimized.

Copy link
Contributor

commented Apr 25, 2016

I don't think we can really make new non-contextual keywords anymore. And I don't see the ambiguity anyway if there were to be a matcher with the same name as a keyword.

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

commented Apr 28, 2016

I'm nominating this for discussion as a "fast track for FCP" thing. However, I also think we should add a note about the follow-set (though it is mostly implied by the comparison to identifier).

@sgrif

This comment has been minimized.

Copy link
Contributor Author

commented Apr 28, 2016

Updated to mention the follow-set

@pnkfelix

This comment has been minimized.

Copy link
Member

commented Apr 28, 2016

(another potential way to denote the bound could be 'ident. As in $lifetime:'ident)

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

commented May 6, 2016

We discussed this RFC in the previous @rust-lang/lang meeting. We all agree this is a pretty harmless addition, but for one concern: there remains some lingering concern among us that the term lifetime may not have been the best choice. Specifically, there is this ambiguity between the lifetime of a value -- i.e., when the destructor will run, which I tend to call the value's scope -- and the lifetime of a reference -- the region of the code where the reference will be used. To make matters just a bit more confusing, these two notions of lifetime are interrelated -- specifically, you can't make a reference to a value for longer than the value's scope.

Up till now the term reference, while firmly entrenched in our documentation and blog posts, hasn't been in the language itself (though it does appear in the associated items RFC; but that was never implemented -- something we ought to fix, but then of course we'd run into the same problem). That said, this may well be a distinction without a difference.

I have to admit I feel pretty terrible holding up this otherwise unobjectionable RFC on this matter, since it's kind of an amorphous concern with no clear resolution. This is one reason we were brainstorming other possible syntaxes, such as 'ident (or maybe even ident?).

I was thinking now though that there is though another possible way to view things which might make the name lifetime perfectly acceptable. That is, one could coin a term representing the region of the code where a reference is used -- candidates might be calling it the reference's region, or extent, or the duration of a borrow. In that case, the term lifetime is kind of a "superset" of these things: a scope is a lifetime, but so is a region. Not sure yet if that's a useful way to think about things.

Anyway, those were our concerns.

@durka

This comment has been minimized.

Copy link
Contributor

commented May 6, 2016

This is about syntax. A macro isn't manipulating the validity region of a reference or the destruction scope of a value or anything like that. Everyone calls the 'a syntax a "lifetime" or a "lifetime specifier" or a "lifetime annotation". This includes libsyntax, and the compiler's error messages :)

$x:'ident would be fine too, and avoid naming considerations!

@durka

This comment has been minimized.

Copy link
Contributor

commented May 6, 2016

Amusingly, the macro macro_rules! m { ($x:'ident) => {} } parses today, and there's no error until you try to invoke it.

@bluss

This comment has been minimized.

Copy link

commented May 6, 2016

Maybe this fact can inspire new names: Loop labels use the same syntax.

@sgrif

This comment has been minimized.

Copy link
Contributor Author

commented May 7, 2016

I definitely think 'ident would be fine as well, but I'm not sure how
painful that would be for implementation.

On Fri, May 6, 2016, 6:38 PM bluss notifications@github.com wrote:

Maybe this fact can inspire new names: Loop labels use the same syntax.


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#1590 (comment)

@bluss

This comment has been minimized.

Copy link

commented May 7, 2016

lifetime is good (named for a lifetime parameter), you could also call it just label (named for a loop label). I think using 'ident is too irregular, and would be another oddity in an already odd macro_rules world.

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

commented May 9, 2016

Yes, this was intentional, because we intended to (and I think still
vaguely intend) allow users to manually label blocks as a way to provide
explicit lifetime names. For example:

let x;
let y;
'a: {
    x = &'a y; // (error)
}

On Fri, May 06, 2016 at 04:38:01PM -0700, bluss wrote:

Maybe this fact can inspire new names: Loop labels use the same syntax.


You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#1590 (comment)

@durka

This comment has been minimized.

Copy link
Contributor

commented May 14, 2016

Is there any hope of un-stalling this? Several ideas have been proposed to solve the trivial naming issue which is blocking the RFC (ignore it and use :lifetime / use :'ident instead / make up a new name like :label or :region). Does the lang team like any of them or shall we continue painting the bike shed?

@bluss

This comment has been minimized.

Copy link

commented May 14, 2016

lifetime is short for lifetime parameter. Does the lang team want to coin a new name for that one? Otherwise i think lifetime should just be the name.

@pnkfelix

This comment has been minimized.

Copy link
Member

commented May 16, 2016

@durka I talked with @nikomatsakis last week about this. I suspect at this point that we are likely to bite the bullet and just accept :lifetime here. I think we agreed that the term "lifetime" is too entrenched at this point for us to expect to actually change it across the board.

Renominating for discussion at lang-team mtg.

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

commented May 20, 2016

We discussed in the @rust-lang/lang meeting. We came to the conclusion that we should just go with the term "lifetime". Hence we are nominating this for final comment period.

My personal feeling is that I would like to have three terms:

  • "lifetime" -- means some span in the code; a portion of the control-flow-graph;
  • "scope" -- the lifetime corresponding to a lexical scope or statement; this corresponds to when things can be named, but also when destructors will run
  • "extent" (maybe) -- the lifetime corresponding to where a reference is used. When you borrow some value, that borrow has an extent which is defined by how long the resulting reference (and any references derived from it) wind up being used.

Right now we tend to call all 3 of these lifetimes, so I am roughly proposing keeping that in place, but adding some more specific terms for two distinct concepts. I am not quite sure what that third term ought to be, though: I vacillate between "extent", "region", "duration", and a few other such words. I hope that in most docs and error messages though we can get away with not needing to use it, so maybe it's just a term that we use when trying to explain the type system at a more advanced level.

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

commented May 20, 2016

Hear ye, hear ye! This RFC is now entering final comment period.

@durka

This comment has been minimized.

Copy link
Contributor

commented Jun 1, 2016

FCP should be over soon, yeah?

@aturon

This comment has been minimized.

Copy link
Member

commented Jun 1, 2016

@durka

Yes -- the lang meeting wound up cancelled last week, but we should have a final decision on Thursday. Sorry or the delay!

@durka

This comment has been minimized.

Copy link
Contributor

commented Jun 15, 2016

This is getting a bit ridiculous.

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

commented Jun 16, 2016

Actually, the problem is my fault. The @rust-lang/lang team did discuss this and decided to accept it some time back (a week or so) -- but i've been overwhelmed and failed to follow up on my clerical duties! I do apologize.

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

commented Jun 16, 2016

Huzzah! The @rust-lang/lang team has decided to accept this RFC.

@durka

This comment has been minimized.

Copy link
Contributor

commented Jun 16, 2016

Woohoo!

@chriskrycho chriskrycho referenced this pull request Mar 29, 2017

Closed

Document all features #9

18 of 48 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.