[Pitch] Attached macros

[s-k (Stephen Kockentiedt)]

@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:

@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.]