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

LeoTestard · 2016-04-08T12:07:24Z

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

pnkfelix · 2016-04-08T12:25:45Z

text/0000-macros-literal-matcher.md

+
+# Drawbacks
+
+This is a bit inconsistent since it does not include all literal constants (in this context, I mean ‶literals that do not require any computation″): indeed it does not include compound literals, for example struct literals `Foo { x: some_literal, y: some_literal }` or arrays `[some_literal ; N]`, where `some_literal` can itself be a compound literal. See in alternatives why this is disallowed.


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 · 2016-04-11T10:10:48Z

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 · 2016-04-11T12:46:57Z

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 · 2016-06-02T15:48:32Z

@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 · 2016-06-02T15:53:25Z

(Edited to mention the possibility of using tt.)

nrc · 2016-08-04T20:26:06Z

cc @jseyfried in case you have an opinion on this

nrc · 2016-08-04T20:26:52Z

also cc @cswords

nrc · 2016-08-04T20:27:25Z

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

jseyfried · 2016-08-04T22:53:43Z

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 · 2016-08-08T18:03:55Z

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 · 2016-08-10T07:20:50Z

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 · 2016-08-10T13:07:29Z

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 · 2016-08-11T20:41:25Z

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 · 2016-08-11T23:55:14Z

@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 · 2016-08-12T20:31:33Z

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

nikomatsakis · 2016-08-12T20:33:32Z

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 · 2018-05-13T20:12:36Z

Dear all, the implementation is now in master :)

LeoTestard force-pushed the master branch 4 times, most recently from 5fa69f4 to 5c67bc0 Compare April 8, 2016 12:20

pnkfelix reviewed Apr 8, 2016
View reviewed changes

LeoTestard force-pushed the master branch 2 times, most recently from 8d9a531 to 7e55f54 Compare April 8, 2016 13:00

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

nikomatsakis assigned pnkfelix Apr 21, 2016

nikomatsakis mentioned this pull request Apr 22, 2016

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

Closed

bluss mentioned this pull request Apr 23, 2016

Add a lifetime specifier to macro_rules! #1590

Merged

LeoTestard force-pushed the master branch from 7e55f54 to 8d29a57 Compare June 2, 2016 15:52

Add a literal fragment specifier to macro_rules!.

09aa1d6

LeoTestard force-pushed the master branch from 8d29a57 to 09aa1d6 Compare June 2, 2016 15:53

aturon added the I-nominated label Jul 28, 2016

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

nrc removed the I-nominated label Aug 11, 2016

nikomatsakis mentioned this pull request Aug 12, 2016

Tracking issue for literal fragment specifier (RFC 1576) rust-lang/rust#35625

Closed

nikomatsakis merged commit 09aa1d6 into rust-lang:master Aug 12, 2016

chriskrycho mentioned this pull request Mar 29, 2017

Document all features rust-lang/reference#9

Closed

48 tasks

Centril mentioned this pull request Oct 18, 2017

RFC: Quick dbg!(expr) macro #2173

Closed

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

This comment has been minimized.

Sign in to view

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

LeoTestard commented Apr 8, 2016 •

edited by Centril

Loading

pnkfelix Apr 8, 2016

bluss commented Apr 11, 2016

DanielKeep commented Apr 11, 2016

LeoTestard commented Jun 2, 2016

LeoTestard commented Jun 2, 2016

nrc commented Aug 4, 2016

nrc commented Aug 4, 2016

nrc commented Aug 4, 2016

jseyfried commented Aug 4, 2016 •

edited

Loading

nikomatsakis commented Aug 8, 2016

joshtriplett commented Aug 10, 2016

LeoTestard commented Aug 10, 2016

nikomatsakis commented Aug 11, 2016

joshtriplett commented Aug 11, 2016

nikomatsakis commented Aug 12, 2016

nikomatsakis commented Aug 12, 2016

da-x commented May 13, 2018

This comment has been minimized.


		# Drawbacks

		This is a bit inconsistent since it does not include all literal constants (in this context, I mean ‶literals that do not require any computation″): indeed it does not include compound literals, for example struct literals `Foo { x: some_literal, y: some_literal }` or arrays `[some_literal ; N]`, where `some_literal` can itself be a compound literal. See in alternatives why this is disallowed.

Add a literal fragment specifier to macro_rules!. #1576

Add a literal fragment specifier to macro_rules!. #1576

Conversation

LeoTestard commented Apr 8, 2016 • edited by Centril Loading

pnkfelix Apr 8, 2016

Choose a reason for hiding this comment

bluss commented Apr 11, 2016

DanielKeep commented Apr 11, 2016

LeoTestard commented Jun 2, 2016

LeoTestard commented Jun 2, 2016

nrc commented Aug 4, 2016

nrc commented Aug 4, 2016

nrc commented Aug 4, 2016

jseyfried commented Aug 4, 2016 • edited Loading

nikomatsakis commented Aug 8, 2016

joshtriplett commented Aug 10, 2016

LeoTestard commented Aug 10, 2016

nikomatsakis commented Aug 11, 2016

joshtriplett commented Aug 11, 2016

nikomatsakis commented Aug 12, 2016

nikomatsakis commented Aug 12, 2016

da-x commented May 13, 2018

This comment has been minimized.

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

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

LeoTestard commented Apr 8, 2016 •

edited by Centril

Loading

jseyfried commented Aug 4, 2016 •

edited

Loading