SE-0431: `@isolated(any)` Function Types

[Jon_Shier]

I like @isolated exactly because it takes a parameter. If Xcode could autocomplete in there I could see it being easier to learn, since you only need to remember isolated, which is used in other ways, and not all the types of isolation. Swift already has tons of keywords, so parameterizing one seems much nicer than creating slightly different variants. And I think your point in the example is well taken, dropping the @ would be confusing (at least, to anyone who knows the difference between parameter and type modifiers).

[Douglas_Gregor]

@John_McCall

If we want to avoid both of these problems, I think the best approach is to use a different spelling entirely. We can still have isolated in the name in order to make the attribute more self-documenting, but we should try to avoid making it look like the existing modifier. That would suggest something like @dynamicallyIsolated. If we introduce other isolation-controlling attributes in the future, we can follow that same pattern with e.g. @callerIsolated.

Hrm. Having this whole "zoo" of Isolated-suffixed new attributes is probably worse than the @-or-not confusion with @isolated. I suppose we could address this with tooling to help you add or remove the @ as appropriate.

Doug

[Nickolas_Pohilets (Nickolas Pokhylets)]

I do like @isolated(any) exactly because it paves the way to value-dependent value isolation. And existing isolated-params, are a limited form of value-dependent isolation. So, IMO, in the long-term we should be aiming at depreciating isolated arguments, global actor attributes and other limited tools, with a more universal @isolated(arg) syntax.

E.g, func foo(param: isolated MyActor) should become @isolated(param) func foo(param: MyActor).

But this looks weird, because @isolated(param) refers to param before it was declared. So maybe this should be among effects, and not attributes?

func foo(param: MyActor) isolated(param) throws(MyError) async -> Bool {
    …
}

[wadetregaskis]

@Nickolas_Pohilets

But this looks weird, because @isolated(param) refers to param before it was declared.

I don't think it looks weird objectively; I think this is just something you'd get used to, easily. The function can only be isolated to one parameter (as far as I understand it?) so at most you have to remember one [parameter] name as you're reading left-to-right.

Putting it after is technically fine too, but makes the ergonomics harder because it's more awkward to line wrap after the parameter list.

Either way, I think this makes way more sense than the current isolated parameter modifier, as this isolation requirement is a function-level attribute, not a parameter-level attribute, and a particularly important one at that - so it makes a lot of sense to have it declared more prominently and in a more predictable place in the grammar.

[stephencelis]

I pulled down a recent development snapshot to take this for a spin, but even with the experimental feature enabled I can't seem to access the closure.isolated parameter. Is there a different syntax being used in the implementation?

[jamieQ (Jamie)]

it's not clear to me from the proposal in exactly which contexts one should expect that new value to be accessible, but the following appeared to work locally (4/21 dev snapshot):

let op: @isolated(any) () async -> Void = { @MainActor in
    // ...
}
print(op.isolation ?? "nil") // Swift.MainActor

[hborla (Holly Borla)]

@stephencelis

I pulled down a recent development snapshot to take this for a spin, but even with the experimental feature enabled I can't seem to access the closure.isolated parameter. Is there a different syntax being used in the implementation?

The syntax is .isolation, not .isolated. Does closure.isolation work for you?

[Douglas_Gregor]

Thakn you for the great discussion everyone, this proposal has been accepted with modification to remove @Sendable inference.

Doug