I have checked in in the strict-concurrency branch support for Swift 6.0 Strict Concurrency, it still has about 48 issues that need to be addressed.
Currently, the bulk of the problems are the shared public variable for singletons, as that one states that it might be a problem, so I will need a plan for what to do there - not with a blanket fix, but on a case-by-case basis because:
Clay mentions that "most of core/ must be thread safe", and also said that things like scenes are not.
There are a number of types there (like UndoRedo) that might have a thread safe API, but would do things that are inherently not thread safe.
Clay mentions that APIs that deal with the scene are not thread safe, that matches what I would expect of a UI toolkit due to their complexity
Plan
The original plan was to assume that everything was @MainActor bound, but I now think this is a bad idea. For example, it is possible to instantiate safely entire Node trees from a PackedScene in the background, but only attaching must take place on the main thread.
So perhaps we need to take a different approach here:
In other cases, it's as you say, even classes that are not thread-safe in principle can be safely used from an arbitrary thread as long as they don't interact with non-thread-safe objects being dealt with from other threads. The most promiment example would be Nodes; you can take a PackedScene resource and instantiate it so you have a tree of Nodes and you can do it on any thread. However, adding that to the scene tree must be done on the main thread or with some kind of sync mechanism.
I think that we can start by assuming that everything is @MainActor bound, unless we have a reason to expose the API to non-main actor users (ClassDB for example might be suitable for multi-threaded use, it lives in core, and sort of makes sense, but we need to validate this assumption).
The @MainActor for the class also has some cascading effects to a few other places, like generated thunk methods.
List of types in Core that have surfaced APIs to SwiftGodot
I have checked in in the
strict-concurrency
branch support for Swift 6.0 Strict Concurrency, it still has about 48 issues that need to be addressed.Currently, the bulk of the problems are the
shared
public variable for singletons, as that one states that it might be a problem, so I will need a plan for what to do there - not with a blanket fix, but on a case-by-case basis because:Plan
The original plan was to assume that everything was @MainActor bound, but I now think this is a bad idea. For example, it is possible to instantiate safely entire Node trees from a PackedScene in the background, but only attaching must take place on the main thread.
So perhaps we need to take a different approach here:
I think that we can start by assuming that everything is @MainActor bound, unless we have a reason to expose the API to non-main actor users (ClassDB for example might be suitable for multi-threaded use, it lives in core, and sort of makes sense, but we need to validate this assumption).The @MainActor for the class also has some cascading effects to a few other places, like generated thunk methods.
List of types in Core that have surfaced APIs to SwiftGodot