# \[Pitch\] Attached macros

**URL:** <https://forums.swift.org/t/pitch-attached-macros/62812>\
**Category:** Pitches\
**Created:** [January 27, 2023, 1:05am UTC](https://forums.swift.org/t/pitch-attached-macros/62812 "2023-01-27T01:05:59Z")\
**Posts on this page:** 1\
**Showing post:** 14

<div class="post-metadata">

**Author:** ![s-k](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/s-k/32/6796_2.png) [@s-k](https://forums.swift.org/u/s-k)\
**Post date:** [February 16, 2023, 2:11pm UTC](https://forums.swift.org/t/pitch-attached-macros/62812/14 "2023-02-16T14:11:11Z")

</div>

> [@Douglas\_Gregor](#):
>
> Should a macro-generated initializer suppress the default member wise initializer?

I think they should be able to. But I also think they shouldn't be forced to generate their own. ~~Member macros and member attribute macros could just also use the peer macro role to add an additional initializer inside an extension.~~ Accessor macros would probably not need to generate an initializer. This leaves freestanding macros used inside a type declaration and witness macros. I think they should be able to choose if a generated initializer suppresses the default one.

One idea I had was to introduce an attribute:

```swift
@doesNotSuppressDefaultInitializer
init(customArgument: String) {
  ...
}

```

Maybe this attribute could be helpful in other circumstances as well?

* * *

> [@beccadax](#):
>
> But that leads me to wonder, would it be a good idea to allow a `Macro` implementation to somehow signal that a role could not be applied to a particular declaration so that the compiler could apply the same soft "at least one role must be valid" logic to those decisions?

I'm not sure I understand you correctly, but given @Douglas_Gregor's rule you quoted, a macro would simply be able to diagnose an error using `MacroExpansionContext.diagnose()` if it was attached to a declaration it cannot handle.

* * *

> [@beccadax](#):
>
> Should this method at least receive information about the _kind_ of context it's injecting peers into?

I believe this information would be very helpful. However, there are other types of information (conformances, attributes on the type, other members, etc.) that would be equally helpful. I would prefer it if there was a holistic solution to this (sooner rather than later 😅).

[Edit: What I wrote about macros being able to generate extensions is wrong. See my next post.]

---

_[View the full topic](https://forums.swift.org/t/pitch-attached-macros/62812)._