Extensions for subtype of a class marked @Observable generate compile error

[virasio]

Description
I cannot add a subtype (class, enum, struct) to a class marked with @Observable macro. If I add an extension to this subtype, I get compile error:

Circular reference resolving attached macro 'Observable'

Steps to reproduce

@Observable
class MyObservableClass {
    var property1 = ""
    var property2 = MyClass()
}

extension MyObservableClass {
    class MyClass {
        var property = ""
    }
}

extension MyObservableClass.MyClass {
    var test: String { "test \(property)" }
}

Expected behavior
It must be compilable because the following version is compilible:

@Observable
class MyObservableClass {
    var property1 = ""
    var property2 = MyClass()
}

extension MyObservableClass {
    class MyClass {
        var property = ""
        var test: String { "test \(property)" }
    }
}

Environment
Xcode 15.0 beta (15A5160n)
Swift 5.9
Target: iOS 17.0

[JessyCatterwaul]

@Model has the same problem. Do all macros exhibit it?

[ugoArangino]

@JessyCatterwaul Yes. It's always the same pattern.
TypeA with a Macro
extension type B nested in type A
extension for type B → compile error

[yermukhanbet]

Are there any workarounds for this issue?

[nekno]

One workaround is to place the extension(s) in a separate file.

[juliand665]

Just ran into this as well; here's a perhaps even more minimal example:

@Observable
final class Outer {
    struct Inner {}
}

extension Outer.Inner {}

[mbrandonw]

+1 to this issue being a problem that definitely comes up quite a bit in every day work.

Also, regarding this:

One workaround is to place the extension(s) in a separate file.

This can work most of the time, but sometimes it can be difficult. For example a macro applied to a generic type that needs to conditionally conform to Equatable:

@SomeMacro
struct Wrapper<T> { var value: T }

extension Model: Equatable where T: Equatable {}  // 🛑 Circular reference

If this extension is moved into a separate file then you lose the automatic synthesis of Equatable, and so that is unfortunate.

[li3zhen1]

Add a new case:

enum Namespace {
    @SomeMacro
    struct SomeStruct { }
}

extension Namespace.SomeStruct { }  // 🛑 Circular reference

[ghost]

Hello, any progress here?

[stephencelis]

We shipped a few macros this week and have had about a dozen folks report this bug to us. Would be nice to have the issue triaged.

[DevYeom]

It seems that this issue has been fixed in Xcode 15.1 Beta 3.

[mbrandonw]

Hi @DevYeom, I am not able to confirm this. Both the example provided in this issue still fails to compile:

---

As does a simpler repro of the problem:

---

I am using Xcode 15.1 beta 3 (15C5059c) to test this. Can anyone else confirm that it is fixed?

[DevYeom]

I'm so sorry for my misleading.

The issue I had was not related to @Observable, but rather with the custom member macro I created.
The message I encountered was as follows, and it was resolved in Xcode 15.1 Beta 3.

Circular reference expanding member attribute macros on 'Something'

[oronbz]

With the amount of macros being utilized now by many libraries, including Apple's, this problem becomes much more prominent, and also very cryptic to even understand that the harmless extension is causing it. Hope it will get addressed.

[stephencelis]

It'd be nice to at least have some acknowledgement of the problem from the core team. While we understand that there are plenty of bugs out there that need attention and triage, this one has quite a bit of activity and reach, and was opened pretty promptly the week of WWDC23.

[hborla]

A class of these circularity issues were fixed by #67689, which is included in Xcode 15.1 Beta 3 where some folks are seeing their specific test cases resolved. However, the circular reference while resolving macro 'X' errors can be manifestations of slightly different circularity paths in the type checker, which is why other people are still seeing the issue.

[crayment]

Would love to see this fixed please!!

[stephencelis]

Checked the latest snapshot this morning and sadly this is still a problem!

Hopefully this gets fixed before the Xcode 15.3 + Swift 5.10 beta cycle completes.

[acosmicflamingo]

NOOOOOOOOOOO!!!

Posting this has worked in another open-source project, so maybe it will work here! If we all collectively pray to the patron saint of computer programming, Saint Isidore of Seville, perhaps it will be addressed very soon 🙏

[IanHoar]

Also experiencing this issue on Xcode 15.3, Swift 5.10

[rhysm94]

Still seeing in Xcode 15.3 and Swift 5.10, as well.

[mhelenurm]

Please give some love to this issue, Swift core team! ❤️🙏

[cmriboldi]

Yup this is a pretty bad one especially since it's a huge challenge for macros which make these extensions in the same file. It would be awesome to fix this one. Thank you in advance!!

[hborla]

This is fixed in #71365

[vanvoorden]

@hborla Awesome! Would you know if we planned to patch this on the 5.10 branch?

[vakhidbetrakhmadov]

@hborla , thank you very much for the fix ! 🙏
Do u happen to know what release this fix is planned to be included in ?
Would be very nice to get this fix out sooner :)

[acecilia]

Reading here and here:

confirmed that Swift 6 will be released this year, replacing the previously anticipated Swift 5.11
...
Swift 6 is set to launch in 2024, alongside Xcode 16 in September, marking the first major update since Swift 5's release five years ago. This update builds on the features introduced in the Swift 5.x series, such as async/await, existentials, and macros.

So seems like the fix will be in upcoming Swift 6, in September