[Prospective Vision] Improving the approachability of data-race safety

[mattie]

No, you are right. If you absolutely require the decoding to happen off the main thread, then you need phase 3. But its a teeny tiny and very manageable bit of phase 3 - will you at least give me that?

[gwendal.roue (Gwendal Roué)]

Of course! And that's why I was not convinced by enabling the simplified mode in a whole module.

My point was that the need for parallelism comes very quickly in modern days (internet), and modern platforms (Apple SDKs).

[mattie]

Well, if I'm understanding right, it is just MainActor-default isolation. And I think that would be ideal for exactly this network decode situation and for many other of Apple's own SDKs.

[gwendal.roue (Gwendal Roué)]

@mattie

many other of Apple's own SDKs

"Many" is interesting, but it is not all. I prefer to push the design team into solving difficult problems. Staging language and SDK improvements is excellent, but skipping a few foreseeable steps is not wrong.

[mattie]

@xwu

However, there is another audience for which this document offers no vision, even as progressive disclosure and approachability are just as essential for them: users who are new to Swift concurrency features, but who have extensive experience with multi-threaded programming and an existing (perhaps very large) multi-threaded codebase. I doubt this is merely a transient cohort of folks, either, as interop is and will remain a tentpole feature of Swift and data-race safety remains a live area of exploration in other language ecosystems.

This is a really interesting point. I want to think more on it.

But the reason I bought up warnings earlier is I'm not sure this is actually what the feedback is about. Many, many people adopt Swift concurrency features incorrectly believing it works certain ways because they have the compiler feedback disabled. They progressively introduce more and more into their code base.

And then, only after they've gotten quite far, they turn on the warnings and realize they have a mess on their hands. At this point, I think it is quite natural to come to the conclusion it is the language that's the problem.

I think that situation is far worse than starting with a purely-GCD-based (for example) system.

[dima_kozhinov (Dmitry Kozhinov)]

@mattie

Many, many people adopt Swift concurrency features incorrectly believing it works certain ways because they have the compiler feedback disabled. They progressively introduce more and more into their code base.

And then, only after they've gotten quite far, they turn on the warnings and realize they have a mess on their hands. At this point, I think it is quite natural to come to the conclusion it is the language that's the problem.

I cannot speak for other programmers, as I don't know if they use Swift Concurrency the wrong way or turn on diagnostic too late. I can only speak for myself. And the thing is, Swift Concurrency safety in its current form does not allow me to write a single-threaded module that does not use Swift Concurrency at all. And when I call a spade a spade (not even call BTW, but politely wave my hat and ask to enlighten me whether we have a spade already), my post is being flagged as inappropriate. So yes, end users like me is the problem that needs to be fixed.