Clarification needed on UnsafeContinuation documentation

That seems to be better suited to be communicated with Apple's feedback mechanisms - doesn't have that much to do with Swift itself, as it has to do with feedback on how release notes for Apples proprietary tools (Xcode and SDK:s) are decided and generated. (even though I agree it is important feedback, I don't think it is fair to call out an individual engineer to answer for what is likely a process problem and defend that in public - at least what it looks from the outside). I'd file a Feedback (and possibly post the reference to it to allow for follow up by individual engineers who might want to give more feedback internally at Apple).

5 Likes

I asked when this bug will be fixed. According to this answer the bug is specific to Xcode 14.0.x, the bug is fixed in Xcode 14.1 beta, and the bug will remain fixed in the future Xcode releases, 14.1 and forward.

Yes, because the bug is caused by the interplay of the Swift 5.7 compiler with the Swift 5.6 standard library's module interface. It will "fix itself" with Xcode 14.1 because 14.1 will ship with the macOS 13 SDK, which will contain the Swift 5.7 standard library's module interface.

I understand your position, but I disagree.

This issue very much pertains to the Swift open source project because Xcode is the way Swift is distributed on Apple platforms. You pretty much have to use Xcode to use Swift on macOS. I find it very disturbing that the current official Swift release generates wrong code on one of Swift's most important platforms and that neither Apple nor the Swift team are communicating this prominently.

A big red warning in the release notes is the minimum I’d have expected. Even better, the warning should be directly in Xcode, or Xcode 14.0 should outright refuse to build macOS targets that use concurrency.

Xcode 14.0 was released a month ago, and if the rumors are true, it will be another ~2 weeks until we see Xcode 14.1. That means people will have been building and releasing Mac apps with a broken compiler for ~6 weeks.

I want this discussion to be in the open. In my view, not much is gained by my filing private feedback. (Plus, I admit that I'm not willing to participate in Apple's dysfunctional — to outsiders — feedback process if I can help it.)

I apologize to @John_McCall for calling you out individually, which wasn't my intention. I understand if Apple folks don't want to or can't have this discussion in public, but I'd love to be proven wrong.

15 Likes

I wholeheartedly agree with Ole. This needs to be discussed in public.

4 Likes