You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unable to use DropboxClientsManager.authorizedClient with Swift 6
error: Reference to class property 'authorizedClient' is not concurrency-safe because it involves shared mutable state
you can find a warning: Reference to class property 'authorizedClient' is not concurrency-safe because it involves shared mutable state; this is an error in the Swift 6 language mode
We believe strict concurrency and swift 6 in general is still new and we'd like to wait to see what improvements can be made to specifically ease our use cases before we migrate.
We believe you should be able to use @preconcurrency to import our code and use it still. By doing this, you'll be taking ownership over ensuring all usages of our SDK are thread-safe, which we think was the intention when the code was written, given the global static variables. If you cannot do this for some reason, we'd love to hear about your use case so we can better understand the problem.
If we don't hear from you, we will still leave this issue open to be revisited later, as we agree that this work must be done at some point and it is important for the future of this library.
Activity
greg-db commentedon Dec 18, 2024
Thanks for the report! I'll ask the team to look into it.
jboulter11 commentedon Jan 17, 2025
Thanks for bringing this up with us!
We've taken a look at this and we'd like to wait to migrate our code to strict concurrency until we see improvements like the ones listed in the vision doc here: https://github.com/hborla/swift-evolution/blob/approachable-concurrency-vision/visions/approachable-concurrency.md
We believe strict concurrency and swift 6 in general is still new and we'd like to wait to see what improvements can be made to specifically ease our use cases before we migrate.
We believe you should be able to use
@preconcurrencyto import our code and use it still. By doing this, you'll be taking ownership over ensuring all usages of our SDK are thread-safe, which we think was the intention when the code was written, given the global static variables. If you cannot do this for some reason, we'd love to hear about your use case so we can better understand the problem.If we don't hear from you, we will still leave this issue open to be revisited later, as we agree that this work must be done at some point and it is important for the future of this library.