# \[Accepted\] SE-0402: Generalize \`conformance\` macros as \`extension\` macros

**URL:** <https://forums.swift.org/t/accepted-se-0402-generalize-conformance-macros-as-extension-macros/66276>\
**Category:** Announcements\
**Created:** [July 20, 2023, 7:37pm UTC](https://forums.swift.org/t/accepted-se-0402-generalize-conformance-macros-as-extension-macros/66276 "2023-07-20T19:37:02Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\
**Post date:** [July 20, 2023, 7:37pm UTC](https://forums.swift.org/t/accepted-se-0402-generalize-conformance-macros-as-extension-macros/66276/1 "2023-07-20T19:37:02Z")

</div>

Hello, everyone. The [review](https://forums.swift.org/t/se-0402-generalize-conformance-macros-as-extension-macros/65965) of [SE-0402](https://github.com/apple/swift-evolution/blob/main/proposals/0402-extension-macros.md) ran from July 3rd to the 17th. Overall feedback was light but positive. Comments on the review were mostly limited to questions about the behavior, some of which may lead to future work, but the Language Steering Group feels that the proposal represents progress as it is and doesn't need to be held up. Accordingly, SE-0402 has been **accepted**.

As always, I'd like to thank the community for participating in the evolution process.

John McCall  
Review Manager

---

<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:** [July 20, 2023, 8:24pm UTC](https://forums.swift.org/t/accepted-se-0402-generalize-conformance-macros-as-extension-macros/66276/2 "2023-07-20T20:24:01Z")

</div>

Was there any discussion regarding this point?

> [@SE-0402: Generalize \`conformance\` macros as \`extension\` macros](https://forums.swift.org/t/se-0402-generalize-conformance-macros-as-extension-macros/65965/11):
>
> We could allow the same `prefixed(X)` and `suffixed(X)` forms in the `conformances` list that we do for `names`, so one can generate a protocol and a conformance to it together, with a name derived from the entity to which the macro is attached.

I believe that accepting the proposal as is would block this possibility from being a future direction, because the conformance names are currently listed directly under `conformances ` instead of being embedded in `named(…)` as it is for `names`.

---

<div class="post-metadata">

**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\
**Post date:** [July 20, 2023, 8:25pm UTC](https://forums.swift.org/t/accepted-se-0402-generalize-conformance-macros-as-extension-macros/66276/3 "2023-07-20T20:25:32Z")

</div>

I believe the idea is that you could write `prefixed(Foo)` in the `conformances` clause; I don’t see why that would be ruled out.

---

<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:** [July 20, 2023, 8:32pm UTC](https://forums.swift.org/t/accepted-se-0402-generalize-conformance-macros-as-extension-macros/66276/4 "2023-07-20T20:32:20Z")

</div>

If this is technically no issue, then it will suffice. Still, I believe this could be a rough edge when the two APIs work differently.

---

<div class="post-metadata">

**Author:** ![blindspotbounty](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/blindspotbounty/32/44760_2.png) [@blindspotbounty](https://forums.swift.org/u/blindspotbounty)\
**Post date:** [July 25, 2023, 4:48pm UTC](https://forums.swift.org/t/accepted-se-0402-generalize-conformance-macros-as-extension-macros/66276/5 "2023-07-25T16:48:50Z")

</div>

Thank you for the improvement. It looks much better now.

However I found that it became impossible to generate arbitrary conformance now that is required inplace or conformance to some protocol(s) that are not defined by the moment of defining macro.

For example, previously it could be used in some situations, e.g.  
Marco definition:

```swift
@attached(conformance)
@attached(peer, names: arbitrary)
public macro GenProtocolAndConformance(_: String) = #externalMacro(...)

```

That could expand the following code:

```swift
@GenProtocolAndConformance("MyProtocol")
public struct MyStruct {
    var var1: Int
    
    func foo() {
        // do stuf
    }
    // ...
}

```

To:

```swift
public struct MyStruct {
    var var1: Int
    
    func foo() {
        // do stuf
    }
    // ...
}

// Expands to
protocol MyProtocol {
    var var1: Int
    
    func foo()
}

extension MyStruct : MyProtocol {}

```

If I understand correctly, now it is impossible. I've tried to do it with both: extension and peer macro. With extension I can't define unknown protocol and with peer macro I have the following error:

```swift
error: macro expansion cannot introduce extension

```

Not sure if it should be addressed here (please let me know if this is a wrong place).

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [July 25, 2023, 5:56pm UTC](https://forums.swift.org/t/accepted-se-0402-generalize-conformance-macros-as-extension-macros/66276/6 "2023-07-25T17:56:46Z")

</div>

> [@\[Update\] Restrictions on Arbitrary Names at Global Scope in SE-0389 and SE-0397](https://forums.swift.org/t/update-restrictions-on-arbitrary-names-at-global-scope-in-se-0389-and-se-0397/66289):
>
> Hi folks, After the acceptance of SE-0389 and SE-0397, [further implementation work](https://github.com/apple/swift/pull/66532) showed that allowing macros to introduce arbitrary names at global scope is fundamentally prone to creating cycles during type resolution. When performing unqualified name lookup, the compiler must expand all macros that produce arbitrary names, but such a macro may also have arguments that must be type-checked prior to expansion, and doing so would require expanding the very same macro. This limitation is not a…