The Swift 5.6 betas have implemented SE-0302, turning on Sendable warnings in any code that has adopted concurrency. These warnings are still too noisy and require more tuning in the compiler, so I've disabled most of them for the Swift 5.6 release. This makes the default set of warnings for Swift 5.6 similar to that of Swift 5.5, although under the hood 5.6 is much closer to the model we want, and folks can explicitly request Sendable-related warnings with -warn-concurrency.
We'll continue to refine the checking with Swift 5.7 and try again for SE-0302 there.
Being open about this backsliding is much appreciated.
While I don’t disagree that they have been annoying (in significant part due to SDK adoption), this is a shame for incremental adoption.
The behavior in the beta has been helping my team plan out actionable, short-term improvements for preconcurrency code that was already involved with Swift concurrency.
-warn-concurrency is not particularly livable in 5.6. Some issues it surfaces are also fixable only with SDK adoption; some of them even surface as errors; some further are errors that are not fixable(!).
It’s probably not tractable in the near term, but it would be nice if warnings for code that already adopted concurrency (like the Sendable checks) were available under a different flag, or if -warn-concurrency had levels.
You can still get some of the benefits by, e.g., marking your own types as Sendable or not, which will trigger warnings for any of their non-Sendable instance storage. It's certainly not as comprehensive as the full suite of warnings.
-warn-concurrency might not be the right name; it's applying stricter logic for concurrency-related checks across the entire module, not just in code that has "adopted concurrency."
If it's wrong, or if the errors are indeed not fixable, please file bugs so we can improve it!
I'm hesitant to do this because each "level" flag is essentially its own dialect. I'd consider adding a new level in between "default warnings" and "-warn-concurrency" to be a fallback plan if the default warnings cannot be made to be more focused and actionable in a reasonable time frame.
Right, I understand. Being such a wide superset is the problem I was alluding to: that it also opts you into checks for all code — including things a team may not be ready to fix, able to fix, able to validate a fix for — means it’s going to be difficult to defend leaving it enabled, so you lose out on any of the possible benefits. Other than that, I agree with erring on the side of avoiding dialects.
I certainly will.
It’s been like the early days of optional audits. I can’t say I’ve found much with -warn-concurrency that’s seemed totally broken on the language side. (Speaking solely for myself, of course. ) Just that there are times where the language side is working very precisely based on some inaccurate information from, say, under-audited SDK headers. Anyway, baby steps. Thanks again!
) Just that there are times where the language side is working very precisely based on some inaccurate information from, say, under-audited SDK headers. Anyway, baby steps. Thanks again!