-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
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. | ||
|
||
# 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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Also, perhaps these other names could be moved to the There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree that the long word |
||
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 |
There was a problem hiding this comment.
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 bytt
. 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)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's the reparse trick. https://play.rust-lang.org/?gist=3287a8aab3bea913916f56d12c7a00ad&version=stable&backtrace=0
There was a problem hiding this comment.
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