# General Registry: Create tag for macro usage

**URL:** https://discourse.julialang.org/t/general-registry-create-tag-for-macro-usage/104528
**Category:** New to Julia
**Created:** [October 3, 2023, 8:42am UTC](https://discourse.julialang.org/t/general-registry-create-tag-for-macro-usage/104528 "2023-10-03T08:42:22Z")
**Posts on this page:** 1
**Showing post:** 7

<div class="post-metadata">

### Author: ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [October 3, 2023, 1:24pm UTC](https://discourse.julialang.org/t/general-registry-create-tag-for-macro-usage/104528/7 "2023-10-03T13:24:42Z")

</div>

Let’s consolidate this discussion over at the simultaneous #Internals & Design post that’s also about how to handle registry submissions that export macros. This is more of an internals/governance sort of thing than it is #New to Julia.

> [@How to discourage macros: disable automerge of General registry PRs?](https://discourse.julialang.org/t/how-to-discourage-macros-disable-automerge-of-general-registry-prs/104529):
>
> It seems to me that macros are defined much too often in the Julia ecosystem and the (error-prone) definitions of such macros are often very complex. FWIW, the Julia Manual page on metaprogramming already heavily discourages defining macros: eval and defining new macros should be typically used as a last resort. It seems to me that (almost?) the only good way to design a package that includes macros is like this: the macro simply provides some syntax sugar over an actual Julia function, w…

---

_[View the full topic](https://discourse.julialang.org/t/general-registry-create-tag-for-macro-usage/104528)._