That's true; the type UIUpdating itself would no longer be isolated. (UIUpdating itself was never actor-isolated. See correction below.) However, CounterView.intValue would still be @MainActor-isolated, because property declarations still infer their own isolation based on the property wrappers applied to that declaration. That inference just wouldn't bubble up to CounterView itself.
I believe it's rare that someone directly interacts with an instance of a property wrapper. But if you were doing something like this:
let x = UIUpdating(wrappedValue: 3)
print(x.wrappedValue)
the call to init would no longer still not be isolated, though the access of x.wrappedValue would.
I started going down the road of only warning when the behavior would actually change. However, I quickly realized that this would produce a warning on every SwiftUI view that uses @ObservedObject or @StateObject, because those views are currently isolated, and under this proposal will no longer be isolated. That could be mitigated if it were coordinated with an update to SwiftUI that makes SwiftUI.View itself MainActor-isolated, but that may come with other trade-offs that I cannot evaluate. Both of those property wrappers are used very commonly; this would be a very wide-spread introduction of warnings for pretty much all SwiftUI users. That's a lot of warnings, and would need a pretty high bar of justification in my opinion.
Since the argument of this pitch is that this inferred isolation is often unintentional, it may not be problematic for the isolation of the type to change. It's not clear to me that a warning is warranted in that situation. But I'm open to discussion!
Another possible route I considered would be to add details to errors produced in the Swift 6 mode, such that when an actor-isolation error occurs, we could check whether it would have been accepted under the Swift 5 rules, and if so suggest adding isolation to the containing type in that case. But even then, that feels overly broad; I think it would make more sense to suggest just adding isolation more locally to the error (i.e. annotating the containing function with @MainActor, rather than the whole type). And the compiler already produces that suggestion.
Yes, that would work. However, adding that via a fix-it suggestion from the compiler would be difficult, because we'd need to add a new declaration of an unused private global actor for every case where this happened.
That seems unlikely to be the right solution for an automated suggestion, so I probably wouldn't want to implement that as a compiler-suggested fix-it. But users could certainly do that on their own.
