I’ve been browsing the Swift Forums for something the other day that was related to sendability of NSItemProvider. I found this reply by Holly Borla – the question doesn’t matter much, I promise:

Holly Borla (2024-10-14):

In this example, the non-Sendable values are captured in isolated Task closures, which should be considered a region merge under region-based isolation, which should prevent the nonisolated async function from being called. I still believe my answer on that GitHub issue is correct. It is safe to call a nonisolated async method on a non-Sendable type if the caller is already on the generic executor, or if the non-Sendable value is in a disconnected region.

If you’re still adapting Swift Concurrency and Swift 6’s strict mode, you may be as surprised as I was: After 10 years with this language, how could I understand so little on the language’s forums? Am I not an expert…?!

Calming down, here’s how I tackled this problem. It’s a very short reply, that was great. It’s dense with vocabulary I didn’t know. It showed how people ‘speaking that language’ used these terms in sentences. So to become one of them, I merely need to understand what they did and copy it.

Extracting the vocabulary:

• isolated Task closures
• region merge
• (region merge under) region-based isolation
• nonisolated async function
• (being on) generic executor
• disconnected region

Now in my Zettelkasten, I literally did this, and created a note with this content:

Holly Borla (2024-10-14):
https://forums.swift.org/t/calling-non-isolated-async-method-from-a-child-task-inheriting-global-actor-allows-for-a-race-condition-in-swift-6/75332/6

> In this example, the non-Sendable values are captured in isolated
> Task closures, which should be considered a region merge under
> region-based isolation, which should prevent the nonisolated async
> function from being called. I still believe my answer on that GitHub
> issue is correct. It is safe to call a nonisolated async method on a
> non-Sendable type if the caller is already on the generic executor,
> or if the non-Sendable value is in a disconnected region.


- isolated Task closures
- region merge
- (region merge under) region-based isolation
- nonisolated async function
- (being on) generic executor
- disconnected region

That’s it. It’s not magic.

But it’s a roadmap to becoming a better developer who can speak ‘Swift Concurrency’ more fluently. It doesn’t help me fix that everyday sendability problem right away, but in the long term, it will help me understand why the compiler complains, and create my own mental map.

I’m sharing this before I progress on this journey for absolute transparency in the process.

Here’s what I’m going to do:

1. Collect. For each item on the list, I’ll try to find articles, forum posts, documentation entries. Also looking up the Swift language book chapters and maybe language grammar entries for later. Swift Evolution propsals, too. Definitely Matt Massicotte’s blog. This is like a University library research: go wide, go quickly, screen for potential use but don’t spend a lot of time on each item immediately. Screening the material will take a while still, and I will probably pick up context clues along the way involuntarily. The result: many, many links in a (nested) outline.
2. Review: Go through all items with more care. The context clues picked up in step 1 will help feel my way through relevancy and spot absolute surprises (things I haven’t even glanced over in the past, that are absolutely unfamiliar). – This is where I’ll be taking more notes as I decide which material to keep and cite. The result: fewer links, more literature manager entries (the keepers), quotable passages and shorthand writing by myself to excerptize, summarize, explain things a bit.
3. Systematize: Create more notes for each topic, for each concept. Create overviews. A random example: “isolated Task closures”, I’ll want to link to “Task”, I’ll want to link to the concept of “isolation”, and also check whether “closure” is just a Swift closure/lambda, or if “Task closures” mean something different in this context. Then find the opposites in this process: isolation implies non-isolation; if there are Task closures, are there other units that can be isolated that are not closures?

That approach works well with many foreign concepts and environments. I’ll keep you posted about this concurrency stuff.