[Pitch] Generalize `conformance` macros as `extension` macros

[Tim.Wang]

This is a great pitch. Thanks for making it happen.

Could we also consider to support this kind of extension below? Since this is to extend system type, the attached extension macro cannot be used. But as we can see the code below, this pattern follows a very strict pattern, which made it a great candidate for using macro. Thanks.

extension EnvironmentValues {
    var myCustomValue: String {
        get { self[MyEnvironmentKey.self] }
        set { self[MyEnvironmentKey.self] = newValue }
    }
}


extension View {
    func myCustomValue(_ myCustomValue: String) -> some View {
        environment(\.myCustomValue, myCustomValue)
    }
}

[beccadax (Becca Royal-Gordon)]

@jaredh159

apologies if this is a dumb question, but after looking over the pitch, i'm still not clear on one thing: will extension macros be able to declare conformances, and then implement them while still having access to the type members?

Yes. In the signature Holly mentioned:

@hborla

  static func expansion(
    of node: AttributeSyntax,
    attachedTo declaration: some DeclGroupSyntax
    providingExtensionsOf type: TypeSyntax,
    in context: some MacroExpansionContext
  ) throws -> [ExtensionDeclSyntax]

node would be the attribute for your macro, declaration would be the type or extension your attribute is attached to (including its members), and type would be the name of the type your extension is supposed to extend. The method would then return zero or more extensions of type, and will be able to examine the contents of declaration and node while it generates those extensions. Both the extension’s conformance list and its members will be generated at the same time.

[Tim.Wang]

Can we have something like this for this purpose?

@freestanding(extension(EnvironmentValues.self), names: named(myCustomValue))
public macro macroName... = #externalMacro(module: "...", type: "...")

[s-k (Stephen Kockentiedt)]

I think this pitch is great! I believe it would allow a feature such as Codable to be implemented as a macro without the need for the macro to reimplement the default initializer.

Will extension macros be allowed to be attached to extensions like this?

@MyMacro extension View {}

[Helge_Hess1 (Helge Heß)]

BTW: The link to the draft (named "here") is b0rked.

[hborla (Holly Borla)]

Probably because I accidentally deleted my branch after it was merged to swift-evolution. This proposal has been reviewed and the document is at https://github.com/apple/swift-evolution/blob/main/proposals/0402-extension-macros.md

[taylorswift]

@beccadax

@jaredh159

apologies if this is a dumb question, but after looking over the pitch, i'm still not clear on one thing: will extension macros be able to declare conformances, and then implement them while still having access to the type members?

Yes. In the signature Holly mentioned:

okay, i know the proposal has been accepted already, but i’m running into a similar problem with extension macros, where i have a huge list of names i’m currently passing directly to the attached macro attribute, and i would really rather the list of names live elsewhere, preferably in an extension block in a different file.

as far as i can tell, the attachedTo:some DeclGroupSyntax argument only contains the main declaration block the attribute is attached to, and the attribute itself can only be attached to the main declaration block.

as far as i understand, there is nowhere this giant list of constant data can live, except inline at the top of the main declaration of the type it’s attached to, which is pretty much the worst possible place it could be.