RE: Stored Property Isolation on SE-327

Evolution Discussion
1

The evolution changed the ability to make a lot of default value properties require to instead be initialized inside an initializer. It gives the following example clarifying why, and it makes sense to me why this wouldn't work:

@MainActor func getStatus() -> Int { /* ... */ }
@PIDActor func genPID() -> ProcessID { /* ... */ }

class Process {
  @MainActor var status: Int = getStatus()
  @PIDActor var pid: ProcessID = genPID()
  
  init() {} // Problem: what is the isolation of this init?
}

However, I'm in a situation where I have a lot of code that is much more like this and getting the errors:

@MainActor func getStatus() -> Int { /* ... */ }
@MainActor func genPID() -> ProcessID { /* ... */ }

@MainActor
class Process {
  @MainActor var status: Int = getStatus()
  @MainActor var pid: ProcessID = genPID()
  
  init() {} // shouldn't this init be restricted to @MainActor through the class's declaration? 
  init(alternate: Bool) {} // I'd rather not have to copy all my properties' inits here too
  init(alternate2: Bool) {} // nor here
}

I'd even be fine restricting the init to @MainActor explicitly. I see no reason why, in this scenario, I should have to move all my default properties into the initializer, when the entirety of the class is restricted to the @MainActor.

It might be worth mentioning that most of the code like this is UI, so being able to constrain to the MainActor is a godsend.

I apologize if I'm missing something obvious. I just feel like the Swift compiler should be smart enough to recognize that this class's properties need to be synthesized on the same actor as the rest of the class, especially when I am explicit about it.

4 Likes
2

Have you tried the latest toolchains off of main? Does activating the global @MainActor isolation using -warn-concurrency help at all here?

3

I have not. To clarify, by trying the latest toolchain off main, do you mean to clone, compile, then set Xcode to use that toolchain instead of what's included? Cuz I'm unsure how to do that (but am more than capable of finding some guide)

Also, I'm unsure how to do this as well and would be unsure of where to look for how to do so:

Does activating the global @MainActor isolation using -warn-concurrency help at all here?

4

No, I mean downloading the latest main toolchain from swift.org and using it through Xcode.

However, from what I've seen it doesn't help, so no real need to try again.

1 Like
5

I'm having this exact same issue. Currently sitting with about 800+ of these warnings and moving all of the property setting to the init seems a bit excessive. We've thought about moving all of the properties to lazy private(set) var.

1 Like
6

Interesting workaround, but I really don't want to lose the immutability/safety of a constant either.

edit: this is re: @michaeldwilliams - unsure why it didn't show that in the post's metadata

7

I should probably just learn how to do that anyways. This will give me a good reason to test that!

8

FYI: looks like the team reverted this

9

Oh wow! That's good to hear they are looking to revise (I assume based on community feedback)!

10

I can't find any discussions about the reverted change. Is there any indication as to when we will see these changes? Will it be a hot fix to 5.6 or will we have to wait for 5.7 to rid ourselves of these warnings?

I'm also curious as to the "important workflows" that were broken mentioned in the PR.

If anyone has any insight to this, would be greatly appreciated!