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

[ConfusedVorlon]

Thanks for the detailed response @hborla

To some specifics:

Re documentation - beyond the point that documentation is important, I actually think running a process of generating accurate documentation would be immensely valuable to the team.

The act of figuring out how to communicate what swift does would force you to confront more directly the reality of the current situation.

I agree with you that the documentation is not the place for general style guides, or recommended patterns. However the behaviour should be fully described.

@hborla

Those improvements aren't covered by the vision document simply because those changes don't need an extensive review process like language changes do

I think you're missing an opportunity here. Technically this is of course true, but I think forcing documentation would add massive value to the review process by really bringing the the fore 'We're telling users do to what???'

Also - the reality is that while technically the language could be documented after release - that hasn't happened so far.

@hborla

Data-race safety is opt in today.

It is. Long may this remain so.

If the vision group were to publicly declare that they expect it to be opt-in for the forseeable future, then I would be much less concerned.

However - my fear is that as with other Apple changes, the new soon becomes mandatory. If not technically, then in practice.

@hborla

I know that a lot of folks have run into compiler warnings about Sendable violations when building with minimal concurrency checking when frameworks they use add @Sendable to completion handles, etc. Those are typically compiler bugs.

This is great. Again - I'd love to see an explicit statement about how much 'leakage' is expected/allowed from swift 6 to swift 5.
For example, I recently had to mark NSImage as Sendable to resolve a warning in swift 5 mode - where I'm explicitly using sendable in a way that I think should fix the warning.

Great to hear that this is (probably) a bug, rather than deliberate imposition on swift 5.

@hborla

@ConfusedVorlon

4) Update the framework/language to better 'play nicely' with concurrency/isolation

e.g. Extend codable so that it can work on a @MainActor struct/class

A solution to this problem is described in the vision document here.

I'm not 100% following what you're suggesting there, but if it allows me to conform to Codable with an isolated type (potentially calling async encode(to:) ) as appropriate - then I'll be a happy camper.

@hborla

The document isn't suggesting that programmers throw away existing uses of concurrency. The idea is that most executable code that isn't explicitly using concurrency is always running on the main actor in practice today. Having to annotate all of that code with @MainActor is not useful because that code is already safe.

I have to disagree on this.

1. By creating an 'easy' mode for the language - you're implicitly telling people to start in easy mode. So, you're throwing away a lot.
   That's an implicit admission that the language has failed to 'make basic use of concurrency simple and easy.'

2. I think explicit annotation is (generally) good.

The bottleneck for writing code isn't the typing part - it is the thinking part.
Explicit annotations make the thinking part clearer. Someone reading the code knows what they're looking at because it is explicit in the local context.

Of course - there is a balance to be had here, and tooling could make this explicit (green checkmark on any implicitly single thread files as an example approach)