Decide on our long term/ideal goals for macros

[nrc]

Both macro_rules and syntax extensions, and other forms of syntactic fiddling. At the moment I don't have a good sense of what is intentional and what is accidental at the moment. I think these long term goals should inform our choice of what to do for 1.0.

cc @kmcallister @sfackler

[brendanzab]

cc @paulstansifer

[kmcallister]

cc @jbclements

[glaebhoerl]

see also #416

[jbclements]

I strongly agree that we need some consensus here. In particular, it seems like the macro system needs to be an ongoing project for a full-timer....

[paulstansifer]

Off the top of my head:

• Macros ought to be importable and exportable (and able to be referred to with paths, e.g., a::b::c::d!()), and interact with modules in a reasonable way.
• Procedural macros should be refined and made easy-to-use (and, when that happens, the name "syntax extension" can be dropped entirely, we can just call everything a macro)
• Hygiene should be fully implemented (currently, it only applies to let-bound names)
• The macro parser should be able to backtrack out of parsing Rust syntax, and the dreaded local ambiguity: multiple parsing options: errors should go away. macro parser should back out of failed nonterminal parsing rust#3232
• Macro-defining macros should work. macros should be parsed more lazily rust#6994 is one obstacle, but there are others

Less sweeping issues (the line between this and the above is somewhat fuzzy):

• Identifier concatenation should work (I believe that this best way to do this is through a special operator) Can't define a function name using concat_idents!() rust#12249
• macro_rules! foo{() => ()} should become macro_rules!{ foo!() => () }
• We need a way for macros to count the repetitions in a sequence
• We probably need some additional positions to allow macro invocations in (currently, only expression, statement, and item macros are allowed)
• The rule for when to treat a macro invocation as a statement or an expression should be refined.
• The macro parser probably could benefit from a few more features.

[paulstansifer]

I'm currently working on the macro parser issue; unfortunately, I'm also currently working on graduating and at least one other side project, so not much progress has been made recently.

[kmcallister]

currently, only expression, statement, and item macros are allowed

I added patterns a while back.

[paulstansifer]

@kmcallister Awesome; I'm sorry I forgot about that.

[nrc]

A few more (some of which might be plain wrong):

• Syntax extensions allowed in more places
• Separating the macro rules phase from the syntax extensions phase (since syntax extensions can change the module structure, it seems like it would be wrong to rely on module scoping for macros whilst the modules can change)
• allow forward references to macros
• get rid of macro_escape (we should not need it with proper import/export)
• hygiene for crates (name resolution should just work, like it should for modules)
• is name hiding hygienic? Should we support it? Could we have a lint for this?
• macro rules and syntax extensions should be somewhat pluggable - should be possible to switch them for something else or nothing at all, whilst still using the parser parts of libsyntax and the all of librustc

[paulstansifer]

@nick29581

• Syntax extensions in more places is the thing that @kmcallister mentioned having done for patterns.
• I think we should not phase-separate macro_rules macros from procedural macros: instead we should have a macro name resolution system that behaves consistently across all kinds of macros (like Scheme's does).
• I believe that we already have forward references, provided those references are inside a macro definition (i.e., one can define two mutually-recursive macros). We should not allow "top-level" forward references like a!() ; macro_rules a!{ ... }, because this, among other things, would interact poorly with procedural macros (it would reorder their side-effects).
• macro_escape should definitely go away when we have import/export.
• I don't understand exactly what you mean, but I agree that macros be accessible from other crates.
• Is name hiding the same thing as shadowing? I don't think that we need to lint-check whether a macro shadows names, but that's just because I don't have much of an intuition for when that would happen accidentally.
• Pluggable macro_rules (and pluggable procedural macros) should fall out of a proper implementation of procedural macros. In fact, making macro_rules into a procedural macro will be a good testcase for whether we got it right, because it ought to be straightforward when proper procedural (and macro-defining) macros are in place.

[reem]

Also, let the bike shedding begin, but I think macro_rules! should be renamed to macro!. The longer name adds minimal clarity and goes against Rust's short-keyword tendencies.

[kmcallister]

@reem: Me too; it's in the RFC I'm drafting.

[paulstansifer]

@reem I agree, provided that we decide to make macro! be used for defining both procedural and pattern-matching-rules-based macros. If not, we could have macro_rules! and macro_cases! (to mimic Scheme; I like reusing existing naming schemes, even if they're not optimal). I'm not dead set against having macro! and macro_procedural! (or whatever), but it seems less clear.

[reem]

I saw this idea brought up a while back, and it's certainly something we should consider for 1.0:

We could accomplish full macro hygiene by having all bindings other than those generated via input arguments to the macro be resolved in the lexical namespace the macro is defined in, rather than the one it is placed in.

This has certain drawbacks, like using a macro causing you to silently adopt several new dependencies, but is a huge step forward because it would provide total hygiene, whereas today we have all kinds of problems with std/core and things like deriving with Encodable, Decodable, and serialize.

Also, this was brought up on reddit but I'll repeat it here, but a stop-gap for full module namespacing of macros would be to namespace them under crates only and confine them to be define in lib.rs, as that would be forward compatible with full module namespacing in the future.

[kmcallister]

Isn't that really hard to implement, especially cross-crate?