[Pitch] Inherit isolation by default for async functions

Evolution Pitches
35

  1. I agree with @Alejandro_Martinez that the non-sticky model was brilliant. I also agree that it is taking a while to internalize, but once I wrapped my head around it, I came to see its benefits. (Although I am not at all an expert, I wrote a little more about this here.)

  2. There is a lot of talk of performance concerns on both sides of this issue. Are there hard numbers anywhere that measure any aspect of this? For example, how expensive are context switches / hops in the grand scheme of things? I don’t have examples at hand right now, but I feel like the subject of context switches / hops always comes up in topics like this, but often in opposing ways! In other words, last time a change came through that potentially increased hops, there was plenty of input opining that hops are relatively negligible / can be elided by the runtime / etc. Now that we are considering this change, hops are the enemy again. Which is it? :stuck_out_tongue:

  3. If I understand the motivating example at the top of the pitch correctly, this is a very simple usage (non-sendable reference type inside an actor) that breaks data-race safety assumptions in a big way. Changing the convention of nonisolated functions seems to be one way to fix this particular construction, for sure. But to me this example, assuming I understand it, suggests more that the model itself is broken. Specifically, it shows that isolation does not compose in a meaningful way. This is a bummer but personally I am already somewhat used to some Swift features not composing as well in cases where they are used with reference types (property observers, @ObservableObject, etc.) as when they are used with value types. To me this usage is no different and if I wanted to fix it I could just pass an isolation to the nested object, right?

  4. I feel like this new construction may place too much emphasis on actors. actor instances are — and to be clear I am open to being wrong — the trickiest part of designing systems in the Swift Concurrency world, for me. They seem like they should be great, but I am not yet comfortable with how isolation and “responsibility” (in the OO sense) are conflated for actor instances. One benefit of the current nonisolated is that it’s easy to get “dispatch-like” concurrency in a system by using nonisolated alone, without having to redesign one’s object graph. Personally as an actors skeptic, I like this. I’m not sure how designing such systems would work after this change — would using actual actor instances be the right way to get back to a world where concurrency / “backgrounding” was always “at hand”?

1 Like