Skip to content

[Old Guidelines Revision] Blanket forbiddance of macro usage #367

Description

@felix91gr

This is part of a larger endeavor to fix numerous issues with our Macros chapter.
Go to the index here

There are three rules that I'm grouping into this one issue, because they feel like they kind of fail in the same way.

Please feel free to leave feedback on this!

The three rules are these:

This is the list of problems they have:

  1. They are all empty / stub rules.
    I would love to see what the reasoning is behind them, because one never knows what insights one might find.

    But I digress. They are empty, which means they need to be filled before they can be useful.

  2. "Shall not invoke macros" and "Shall not write code that expands macros" are the same thing. The former is the compile-time behavior of the latter.

  3. The big one: they are blanket prohibitions.

    • Not invoking macros is pretty bad. Making functional Rust code without macros is extremely hard, and I wouldn't be surprised if the resulting code had more errors than the state-of-the art. There's so much code that good macros streamline, that it is kind of a super-power of Rust, for better or worse (mostly for the better).
    • Not using Declarative Macros... well, I mean, you gotta use one of the two kinds of macros, right? And Declarative Macros tend to be the default kind of macro to use. I don't think it's reasonable to forbid the default, unless this default is actively harmful.

So, anyway. I would just Retire these three guidelines. I don't think we can use them.

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingchapter: macroshelp wantedExtra attention is neededquestionFurther information is requested

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions