I’ve been working on some macros for dependency injection recently and was incredibly frustrated by the restriction that extension macros must “forward-declare” the protocol conformances they intend to add.
Not only this, but unlike other macro types, you can’t use suffixed(MyProtocol) so it is impossible to make a macro that generates a protocol declaration and conforms to it.
This has led me to a couple of annoying workarounds like creating a private proxy class that conforms to the protocol, or forcing the user to manually conform to the protocol generated by the macro (which they can’t see unless they expand the macro).
This limitation feels entirely arbitrary. In fact, I believe you could add arbitrary protocol conformances in some beta Xcode versions. Other macros are able to generate conflicting declarations, so why are protocol conformances special?
Expansion of macros during compilation is somewhat expensive because it requires launching your plugin’s executable. If the macro declaration didn’t declare the list of protocol conformances it would add, the compiler would always need to expand your macro when deciding whether a type with a macro conforms to a protocol. With the list of protocol conformances that the macro might add in the macro’s definition, the compiler can avoid the macro expansion if the protocol is not mentioned in the macro’s definition, which significantly helps compilation time and intelligent functionality in source editors / IDEs that rely on the type checker. That’s also the reason why you need to list the names of all the members that a member macro may add.
Regarding your use case of creating a macro and then making a type conform to it, I think that would be a good idea to pitch.