- What is your evaluation of the proposal?
+1 (with request for consideration of change below)
- Is the problem being addressed significant enough to warrant a change to Swift?
Definitely.
- Does this proposal fit well with the feel and direction of Swift?
Seems to, yes.
- If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Haven't.
- How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Read it through once moderately carefully. Thought about it in the context of teams I've been on.
I haven't done much with Swift Concurrency yet, so I'm reading it as someone relatively new to the topic and so potentially in the target audience for those with an older code base moving to Swift 6 and taking advantage of the new Swift Concurrency capabilities.
Feedback and addition/change request
Many teams I've worked on have the warnings-are-errors setting turned on as a policy.
When I read the workflow description in the Proposed Solution section, item (2) says (emphasis mine):
Start solving those problems. If they relate to types from another module, a fix-it will suggest using a special kind of import,
@preconcurrency import, which silences these warnings.
However, later in the @preconcurrency attribute on import declarations section it says (emphasis mine):
- If the type is visible through a
@preconcurrency import, the diagnostic is suppressed (prior to Swift 6) or emitted as a warning (in Swift 6 and later).
Seems like this second part is going to be a problem for the errors-as-warnings teams, and also seems counter to the Proposed Solution section.
In particular, teams which dictate errors-as-warnings turned on who want or need to upgrade to Swift 6 but need to use the helpful @preconcurrency annotation this proposal provides to annotate modules that haven't been updated yet will find that their build will fail and their CI will yell at everyone because of the warnings. Seems like that's going to get in the way of using this nice migration path this proposal is creating.
For these teams it would be useful to be able to disable those particular warnings (only the ones that are generated as downgraded errors because of the @preconcurrency annotation) while retaining warnings/errors for anything not shielded by the @preconcurrency annotation.
Thank you to all involved for all the hard work on Swift Concurrency and this effort towards making the transition manageable for those with existing code bases.