Stream: t-lang

Topic: decl macro syntax

Simon Sapin (Apr 13 2020 at 18:44, on Zulip):

@eddyb I don’t understand re how to use macro with multiple token-matching arms. macro_rules has another nesting level of {…}

eddyb (Apr 13 2020 at 18:48, on Zulip):

@Simon Sapin you write macro instead of macro_rules! (and use , between the arms instead of ;)

eddyb (Apr 13 2020 at 18:48, on Zulip):

the shorthand syntax is optional

eddyb (Apr 13 2020 at 18:48, on Zulip):

as a nicety

eddyb (Apr 13 2020 at 18:49, on Zulip):

macro is rebranded macro_rules!, it's not a different MBE system

Simon Sapin (Apr 13 2020 at 18:54, on Zulip):


Simon Sapin (Apr 13 2020 at 18:55, on Zulip):

Ok, the part I was missing is that there’s a shorthand for single-arm when the macro name is followed by ( instead of {

Simon Sapin (Apr 13 2020 at 18:56, on Zulip):

The shorthand is the only form I’d seen in any example

RalfJ (Apr 13 2020 at 22:49, on Zulip):

Simon Sapin said:


Macros By Example (I guess)

centril (Apr 13 2020 at 23:00, on Zulip):

yeah that's what the initialism stands for

eddyb (Apr 13 2020 at 23:35, on Zulip):

@Simon Sapin yeah, that doesn't help. everyone loves using that form when there's only one arm just because it looks pretty :P

eddyb (Apr 13 2020 at 23:36, on Zulip):

I remember being confused by the , vs ; thing, a few years ago, and thinking macro doesn't support multiple arms

eddyb (Apr 13 2020 at 23:36, on Zulip):

might be good to replace all macro_rules! in the standard library with macros with the attribute @Vadim Petrochenkov mentioned

eddyb (Apr 13 2020 at 23:36, on Zulip):

and we can remove the attribute if/when we're sure it doesn't matter

eddyb (Apr 13 2020 at 23:37, on Zulip):

if nothing else we could try it as a test

mark-i-m (Apr 16 2020 at 15:26, on Zulip):

We ought to document macro better... also, I still think it needs a real RFC

nikomatsakis (Apr 16 2020 at 18:21, on Zulip):

Yeah. @Vadim Petrochenkov pointed to the docs they wrote up on hygiene, and I was thinking it'd be great to dive into those and maybe have a design meeting or something where we try to really hash it out

Vadim Petrochenkov (Apr 16 2020 at 19:19, on Zulip):

macro items have multiple components to figure out before stabilizing, syntactic and semantic:
- Span::def_site, pretty far away, requires implementing cross-crate hygiene at least, and then formalizing stuff in more carefully, in application to type-relative paths in particular.
- Syntax of the macro's left side (macro "parameters"), requires major design work to figure out future-compatibility (currently done with FIRST and FOLLOW sets) and figuring out how to match or not match all arms at the same time.
- Syntax of the macro's right side (macro body), requires a syntax for hygiene opt-out perhaps, maybe simplifying the use of repetitions (, but otherwise seems ok, it's just an arbitrary token stream.
- Surface syntax of the macro. The last year I almost wrote and RFC to set the top-level syntax macro single_arm() {} + macro multiple_arms { (lhs1) {rhs1} (lhs2) {rhs2} } in stone, but them recalled that people wanted the macros want to control what delimiters they are invoked with (e.g. restrict vec![] to only use square brackets), and that added more questions to the surface syntax, and I didn't write anything.

mark-i-m (Apr 17 2020 at 15:46, on Zulip):

@Vadim Petrochenkov thanks for the update! It's probably worth reposting your comment on the tracking issue...

nikomatsakis (Apr 18 2020 at 10:55, on Zulip):

we should move it to the header, even

Last update: Jun 05 2020 at 23:15UTC