TIL that isolated parameters are thing: https://www.massicotte.org/isolated-parameters

(As usual when I learn about a new Swift syntax, a SwiftFormat update will probably be required šŸ˜…)

Isolated Parameters

I’ve been using Swift concurrency a lot over the past year or so. And I’m a bit embarrassed to say that I haven’t used isolated parameters at all. I knew they existed, and I read about them a little. But I never understood why you might use them or what problems they solve. That is, until I read this post by Jack Morris. It’s part of a series he’s been doing on a SQLite interface. There’s lots of interesting stuff in there.

massicotte.org
@nicklockwood I do like that this gives you the ā€œalgebraicā€ free function equivalent of `extension MyActor { func doThing() }` but I’m also not really sure I’d ever use isolated parameters over the easier syntax!

@rhysmorgan IIUC because it's a parameter it allows you to write a function that can be executed on any actor, as determined by the caller.

Extending a particular actor wouldn't give you that flexibility (unless you could do it by extending a protocol that multiple actors conformed to - would that work?)

@nicklockwood @rhysmorgan Yeah it’s not the same, just similar.

But just wait until this proposal is accepted. They will become super powerful and I bet will be commonly used

https://forums.swift.org/t/pitch-inheriting-the-callers-actor-isolation/68391

[Pitch] Inheriting the caller's actor isolation

Hi. One problem we've been seeing with Swift concurrency is that there isn't an easy way for async functions to polymorphically share their callers' actor isolation. This makes it hard to use certain kinds of async abstractions from isolated contexts because technically the async functions in the abstraction have a different isolation, which means e.g. you can't share non-Sendable values with them. It also can have unwanted performance consequences. I've written a proposal which adds a handf...

Swift Forums