Add a `literal` fragment specifier to `macro_rules!`.

[LeoTestard]

Add a literal fragment specifier for macro_rules! patterns that matches literal constants.

Rendered

[pnkfelix]

The Design section should be expanded to specify what is the set of literal constants that you are adding here.

(I.e. the fact that you are adding the clarifying aside "in this context, I mean ..." in the drawbacks section is a bad sign -- the design section should have enough information for someone to deduce what you mean by "literal".)

[bluss]

I've been missing this, for example in a macro that uses consecutive integer literals like shuffle![v, 1 2 3 4]. You can work around it using tt.

[DanielKeep]

Aye; there's an important alternative not mentioned in the RFC: use tt instead.

The problem I can see with this proposal is that it doesn't really simplify existing macros, nor open up new ones. The lack of backtracking means that even if this matcher is more specific than tt, it won't permit macros that wouldn't have been expressible before.

This will probably give better error messages on matching failures, but nothing else I can think of. No, wait, it does have one advantage over tt: you won't need the reparse trick, since you should be able to assume a literal is an expression. ... still not sure that's enough to pull its weight, though.

[LeoTestard]

@DanielKeep The weight should be that big. And backtracking is coming with rust-lang/rust#33840. The better error messages are a big gain. :/

[LeoTestard]

(Edited to mention the possibility of using tt.)

[nrc]

cc @jseyfried in case you have an opinion on this

[nrc]

also cc @cswords

[nrc]

I'm in favour of this, though slightly (and vaguely) worried about the implementation details

[jseyfried]

I'm also in favour of this.

I don't think implementation will be a problem, but I'm not too familiar with the details of how fragments are implemented.

n.b. the reparse trick is no longer needed, so that's no longer an advantage over tt.

[nikomatsakis]

Hear ye, hear ye! This RFC is now entering final comment period. We discussed this at the most recent @rust-lang/lang meeting and decided that we are currently inclined to accept (of course no final decision has been reached).

To summarize the discussion so far:

• one can currently use tt for this purpose, but the error messages are less good

[joshtriplett]

I like this RFC.

Would it make sense to also have more specific versions for specific kinds of literals? Several times, I've wanted to have a macro accept a string literal specifically.

[LeoTestard]

I don't think implementation will be a problem, but I'm not too familiar with the details of how fragments are implemented.

It's actually very simple, it just calls the parse_whatever() functions from libsyntax::parse::parser.

• one can currently use tt for this purpose, but the error messages are less good

And the future-proofing is less good too. Using a more specific matcher restricts the FIRST sets, which is good.

Would it make sense to also have more specific versions for specific kinds of literals? Several times, I've wanted to have a macro accept a string literal specifically.

I guess it would make sense, though the gain in terms of error messages is small. I'm not sure if it's possible though, since I think the libsyntax parser has a single parsing function for all literal types. It can surely be refactored and split into several functions, but I'm not sure it's worth it.

[nikomatsakis]

Would it make sense to also have more specific versions for specific kinds of literals? Several times, I've wanted to have a macro accept a string literal specifically.

Yeah, I wondered the same. Could be useful, but I guess there is value in "any literal" as well, and it's something we could easily add later.

[joshtriplett]

@nrc Absolutely! To clarify, I'd love to see the proposed RFC accepted, and I don't want to bikeshed it. I'd also love to see specifiers for specific types of literals, which could either go in this RFC or a future RFC.

[nikomatsakis]

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

[nikomatsakis]

Tracking issue: rust-lang/rust#35625

If you'd like to keep following the development of this feature, please subscribe to that issue, thanks! :)

[da-x]

Dear all, the implementation is now in master :)

[pravic]

Is there any link to a rendered version?