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
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 49 additions & 0 deletions text/0000-macro-lifetimes.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
- Feature Name: Allow `lifetime` specifiers to be passed to macros
- Start Date: 2016-04-22
- RFC PR: (leave this empty)
- Rust Issue: (leave this empty)

# Summary
[summary]: #summary

Add a `lifetime` specifier for `macro_rules!` patterns, that matches any valid
lifetime.

# Motivation
[motivation]: #motivation

Certain classes of macros are completely impossible without the ability to pass
lifetimes. Specifically, anything that wants to implement a trait from inside of
a macro is going to need to deal with lifetimes eventually. They're also
commonly needed for any macros that need to deal with types in a more granular
way than just `ty`.

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

Copy link
Member

@bluss bluss Apr 23, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


# Detailed design
[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
Copy link
Member

@brendanzab brendanzab Apr 23, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

like an identifier, and can appear in almost as many places, it can be handled
almost identically. A preliminary implementation can be found at
https://github.com/rust-lang/rust/pull/33135

# Drawbacks
[drawbacks]: #drawbacks

None

# Alternatives
[alternatives]: #alternatives

A more general specifier, such as a "type parameter list", which would roughly
map to `ast::Generics` would cover most of the cases that matching lifetimes
individually would cover.

# Unresolved questions
[unresolved]: #unresolved-questions

None