@Sendable function conversions seem unnecessarily restrictive

[mattmassicotte]

Description

I cannot see a scenario where these conversions could actually introduce races. My guess would have been that you could never form these functions in an unsafe way in the first place. Maybe I don't see it, but I thought it was at least worth a bug report.

Could it be that the @Sendable-ness is not being taken into account?

Reproduction

class NonSendable {}

let a: @Sendable (NonSendable) -> Void = { _ in }
// warning: Cannot convert '@Sendable (NonSendable) -> Void' to '@Sendable (NonSendable) async -> Void' because crossing of an isolation boundary requires parameter and result types to conform to 'Sendable' protocol
let b: @Sendable (NonSendable) async -> Void = a

let c: @Sendable () -> NonSendable = { fatalError() }
// warning: Cannot convert '@Sendable () -> NonSendable' to '@Sendable () async -> NonSendable' because crossing of an isolation boundary requires parameter and result types to conform to 'Sendable' protocol
let d: @Sendable () async -> NonSendable = c

Expected behavior

I think both of these should build warning-free.

Environment

Apple Swift version 6.3-dev (LLVM f6e8f31819e2e67, Swift cecebdd)

Additional information

No response

[jamieQ]

this appears to be a change introduced in 6.2 by the logic here. seems it'd be easy enough to skip that check in the case that the source function is @Sendable (draft PR of such a change: #86210)... @xedin @hborla does that seem like a sound thing to do?

thinking about it a bit... if the source and target of the conversion are both nonisolated (in the @concurrent sense), and the source is @Sendable, then either converting sync to async or dropping the @Sendable annotation seem like they should be fine, regardless of whether the parameters or results involve non-Sendable types.

[xedin]

The rules are outlined in https://github.com/swiftlang/swift-evolution/blob/main/proposals/0461-async-function-isolation.md#function-conversions. The rule is that if arguments/results are crossing an isolation boundary they have to be sendable.

[mattmassicotte]

The outlined rules make a lot of sense, however, I think this proposal could be missing coverage of the specific scenarios here.

[jamieQ]

the current implementation seems at least a bit inconsistent because you can effectively perform these conversions 'manually' by writing out the appropriate thunks yourself:

open class NonSendable {}

@Sendable
nonisolated func fn() -> NonSendable { NonSendable() }

nonisolated func test() {
    let syncToAsync: @Sendable () async -> NonSendable = { fn() } // ✅
    let dropSendable: () async -> NonSendable = { fn() } // ✅
}

i don't really follow why these cases would constitute isolation boundary crossings... the function type's isolation would seem to be the same after the conversion, and the set of contexts in which the function may be called would become smaller in each case.

[xedin]

I might be too conservative to treat non-async nonisolated functions the same as async functions when it comes to conversions because they’d be indeed called in the context of the “to” function but the result type would still cross isolation boundary when returned, same with arguments.