Rfcs: Extend macro_rules! to make macros with pre-bracket items

[Nokel81]

Currently the macro_rules macro is used as the following:

macro_rules! name {
    pattern => code;
    ...
}

Which produces a macro that is used: name!{pattern}.

This proposal would allow for syntax within the macro_rules! macro creator for macros that have some patterns before the initial brackets. I think that it would also be nice if it was possible to control which of the three {}, [], () bracket types were allowed to be used with the with the macro, by default all three would be allowed.

As more information was requested, read below:

Motivation:
For some macros it would make sense for there to be a visual distinction between some parts of the macro. These are generally identifiers or other similar overarching aspects of them.

Explanation:
This is a proposal to facilitate both allowing some pattern matching before the start of the main brackets as well as which type(s) of brackets are allowed to be used. This would act similarly to how the macro_rules macro works where the identifier of the new macro is situated before the start of the brackets that contain the pattern branches.

Example:
Maybe not the best example but I believe that it shows the point rather well

unless! item.is_empty() { continue; }

Instead of something like the following (what is currently available easily):

unless! { item.is_empty() -> { continue; } }

[Centril]

What proposal? This is issue very light on detail making it impossible to understand what is proposed..

[Nokel81]

@Centril I have added some additional material

[Centril]

A few questions:

1. How do you specify what parts are allowed before the main brackets?
2. What macro fragments are allowed before the main brackets?
3. Do we want to extend macro_rules further given macros 2.0?
4. Would this not lead to not being able to parse tokens ahead of the macro invocation into AST nodes without checking the macro definition? That could potentially make parsing a lot more expensive? This depends on question 2.

[Nokel81]

1. That, I believe would be made by an extensions to the pattern syntax. For each optional pattern an optional prefix of some kind would be allowed.
2. Originally I was thinking any tokens but without repetition, I know believe (re: 1) that it would not matter
3. Maybe not but this might just turn into a proposition for what is possible with the new macros, having read the RFC I don't know if I am convinced of the benefits but even if this isn't implemented within macro_rules I believe that it should be easily accessible
4. Part 1 see answer 1. Part two, if by expensive you mean time consuming then yes it will but only because it is doing more parsing. I don't believe that this will increase the complexity of the parsing since we already know that it is possible and being done

[Centril]

1. Right, but I'm asking for specifics =)
2. Elaborate?
3. Since macros 2.0 is in the roadmap (RFC #2314) for stabilization this year, it seems like the best option to change macros 2.0.
4. Compilation is already slow compared to other languages; granted, not much time is spent in parsing, but should we aggravate the situation? Does the benefits outweigh the costs?

[Nokel81]

1. So I think that all fragments would be allowed. Given that I believe that the place for this would be in each set of patterns it would be able to be expanded.
2. Fair
3. I believe that the benefits do outweigh the costs. Those costs being the possibility of a slightly longer compilation; the benefits being easier to read macro invocations. I believe this not only because the benefits would be, in my opinion, very useful but because the costs are so small. The majority of the cost would come not from the fact of patterns being able to used in more places but because it would be used more. From a parsing time there would be no complexity change.

[Centril]

cc https://github.com/rust-lang/rust/issues/39412