Add a lifetime specifier to macro_rules!

[sgrif]

Rendered

[bluss]

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)

[sgrif]

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.

[sgrif]

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

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

[bluss]

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

[bluss]

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.

[bluss]

Here's the reparse trick. https://play.rust-lang.org/?gist=3287a8aab3bea913916f56d12c7a00ad&version=stable&backtrace=0

[sgrif]

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

[brendanzab]

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

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

[sgrif]

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

[bluss]

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

[durka]

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]

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]

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]

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]

Updated to mention the follow-set

[pnkfelix]

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

[nikomatsakis]

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 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]

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

[bluss]

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

[sgrif]

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]

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]

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]

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]

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]

@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]

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]

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

[durka]

FCP should be over soon, yeah?

[aturon]

@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 is getting a bit ridiculous.

[nikomatsakis]

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]

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

[durka]

Woohoo!