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

sgrif · 2016-04-22T20:59:07Z

bluss · 2016-04-23T13:14:35Z

text/0000-macro-lifetimes.md

+
+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.


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)

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.

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

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

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

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.

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

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 · 2016-04-23T16:13:39Z

text/0000-macro-lifetimes.md

+[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


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

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

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

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

durka · 2016-04-23T17:44:45Z

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 · 2016-04-25T15:04:25Z

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 · 2016-04-25T15:40:27Z

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 · 2016-04-28T00:10:56Z

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 · 2016-04-28T00:14:07Z

Updated to mention the follow-set

pnkfelix · 2016-04-28T21:30:31Z

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

nikomatsakis · 2016-05-06T22:37:31Z

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 · 2016-05-06T22:56:08Z

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 · 2016-05-06T23:00:06Z

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

bluss · 2016-05-06T23:37:53Z

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

sgrif · 2016-05-07T00:05:48Z

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 [email protected] 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 · 2016-05-07T00:38:18Z

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 · 2016-05-09T10:18:06Z

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 · 2016-05-14T17:12:23Z

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 · 2016-05-14T17:38:51Z

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 · 2016-05-16T12:29:04Z

@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 · 2016-05-20T18:56:32Z

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 · 2016-05-20T18:56:36Z

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

durka · 2016-06-01T15:12:10Z

FCP should be over soon, yeah?

aturon · 2016-06-01T15:23:32Z

@durka

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

durka · 2016-06-15T22:37:56Z

This is getting a bit ridiculous.

nikomatsakis · 2016-06-16T08:22:57Z

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 · 2016-06-16T08:23:11Z

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

durka · 2016-06-16T14:25:46Z

Woohoo!

Add a lifetime specifier to macro_rules!

08a98b4

sgrif mentioned this pull request Apr 22, 2016

Allow lifetimes to be passed to macros rust-lang/rust#33135

Closed

bluss reviewed Apr 23, 2016
View reviewed changes

Note that tt can be used to match a lifetime

942c40e

brendanzab reviewed Apr 23, 2016
View reviewed changes

pnkfelix added the T-lang Relevant to the language team, which will review and decide on the RFC. label Apr 23, 2016

nikomatsakis added the I-nominated label Apr 28, 2016

Add an explicit mention of the follow rules for the specifier

17d68e5

nikomatsakis assigned pnkfelix Apr 28, 2016

nikomatsakis removed the I-nominated label May 5, 2016

pnkfelix added the I-nominated label May 16, 2016

nikomatsakis added the final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. label May 20, 2016

nikomatsakis removed the I-nominated label May 20, 2016

nikomatsakis mentioned this pull request Jun 16, 2016

Tracking issue for adding a lifetime specifier to macro_rules! rust-lang/rust#34303

Closed

nikomatsakis merged commit 17d68e5 into rust-lang:master Jun 16, 2016

Phlosioneer mentioned this pull request Jun 21, 2016

Macro lifetimes aren't a thing (yet) rust-bakery/nom#268

Closed

chriskrycho mentioned this pull request Mar 29, 2017

Document all features rust-lang/reference#9

Closed

48 tasks

Centril added A-macros Macro related proposals and issues A-syntax Syntax related proposals & ideas labels Nov 23, 2018

jeberger mentioned this pull request Oct 16, 2019

Add the lifetime capture type DanielKeep/tlborm#39

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

sgrif commented Apr 22, 2016 •

edited

Loading

bluss Apr 23, 2016

sgrif Apr 23, 2016

sgrif Apr 23, 2016

bluss Apr 23, 2016 •

edited

Loading

bluss Apr 23, 2016

bluss Apr 23, 2016

sgrif Apr 23, 2016

brendanzab Apr 23, 2016 •

edited

Loading

sgrif Apr 23, 2016

bluss Apr 23, 2016

durka commented Apr 23, 2016

Diggsey commented Apr 25, 2016

durka commented Apr 25, 2016

nikomatsakis commented Apr 28, 2016

sgrif commented Apr 28, 2016

pnkfelix commented Apr 28, 2016

nikomatsakis commented May 6, 2016

durka commented May 6, 2016 •

edited

Loading

durka commented May 6, 2016

bluss commented May 6, 2016

sgrif commented May 7, 2016

bluss commented May 7, 2016

nikomatsakis commented May 9, 2016

durka commented May 14, 2016 •

edited

Loading

bluss commented May 14, 2016

pnkfelix commented May 16, 2016

nikomatsakis commented May 20, 2016

nikomatsakis commented May 20, 2016

durka commented Jun 1, 2016

aturon commented Jun 1, 2016

durka commented Jun 15, 2016

nikomatsakis commented Jun 16, 2016 •

edited

Loading

nikomatsakis commented Jun 16, 2016

durka commented Jun 16, 2016

Add a lifetime specifier to macro_rules! #1590

Add a lifetime specifier to macro_rules! #1590

Conversation

sgrif commented Apr 22, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bluss Apr 23, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

brendanzab Apr 23, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

durka commented Apr 23, 2016

Diggsey commented Apr 25, 2016

durka commented Apr 25, 2016

nikomatsakis commented Apr 28, 2016

sgrif commented Apr 28, 2016

pnkfelix commented Apr 28, 2016

nikomatsakis commented May 6, 2016

durka commented May 6, 2016 • edited Loading

durka commented May 6, 2016

bluss commented May 6, 2016

sgrif commented May 7, 2016

bluss commented May 7, 2016

nikomatsakis commented May 9, 2016

durka commented May 14, 2016 • edited Loading

bluss commented May 14, 2016

pnkfelix commented May 16, 2016

nikomatsakis commented May 20, 2016

nikomatsakis commented May 20, 2016

durka commented Jun 1, 2016

aturon commented Jun 1, 2016

durka commented Jun 15, 2016

nikomatsakis commented Jun 16, 2016 • edited Loading

nikomatsakis commented Jun 16, 2016

durka commented Jun 16, 2016

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

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

sgrif commented Apr 22, 2016 •

edited

Loading

bluss Apr 23, 2016 •

edited

Loading

brendanzab Apr 23, 2016 •

edited

Loading

durka commented May 6, 2016 •

edited

Loading

durka commented May 14, 2016 •

edited

Loading

nikomatsakis commented Jun 16, 2016 •

edited

Loading